You are not logged in.
After update from 3.13 to 3.14 boot stops just after the "Booting the kernel" message appears. No other diagnostic messages appear on screen even with debugging turned on. Downgrading to 3.13 and the system boots again. Does anyone else have the same issue? Any ideas on how to dissect the problem? My bootloader is syslinux and mkinitcpio seems to produce no error. In mkinitcpio.conf MODULES, BINARIES, FILES are empty (""). Hooks is:
HOOKS="base udev autodetect modconf block filesystems keyboard fsck"
cpu: i5-4670, built-in graphics, arch 64-bit, mb: gigabyte b85-hd3
UPDATE: This only seems to happen on this pc. The other two PCs with arch (phenom x4-955, gigabyte ma790xt-ud4p and celeron 847, gigabyte ga-c847n) seem to boot as normally. If anyone has the same problem, what are your specs?
Last edited by Foucault (2014-04-10 16:59:46)
Offline
I'm having exactly the same problem and interest for finding out the reasons for it. For now I also just downgraded the kernel to continue working with my main rig, but I might update again if there's good suggestions posted about troubleshooting.
Arch x86_64
Cpu: Intel i5-4670K
Mobo: Gigabyte Z87P-D3
Gpu: GeForce GTX 760
EDIT: added specs
Last edited by Maty (2014-04-10 17:10:14)
Offline
Same issue here, downgrading to 3.13 fixed it aswell.
The issue is not present on my Laptop which is apart from the hardware identical to my main PC.
Offline
+1
Same issue both with standard and fallback presets.
Downgrading to 3.13.8 fixes the issue (or falling back to linux-lts).
I do not see the problem on my celeron laptop, only on my i7-4770k desktop pc.
Offline
One of the differences between the two computers I have apart from hardware components is that :
1. the "booting one" uses grub uefi
2. the "not booting one" uses grub mbr...
Is this also the case for you guys?
Offline
I am using syslinux gpt/bios on all my machines. Only the 4670 exhibits the issue. So far all of us have a Haswell chip.
Last edited by Foucault (2014-04-10 19:30:17)
Offline
Mine is a Haswell aswell! My laptop (not haswell) boots ..
Offline
I haven't been able to boot 3.14 since it came into [testing]. I use a different init system which gives me useful output during boot and here it is during mounting that the hang happens. I don't have a haswell chip.
You're just jealous because the voices only talk to me.
Offline
I am wondering if this is a regression that affects the cpu or the chipset (both maybe?). So far it seems that it affects haswell chips. I opened a bug report https://bugs.archlinux.org/index.php?do … k_id=39811
Offline
I haven't been able to boot 3.14 since it came into [testing]. I use a different init system which gives me useful output during boot and here it is during mounting that the hang happens. I don't have a haswell chip.
I am not entirely sure this is the same issue. My problem is that system does not start to boot *at all*. It just decompresses the kernel and halts. No signs of activity. It does not even reach the point at which the disks are about to be mounted. Even adding "debug" in the kernel cmdline does nothing since the kernel does not execute at all.
Offline
Same problem here. 3.13 is working, 3.14 not.
Hardware:
CPU: Xeon E3-1275 V2
Board: Supermicro X9SAE-V
GPU: integrated
Bootloader: grub-efi
Hardware, that is working:
Lenovo Thinkpad X230
Offline
Seems to be the same here.
CPU 4670k
Mobo Gigabyte Z87X
Graphics: nvidia gtx760
Boot sequence: uefi --> grub --> arch64
Could I get some insight with chicken-egg problem I'm having?
Upgraded "linux" AND "nvidia" today. Boot hangs on the following mssg: "Loading intial ramdisk..."
Based on above, I'm trying to downgrade "linux" kernel from 3.14 to 3.13.8
After chroot
# pacman -U linux-3.13.8-1-x86_64.pkg.tar.xz
error: failed to prepare transaction (could not satisfy dependencies)
:: nvidia: requires linux>=3.14
Ok. Based on above mssg, I'll downgrade nvidia 1st to the previous version.
# pacman -U nvidia-334.21-2-x86_64.pkg.tar.xz
warning: cannot resolve "linux<3.14", a dependency of "nvidia"
:: The following package cannot be upgraded due to unresolvable dependencies:
nvidia
:: Do you want to skip the above package for this upgrade? [y/N] N
error: failed to prepare transaction (could not satisfy dependencies)
:: nvidia: requires linux<3.14
How to resolve/approach? Thanks
PS: Namarrgon helped on IRC and directed me to this post (just giving credit for helping).
Edit: formatting
Last edited by zeek (2014-04-10 23:11:56)
Offline
zeek, just combine them in a single command: "pacman -U nvidia-334.21-2-x86_64.pkg.tar.xz linux-3.13.8-1-x86_64.pkg.tar.xz". I had just the same situation.
Offline
Maty
Thanks for the quick reply. Worked.
Makes sense.
Will use the following (for a while, at least):
# pacman -Syu --ignore linux,nvidia
Also, from now on: will upgrade kernel and nvidia separately.
Again: Thanks
Last edited by zeek (2014-04-11 02:09:16)
Offline
Hi,
The problem is still there after the linux kernel update 3.14-4 -> 3.14.1-1...
I guess the better option is booting with linux-lts for a while.
Offline
Hi,
The problem is still there after the linux kernel update 3.14-4 -> 3.14.1-1...
I guess the better option is booting with linux-lts for a while.
Look at the comments in the bug-report.
Most people (including me) have Gigabye boards and a BIOS upgrade resolved the problem and we can boot the new kernels.
Offline
Thanks for the tip! I also have a Gigabyte motherboard, so I'll look into it.
Offline
My Gigabyte H87N-WIFI with newest bios version F5 do not boot linux 3.14.1-1 with EFISTUB Sorry for my little english
Offline
Try to boot your kernel with acpi=off or acpi=rsdt to see if it helps.
Offline
Try to boot your kernel with acpi=off or acpi=rsdt to see if it helps.
It did not I have now no time to further testing.
Offline
Try to add earlyprintk=vga,keep to your kernel command line. See if it prints any acpi related stack trace. In my case I got this message
? acpi_find_root_pointer+0x116/0x158
? early_idt_handlers+0x120/0x120
acpi_initialize_tables+0x57/0x59
acpi_table_init+0x1b/0x99
acpi_boot_table_init+0x1e/0x85
setup_arch+0x992/0x452
? early_idt_handlers+0x120/0x120
x86_64_start_reservations+0x2a/0x2c
x86_64_start_kernel+0x13e/0x14d
Code: 00 00 00 41 bd 04 00 00 00 e0 54 73 9f ff 48 c7 c2 74
81 48 89 c1 be 00 02 00 00 48 c7 c7 b0 c0 64 81 31 c0 e8 20
a6 9f ff <41> 8b 5c 24 10 be 24 00 00 00 48 89 df e8 64 23
bb ff 48 85 c0
RIP acpi_tb_parse_root_table+0x120/0x2d2
RSP
You can also try applying this patch on top of 3.14.1 to see if it helps. Or use this source tarball and makepkg -sf.
Offline
same issue here.
After I upgrade my arch system from kernel 3.13.8-1 to 3.14.2-1 ( [2014-05-04 11:26] [PACMAN] upgraded linux (3.13.8-1 -> 3.14.2-1) ),
when I boot arch in grub, no any diagnostic messages appear on screen, just black screen for a long time.
Then I made a live USB with the latest ISO arch_201405 and tried to boot into live environment, BUT FAIL, just like above I have mentioned --> black screen and nothing happen.
So I go to download the previous version ISO image(arch_201403) on http://hkg.mirror.rackspace.com/archlin … 014.03.01/
I can boot into the live environment this time and chroot to my existing system to downgrade the kernel by following command
pacman -U linux-3.13.8-1-x86_64.pkg.tar.xz linux-headers-3.13.8-1-x86_64.pkg.tar.xz virtualbox-host-modules-4.3.10-1-x86_64.pkg.tar.xz
and my system can boot again.
my PC specs:
motherbroad: gigabyte GA-P55A-UD3
cpu: i5-750
display: ati 5750
os: arch 64bit
Last edited by samtai (2014-05-04 07:58:00)
Offline
The xsdt patch is incorporated in 3.14.2 so it should not exhibit this issue (it fixes the problem on my affected computers) so I am not entirely sure this is the same issue. You can try adding earlyprintk=vga,keep on your linux boot entry in your bootloader to see if it prints any messages related to acpi and/or xsdt. Also try to see if you can boot the kernel with acpi=off or acpi=rsdt.
Also the affected BIOSes (sic!) are american megatrends version F2, F3 and F4. You can try updating your BIOS if the problem persists.
On a semi-related note, you can also have linux-lts installed as a fallback kernel so you do not have to chroot from the live usb every time something nukes the mainline kernel.
Last edited by Foucault (2014-05-04 09:56:46)
Offline
The xsdt patch is incorporated in 3.14.2 so it should not exhibit this issue (it fixes the problem on my affected computers) so I am not entirely sure this is the same issue. You can try adding earlyprintk=vga,keep on your linux boot entry in your bootloader to see if it prints any messages related to acpi and/or xsdt. Also try to see if you can boot the kernel with acpi=off or acpi=rsdt.
Also the affected BIOSes (sic!) are american megatrends version F2, F3 and F4. You can try updating your BIOS if the problem persists.
On a semi-related note, you can also have linux-lts installed as a fallback kernel so you do not have to chroot from the live usb every time something nukes the mainline kernel.
Thanks for your advise.
I will follow your suggestion when I perform upgrade next time if this problem appear again.
But this is weird because my PC cannot boot into live environment with the latest ISO image (arch_201405).
Offline
My Gigabyte H87N-WIFI with bios version F7 do boot linux 3.14.4-1
Offline