| Summary: | update-grub doesn't configure /boot/grub2/grub.cfg | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | peter lawford <petlaw726> |
| Component: | RPM Packages | Assignee: | Kernel and Drivers maintainers <kernel> |
| Status: | NEW --- | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | davidwhodgins, ouaurelien |
| Version: | 8 | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: |
content of /boot/grub2/grub.cfg.new
text obtained by changing grub2 graphical to text on mcc return of strace update-grub tail -n 1000 strace.txt > strace2.txt /boot/grub2/grub.cfg of the system mag6, which is mageia7 |
||
|
Description
peter lawford
2021-04-01 23:52:54 CEST
Hi, can you provide the content of /boot/grub2/install.sh please? and also the content of /etc/fstab CC:
(none) =>
ouaurelien *** Bug 28700 has been marked as a duplicate of this bug. *** (In reply to Aurelien Oudelet from comment #1) > Hi, can you provide the content of /boot/grub2/install.sh please? problem there is no such file [alain4@mga6-64 ~]$ ls -l /boot/grub2/ total 60 -rw-r--r-- 1 root root 158 févr. 17 12:43 custom.cfg drwxr-xr-x 2 root root 4096 févr. 17 12:43 fonts/ -rw------- 1 root root 8780 avril 2 13:27 grub.cfg.new -rw-r--r-- 1 root root 26498 déc. 23 2018 grub.cfg.old -rw-r--r-- 1 root root 1024 juil. 30 2017 grubenv drwxr-xr-x 3 root root 4096 avril 2 13:11 themes/ -rw-r--r-- 1 root root 150 avril 3 2018 unicode.pf2 -rw-r--r-- 1 root root 0 mars 13 16:27 updtrans [alain4@mga6-64 ~]$ although I have 2 times uninstalled and reinstalled the pkgs grub2-common-2.04.0-29.mga8 grub2-mageia-theme-2.04.0-29.mga8 grub2-2.04.0-29.mga8 > and also the content of /etc/fstab [alain4@mga6-64 ~]$ cat /etc/fstab /dev/vgmageia/lvrootmga6-64 / ext4 relatime,acl 1 1 /dev/vgmageia/lvbootmga6-64 /boot ext4 relatime,acl 1 2 /dev/vgmageia/lvhomemga6-64 /home ext4 relatime,acl 1 2 /dev/vghome/lvscratch /home/alain4/Téléchargements ext4 relatime,acl 1 2 /dev/vghome/lvhomedoc /home/alain4/Documents ext4 relatime,acl 1 2 /dev/vghome/lvhomemusic /home/alain4/Musique ext4 noauto,user,relatime,acl 1 2 /dev/sr0 /media/cdrom auto umask=0,users,iocharset=utf8,noauto,ro,exec 0 0 /dev/vgremote1/lvstockr1 /home/alain4/mnt/stockremote1 ext4 user,noauto 0 0 /dev/vgremote1/lvhdbckr1 /home/alain4/mnt/homedocbackupremote1 ext4 user,noauto 0 0 /dev/vgremote/lvstockr /home/alain4/mnt/stockremote ext4 user,noauto 0 0 /dev/vgremote/lvhdbckr /home/alain4/mnt/homedocbackupremote ext4 user,noauto 0 0 /dev/vgremote/lvstockmusicr /home/alain4/mnt/stockmusicremote ext4 user,noauto 0 0 /dev/vgremote1/lvstockmusicr1 /home/alain4/mnt/stockmusicremote1 ext4 user,noauto 0 0 /dev/vgstock/lvhomedocbackup /home/alain4/mnt/homedocbackup ext4 user,noauto,relatime,acl 1 2 /dev/vgstock/lvstockmusic /home/alain4/mnt/stockmusic ext4 user,noauto,relatime,acl 1 2 /dev/vgstock/lvstock /home/alain4/mnt/stock ext4 user,noauto,relatime,acl 1 2 /dev/vgstock/lvtempo /mnt/temp ext4 noauto,relatime,acl 1 2 none /proc proc defaults 0 0 none /tmp tmpfs defaults 0 0 # entry for swap: /dev/vgmageia/lvswapmageia UUID=07e49b34-5658-4995-8f08-69c76d8553e0 swap swap defaults,nofail 0 0 [alain4@mga6-64 ~]$ vgremote and vgremote1 are on external USB disks (backup) (In reply to Aurelien Oudelet from comment #2) > *** Bug 28700 has been marked as a duplicate of this bug. *** for your information the file /boot/grub2/install.sh doesn't exist either on one of my mageia7 system, on which update-grub fine works: [root@mga6-64 ~]# ls -l /mnt/bootmagaux/grub2/ total 60 -rw-r--r-- 1 root root 158 mai 11 2019 custom.cfg drwxr-xr-x 2 root root 4096 mai 11 2019 fonts/ -rwxr-xr-x 1 root root 20974 avril 1 18:51 grub.cfg* -rw-r--r-- 1 root root 1024 mai 13 2019 grubenv drwxr-xr-x 2 root root 12288 janv. 30 22:57 i386-pc/ drwxr-xr-x 2 root root 4096 janv. 30 22:57 locale/ drwxr-xr-x 2 root root 4096 mai 11 2019 themes/ -rw-r--r-- 1 root root 150 mars 31 2018 unicode.pf2 -rw-r--r-- 1 root root 0 sept. 12 2019 updtrans [root@mga6-64 ~]# (In reply to Aurelien Oudelet from comment #2) > *** Bug 28700 has been marked as a duplicate of this bug. *** I have a 3rd mga7 system on which the file /boot/grub2/install.sh exists: [root@mga6-64 ~]# cat /mnt/bootmag6/grub2/install.sh grub2-install /dev/sda I would be surprised that this content would make update-grub to work I am convinced that something is broken in /usr/bin/update-grub (or update-grub2)version mageia8 /boot/grub2/install.sh is created by /usr/lib/libDrakX/bootloader.pm when mcc is used to set the setup the boot boot system and grub2 is selected. Try using it and changing the it from grub2 with graphical menu to using a text menu, or vice/versa. CC:
(none) =>
davidwhodgins (In reply to Dave Hodgins from comment #6) > /boot/grub2/install.sh is created by /usr/lib/libDrakX/bootloader.pm > when mcc is used to set the setup the boot boot system and grub2 is > selected. Try using it and changing the it from grub2 with graphical > menu to using a text menu, or vice/versa. the problem is not install.sh, but the creation (or modification) of the file /boot/grub2/grub.cfg, which commands what is written on /dev/sdx, which is the key of the boot (grub2, and even efi), it is what update-grub is essential, especially for those who have multiboot. I've just discovered that on mga8, update-grub do the half of its job: it creates an unfinished file /boot/grub2/grub.cfg.new, which has rights 600, and contains only a part of /etc/grub.d: before running update-grub: [root@mga6-64 ~]# ls -l /boot/grub2/ total 48 -rw-r--r-- 1 root root 158 févr. 17 12:43 custom.cfg drwxr-xr-x 2 root root 4096 févr. 17 12:43 fonts/ -rw-r--r-- 1 root root 26498 déc. 23 2018 grub.cfg.old -rw-r--r-- 1 root root 1024 juil. 30 2017 grubenv drwxr-xr-x 3 root root 4096 avril 2 13:11 themes/ -rw-r--r-- 1 root root 150 avril 3 2018 unicode.pf2 -rw-r--r-- 1 root root 0 mars 13 16:27 updtrans after running update-grub: [root@mga6-64 ~]# ls -l /boot/grub2/ total 60 -rw-r--r-- 1 root root 158 févr. 17 12:43 custom.cfg drwxr-xr-x 2 root root 4096 févr. 17 12:43 fonts/ -rw------- 1 root root 8780 avril 2 23:32 grub.cfg.new -rw-r--r-- 1 root root 26498 déc. 23 2018 grub.cfg.old -rw-r--r-- 1 root root 1024 juil. 30 2017 grubenv drwxr-xr-x 3 root root 4096 avril 2 13:11 themes/ -rw-r--r-- 1 root root 150 avril 3 2018 unicode.pf2 -rw-r--r-- 1 root root 0 mars 13 16:27 updtrans but: [root@mga6-64 ~]# cat /boot/grub2/grub.cfg.new > grub.cfg.new you'll find here as attached document and: [root@mga6-64 ~]# ls -l /etc/grub.d total 148 -rwxr-xr-x 1 root root 9346 févr. 17 12:43 00_header* -rwxr-xr-x 1 root root 236 févr. 17 12:43 01_users* -rwxr-xr-x 1 root root 259 avril 3 2018 02_grub-customizer_menu_color_helper* -rw-r--r-- 1 root root 835 févr. 17 12:43 08_fallback_counting -rw-r--r-- 1 root root 11771 févr. 17 12:43 10_linux -rw-r--r-- 1 root root 833 févr. 17 12:43 10_reset_boot_success -rwxr-xr-x 1 root root 5151 avril 1 23:12 11_custom* -rw-r--r-- 1 root root 892 févr. 17 12:43 12_menu_auto_hide -rw-r--r-- 1 root root 410 févr. 17 12:43 14_menu_show_once -rwxr-xr-x 1 root root 12285 févr. 17 12:43 20_linux_xen* -rw-r--r-- 1 root root 4136 sept. 28 2018 20_memtest86+ -rw-r--r-- 1 root root 2562 févr. 17 12:43 20_ppc_terminfo -rwxr-xr-x 1 root root 4136 mai 31 2016 21_memtest86+* -rwxr-xr-x 1 root root 2559 déc. 1 2017 22_ppc_terminfo* -rw-r--r-- 1 root root 10673 févr. 17 12:43 30_os-prober -rwxr-xr-x 1 root root 1415 févr. 17 12:43 30_uefi-firmware* -rwxr-xr-x 1 root root 5183 avril 1 23:12 40_custom* -rw-r--r-- 1 root root 218 mai 11 2019 40_custom.rpmnew -rwxr-xr-x 1 root root 220 févr. 17 12:43 41_custom* -rwxr-xr-x 1 root root 6131 avril 1 23:13 50_custom* drwxr-xr-x 4 root root 4096 mars 30 2018 backup/ drwxr-xr-x 2 root root 4096 mars 30 2018 bin/ drwxr-xr-x 2 root root 4096 juin 20 2018 proxifiedScripts/ -rw-r--r-- 1 root root 483 févr. 17 12:43 README if you compare the content of /etc/grub.d and this one of grub.cfg.new, you'll see that in the latter, only 00_header*, 01_users*, 02_grub-customizer_menu_color_helper* and 11_custom* are retranscrypted, while the other executable items, which correspond to the entries of others systems, are forgotten; this means that as long as the problem will be not solved, mga8 can't manage multiboot and is just good for the trash Created attachment 12559 [details]
content of /boot/grub2/grub.cfg.new
The kernel packages call /usr/sbin/installkernel in the posttrans scriptlet. /usr/sbin/installkernel calls /usr/sbin/bootloader-config, which calls /usr/lib/libDrakX/bootloader.pm, which calls either /boot/grub/install.sh or /boot/grub2/install.sh depending on bootloader chosen. Please try my suggestion from comment 6. My intention is to get the system working properly, and then try to figure out how it got to the non-working state. (In reply to Dave Hodgins from comment #9) > The kernel packages call /usr/sbin/installkernel in the posttrans scriptlet. > /usr/sbin/installkernel calls /usr/sbin/bootloader-config, which calls > /usr/lib/libDrakX/bootloader.pm, which calls either /boot/grub/install.sh > or /boot/grub2/install.sh depending on bootloader chosen. > > Please try my suggestion from comment 6. > > My intention is to get the system working properly, and then try to figure > out how it got to the non-working state. thank you very much for your efforts I made what you suggested me to do, on mcc I have changed grub2 with graphical menu to using a text menu, and I got the following text (attached file bug_update-grub_mga8.txt) expect this problem will be fixed soon Created attachment 12560 [details]
text obtained by changing grub2 graphical to text on mcc
The question now is why is drakboot is failing with ... drakbug::bug_handler() called from /usr/libexec/drakboot:49 Is this a lvm, or combination raid/lvm install? If raid too, hardware or software? It explains why I'm not seeing it, as I'm not using either lvm or raid. Assigning to the kernel team Assignee:
bugsquad =>
kernel (In reply to Dave Hodgins from comment #12) > The question now is why is drakboot is failing with ... > drakbug::bug_handler() called from /usr/libexec/drakboot:49 > > Is this a lvm, or combination raid/lvm install? If raid too, hardware or > software? surely not combination lvm/raid, since all my systems are based on this combination, and systems which are mga7 meet no problem with update-grub; but after upgrading 7>8 the actual system, many pkgs, some of them being mga8, were considered as orphans by urpme, and I have removed them, relying in urpme --auto-orphans > > It explains why I'm not seeing it, as I'm not using either lvm or raid. > > Assigning to the kernel team (In reply to Dave Hodgins from comment #12) > The question now is why is drakboot is failing with ... > drakbug::bug_handler() called from /usr/libexec/drakboot:49 > > Is this a lvm, or combination raid/lvm install? If raid too, hardware or > software? raid are only software: [root@mga6-64 alain4]# mdadm --detail --scan -v ARRAY /dev/md122 level=raid5 num-devices=4 metadata=1.2 name=mageia:magaux UUID=06cefede:1d3d7621:f25b7414:f376dc27 devices=/dev/sde3,/dev/sdf3,/dev/sdg3,/dev/sdh3 ARRAY /dev/md127 level=raid5 num-devices=4 metadata=1.2 name=mageia:mageia UUID=efc98f0b:c50824fb:963147dd:6e628334 devices=/dev/sda6,/dev/sdb6,/dev/sdc6,/dev/sdd6 ARRAY /dev/md128 level=raid5 num-devices=4 metadata=1.2 name=mageia:stock UUID=a71a05da:c87bd344:d32047ab:75464e3f devices=/dev/sde6,/dev/sdf6,/dev/sdg6,/dev/sdh6 ARRAY /dev/md126 level=raid5 num-devices=4 metadata=1.2 name=mageia:home UUID=8bc713ce:a9f7966e:eaab4294:0ab46fbd devices=/dev/sda7,/dev/sdb7,/dev/sdc7,/dev/sdd7 > > It explains why I'm not seeing it, as I'm not using either lvm or raid. > > Assigning to the kernel team (In reply to Dave Hodgins from comment #12) > The question now is why is drakboot is failing with ... > drakbug::bug_handler() called from /usr/libexec/drakboot:49 > > Is this a lvm, or combination raid/lvm install? If raid too, hardware or > software? > > It explains why I'm not seeing it, as I'm not using either lvm or raid. > > Assigning to the kernel team I'd the hope that th kernel upgrade 5.10.25-1.mga8 > 5.10.27-1.mga8 solved the problem, but it didn't update-grub(2) is not meant to *create* an grub config, only update an existing one. grub2-mkconfig is the one responsible for creating the initial one... so: grub2-mkconfig -o /boot/grub2/grub.cfg will do what you want (In reply to Thomas Backlund from comment #16) > update-grub(2) is not meant to *create* an grub config, only update an > existing one. > > > grub2-mkconfig is the one responsible for creating the initial one... > > so: > > grub2-mkconfig -o /boot/grub2/grub.cfg > > will do what you want wrong! it the first thing I have made, and it doesn't work more than update-grub. demonstration: [root@mga6-64 alain4]# ls -l /boot/grub2 total 48 -rw-r--r-- 1 root root 158 févr. 17 12:43 custom.cfg drwxr-xr-x 2 root root 4096 févr. 17 12:43 fonts/ -rw-r--r-- 1 root root 26498 déc. 23 2018 grub.cfg.old -rw-r--r-- 1 root root 1024 juil. 30 2017 grubenv drwxr-xr-x 3 root root 4096 avril 2 13:11 themes/ -rw-r--r-- 1 root root 150 avril 3 2018 unicode.pf2 -rw-r--r-- 1 root root 0 mars 13 16:27 updtrans [root@mga6-64 alain4]# LC_ALL=C grub2-mkconfig -o /boot/grub2/grub.cfg Generating grub configuration file ... Found theme: /boot/grub2/themes/maggy/theme.txt important remark: the return doesn't end by "done" [root@mga6-64 alain4]# ls -l /boot/grub2 total 60 -rw-r--r-- 1 root root 158 févr. 17 12:43 custom.cfg drwxr-xr-x 2 root root 4096 févr. 17 12:43 fonts/ -rw------- 1 root root 8793 avril 3 23:09 grub.cfg.new -rw-r--r-- 1 root root 26498 déc. 23 2018 grub.cfg.old -rw-r--r-- 1 root root 1024 juil. 30 2017 grubenv drwxr-xr-x 3 root root 4096 avril 2 13:11 themes/ -rw-r--r-- 1 root root 150 avril 3 2018 unicode.pf2 -rw-r--r-- 1 root root 0 mars 13 16:27 updtrans (In reply to Thomas Backlund from comment #16) > update-grub(2) is not meant to *create* an grub config, only update an > existing one. > > > grub2-mkconfig is the one responsible for creating the initial one... > > so: > > grub2-mkconfig -o /boot/grub2/grub.cfg > > will do what you want see comment 6 and the attached file: "text obtained by changing grub2 graphical to text on mcc" if it was so easy to fix the problem, on mcc I didn't get an error message So something is broken in your setup/system. looking on your /etc/grub.d/ you have a lot of "extra" stuff... and what seems to be a lot of duplicated stuff... on my system I with mdadm setup I have: # l -1 /etc/grub.d/* /etc/grub.d/00_header* /etc/grub.d/01_users* /etc/grub.d/08_fallback_counting* /etc/grub.d/10_linux* /etc/grub.d/10_reset_boot_success* /etc/grub.d/12_menu_auto_hide* /etc/grub.d/14_menu_show_once* /etc/grub.d/20_linux_xen* /etc/grub.d/20_ppc_terminfo* /etc/grub.d/30_os-prober* /etc/grub.d/30_uefi-firmware* /etc/grub.d/40_custom* /etc/grub.d/41_custom* /etc/grub.d/README so by the looks of it, it hangs on some of the stuff you have... I guess next up is to run grub2-mkconfig under strace to see what file it parses last... What's the output of "ls -l /boot" and "grep /dev /proc/mounts"? (In reply to Thomas Backlund from comment #19) > So something is broken in your setup/system. I am sure of that > > looking on your /etc/grub.d/ you have a lot of "extra" stuff... and what > seems to be a lot of duplicated stuff... > > on my system I with mdadm setup I have: > > # l -1 /etc/grub.d/* > /etc/grub.d/00_header* > /etc/grub.d/01_users* > /etc/grub.d/08_fallback_counting* > /etc/grub.d/10_linux* > /etc/grub.d/10_reset_boot_success* > /etc/grub.d/12_menu_auto_hide* > /etc/grub.d/14_menu_show_once* > /etc/grub.d/20_linux_xen* > /etc/grub.d/20_ppc_terminfo* > /etc/grub.d/30_os-prober* > /etc/grub.d/30_uefi-firmware* > /etc/grub.d/40_custom* > /etc/grub.d/41_custom* > /etc/grub.d/README > > > so by the looks of it, it hangs on some of the stuff you have... > > > I guess next up is to run grub2-mkconfig under strace to see what file it > parses last... strace:? this word seems no to exist in english the problem came after a successfull upgrading 7>8 with the method suggested by mageia: "urpmi --auto-update --auto --force --download-all --test, and after th same commande without test but I met strange things: see comment 13 however, if the problem is due to having purged orphans, some of them being mga8 pkgs, that means that mga8 suffers of severe dependancy issues (In reply to Dave Hodgins from comment #20) > What's the output of "ls -l /boot" and "grep /dev /proc/mounts"? [alain4@mga6-64 ~]$ ls -l /boot total 123864 -rw-rw-r-- 1 root root 440 févr. 6 2014 boot.backup.sda -rw-r--r-- 1 root root 244341 mars 20 18:54 config-5.10.25-desktop-1.mga8 -rw-r--r-- 1 root root 244450 mars 20 20:06 config-5.10.25-server-1.mga8 -rw-r--r-- 1 root root 244345 mars 31 02:57 config-5.10.27-desktop-1.mga8 -rw-r--r-- 1 root root 244410 mars 31 04:16 config-5.10.27-server-1.mga8 drwxr-xr-x 2 root root 4096 déc. 26 15:34 dracut/ lrwxrwxrwx 1 root root 3 avril 4 13:31 efi -> EFI/ drwx------ 3 root root 4096 mars 13 16:23 EFI/ drwxr-xr-x 2 root root 4096 janv. 21 12:33 exportmga6-64/ -rwxr-xr-x 1 root root 574464 mars 13 18:57 gfxmenu* drwxr-xr-x 2 root root 4096 mars 13 16:21 grub/ drwxr-xr-x 6 root root 4096 mars 13 19:04 grub2/ -rw------- 1 root root 17421901 mars 23 22:48 initrd-5.10.25-desktop-1.mga8.img -rw------- 1 root root 17420903 mars 23 22:50 initrd-5.10.25-server-1.mga8.img -rw------- 1 root root 17420823 avril 4 14:12 initrd-5.10.27-desktop-1.mga8.img -rw------- 1 root root 17420037 avril 4 14:14 initrd-5.10.27-server-1.mga8.img lrwxrwxrwx 1 root root 33 avril 4 14:12 initrd-desktop.img -> initrd-5.10.27-desktop-1.mga8.img lrwxrwxrwx 1 root root 32 avril 4 14:14 initrd.img -> initrd-5.10.27-server-1.mga8.img lrwxrwxrwx 1 root root 32 avril 4 14:14 initrd-server.img -> initrd-5.10.27-server-1.mga8.img drwx------ 2 root root 16384 août 13 2012 lost+found/ -rw-r--r-- 1 root root 92672 déc. 12 11:34 pcmemtest -rw-r--r-- 1 root root 202364 mars 20 18:54 symvers-5.10.25-desktop-1.mga8.xz -rw-r--r-- 1 root root 202484 mars 20 20:06 symvers-5.10.25-server-1.mga8.xz -rw-r--r-- 1 root root 202496 mars 31 02:57 symvers-5.10.27-desktop-1.mga8.xz -rw-r--r-- 1 root root 202520 mars 31 04:16 symvers-5.10.27-server-1.mga8.xz -rw-r--r-- 1 root root 4999053 mars 20 18:54 System.map-5.10.25-desktop-1.mga8 -rw-r--r-- 1 root root 5044844 mars 20 20:06 System.map-5.10.25-server-1.mga8 -rw-r--r-- 1 root root 5000007 mars 31 02:57 System.map-5.10.27-desktop-1.mga8 -rw-r--r-- 1 root root 5045798 mars 31 04:16 System.map-5.10.27-server-1.mga8 lrwxrwxrwx 1 root root 29 avril 4 14:14 vmlinuz -> vmlinuz-5.10.27-server-1.mga8 -rw-r--r-- 1 root root 7969312 mars 20 18:54 vmlinuz-5.10.25-desktop-1.mga8 -rw-r--r-- 1 root root 9287712 mars 20 20:06 vmlinuz-5.10.25-server-1.mga8 -rw-r--r-- 1 root root 7975168 mars 31 02:57 vmlinuz-5.10.27-desktop-1.mga8 -rw-r--r-- 1 root root 9292032 mars 31 04:16 vmlinuz-5.10.27-server-1.mga8 lrwxrwxrwx 1 root root 30 avril 4 14:12 vmlinuz-desktop -> vmlinuz-5.10.27-desktop-1.mga8 lrwxrwxrwx 1 root root 29 avril 4 14:14 vmlinuz-server -> vmlinuz-5.10.27-server-1.mga8 [alain4@mga6-64 ~]$ grep /dev /proc/mounts devtmpfs /dev devtmpfs rw,nosuid,noexec,size=32875944k,nr_inodes=8218986,mode=755,inode64 0 0 devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 tmpfs /dev/shm tmpfs rw,nosuid,nodev,noexec,inode64 0 0 /dev/mapper/vgmageia-lvrootmga6--64 / ext4 rw,relatime,stripe=384 0 0 mqueue /dev/mqueue mqueue rw,nosuid,nodev,noexec,relatime 0 0 hugetlbfs /dev/hugepages hugetlbfs rw,relatime,pagesize=2M 0 0 /dev/mapper/vgmageia-lvbootmga6--64 /boot ext4 rw,relatime,stripe=384 0 0 /dev/mapper/vgmageia-lvhomemga6--64 /home ext4 rw,relatime,stripe=384 0 0 /dev/mapper/vghome-lvscratch /home/alain4/Téléchargements ext4 rw,relatime,stripe=96 0 0 /dev/mapper/vghome-lvhomedoc /home/alain4/Documents ext4 rw,relatime,stripe=96 0 0 I think that the problem comes from the fact that all my systems are based on lvm/mdraid and not on physical HDD's partitions; I got precedently an issue due to that (see bug 25698) (In reply to peter lawford from comment #21) strace is a command line utility to look what a program does. # strace update-grub For usage. > but I met strange things: see comment 13 > however, if the problem is due to having purged orphans, some of them being > mga8 pkgs, that means that mga8 suffers of severe dependancy issues You should never do uprmi --auto-orphans and let mga8 packages to be removed after upgrading. But, you should ask help before and take carefully the named packages. What's the output of "df -h"? And "df -i". (In reply to Aurelien Oudelet from comment #24) > (In reply to peter lawford from comment #21) > > strace is a command line utility to look what a program does. here as attached file > > # strace update-grub > > For usage. > > > but I met strange things: see comment 13 > > however, if the problem is due to having purged orphans, some of them being > > mga8 pkgs, that means that mga8 suffers of severe dependancy issues > > You should never do uprmi --auto-orphans and let mga8 packages to be removed > after upgrading. > But, you should ask help before and take carefully the named packages. I agree with you entirely, I was reckless Created attachment 12573 [details]
return of strace update-grub
(In reply to Dave Hodgins from comment #26) > And "df -i". [root@mga6-64 alain4]# df -h Sys. de fichiers Taille Utilisé Dispo Uti% Monté sur devtmpfs 32G 0 32G 0% /dev tmpfs 32G 94M 32G 1% /dev/shm tmpfs 32G 2,4M 32G 1% /run /dev/mapper/vgmageia-lvrootmga6--64 35G 24G 9,4G 72% / none 32G 180K 32G 1% /tmp /dev/mapper/vgmageia-lvbootmga6--64 1,2G 83M 991M 8% /boot /dev/mapper/vgmageia-lvhomemga6--64 16G 12G 2,8G 82% /home /dev/mapper/vghome-lvscratch 20G 4,6G 14G 26% /home/alain4/Téléchargements /dev/mapper/vghome-lvhomedoc 185G 146G 30G 84% /home/alain4/Documents tmpfs 6,3G 184K 6,3G 1% /run/user/500 [root@mga6-64 alain4]# df -i Sys. de fichiers Inœuds IUtil. ILibre IUti% Monté sur devtmpfs 7,9M 1,3K 7,9M 1% /dev tmpfs 7,9M 71 7,9M 1% /dev/shm tmpfs 7,9M 2,4K 7,9M 1% /run /dev/mapper/vgmageia-lvrootmga6--64 2,2M 606K 1,7M 27% / none 7,9M 45 7,9M 1% /tmp /dev/mapper/vgmageia-lvbootmga6--64 75K 369 75K 1% /boot /dev/mapper/vgmageia-lvhomemga6--64 1000K 153K 848K 16% /home /dev/mapper/vghome-lvscratch 1,3M 93 1,3M 1% /home/alain4/Téléchargements /dev/mapper/vghome-lvhomedoc 12M 110K 12M 1% /home/alain4/Documents tmpfs 1,6M 135 1,6M 1% /run/user/500 [root@mga6-64 alain4]# (In reply to peter lawford from comment #27) > (In reply to Aurelien Oudelet from comment #24) > > (In reply to peter lawford from comment #21) > > > > strace is a command line utility to look what a program does. we learn every day > here as attached file > > > > # strace update-grub > > > > For usage. > > > > > but I met strange things: see comment 13 > > > however, if the problem is due to having purged orphans, some of them being > > > mga8 pkgs, that means that mga8 suffers of severe dependancy issues > > > > You should never do uprmi --auto-orphans and let mga8 packages to be removed > > after upgrading. > > But, you should ask help before and take carefully the named packages. > I agree with you entirely, I was reckless I suspect a urpme --auto-orphans that remove critical and essentials RPM, because a missing task-desktop (plasma5,gnome,...) That has been removed. @ reporter, strace output shows us customs files involved in grub generation. I think something is missing this leads you in a bad state. I suggest: If ever DNF or Urpmi are still installed and working, try to reinstall urpmi, grub, basesystem and "task-plasma5-minimal" if you use Plasma. s/plasma5/gnome or xfce or your desktop choice. If grub2 still broken and unable to update his menu: Dump a Mageia 8 classic ISO to a USB key and perform an upgrade install. Doing this DrakX should be able to use our existing partitions and logical LVM/RAID. Later, don't forget about the --auto-orphans switch to be carefully use. (In reply to Aurelien Oudelet from comment #31) > I suspect a urpme --auto-orphans that remove critical and essentials RPM, > because a missing task-desktop (plasma5,gnome,...) That has been removed. > > @ reporter, > > strace output shows us customs files involved in grub generation. > I think something is missing this leads you in a bad state. > > I suggest: > If ever DNF or Urpmi are still installed and working, try to reinstall > urpmi, grub, see comment 3 basesystem and "task-plasma5-minimal" if you use Plasma. > s/plasma5/gnome or xfce or your desktop choice. > > If grub2 still broken and unable to update his menu: > Dump a Mageia 8 classic ISO to a USB key and perform an upgrade install. > Doing this DrakX should be able to use our existing partitions and logical > LVM/RAID. I've tried yesterday: result, crash system: at the step "bootloader installation, installer indefinitely told me that installation of grub2 failed and sent me an error message (the same as that one:"text obtained by changing grub2 graphical to text on mcc" in attached files) as I couldn't end my life with this infinite process (because with installer, exit at any step is not an option) I choosed to install legacy grub to exit; but when I rebooted, splash showed me some error messages (systemd ntpd.service failed, and one another I don't remember); I decided to erase the whole system (dd if=/dev/zero of=/dev/vgmageia/lv<boot,root,home>mga6-64 bs=...) and restore it: I dump all my systems 2 or 3 times /months with the old but reliable tool dump/restore: I'm not so reckless > > Later, don't forget about the --auto-orphans switch to be carefully use. (In reply to Aurelien Oudelet from comment #31) > I suspect a urpme --auto-orphans that remove critical and essentials RPM, > because a missing task-desktop (plasma5,gnome,...) That has been removed. > > @ reporter, > > strace output shows us customs files involved in grub generation. > I think something is missing this leads you in a bad state. > > I suggest: > If ever DNF or Urpmi are still installed and working, try to reinstall > urpmi, grub, basesystem and "task-plasma5-minimal" task-plasma5-minimal and task-plasma5 are already installed >if you use Plasma. > s/plasma5/gnome or xfce or your desktop choice. > > If grub2 still broken and unable to update his menu: > Dump a Mageia 8 classic ISO to a USB key and perform an upgrade install. > Doing this DrakX should be able to use our existing partitions and logical > LVM/RAID. > > Later, don't forget about the --auto-orphans switch to be carefully use. The strace output shows the child process exited, but doesn't show why. Use "strace -f -o strace.txt update-grub2" then attach strace.txt to the bug report. The -f option causes the child processes to be traced too. (In reply to Dave Hodgins from comment #34) > The strace output shows the child process exited, but doesn't show why. > > Use "strace -f -o strace.txt update-grub2" then attach strace.txt to the > bug report. The -f option causes the child processes to be traced too. strace.txt attached (In reply to Dave Hodgins from comment #34) > The strace output shows the child process exited, but doesn't show why. > > Use "strace -f -o strace.txt update-grub2" then attach strace.txt to the > bug report. The -f option causes the child processes to be traced too. impossible to attach strace.txt:too heavy 286 MB (In reply to Dave Hodgins from comment #34) > The strace output shows the child process exited, but doesn't show why. > > Use "strace -f -o strace.txt update-grub2" then attach strace.txt to the > bug report. The -f option causes the child processes to be traced too. strace.txt: 3916784 lines (it's not a joke) even bzip2 reduces it to (only) 11 MB Likely the last few hundred lines will have enough info. tail -n 200 strace.txt>strace2.txt On my system, the file produced by "strace -f -o strace.txt update-grub2" with two kernels installed is 340362 lines. We have to figure out why it's so many on that system. Think I figured it out. I have os-prober disabled on my system as I have enough test installs that the grub menu will no longer fit on my screen. In mcc, select Boot, then Set up boot system, select Next, unselect the option "Probe Foreign OS" and select Finish. How many installs to you have, and how many kernels installed in them? Run update-grub2 after that, and it should finish much faster, though accessing other os requires other methods. Most of my installs are on a large hard drive from when I was installing grub to the boot record of the partition and using the gag boot loader in the mbr of sda. Those installs are not used any more. I now have one per ssd drive with grub installed to the mbr of that drive, and I use the bios boot menu to select which drive to boot from. (In reply to Dave Hodgins from comment #38) > Likely the last few hundred lines will have enough info. > > tail -n 200 strace.txt>strace2.txt I was more generous, you'll have the 1000 last lines of strace.txt you'll find as attached files Created attachment 12576 [details]
tail -n 1000 strace.txt > strace2.txt
(In reply to Dave Hodgins from comment #40) > Think I figured it out. I have os-prober disabled on my system as I have > enough test installs that the grub menu will no longer fit on my screen. > > In mcc, select Boot, then Set up boot system, select Next, unselect the > option > "Probe Foreign OS" and select Finish. > > How many installs to you have, and how many kernels installed in them? I have: 8 hdds, 4 mdadm-raid5 (comment 14), 3 mageia systems names mga6-64 (mga8), mag6 (mga7) and magaux (mga7): 2 mga7 and the actual faulty mga8 (mga6-64), on each one kernel (5.10.27-1.mga <7,8> on 2 of them and 5.10.25-1 on 1 mga7); all systems are on lvm, and the corresponding vg's are on mdadm-raid5 volumes each hdd has gpt partition, and 1st partition of each hdd is a little (2 MB) EF02-type partition the other vgs are used for backup sd[a-d]1 have a bootloader generated by mag6 and sd[e-f]1 a bootloader from magaux this means that all my entries for the 3 systems are in /etc/grub.d of the 2 mga7 systems (mag6 and magaux); the mga8 (mga6-64 named) system is not use for boot, but I have to fix the problem because the 2 others mga7 systems will be upgraded to mga8 one day or the other. Just noticed some thing else strange in that 1000 lines
# grep -e /etc/grub.d -e /boot attachment.cgi\?id\=12576 |grep -v -e ENOENT
43826 openat(AT_FDCWD, "/boot/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
26055 write(1, "### END /etc/grub.d/20_linux_xen"..., 37) = 37
26055 stat("/etc/grub.d/20_memtest86+", {st_mode=S_IFREG|0644, st_size=4136, ...}) = 0
26055 faccessat(AT_FDCWD, "/etc/grub.d/20_memtest86+", X_OK) = -1 EACCES (Permission non accordée)
26055 stat("/etc/grub.d/20_ppc_terminfo", {st_mode=S_IFREG|0644, st_size=2562, ...}) = 0
26055 faccessat(AT_FDCWD, "/etc/grub.d/20_ppc_terminfo", X_OK) = -1 EACCES (Permission non accordée)
26055 stat("/etc/grub.d/21_memtest86+", {st_mode=S_IFREG|0755, st_size=4136, ...}) = 0
26055 faccessat(AT_FDCWD, "/etc/grub.d/21_memtest86+", X_OK) = 0
26055 write(1, "### BEGIN /etc/grub.d/21_memtest"..., 40) = 40
44058 execve("/etc/grub.d/21_memtest86+", ["/etc/grub.d/21_memtest86+"], 0x10bc080 /* 71 vars */) = 0
44058 openat(AT_FDCWD, "/etc/grub.d/21_memtest86+", O_RDONLY) = 3
44058 stat("/etc/grub.d/21_memtest86+", {st_mode=S_IFREG|0755, st_size=4136, ...}) = 0
After noticing the "Permission non accordée", I looked back at comment 7
Many of the files in /etc/grub.d are not executable.
On my system all of the files in that directory are marked executable.
Try running "chmod a+x /etc/grub.d/*".
(In reply to Dave Hodgins from comment #45) > Just noticed some thing else strange in that 1000 lines > > # grep -e /etc/grub.d -e /boot attachment.cgi\?id\=12576 |grep -v -e ENOENT > 43826 openat(AT_FDCWD, "/boot/", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) > = 3 > 26055 write(1, "### END /etc/grub.d/20_linux_xen"..., 37) = 37 > 26055 stat("/etc/grub.d/20_memtest86+", {st_mode=S_IFREG|0644, st_size=4136, > ...}) = 0 > 26055 faccessat(AT_FDCWD, "/etc/grub.d/20_memtest86+", X_OK) = -1 EACCES > (Permission non accordée) > 26055 stat("/etc/grub.d/20_ppc_terminfo", {st_mode=S_IFREG|0644, > st_size=2562, ...}) = 0 > 26055 faccessat(AT_FDCWD, "/etc/grub.d/20_ppc_terminfo", X_OK) = -1 EACCES > (Permission non accordée) > 26055 stat("/etc/grub.d/21_memtest86+", {st_mode=S_IFREG|0755, st_size=4136, > ...}) = 0 > 26055 faccessat(AT_FDCWD, "/etc/grub.d/21_memtest86+", X_OK) = 0 > 26055 write(1, "### BEGIN /etc/grub.d/21_memtest"..., 40) = 40 > 44058 execve("/etc/grub.d/21_memtest86+", ["/etc/grub.d/21_memtest86+"], > 0x10bc080 /* 71 vars */) = 0 > 44058 openat(AT_FDCWD, "/etc/grub.d/21_memtest86+", O_RDONLY) = 3 > 44058 stat("/etc/grub.d/21_memtest86+", {st_mode=S_IFREG|0755, st_size=4136, > ...}) = 0 > > After noticing the "Permission non accordée", I looked back at comment 7 > Many of the files in /etc/grub.d are not executable. > > On my system all of the files in that directory are marked executable. > > Try running "chmod a+x /etc/grub.d/*". it's absolutely normal, I don't mark executable some files, I'll explain why: comment7 is not a good example, because as I told you in comment 44, the mageia8 mga6-64 system is not used for boot, and its /etc/grub.d has not the right entries; see here the /etc/grub.d content of the mageia7 mag6 system used for boot: [root@mag6 alain4]# ls -l /etc/grub.d total 136 -rwxr-xr-x 1 root root 8703 mai 11 2019 00_header* -rwxr-xr-x 1 root root 236 mai 11 2019 01_users* -rwxr-xr-x 1 root root 259 avril 3 2018 02_grub-customizer_menu_color_helper* -rw-r--r-- 1 root root 10594 mai 11 2019 10_linux -rwxr-xr-x 1 root root 5151 avril 5 14:03 11_custom* -rwxr-xr-x 1 root root 10487 mai 11 2019 20_linux_xen* -rw-r--r-- 1 root root 4136 sept. 28 2018 20_memtest86+ -rw-r--r-- 1 root root 2562 mai 11 2019 20_ppc_terminfo -rwxr-xr-x 1 root root 4136 mai 31 2016 21_memtest86+* -rwxr-xr-x 1 root root 2559 déc. 1 2017 22_ppc_terminfo* -rw-r--r-- 1 root root 11817 mai 11 2019 30_os-prober -rwxr-xr-x 1 root root 5183 avril 5 14:01 40_custom* -rw-r--r-- 1 root root 218 mai 11 2019 40_custom.rpmnew -rwxr-xr-x 1 root root 220 mai 11 2019 41_custom* -rwxr-xr-x 1 root root 6131 avril 5 14:02 50_custom* -rw-r--r-- 1 root root 3462 mai 25 2020 51_custom -rw-r--r-- 1 root root 3688 mai 25 2020 55_custom drwxr-xr-x 4 root root 4096 mars 30 2018 backup/ drwxr-xr-x 2 root root 4096 mars 30 2018 bin/ drwxr-xr-x 2 root root 4096 juin 20 2018 proxifiedScripts/ -rw-r--r-- 1 root root 483 mai 21 2015 README here, 11_custom is the entry for mag6, 40_custom the one for magaux and 50_custom for the "faulty" mageia8 mga6-64; I have designed these files by myself and they work very well (provided that command update-grub works, of course) therefore, I don't need 30_os-prober, and it's the reason it is not marked executable, the same for 20_memtest... since 21_memtest... is already executable you'll also find as attached files /boot/grub2/grub.cfg of the same mageia7-mag6 system, which is up-to-date and perfectly functional (I recall that update-grub fine work on my mageia7 systems) Created attachment 12579 [details]
/boot/grub2/grub.cfg of the system mag6, which is mageia7
There is something in one of those /etc/grub.d files that causes the Mageia 8 version of update grub to fail. As this is an efi system, please install the package refind if it hasn't already been installed, and use mcc to switch from grub to refind. See if it works in a way suitable for your usage. It's now the boot manager I prefer to use on my efi systems when I'm not testing something related to grub. (In reply to Dave Hodgins from comment #48) > There is something in one of those /etc/grub.d files that causes the Mageia > 8 version of update grub to fail. > > As this is an efi system, please install the package refind if it hasn't > already > been installed, and use mcc to switch from grub to refind. it is not an efi system, the compatible module csm is enabled in the bios > > See if it works in a way suitable for your usage. It's now the boot manager I > prefer to use on my efi systems when I'm not testing something related to > grub. I have a very bad new: I've just upgrade (successfully) my system mag6 7>8, using graphical method (mgaapplet) and now update-grub(2) which worked well when it was mageia7 no longer work, exactly like for mga6-64; but this time, I haven't remove neither orphans pkgs (there are 318 pkgs) nor old remaining mga7 pkgs that means that mga8 have to be entirely redesigned; sorry since I need for my daily businees a system which normally works, I think to switch to others distros than mageia (In reply to Dave Hodgins from comment #48) > There is something in one of those /etc/grub.d files that causes the Mageia > 8 version of update grub to fail. > > As this is an efi system, please install the package refind if it hasn't > already > been installed, and use mcc to switch from grub to refind. > > See if it works in a way suitable for your usage. It's now the boot manager I > prefer to use on my efi systems when I'm not testing something related to > grub. if you wish I am at your disposal to attach the orphans list (In reply to peter lawford from comment #49) > > I have a very bad new: I've just upgrade (successfully) my system mag6 7>8, > using graphical method (mgaapplet) and now update-grub(2) which worked well > when it was mageia7 no longer work, exactly like for mga6-64; but this time, > I haven't remove neither orphans pkgs (there are 318 pkgs) nor old remaining > mga7 pkgs > that means that mga8 have to be entirely redesigned; sorry > since I need for my daily businees a system which normally works, I think to > switch to others distros than mageia I really don't know what is wrong with your installation as long as we can't take physically a look at this. FYI, I have nearly 35 PC I manage for friends and family. I do not find any grub2 issue on them. Mageia 7 to 8 was smooth and gracefully handle on all of them. I don't know why you use many Mageia instance on your production PC but your are totally right to do so, like the still use of Legacy Bios boot on Uefi system. The recommanded way to upgrade is mgaapplet and this seems to let you in an uncomfortable situation. I would like to apologize this. Restarting from scratch is not the preferable way, but sometimes it produces better results. Normally, the system updated with mgaapplet should have in system log the output of RPM commands. Could you attach here such output? journalctl -b -X as root where X is a number of how many times the system rebooted. Ex. If your system rebooted 4 times since mgaapplet upgrade to 8, please do: # journalctl -b -4 --no-pager --no-hostname > /boot-mgaapplet7to8.txt Make sure the RPM transactions are here and eventually all references to grub/boootconfig. You should also tar.xz the file to make it less than 1 Mb. (In reply to Dave Hodgins from comment #48) > There is something in one of those /etc/grub.d files that causes the Mageia > 8 version of update grub to fail. > > As this is an efi system, please install the package refind if it hasn't > already > been installed, and use mcc to switch from grub to refind. sorry, but I installed refind-0.12.0-2.mga8.x86_64.rpm, and in mcc > boot, the only options are: grub2 <graphical,text>, grub <graphical,text> and lilo text; no refind option this is not an efi system: [root@mag6 alain4]# ls /sys/firmware/ acpi/ dmi/ edd/ memmap/ > > See if it works in a way suitable for your usage. It's now the boot manager I > prefer to use on my efi systems when I'm not testing something related to > grub. (In reply to Aurelien Oudelet from comment #51) > (In reply to peter lawford from comment #49) > > > > I have a very bad new: I've just upgrade (successfully) my system mag6 7>8, > > using graphical method (mgaapplet) and now update-grub(2) which worked well > > when it was mageia7 no longer work, exactly like for mga6-64; but this time, > > I haven't remove neither orphans pkgs (there are 318 pkgs) nor old remaining > > mga7 pkgs > > that means that mga8 have to be entirely redesigned; sorry > > since I need for my daily businees a system which normally works, I think to > > switch to others distros than mageia > > I really don't know what is wrong with your installation as long as we can't > take physically a look at this. > > FYI, I have nearly 35 PC I manage for friends and family. I do not find any > grub2 issue on them. Mageia 7 to 8 was smooth and gracefully handle on all > of them. > FYI ? > I don't know why you use many Mageia instance on your production PC but your > are totally right to do so, like the still use of Legacy Bios boot on Uefi > system. > see below, please > The recommanded way to upgrade is mgaapplet and this seems to let you in an > uncomfortable situation. I would like to apologize this. Restarting from > scratch is not the preferable way, but sometimes it produces better results. two weeks ago, I upgraded one of my system mga7 (system called mga6-64) by the command line method (see comment 21) and not mgaapplet; the issue with update-grub was the same (see comments above); it is simple to understand: without update-grub(2), or grub2-mkconfig -o /boot/grub2/grub.cfg which doesn't work too, I can't generate or modify if needed the file /boot/grub2/grub.cfg, and without this file, grub2-install /dev/sdx installs nothing, and I can't boot any of my systems; even an efi-system takes it informations from this file, it's the reason for what I can't use efi as long as the problem of update-grub won't be fixed > > Normally, the system updated with mgaapplet should have in system log the > output of RPM commands. > Could you attach here such output? > journalctl -b -X as root where X is a number of how many times the system > rebooted. > > Ex. If your system rebooted 4 times since mgaapplet upgrade to 8, please do: > # journalctl -b -4 --no-pager --no-hostname > /boot-mgaapplet7to8.txt > > Make sure the RPM transactions are here and eventually all references to > grub/boootconfig. You should also tar.xz the file to make it less than 1 Mb. (In reply to Aurelien Oudelet from comment #51) > (In reply to peter lawford from comment #49) > > > > I have a very bad new: I've just upgrade (successfully) my system mag6 7>8, > > using graphical method (mgaapplet) and now update-grub(2) which worked well > > when it was mageia7 no longer work, exactly like for mga6-64; but this time, > > I haven't remove neither orphans pkgs (there are 318 pkgs) nor old remaining > > mga7 pkgs > > that means that mga8 have to be entirely redesigned; sorry > > since I need for my daily businees a system which normally works, I think to > > switch to others distros than mageia > > I really don't know what is wrong with your installation as long as we can't > take physically a look at this. > > FYI, I have nearly 35 PC I manage for friends and family. I do not find any > grub2 issue on them. Mageia 7 to 8 was smooth and gracefully handle on all > of them. FYI ? > I don't know why you use many Mageia instance on your production PC but your > are totally right to do so, like the still use of Legacy Bios boot on Uefi > system. see below, please > The recommanded way to upgrade is mgaapplet and this seems to let you in an > uncomfortable situation. I would like to apologize this. Restarting from > scratch is not the preferable way, but sometimes it produces better results. two weeks ago, I upgraded one of my system mga7 (system called mga6-64) by the command line method (see comment 21) and not mgaapplet; the issue with update-grub was the same (see comments above); it is simple to understand: without update-grub(2), or grub2-mkconfig -o /boot/grub2/grub.cfg which doesn't work too, I can't generate or modify if needed the file /boot/grub2/grub.cfg, and without this file, grub2-install /dev/sdx installs nothing, and I can't boot any of my systems; even an efi-system takes it informations from this file, it's the reason for what I can't use efi as long as the problem of update-grub won't be fixed > Normally, the system updated with mgaapplet should have in system log the > output of RPM commands. > Could you attach here such output? > journalctl -b -X as root where X is a number of how many times the system > rebooted. > > Ex. If your system rebooted 4 times since mgaapplet upgrade to 8, please do: > # journalctl -b -4 --no-pager --no-hostname > /boot-mgaapplet7to8.txt > > Make sure the RPM transactions are here and eventually all references to > grub/boootconfig. You should also tar.xz the file to make it less than 1 Mb. comment 22 shows lrwxrwxrwx 1 root root 3 avril 4 13:31 efi -> EFI/ drwx------ 3 root root 4096 mars 13 16:23 EFI/ Did you install in uefi mode and then switch to legacy mode? Mageia does not support that. With uefi systems, refind does not use grub.cfg. It dynamically finds the installations, and shows an icon for each. It dynamically finds the kernels in /boot. It removes the need to update a boot menu. (In reply to Dave Hodgins from comment #55) > comment 22 shows > lrwxrwxrwx 1 root root 3 avril 4 13:31 efi -> EFI/ > drwx------ 3 root root 4096 mars 13 16:23 EFI/ > > Did you install in uefi mode and then switch to legacy mode? > > Mageia does not support that. > > With uefi systems, refind does not use grub.cfg. It dynamically finds the > installations, and shows an icon for each. > > It dynamically finds the kernels in /boot. It removes the need to update > a boot menu. I do think this is the issue. Also, you did not provide any system journal output, as requested earlier. @peter, you have decided that the issue is in grub and its commands. Let's me decide the bug is somewhere in-between: from your own setup / own settings / own misuse of the underlying technology like LVM/software RAID and grub2 and drakboot services. Normally, I recommend use of a real primary /boot partition in ext4. Then, you can use what you want in LVM/RAID primary or extended/logical partition, in mbr/got.... (In reply to Aurelien Oudelet from comment #56) > (In reply to Dave Hodgins from comment #55) > > comment 22 shows > > lrwxrwxrwx 1 root root 3 avril 4 13:31 efi -> EFI/ > > drwx------ 3 root root 4096 mars 13 16:23 EFI/ > > > > Did you install in uefi mode and then switch to legacy mode? > > > > Mageia does not support that. > > > > With uefi systems, refind does not use grub.cfg. It dynamically finds the > > installations, and shows an icon for each. > > > > It dynamically finds the kernels in /boot. It removes the need to update > > a boot menu. > > I do think this is the issue. > Also, you did not provide any system journal output, as requested earlier. > @peter, you have decided that the issue is in grub and its commands. Let's > me decide the bug is somewhere in-between: from your own setup / own > settings / own misuse of the underlying technology like LVM/software RAID > and grub2 and drakboot services. > > Normally, I recommend use of a real primary /boot partition in ext4. Then, > you can use what you want in LVM/RAID primary or extended/logical partition, > in mbr/got.... on my all systems, all partitions, included the /boot one, are in ext4; have to admit that mageia8, once booted thanks to other old systems in mageia7, works rather well; it's really a pity that this problem of update-grub couldn't be fixed; I would be very interested to know how you boot yours mga8 without bootloader (I recall that a bootloader can't be installed on mga8, at least in a bios config, even with the installer: see comment 32) to day, I'll try to install a bootloader in efi-config, by desabling the cms in the bios-efi of the mobo, with the installer; I let you inform of the result, but I have no illusion (In reply to peter lawford from comment #57) > on my all systems, all partitions, included the /boot one, are in ext4; have > to admit that mageia8, once booted thanks to other old systems in mageia7, > works rather well; it's really a pity that this problem of update-grub > couldn't be fixed; I would be very interested to know how you boot yours > mga8 without bootloader (I recall that a bootloader can't be installed on > mga8, at least in a bios config, even with the installer: see comment 32) > to day, I'll try to install a bootloader in efi-config, by desabling the cms > in the bios-efi of the mobo, with the installer; I let you inform of the > result, but I have no illusion I boot all my Mageia 8 in UEFI mode with grub2 and update-grub runs fine each kernel upgrade and/or doing this manually. All my Virtual Machines run Mageia 8 in BIOS (Legacy) mode and boot well! Update-grub on such systems also. I will test later this month a test with LVM and or software RAID mode and in BIOS mode to make sure Mageia 8 boot fine. I recall Mageia is well tested by QA members. Also, when english is difficult to speak, you are able to say it in French, Bugsquad members will translate it. (In reply to Aurelien Oudelet from comment #58) > (In reply to peter lawford from comment #57) > > on my all systems, all partitions, included the /boot one, are in ext4; have > > to admit that mageia8, once booted thanks to other old systems in mageia7, > > works rather well; it's really a pity that this problem of update-grub > > couldn't be fixed; I would be very interested to know how you boot yours > > mga8 without bootloader (I recall that a bootloader can't be installed on > > mga8, at least in a bios config, even with the installer: see comment 32) > > to day, I'll try to install a bootloader in efi-config, by desabling the cms > > in the bios-efi of the mobo, with the installer; I let you inform of the > > result, but I have no illusion > > I boot all my Mageia 8 in UEFI mode with grub2 and update-grub runs fine > each kernel upgrade and/or doing this manually. > > All my Virtual Machines run Mageia 8 in BIOS (Legacy) mode and boot well! > Update-grub on such systems also. > > I will test later this month a test with LVM and or software RAID mode and > in BIOS mode to make sure Mageia 8 boot fine. > I recall Mageia is well tested by QA members. > Also, when english is difficult to speak, you are able to say it in French, > Bugsquad members will translate it. a way to say that my english is bad! There is something in the grub.d files on that system that is causing the mga8 version of update-grub to fail, apparently going into some sort of loop. For everyone else, it's been working ok. I guess one test could be doing: mv /etc/grub.d /etc/grub.d.old urpmi --replace-packages grub2-common update-grub2 could be tested to see if it works as a "clean" install, then if that works, add back one change at a time until it stops working... (In reply to Thomas Backlund from comment #61) > I guess one test could be doing: > > mv /etc/grub.d /etc/grub.d.old > urpmi --replace-packages grub2-common > update-grub2 > > could be tested to see if it works as a "clean" install, then if that > works, add back one change at a time until it stops working... sorry, doesn't work [root@mga6-64 alain4]# mv -v /etc/grub.d/ /etc/grub.d.old renommé '/etc/grub.d/' -> '/etc/grub.d.old' root@mga6-64 alain4]# LANGUAGE=C urpmi --replace-packages grub2-common Unknown option: replace-packages Package grub2-common-2.04.0-29.mga8.x86_64 is already installed (In reply to peter lawford from comment #62) > (In reply to Thomas Backlund from comment #61) > > I guess one test could be doing: > > > > mv /etc/grub.d /etc/grub.d.old > > urpmi --replace-packages grub2-common > > update-grub2 > > > > could be tested to see if it works as a "clean" install, then if that > > works, add back one change at a time until it stops working... > > sorry, doesn't work > [root@mga6-64 alain4]# mv -v /etc/grub.d/ /etc/grub.d.old > renommé '/etc/grub.d/' -> '/etc/grub.d.old' > root@mga6-64 alain4]# LANGUAGE=C urpmi --replace-packages grub2-common > Unknown option: replace-packages > Package grub2-common-2.04.0-29.mga8.x86_64 is already installed Correct switch is --reinstall under Mageia 8 and --replacepkg un earlier version. (In reply to peter lawford from comment #62) > (In reply to Thomas Backlund from comment #61) > > I guess one test could be doing: > > > > mv /etc/grub.d /etc/grub.d.old > > urpmi --replace-packages grub2-common > > update-grub2 > > > > could be tested to see if it works as a "clean" install, then if that > > works, add back one change at a time until it stops working... > > sorry, doesn't work > [root@mga6-64 alain4]# mv -v /etc/grub.d/ /etc/grub.d.old > renommé '/etc/grub.d/' -> '/etc/grub.d.old' > root@mga6-64 alain4]# LANGUAGE=C urpmi --replace-packages grub2-common > Unknown option: replace-packages > Package grub2-common-2.04.0-29.mga8.x86_64 is already installed Sorry, I meant urpmi --replacepkgs I have found the faulty files in /etc/grub.d: it's 21_memtest86+* (the same for 20_memtest86+*) [root@mga6-64 alain4]# ls -l /etc/grub.d/ total 136 -rwxr-xr-x 1 root root 8703 mai 11 2019 00_header* -rwxr-xr-x 1 root root 236 mai 11 2019 01_users* -rwxr-xr-x 1 root root 259 avril 3 2018 02_grub-customizer_menu_color_helper* -rw-r--r-- 1 root root 10594 mai 11 2019 10_linux -rwxr-xr-x 1 root root 5151 mars 22 23:12 11_custom* -rwxr-xr-x 1 root root 10487 mai 11 2019 20_linux_xen* -rw-r--r-- 1 root root 4136 sept. 28 2018 20_memtest86+ -rw-r--r-- 1 root root 2562 mai 11 2019 20_ppc_terminfo -rwxr-xr-x 1 root root 4136 mai 31 2016 21_memtest86+* -rwxr-xr-x 1 root root 2559 déc. 1 2017 22_ppc_terminfo* -rw-r--r-- 1 root root 11817 mai 11 2019 30_os-prober -rwxr-xr-x 1 root root 5183 mars 22 23:13 40_custom* -rw-r--r-- 1 root root 218 mai 11 2019 40_custom.rpmnew -rwxr-xr-x 1 root root 220 mai 11 2019 41_custom* -rwxr-xr-x 1 root root 6131 mars 30 14:57 50_custom* -rw-r--r-- 1 root root 3462 mai 25 2020 51_custom -rw-r--r-- 1 root root 3688 mai 25 2020 55_custom drwxr-xr-x 4 root root 4096 mars 30 2018 backup/ drwxr-xr-x 2 root root 4096 mars 30 2018 bin/ drwxr-xr-x 2 root root 4096 juin 20 2018 proxifiedScripts/ -rw-r--r-- 1 root root 483 mai 21 2015 README [root@mga6-64 alain4]# ls -l /boot/grub2/ total 36 -rw-r--r-- 1 root root 158 févr. 17 12:43 custom.cfg drwxr-xr-x 2 root root 4096 févr. 17 12:43 fonts/ -rw-r--r-- 1 root root 1024 juil. 30 2017 grubenv drwxr-xr-x 2 root root 12288 déc. 23 2018 i386-pc/ drwxr-xr-x 2 root root 4096 déc. 23 2018 locale/ drwxr-xr-x 3 root root 4096 mars 13 18:58 themes/ -rw-r--r-- 1 root root 150 avril 3 2018 unicode.pf2 -rw-r--r-- 1 root root 0 mars 13 16:27 updtrans [root@mga6-64 alain4]# LC_ALL=C update-grub Création du fichier de configuration GRUB… Arrière-plan trouvé : /home/alain4/Documents/Images/images1/3.jpg [root@mga6-64 alain4]# ls -l /boot/grub2/ total 48 -rw-r--r-- 1 root root 158 févr. 17 12:43 custom.cfg drwxr-xr-x 2 root root 4096 févr. 17 12:43 fonts/ -rw------- 1 root root 8446 avril 7 19:58 grub.cfg.new -rw-r--r-- 1 root root 1024 juil. 30 2017 grubenv drwxr-xr-x 2 root root 12288 déc. 23 2018 i386-pc/ drwxr-xr-x 2 root root 4096 déc. 23 2018 locale/ drwxr-xr-x 3 root root 4096 mars 13 18:58 themes/ -rw-r--r-- 1 root root 150 avril 3 2018 unicode.pf2 -rw-r--r-- 1 root root 0 mars 13 16:27 updtrans file grub.cfg NOT created; now: [root@mga6-64 alain4]# chmod a-x /etc/grub.d/21_memtest86+ [root@mga6-64 alain4]# ls -l /etc/grub.d/ total 136 -rwxr-xr-x 1 root root 8703 mai 11 2019 00_header* -rwxr-xr-x 1 root root 236 mai 11 2019 01_users* -rwxr-xr-x 1 root root 259 avril 3 2018 02_grub-customizer_menu_color_helper* -rw-r--r-- 1 root root 10594 mai 11 2019 10_linux -rwxr-xr-x 1 root root 5151 mars 22 23:12 11_custom* -rwxr-xr-x 1 root root 10487 mai 11 2019 20_linux_xen* -rw-r--r-- 1 root root 4136 sept. 28 2018 20_memtest86+ -rw-r--r-- 1 root root 2562 mai 11 2019 20_ppc_terminfo -rw-r--r-- 1 root root 4136 mai 31 2016 21_memtest86+ -rwxr-xr-x 1 root root 2559 déc. 1 2017 22_ppc_terminfo* -rw-r--r-- 1 root root 11817 mai 11 2019 30_os-prober -rwxr-xr-x 1 root root 5183 mars 22 23:13 40_custom* -rw-r--r-- 1 root root 218 mai 11 2019 40_custom.rpmnew -rwxr-xr-x 1 root root 220 mai 11 2019 41_custom* -rwxr-xr-x 1 root root 6131 mars 30 14:57 50_custom* -rw-r--r-- 1 root root 3462 mai 25 2020 51_custom -rw-r--r-- 1 root root 3688 mai 25 2020 55_custom drwxr-xr-x 4 root root 4096 mars 30 2018 backup/ drwxr-xr-x 2 root root 4096 mars 30 2018 bin/ drwxr-xr-x 2 root root 4096 juin 20 2018 proxifiedScripts/ -rw-r--r-- 1 root root 483 mai 21 2015 README [root@mga6-64 alain4]# update-grub Création du fichier de configuration GRUB… Arrière-plan trouvé : /home/alain4/Documents/Images/images1/3.jpg fait [root@mga6-64 alain4]# ls -l /boot/grub2/ total 56 -rw-r--r-- 1 root root 158 févr. 17 12:43 custom.cfg drwxr-xr-x 2 root root 4096 févr. 17 12:43 fonts/ -rw-r--r-- 1 root root 20143 avril 7 20:01 grub.cfg -rw-r--r-- 1 root root 1024 juil. 30 2017 grubenv drwxr-xr-x 2 root root 12288 déc. 23 2018 i386-pc/ drwxr-xr-x 2 root root 4096 déc. 23 2018 locale/ drwxr-xr-x 3 root root 4096 mars 13 18:58 themes/ -rw-r--r-- 1 root root 150 avril 3 2018 unicode.pf2 -rw-r--r-- 1 root root 0 mars 13 16:27 updtrans grub.cfg is created and I've checked that its content is exactly this one of executable files in /etc/grub.d now, I don't know if memtest86+ is needed or not for the creation of the bootloader with (bios config) grub2-install /dev/sdx You can ditch memtest86+ safely. At last we have culprit. Perhaps the file is here to generate the memtest86 entry in grub2 menu but memtest86 binary was missing on this computer. Remove memtest86 files in this directory and regenerate your grub. Then you can close this. Don't close this until I see If I can recreate the problem. If so, we must ensure the package is removed on upgrade. I exists in mga7, but not 8. I can not recreate the issue. In my upgrade test, memtest86+ was replaced with pcmemtest and the file in /etc/grub.d for memtest86+ replaced too. Oops. Spoke too soon. I was watching the upgrade, checked the packages and
/etc/grub.d which were ok, but hadn't rebooted yet.
# grep memtest /boot/grub2/grub.cfg
### BEGIN /etc/grub.d/20_memtest86+ ###
menuentry 'Mageia Memtest memtest86+-5.01' {
echo 'Loading Mageia Memtest memtest86+-5.01 ...'
knetbsd /boot/elf-memtest86+-5.01
### END /etc/grub.d/20_memtest86+ ###
### BEGIN /etc/grub.d/20_pcmemtest ###
echo 'Loading pcmemtest ...'
linux32 /boot/pcmemtest
### END /etc/grub.d/20_pcmemtest ###
# ll /etc/grub.d
total 92
-rwxr-xr-x 1 root root 9346 Feb 17 06:43 00_header*
-rwxr-xr-x 1 root root 236 Feb 17 06:43 01_users*
-rwxr-xr-x 1 root root 835 Feb 17 06:43 08_fallback_counting*
-rwxr-xr-x 1 root root 11771 Feb 17 06:43 10_linux*
-rwxr-xr-x 1 root root 833 Feb 17 06:43 10_reset_boot_success*
-rwxr-xr-x 1 root root 892 Feb 17 06:43 12_menu_auto_hide*
-rwxr-xr-x 1 root root 410 Feb 17 06:43 14_menu_show_once*
-rwxr-xr-x 1 root root 12285 Feb 17 06:43 20_linux_xen*
-rwxr-xr-x 1 root root 3429 Dec 12 05:34 20_pcmemtest*
-rwxr-xr-x 1 root root 2562 Feb 17 06:43 20_ppc_terminfo*
-rwxr-xr-x 1 root root 10673 Feb 17 06:43 30_os-prober*
-rwxr-xr-x 1 root root 1415 Feb 17 06:43 30_uefi-firmware*
-rwxr-xr-x 1 root root 218 Feb 17 06:43 40_custom*
-rwxr-xr-x 1 root root 220 Feb 17 06:43 41_custom*
# update-grub
Generating grub configuration file ...
Found theme: /boot/grub2/themes/maggy/theme.txt
Found linux image: /boot/vmlinuz-5.10.27-desktop-1.mga8
Found initrd image: /boot/initrd-5.10.27-desktop-1.mga8.img
Found linux image: /boot/vmlinuz-5.10.27-desktop-1.mga7
Found initrd image: /boot/initrd-5.10.27-desktop-1.mga7.img
Found linux image: /boot/vmlinuz-5.10.25-desktop-1.mga7
Found initrd image: /boot/initrd-5.10.25-desktop-1.mga7.img
Found linux image: /boot/vmlinuz-5.10.19-desktop-1.mga7
Found initrd image: /boot/initrd-5.10.19-desktop-1.mga7.img
Found linux image: /boot/vmlinuz-desktop
Found initrd image: /boot/initrd-desktop.img
Found pcmemtest image: /boot/pcmemtest
done
[root@localhost grub2]# grep memtest /boot/grub2/grub.cfg
### BEGIN /etc/grub.d/20_pcmemtest ###
echo 'Loading pcmemtest ...'
linux32 /boot/pcmemtest
### END /etc/grub.d/20_pcmemtest ###
I didn't recreate the problem of update-grub not working, but it appears
update grub was run after pcmemtest was installed, but before memtest86+
was removed.
(In reply to Aurelien Oudelet from comment #58) > (In reply to peter lawford from comment #57) > > on my all systems, all partitions, included the /boot one, are in ext4; have > > to admit that mageia8, once booted thanks to other old systems in mageia7, > > works rather well; it's really a pity that this problem of update-grub > > couldn't be fixed; I would be very interested to know how you boot yours > > mga8 without bootloader (I recall that a bootloader can't be installed on > > mga8, at least in a bios config, even with the installer: see comment 32) > > to day, I'll try to install a bootloader in efi-config, by desabling the cms > > in the bios-efi of the mobo, with the installer; I let you inform of the > > result, but I have no illusion > > I boot all my Mageia 8 in UEFI mode with grub2 and update-grub runs fine > each kernel upgrade and/or doing this manually. > > All my Virtual Machines run Mageia 8 in BIOS (Legacy) mode and boot well! > Update-grub on such systems also. > > I will test later this month a test with LVM and or software RAID mode and > in BIOS mode to make sure Mageia 8 boot fine. > I recall Mageia is well tested by QA members. > Also, when english is difficult to speak, you are able to say it in French, > Bugsquad members will translate it. Hi Aurelien, take it easy with my comment; feel free to tell me if you can't understand my english, I'm not expert in which; I use this language like everybody, in fact it would better to say globish than english |