You are not logged in.
I have two computers that stopped booting today after doing updates. The updates included linux-4.2.5 and nvidia-304xx-304.128-4. The boot process stops at Loading initial ramdisk...
I arch-chrooted in and regenerated grub.cfg but no help.
Is anyone else having similar problems? Any advice would be appreciated.
Last edited by kekules_dream (2015-11-01 21:13:38)
Offline
I had tried rebooting from the fallback image. Now I went ahead with regenerating the initramfs. Unfortunately neither of these made any difference. I see grub trying to start, then I see:
Loading Linux linux...
Loading initial ramdisk...
But then, nothing happens. Strange it happened to two computers.
Offline
What is in the journal for one of these failed boots?
Offline
I'm having trouble determining that.
journalctl -b
gives No entries
and
journalctl -b -1
gives information for the last good boot before the updates that caused the trouble. I don't understand that because I obviously booted the machine today and did the updates.
Offline
For rescue, I was using the Arch Linux disk from May 2015, which used the 4.0.1-1 kernel. So I downloaded the new Nov 2015 disk, which includes kernel 4.2.5. Checked the sums of the file and even the md5sum of the burned disk. All good.
This disk could not boot my WIFE'S computer (you can imagine the climate here). It gave a kernel panic.
Booted again from the May disk to get:
cat /proc/cpuinfo
AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
Using the May disk, I installed the lts kernel, which Is 4.1.2, but the boot process stopped in the same place with it also.
This doesn't make sense to me though, because when I checked the pacman.log, I see the the computer was booting fine with linux-4.1.5 from August until yesterday when I upgraded from 4.1.5 to 4.2.5.
Offline
What's happening after the 'Loading initial ramdisk'? Does the screen turn black but computer keeps running? If that's the case try booting with the nomodeset option which helped me with my nvidia card.
Offline
Thank you for your suggestion. No, the screen does not turn black on either affected computer. the following shows and stays:
Loading Linux linux ...
Loading initial ramdisk ...
After adding nomodeset, then I see
Booting a command list
Loading Linux linux ...
Loading initial ramdisk ...
and it stays, visible. Although I initially thought it might have something to do with the nvidia 304xx driver, I now doubt that since I can't boot from the Nov 2015 installation CD.
Offline
If reverting to last working kernel doesn't help, I'd imagine either systemd or grub is causing your issue.
If you don't have HOOKS="systemd" in your mkinitcpio.conf, and you aren't seeing any kernel boot messages (even without 'quiet' kernel boot flag), I'm pretty sure it's the latter.
I vaguely remember having similar issue that was caused by some syslinux update, and reverting to previous version made my system bootable again.
I haven't owned a nvidia card for years though, so I don't know if proprietary drivers could be causing this. Although if you haven't bundled the nvidia kernel module in your initramfs, I don't see how that could be the case.
Offline
I had this before when using an old version of UEFI GRUB on a USB stick. I fixed it by just updating grub and then re-installing it. Something along the lines of:
ONLY if you are using UEFI
# pacman -S grub efibootmgr
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub --recheck
# grub-mkconfig -o /boot/grub/grub.cfg
Your efi-directory might be just /boot especially if you followed the Arch wiki when setting up.
ONLY if you are using BIOS
# pacman -S grub
# grub-install --target=i386-pc /dev/sda
# grub-mkconfig -o /boot/grub/grub.cfg
Where /dev/sda is your boot disk
Offline
Hi all
I have the same problem, on the only computer of the house (and my wife isn't happy either !)
I upgraded monday evening, saw Linux was getting updated, but didn't pay attention to the version and didn't reboot afterwards to check. [Edit : I remember I checked nevertheless that there was no warning message during the mkinitcpio build, as I do every time.] The next morning my wife reported that it didn't boot anymore. The symptoms are exactly the same (except the messages are in french, but that's not relevant). The fallback initramfs produces the same effects, as does an old initramfs that was there in my /boot.
My processor is also an Athlon 64 X2 Dual Core but my graphics card is an ATI, not nvidia. I guess the problem must come from the linux update, which is certainly 4.2.5 version according to this thread.
I couldn't find a working bootable disc yesterday but now I'm worried that the 2015-11 that I just burned may not boot, as it happens for kekules_dream... maybe I'll also burn a less recent disk, like 2 or 3 months old, just in case. But I see that kekules_dream still couldn't fix his computers even with a working disk, so I think I might be stuck the same way.
I really hope someone can help us ! I'll post tonight's results as soon as I can.
Thanks
Last edited by gdeshors (2015-11-04 10:01:10)
Offline
It seems I have the same issue also. I updated yesterday and today, when I booted up, same thing, blank screen just after grub.
intel corei5 and nvidia GTX670.
I am quite a newbie so I tried whatever I could find here and there.
Booted with arch install boot disk, chrooted, pacman -Syu, updated to the latest. Removed whatever I installed yesterday (xboxdrv). Same thing.
I tried to look at the different logs in /var/log but could not find anything that seems to be related.
Which log should I look at to debug boot issues like this?
Offline
just followed [https://wiki.archlinux.org/index.php/Bo … ith_pacman] but no success
Offline
Assuming you use an EFI system, you could try to boot the kernel directly using efibootmgr to circumvent possible bootloader issues.
See https://wiki.archlinux.org/index.php/EF … bootmgr.29
Offline
Update: Just tried the two disks I had burned.
The november disk fails with a kernel panic, just like kekules_dream. I took a photo of the screen, should I post it ?
The september disk goes further but shows read errors and then fails on the seemingly common 30 seconds error, so maybe my image or burn was corrupted. Im really out of luck these days!
Thus I'm still stuck and couldnt even chroot and try anything.
(Just for a check, i tried also i686 kernels on both discs and the repective behavior was identical to the x86 64)
Offline
Are you able to boot anything?
E.g. memtest86+ which is, if I recall correctly, on the arch-install disk.
Don't know, if this really calls as booting something, but it does not harm to try.
Offline
I didn't try memtest from the archlinux cd, but tuesday evening I successfully booted from a SystemRescueCD that was probably several years old, in order to chroot on my system.
(This attempt failed because it refused to mount my LVM partitions, and anyway I guess it was probably a i686 kernel so I'm not sure I could have repaired my system with this.)
Offline
Update: Just tried the two disks I had burned.
The november disk fails with a kernel panic, just like kekules_dream. I took a photo of the screen, should I post it ?
The september disk goes further but shows read errors and then fails on the seemingly common 30 seconds error, so maybe my image or burn was corrupted. Im really out of luck these days!
Thus I'm still stuck and couldnt even chroot and try anything.(Just for a check, i tried also i686 kernels on both discs and the repective behavior was identical to the x86 64)
To get past 30 second problem, either burn to DVD instead of CD, if that does not work at the emergency shell try this:
cd /dev
ln sr0 archiso
cd /
mkdir /archiso
mount -t iso9660 /dev/sr0 /archiso
cd /dev/disk
mkdir by-label
ln /dev/sr0 ./ARCH_201509
cd /
exit
and wait for boot to complete
assumptions:
/dev/sr0 is your cd drive
ARCH_201509 if your booting september ISO
Offline
Thank you very much, rlees85 : your hint allowed me to boot with the september CD without having to burn it again of find a free usb stick. For anyone reading this later, I had to correct the last ln to "ln /dev/sr0 ./by-label/ARCH_201509" but it's quite obvious.
For me, the problem seems solved, at least with the LTS kernel.
I chrooted, installed the LTS kernel (I had to uninstall the linux package because my /boot was too small...) And as I remembered that doing this didn't do the trick for kekules_dream and I had seen grub mentioned a few times, I also reinstalled grub on the disk :
# grub-install --recheck /dev/sda
Of course I also did a # grub-mkconfig -o /mnt/usb/boot/grub/grub.cfg because I had installed the LTS kernel.
I rebooted, and all worked fine (a few errors during startup, but I think they come from my not-so-good arch CD still in the box). I was then able to make my /boot a little bigger eating a little on my swap partition, reinstalled the standard linux kernel, and I'm now going to reboot to test the classic kernel (4.2.5) and let you know.
If it works, my guess is it came from grub... but why ???
And also, there's still this question : why aren't we kekules_dream and I able to boot the computer with the november image ? Shouldn't we file a bug report for this ?
Offline
I just did my test, and the report is : the boot with linux 4.2.5 is still broken on my computer. So probably it's just installing the LTS kernel that solved it for me. At least this is coherent with the issue with the november image not booting.
I'm good for now, but a little worried about the future : what should I do to help maintainers of the vanilla kernel get it working again on my machine ?
Offline
I found that a bug existed and seemed really similar, so I posted a reply to to bring in what I could : https://bugs.archlinux.org/task/46894
Just for quick reference :
**** tested KO
* linux-4.2.4-1-x86_64.pkg.tar.xz
* linux-4.2.5-1-x86_64.pkg.tar.xz
* 201511 Arch CD
**** tested OK
* linux-4.2.3-1-x86_64.pkg.tar.xz
* linux-lts-4.1.12-1-x86_64.pkg.tar.xz
* 201509 Arch CD
Offline
On my side, it seems to be a nvidia issue after an update .
Offline
If it is indeed a kernel issue someone affected must start bisecting the kernel between the last working (4.2.3?) and the first non working kernel (4.2.4?). That way the offending git commit can be identified and be reported upstream. You can use the kernel PKGBUILD to create a custom kernel based on the working git commit.
Offline
I have also had this issue and have resolved it by downgrading the kernel (to 4.2.2 which was the last one prior to 4.2.5 I had in /var/cache/pacman/pkg).
Offline
If I can find a little free time when my babies have a nap, I'm willing to do a bisect, but I never did it on the kernel, only on other software I develop at work or at home.
I checked http://git.kernel.org/cgit/linux/kernel … .y&ofs=150 and saw that there are about 550 commits between 4.2.3 and 4.2.4, which makes it about 6 bisect steps. Is it the right repository to do the bisction ?
Also, if it exists I would appreciate a pointer to a more detailed guide to the mentioned step "use the kernel PKGBUILD to create a custom kernel based on the working git commit". I currently don't know how to do that (but didn't search yet, I admit).
Offline