And I can't type...

"After rebooting, the kernel crashed", not "failed to crash".

I didn't even get to a shell.

So... now I can reproduce it. After I uninstalled all 4.4.16-related packages (kernel-desktop-latest, kernel-desktop-4.4.16, kernel-desktop-devel-latest, and kernel-desktop-devel-4.4.16), then re-installed them, it worked just fine.


I'm wondering if the initrd link in /boot wasn't setup correctly the first time it got installed. Could updating glibc at the same time as the kernel without rebooting cause a problem? Both were previously updated at the same time. This time, glibc was already installed.

(In reply to Nathan Owens from comment #2)
> So... now I can reproduce it.

do you mean âcan't â?

> After I uninstalled all 4.4.16-related
> packages (kernel-desktop-latest, kernel-desktop-4.4.16,
> kernel-desktop-devel-latest, and kernel-desktop-devel-4.4.16), then
> re-installed them, it worked just fine.
> 
> 
> I'm wondering if the initrd link in /boot wasn't setup correctly the first
> time it got installed. Could updating glibc at the same time as the kernel
> without rebooting cause a problem? Both were previously updated at the same
> time. This time, glibc was already installed.

if before, grub2 couldn't find an initrd image, then the logs from when you installed kernel-4.4.16 for the first time would be interesting to have.

please run, as root, while, if needed, adjusting 'since=' and 'until=' to date + times before and after the update respectively:
 
  journalctl -a since="2016-08-03 18:00" until="2016-08-03 19:00" > output.txt

and attach output.txt to this bug report

Keywords: (none) => NEEDINFO
CC: (none) => marja11
Assignee: bugsquad => tmb

Thanks for showing me how to view my logs (haven't had to do that since we switched to systemd - shows how well the system's been working).

After looking at the logs, it appears the order of events was:
1) Install glibc-6:2.20-23 and kernel 4.4.16-1 on August 1 (Monday, not Wednesday August 3)
2) Forget to reboot (got busy doing other things I guess)
3) Run more updates on August 3 (not related to glibc or the kernel)
4) Get the reminder to reboot
5) Reboot, and fail multiple times
6) Eventually realize kernel 4.4.13 is still installed, and so boot 4.4.13 20 minutes later.

I've attached the journalctl logs from the install of glibc and the kernel on August 1, as well as the "subsequent" install from Step 3 and the reboot. There are no logs for the failed reboots (I don't think it got that far, and I don't see it in journalctl).

Created attachment 8307 [details]
Install/Update of glibc and kernel on August 1, 2016

Created attachment 8308 [details]
Subsequent install and reboot on August 3, 2016

(In reply to Nathan Owens from comment #5)
> Created attachment 8307 [details]
> Install/Update of glibc and kernel on August 1, 2016

I see this line twice:

running: mkinitrd -f /boot/initrd-4.4.16-desktop-1.mga5.img 4.4.16-desktop-1.mga5

and that /boot/vmlinuz-4.4.16-desktop-1.mga5 was created and later found by update-grub2.

However, the matching initrd-4.4.16-desktop-1.mga5.img is _not_ mentioned as being found.



(In reply to Nathan Owens from comment #2)

> 
> 
> I'm wondering if the initrd link in /boot wasn't setup correctly the first
> time it got installed. Could updating glibc at the same time as the kernel
> without rebooting cause a problem? 

Thomas and Colin will know whether that's a possible cause.

CC'ing dracut maintainer

Keywords: NEEDINFO => (none)
CC: (none) => mageia
Summary: Kernel 4.4.16 crashes on boot => Kernel 4.4.16 crashes on boot (matching initrd img not found)
Source RPM: kernel-desktop-4.4.16-1.mga5-1-1.mga5 => kernel-desktop-4.4.16-1.mga5-1-1.mga5, dracut

Mass-reassigning all bugs with "kernel" in the Source RPM field that are assigned to tmb, to the kernel packagers group, because tmb is currently MIA.

Assignee: tmb => kernel

On QA ml, lebarhon reported that a user in the French forums reported hitting this issue twice, with the 4.4.22 and with the 4.4.26 kernel

http://www.mageialinux-online.org/forum/topic-22767.php#m219140

Usually when it fails to generate the initrd it's because of a lack of disk space in the /boot or / partition.

My /boot directory is on my / partition, and it has 5.0G free and has never been close to the limit, so that wasn't the problem for me.

I just installed the 4.4.26 kernel and it worked just fine (I checked before rebooting).

Could the package be made to fail/revert to the old kernel if the initrd fails to generate for these intermittent cases (if the root cause can't be determined - I haven't reproduced it myself)? That would at least make the system bootable by-default. Maybe even just not update the symlinks until it worked, and then throw an error to the user?

I just encountered the problem today with the update to 4.4.50 kernel.
The /boot/initrd-desktop.img point to .boot/initrd-4.4.50-desktop-2.mga5.img which doesn't exist.
The boot ended with a kernel panic.
Rebooting with the previous kernel, I executed in /boot:
 mkinitrd initrd-4.4.50-desktop-2.mga5.img 
which worked.
I have 2 luks partitions, one for /home and a second on an external drive.
The problem is also similar to:
https://forums.mageia.org/en/viewtopic.php?f=7&t=11464
I have 1 G free space on /
/boot is not separated partition.
I will join the journal sequence during update.

CC: (none) => yves.brungard_mageia

Created attachment 9134 [details]
Journal sequence updating kernel to 4.4.50

Did anyone hit this issue in Mageia 6?

If so, please tell so and change the Version of this report (near the top of this screen, on the left) to 6

@ Nathan

==> If you didn't reset your password after february 2018, then you'll need to reset it here https://identity.mageia.org/forgot_password to be able to log in and comment in this report. <==

I haven't seen it happen.

(In reply to Nathan Owens from comment #15)
> I haven't seen it happen.

Thanks for the feedback.

Closing this report as OLD, then, because Mageia 5 is no longer supported and Mageia 6 doesn't seem to be affected.

Status: NEW => RESOLVED
Resolution: (none) => OLD