I recently updated one of my F31 machines and rebooted it remotely. I was wondering why I couldn't get to it after a couple of minutes so I went out and switch the input to the PC (It's the multimedia machine) to be greeted by a rescue prompt.
I rebooted again locally to find that when the grub menu appeared it was defaulting to the rescue line.
I also just noticed there are 5 kernels listed in the menu but I only have the usual 3 installed.
grubenv has the latest, 5.5.13, as the saved entry but this appears to have no effect.
# grub2-editenv list saved_entry=6ca716a66a574a03a155f3fcdcea1c3f-5.5.13-200.fc31.x86_64 boot_success=1 boot_indeterminate=1 kernelopts=root=/dev/mapper/vg_calvin-lv_root ro rd.lvm.lv=vg_calvin/lv_swap rd.dm=0 SYSFONT=latarcyrheb-sun16 rd.lvm.lv=vg_calvin/lv_root KEYTABLE=us rd.md=0 rd.luks=0 LANG=en_US.UTF-8 rhgb quiet rd.driver.blacklist=nouveau modprobe.blacklist=nouveau nvidia-drm.modeset=1
Any ideas?
Thanks, Richard
Well I figured out PART of it... I'm not sure when it changed but the individual boot load entries are no longer generated and inserted into grub.cfg during grub2-mkconfig, but are individual files now in /boot/loader/entries.
And even though I only have 3 kernels installed (all 5.5.x series) there were left over files (vmlinuz, System.map, initramfs, & config) for older kernels so something wasn't cleaning them up correctly on update.
I guess I'll have to wait for another kernel release to see if I can figure out what's failing.
Thanks, RIchard
On Sun, 2020-04-05 at 20:57 -0500, Richard Shaw wrote:
I guess I'll have to wait for another kernel release to see if I can figure out what's failing.
If you didn't want to wait that long, you could temporarily enable the testing repos.
On Mon, 2020-04-06 at 18:24 +0930, Tim via users wrote:
On Sun, 2020-04-05 at 20:57 -0500, Richard Shaw wrote:
I guess I'll have to wait for another kernel release to see if I can figure out what's failing.
If you didn't want to wait that long, you could temporarily enable the testing repos.
Probably best to do that only for the kernel packages, e.g.
sudo dnf --enablerepo=updates-testing update kernel*
poc
On Sun, 5 Apr 2020 20:57:48 -0500 Richard Shaw hobbes1069@gmail.com wrote:
Well I figured out PART of it... I'm not sure when it changed but the individual boot load entries are no longer generated and inserted into grub.cfg during grub2-mkconfig, but are individual files now in /boot/loader/entries.
I think this was introduced in F30, and it became the default in F31. Called snippets. It is no longer necessary to update the grub.cfg file with snippets enabled, though it is OK to do so.
And even though I only have 3 kernels installed (all 5.5.x series) there were left over files (vmlinuz, System.map, initramfs, & config) for older kernels so something wasn't cleaning them up correctly on update.
Assuming you are using efi, and if you go into /boot/efi/EFI/fedora and run the command grub2-mkconfig -o grub.cfg that should fix your issue with kernels in the menu. Not sure what is causing the lack of cleanup, as everything updates correctly here on F31. Maybe check /etc/default/grub to ensure options are set the way you want? Perhaps you caught the migration from the old grub2 technique to the snippets technique, and there was cruft left over. Did you save more kernels in the past, /etc/dnf/dnf.conf?
On Mon, Apr 6, 2020 at 11:23 AM stan via users < users@lists.fedoraproject.org> wrote:
On Sun, 5 Apr 2020 20:57:48 -0500 Richard Shaw hobbes1069@gmail.com wrote:
Well I figured out PART of it... I'm not sure when it changed but the individual boot load entries are no longer generated and inserted into grub.cfg during grub2-mkconfig, but are individual files now in /boot/loader/entries.
I think this was introduced in F30, and it became the default in F31. Called snippets. It is no longer necessary to update the grub.cfg file with snippets enabled, though it is OK to do so.
Yup, found the change URL. I'm sure I read it when it was originally published, but failed to "grok" it's impact.
And even though I only have 3 kernels installed (all 5.5.x series) there were left over files (vmlinuz, System.map, initramfs, & config) for older kernels so something wasn't cleaning them up correctly on update.
Assuming you are using efi, and if you go into /boot/efi/EFI/fedora and run the command grub2-mkconfig -o grub.cfg that should fix your issue with kernels in the menu.
Well, not exactly... This one is non-EFI. I actually converted my desktop to EFI and it was VERY painful and took me months to track down weird bugs because it wasn't 100% migrated. I'm glad I did it one (got the T-shirt) but I have no intention of ever doing that again :)
Not sure what is causing the lack of cleanup, as everything updates correctly here on F31. Maybe check /etc/default/grub to ensure options are set the way you want? Perhaps you caught the migration from the old grub2 technique to the snippets technique, and there was cruft left over. Did you save more kernels in the past, /etc/dnf/dnf.conf?
I updated grub2/grub.cfg but I did it to a temporary file first and diff'ed the differences not finding anything significant. I deleted the extraneous entries in /boot/loader/entries and installed a new kernel in testing (5.5.15) and everything appears OK.
Must have been a migration issue. Not that should make a different but I am booting BIOS with a GPT partition using a 2M "bios_boot" partition.
Thanks, Richard
On Mon, 6 Apr 2020 11:32:18 -0500 Richard Shaw hobbes1069@gmail.com wrote:
I updated grub2/grub.cfg but I did it to a temporary file first and diff'ed the differences not finding anything significant. I deleted the extraneous entries in /boot/loader/entries and installed a new kernel in testing (5.5.15) and everything appears OK.
Must have been a migration issue. Not that should make a different but I am booting BIOS with a GPT partition using a 2M "bios_boot" partition.
As Will said, "All's well that ends well."
On Sun, 5 Apr 2020 20:44:35 -0500 Richard Shaw wrote:
I recently updated one of my F31 machines and rebooted it remotely. I was wondering why I couldn't get to it after a couple of minutes so I went out and switch the input to the PC (It's the multimedia machine) to be greeted by a rescue prompt.
I also rebooted remotely (Saturday) and found I couldn't talk to my machine either, but I don't know if this was the problem because the monitor I have is very flaky and wouldn't show me anything at first (it only works right if the monitor has power when the machine boots).
When I power cycled the machine, it booted OK, but it had no network because dhcp client apparently failed. Booting it again finally made it work, so I have been guessing the initial reboot simply had no network, but it could have been more messed up than that without me knowing it.
Anyway, as long as I'm working remotely, I'm not planning to reboot again so as to avoid having to drive into work and smack my machine around.
-
Patrick O'Callaghan -
Richard Shaw -
stan -
Tim -
Tom Horsley