For a month or so... on one of my computers, that happens to be my workstation: When installing a kernel: in console and log I see it say it can not find a bootloader. For a new kernel to be visible in grub menu, I need to manually run update-grub2. And yes the computer boots and show grub, so what does it mean by no booloader...? Launching drakboot, it too say boot loader is missin, i tell it to fix, it then ctrash "drakboot" with an error report dialogue saying grub2-install failed, /usr/lib/grub/i386-ieee1275/modinfo.sh does not exist. [root@svarten ~]# ls /usr/lib/grub/ i386-pc/ [root@svarten ~]# ls /usr/lib/grub/i386-pc/modin* /usr/lib/grub/i386-pc/modinfo.sh And yes the grub2 package contain the i386-pc/ folder, not i386-ieee1275/ . So why is it looking for i386-ieee1275/modinfo.sh ? i386-ieee1275 is not in *any* package in configured repos! It seem to suddenly think the machine is not a "i386-pc", but a "i386-ieee1275"? Thinking about it, it started after I changed my SSD for a newer one, same size and blocksize. I wanted to change before it get too old and unreliable. I just dd the complete content from the old to the new. Everything works. But I dont understand how that could lead to this problem...
1. We have seen this 'i386-ieee1275/' recently in another bug, no time to find it no. There was an explanation. CC'ing Giuseppe for this point. 2. You say the system works, but without the new kernel showing in the Grub menu. Does this mean it loads a kernel not in its menu? Or only after: 3. "For a new kernel to be visible in grub menu, I need to manually run update-grub2." Just once? Does that fix the problem for a newer kernal, or do you have to update Grub each time? 3. "it started after I changed my SSD for a newer one I just dd the complete content from the old to the new. Everything works" I am unsure that this would work with a real disc - UUIDs? CC'ing Martin in case he can see something.
CC: (none) => ghibomgx, lewyssmith, mageia
(In reply to Lewis Smith from comment #1) > 1. We have seen this 'i386-ieee1275/' recently in another bug, no time to > find it no. There was an explanation. CC'ing Giuseppe for this point. Bug 34541 ? But on my system why have it been OK on this main board for over a decade and suddenly misbehaves? > 2. You say the system works, but without the new kernel showing in the Grub > menu. Does this mean it loads a kernel not in its menu? Or only after: The new installed kernel(s) is(are) not listed. I selected another kernel than the last installed. (think that old was still preselected) > 3. "For a new kernel to be visible in grub menu, I need to manually run > update-grub2." > Just once? Yes > Does that fix the problem for a newer kernal, or do you have to > update Grub each time? runing update-grub2 makes all new kernels installed since last I ran it appear in grub menu from now on. > 3. "it started after I changed my SSD for a newer one > I just dd the complete content from the old to the new. Everything works" > I am unsure that this would work with a real disc - UUIDs? > CC'ing Martin in case he can see something. Detail: I booted on a USB stick, with new SSD added, dd from old SSD to new, power off, switched SSD (old one removed, I understand it now have identical UUID so should never be used on same system). -> normal boot The new SSD *may* be on another SATA port now, i don´t remember. I have not touched BIOS setting. Using traditional MBR (IIRC...)
(In reply to Morgan Leijström from comment #2) > (In reply to Lewis Smith from comment #1) > > 3. "For a new kernel to be visible in grub menu, I need to manually run > > update-grub2." > > Just once? What I meant: Each time after i install a new kernel, I need to run update-grub2 again in order for it to be selectable at boot.
But you get in mga9 or mga10? as #34541 happens on mga10 with newer grub.
cloning a disk with dd should clone also the UUIDs (either UUIDs and PARTUUIds), there might be however some case where IDs are unique to disks, and you need to be sure there aren't reference in some config file or in some initrd image or grub.cfg to them, e.g. /dev/disk/by-id/<...>, as in /dev/disk/by-id/ there are unique identifier to disks, e.g. /dev/disk/by-id/ata-<vendor>-<model>-<serial>/ and this won't be cloned.
mga9. [morgan@svarten ~]$ ls -l /dev/disk/by-id totalt 0 lrwxrwxrwx 1 root root 9 aug 8 21:31 ata-PHILIPS_DVD+_-RW_DVD8631_MY0P95137015952O05C4 -> ../../sr0 lrwxrwxrwx 1 root root 9 aug 13 23:32 ata-Samsung_SSD_870_EVO_500GB_S7EWNL0X512903M -> ../../sdb lrwxrwxrwx 1 root root 10 aug 13 23:32 ata-Samsung_SSD_870_EVO_500GB_S7EWNL0X512903M-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 aug 13 23:32 ata-Samsung_SSD_870_EVO_500GB_S7EWNL0X512903M-part2 -> ../../sdb2 lrwxrwxrwx 1 root root 10 aug 13 23:32 ata-Samsung_SSD_870_EVO_500GB_S7EWNL0X512903M-part3 -> ../../sdb3 lrwxrwxrwx 1 root root 9 aug 13 23:32 ata-ST4000VN006-3CW104_WW66N9S2 -> ../../sda lrwxrwxrwx 1 root root 10 aug 13 23:32 ata-ST4000VN006-3CW104_WW66N9S2-part1 -> ../../sda1 lrwxrwxrwx 1 root root 10 aug 8 21:31 dm-name-crypt_sda2 -> ../../dm-0 lrwxrwxrwx 1 root root 10 aug 8 21:31 dm-name-vg--mga-lv_home -> ../../dm-3 lrwxrwxrwx 1 root root 10 aug 8 21:31 dm-name-vg--mga-lv_root -> ../../dm-2 lrwxrwxrwx 1 root root 10 aug 8 21:31 dm-name-vg--mga-lv_swap -> ../../dm-1 lrwxrwxrwx 1 root root 10 aug 8 21:31 dm-uuid-CRYPT-LUKS2-7988f3fc3408486182fa1018fb905a72-crypt_sda2 -> ../../dm-0 lrwxrwxrwx 1 root root 10 aug 8 21:31 dm-uuid-LVM-MykZw8dKHGUaOfGvOa4TuN2hPSr6x51YD9U5AvcfOqeFG4PR9Pc40k5aAcXfLjgP -> ../../dm-2 lrwxrwxrwx 1 root root 10 aug 8 21:31 dm-uuid-LVM-MykZw8dKHGUaOfGvOa4TuN2hPSr6x51Ygh7JXHh6BTOtya7KyAoe2eyk7qgfc7eH -> ../../dm-1 lrwxrwxrwx 1 root root 10 aug 8 21:31 dm-uuid-LVM-MykZw8dKHGUaOfGvOa4TuN2hPSr6x51Yyip5PoR4o7I7OXOWSI7rc4qqivi9EpZC -> ../../dm-3 lrwxrwxrwx 1 root root 10 aug 8 21:31 lvm-pv-uuid-ajW3wM-jl3R-lbIH-1ppg-wmU9-77Jy-j7N9qP -> ../../dm-0 lrwxrwxrwx 1 root root 9 aug 13 23:32 wwn-0x5000c500fb06257c -> ../../sda lrwxrwxrwx 1 root root 10 aug 13 23:32 wwn-0x5000c500fb06257c-part1 -> ../../sda1 lrwxrwxrwx 1 root root 9 aug 13 23:32 wwn-0x5002538f5450d030 -> ../../sdb lrwxrwxrwx 1 root root 10 aug 13 23:32 wwn-0x5002538f5450d030-part1 -> ../../sdb1 lrwxrwxrwx 1 root root 10 aug 13 23:32 wwn-0x5002538f5450d030-part2 -> ../../sdb2 lrwxrwxrwx 1 root root 10 aug 13 23:32 wwn-0x5002538f5450d030-part3 -> ../../sdb3 [morgan@svarten ~]$ LC_ALL=C df Filesystem Size Used Avail Use% Mounted on devtmpfs 7.8G 0 7.8G 0% /dev tmpfs 7.8G 12K 7.8G 1% /dev/shm tmpfs 7.8G 1.7M 7.8G 1% /run /dev/mapper/vg--mga-lv_root 39G 27G 10G 73% / tmpfs 7.8G 19M 7.8G 1% /tmp /dev/sdb3 572M 315M 216M 60% /boot /dev/sda1 3.6T 429G 3.0T 13% /mnt/IWolf4TB /dev/mapper/vg--mga-lv_home 361G 292G 70G 81% /home tmpfs 1.6G 78M 1.5G 5% /run/user/10702
Thanks for your clarifications. As I understand them: - After installing a new kerrnel, it does not show in the Grub menu, so you are stuck with loading an earlier one. - After 'update-grub2', the new kernel is then visible in Grub. However the previous point still applies if you add another kernel. - So you need to run 'update-grub2' after installing each new kernel for it to be visible in Grub. "it started after I changed my SSD for a newer one" remains a crucial point. Have you tried the forum? Please do before we push this to packagers.
That is correct. OK, now I opened https://forums.mageia.org/en/viewtopic.php?t=15737
CC: (none) => stephengermany
From the information you've posted, I think that before the SSD swap your SSD was appearing as /dev/sda, and now it is appearing as /dev/sdb. Edit /boot/grub2/install.sh and change the line grub2-install sda to grub2-install sdb and drakboot should work again.
Thank you for the suggestion. Tried that now. drakboot still complain no bootloader configuration exist when attempting to create one, crash like in Comment 0 with message: grub2-install failed: grub2-install: fel: /usr/lib/grub/i386-ieee1275/modinfo.sh finns inte I will try to swap drives SATA connetions
I shouldn't rely on my memory... That should have been change grub2-install /dev/sda to grub2-install /dev/sdb Just tested this in VirtualBox, forcing the boot disk to come up as sdb. Before editing /boot/grub2/install.sh [root@vbox ~]# /sbin/detectloader Cannot find a boot loader installed After making that change [root@vbox ~]# /sbin/detectloader GRUB2 and drakboot was also happy.
Thank you for your input, Martin. It looks promising.
I did understand that memory slip, and changed /dev/sda to /dev/sdb :) I do get # /sbin/detectloader GRUB2 But regardless, in drakboot, after clicking the [Finish] button, it crash saying it cannot find /usr/lib/grub/i386-ieee1275/modinfo.sh With /dev/sda in /boot/grub2/install.sh, I get: # /sbin/detectloader Cannot find a boot loader installed And drakboot on start pops up a message it cannot find a bootloader and will create a new configuration, and later crash with the same message cannot find /usr/lib/grub/i386-ieee1275/modinfo.sh So it appears drakboot can handle handle sda to sdb change but in both cases why do it need usr/lib/grub/i386-ieee1275/modinfo.sh or why is that file missing?
(In reply to Morgan Leijström from comment #13) > So it appears drakboot can handle handle sda to sdb change but in both cases > why do it need usr/lib/grub/i386-ieee1275/modinfo.sh or why is that file > missing? That's the bug#34541, I think it's not a single file missing, but a new module.
But then why am I the only one experiencing (or at least reporting) it on mga9?
(In reply to Giuseppe Ghibò from comment #14) > (In reply to Morgan Leijström from comment #13) > > > So it appears drakboot can handle handle sda to sdb change but in both cases > > why do it need usr/lib/grub/i386-ieee1275/modinfo.sh or why is that file > > missing? > > That's the bug#34541, I think it's not a single file missing, but a new > module. with module missing, I mean not that it's not installed, but it's not built in the grub2 package. I quickly looked at the grub2 SPEC and it's not trivial to add.
For testing (if we should) I maybe could download and add that file manually and just place it where it is looked for. But first: why do it suddenly need it on this old system, and just on my mga9 system?
(In reply to Morgan Leijström from comment #17) > For testing (if we should) I maybe could download and add that file manually > and just place it where it is looked for. > The module ieee1275 is missed from building in the grub package it, so it can't be added manually. Apparently it's related to open firmware. An quick hack that works (but broken) to get past that error, it's to add a soft link from /usr/lib/grub/i386-ieee1275/modinfo.sh to /usr/lib/grub/i386-pc/modinfo.sh, and then rerun grub.
No, don't do a quick hack, let's find out what the problem really is. For some reason grub2-install is wrongly identifying your system type. I've not managed to reproduce that in VirtualBox. Please run (as root) grub2-install -v /dev/sda and report the output from that. (I'm suggesting doing it with /dev/sda to avoid any chance of it messing up your working installation of grub on /dev/sdb)
I set /boot/grub2/install.sh to /dev/sda, and then: [root@svarten ~]# grub2-install -v /dev/sda grub2-install: info: executing modprobe efivars 2>/dev/null. grub2-install: info: Looking for /sys/firmware/efi ... grub2-install: info: ... not found. grub2-install: info: Looking for /proc/device-tree ... grub2-install: info: ...found. grub2-install: error: /usr/lib/grub/i386-ieee1275/modinfo.sh doesn't exist. Please specify --target or --directory.
I assume this is a standard PC with legacy BIOS. Could you check whether /proc/device-tree really exists. I don't think it should...
IIRC it is an old style install - how to check to be sure? [root@svarten ~]# ls -al /proc/device-tree lrwxrwxrwx 1 root root 29 aug 27 12:47 /proc/device-tree -> /sys/firmware/devicetree/base/ Now I will leave for a few hours customer site work.
What linux kernel version are you running?
Currently the backport 6.12.41-desktop-1.stable.mga9 x86_64 I noticed the problem when running 6.6 kernels too. [root@svarten ~]# inxi -SMC System: Host: svarten.tribun Kernel: 6.12.41-desktop-1.stable.mga9 arch: x86_64 bits: 64 Console: pty pts/0 Distro: Mageia 9 Machine: Type: Desktop Mobo: ASRock model: P55 Pro serial: N/A BIOS: American Megatrends v: P2.60 date: 08/20/2010 CPU: Info: quad core model: Intel Core i7 870 bits: 64 type: MT MCP cache: L2: 1024 KiB Speed (MHz): avg: 1200 min/max: 1200/2934 cores: 1: 1200 2: 1200 3: 1200 4: 1200 5: 1200 6: 1200 7: 1200 8: 1200
OK, it's that kernel that's causing the problem. In the kernel configuration file I find "CONFIG_OF=y". That causes the soft link "/proc/device-tree" to be created, and that in turn causes grub2-install to believe you are running on a system using Open Firmware (a.k.a. IEEE 1275) instead of a normal PC BIOS. I don't know why that configuration option has been added to the backport kernel - from what I can find on the internet it seems only to be needed for OLPC machines. If you want to keep using that kernel, you can temporarily work around the problem by changing the line in /boot/grub2/install.sh to grub2-install --target=i386-pc /dev/sdb but note that drakboot rewrites that file and will remove the --target option.
You are spot on, Martin! Big thank you! Seems I was mistaken about the problem also showing when using 6.6 kernels, sorry about that. Booting either desktop kernel 6.6.93 or .101, /proc/device-tree do not exist. And drakboot then works ( Noting, that after changing /boot/grub2/install.sh between sda and sdb and vice versa, drakboot do not find bootloader, so it seems it delete the one on the other drive.) So kernel 6.12 in backport (and maybe kernels in mga10 too?) need to be fixed.
Assignee: bugsquad => kernel
Summary: Suddenly "no bootloader", but grub and system works. drakboot crash. update-grub2 OK. => Backport kernel 6.12.41 make boot menu not update & drakboot crash. update-grub2 OK.Status comment: (none) => Workaround in c25
(In reply to Morgan Leijström from comment #26) > You are spot on, Martin! > > Big thank you! > > > Seems I was mistaken about the problem also showing when using 6.6 kernels, > sorry about that. > > Booting either desktop kernel 6.6.93 or .101, /proc/device-tree do not exist. > > And drakboot then works > > ( Noting, that after changing /boot/grub2/install.sh between sda and sdb and > vice versa, drakboot do not find bootloader, so it seems it delete the one > on the other drive.) > > So kernel 6.12 in backport (and maybe kernels in mga10 too?) need to be > fixed. Nice catch! A kernel for cauldron without CONFIG_OF was pushed this morning (and it is still building, 6.12.43-2.mga10). grub-install probably should check for extra information beyond /proc/device-tree as well. Also, would it be possible to include a few more debugging tools in the current network bootable image? It’s quite minimal, making it difficult to diagnose issues that might arise, especially during the last stages of installation.
Note that this was two separate issues: 1. The drakx tools (detectloader, drakboot, etc.) create and subsequently read /boot/grub2/install.sh to determine where the GRUB loader is installed (for legacy BIOS systems only; with UEFI it is stored in the ESP). But that uses the device name (e.g. /dev/sda), so if the device name changes, the drakx tools will look in the wrong place and mistakenly conclude that GRUB is not installed. That would have happened regardless of which kernel version was used and was what prevented the GRUB menu being automatically updated when a new kernel was installed. 2. grub2-install was mislead by the presence of /proc/device-tree. That would only happen when using kernels with the CONFIG_OF option enabled and was what caused drakboot to fail when trying to reinstall GRUB. (In reply to Giuseppe Ghibò from comment #27) > Also, would it be possible to include a few more debugging tools in the > current network bootable image? It’s quite minimal, making it difficult to > diagnose issues that might arise, especially during the last stages of > installation. It's deliberately minimal. The installer stage2 image downloaded by the network installer is the same one included on the classical installer ISOs, and we are always short of space on the classical installer ISOs. However, in the last stages of installation (after packages have been installed) you also have use of all the tools in the installed system, so just make sure you install anything you need.
(In reply to Martin Whitaker from comment #28) > Note that this was two separate issues: > > 1. The drakx tools (detectloader, drakboot, etc.) create and subsequently > read /boot/grub2/install.sh to determine where the GRUB loader is installed > (for legacy BIOS systems only; with UEFI it is stored in the ESP). But that > uses the device name (e.g. /dev/sda), so if the device name changes, the > drakx tools will look in the wrong place and mistakenly conclude that GRUB > is not installed. That would have happened regardless of which kernel > version was used and was what prevented the GRUB menu being automatically > updated when a new kernel was installed. Learnt that now, thanks. Ah yes that was the part I saw with other kernels. Working as designed. > 2. grub2-install was mislead by the presence of /proc/device-tree. That > would only happen when using kernels with the CONFIG_OF option enabled and > was what caused drakboot to fail when trying to reinstall GRUB. I confirm this problem is fixed in backport testing kernel-stable-desktop-6.12.43-1.stable.mga9-1-1.mga9 So I mark this as fixed. > (In reply to Giuseppe Ghibò from comment #27) > > Also, would it be possible to include a few more debugging tools in the > > current network bootable image? It’s quite minimal, making it difficult to > > diagnose issues that might arise, especially during the last stages of > > installation. > > It's deliberately minimal. The installer stage2 image downloaded by the > network installer is the same one included on the classical installer ISOs, > and we are always short of space on the classical installer ISOs. However, > in the last stages of installation (after packages have been installed) you > also have use of all the tools in the installed system, so just make sure > you install anything you need. Giuseppe, is there some compact tool you mean could be handy for investigating a problem that prevents the install to finish?
Status: NEW => RESOLVEDResolution: (none) => FIXED
(In reply to Morgan Leijström from comment #29) > (In reply to Martin Whitaker from comment #28) > > Note that this was two separate issues: > > > > 1. The drakx tools (detectloader, drakboot, etc.) create and subsequently > > read /boot/grub2/install.sh to determine where the GRUB loader is installed > > (for legacy BIOS systems only; with UEFI it is stored in the ESP). But that > > uses the device name (e.g. /dev/sda), so if the device name changes, the > > drakx tools will look in the wrong place and mistakenly conclude that GRUB > > is not installed. That would have happened regardless of which kernel > > version was used and was what prevented the GRUB menu being automatically > > updated when a new kernel was installed. > > Learnt that now, thanks. > > Ah yes that was the part I saw with other kernels. > > Working as designed. > > > > 2. grub2-install was mislead by the presence of /proc/device-tree. That > > would only happen when using kernels with the CONFIG_OF option enabled and > > was what caused drakboot to fail when trying to reinstall GRUB. > > I confirm this problem is fixed in backport testing > kernel-stable-desktop-6.12.43-1.stable.mga9-1-1.mga9 > > So I mark this as fixed. > > > > (In reply to Giuseppe Ghibò from comment #27) > > > Also, would it be possible to include a few more debugging tools in the > > > current network bootable image? It’s quite minimal, making it difficult to > > > diagnose issues that might arise, especially during the last stages of > > > installation. > > > > It's deliberately minimal. The installer stage2 image downloaded by the > > network installer is the same one included on the classical installer ISOs, > > and we are always short of space on the classical installer ISOs. However, > > in the last stages of installation (after packages have been installed) you > > also have use of all the tools in the installed system, so just make sure > > you install anything you need. > > Giuseppe, is there some compact tool you mean could be handy for > investigating a problem that prevents the install to finish? I'm not referring to a particular tool, but the tree of tiny CLI commands available in the installer, out of the what you might install in the chroot (which is mounted in the /mnt). In my opinion, it's too stripped down and lacks many basic utilities that would be useful for debugging when something goes wrong, and also for reporting issues. For example, when you press Ctrl-Alt-F2 in the installer, to access the shell, the complete coreutils binaries and networking tools from iproute2 aren't present. So, when something goes wrong, you have to chroot into /mnt and hope that you can use it or that can be helpful. Regarding space, perhaps we should rely on a Net installer ISO including a stage2 alternative to the classic one. coreutils is for instance 2.7MB.