[opensuse] Grub error when booting secondary openSUSE linux system.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, In my laptop I have Win 10, OS 13.1, and 42.2 RC2; the later just installed and doesn't boot. In 13.1 I have grub 1, with this entry that has worked for years: title openSUSE Factory (/dev/sda9) via chainloader rootnoverify (hd0,8) chainloader +1 but now produces this error: Error 13: Invalid or unsupported executable format press any key to continue The documentation says: 13 : Invalid or unsupported executable format This error is returned if the kernel image being loaded is not recognized as Multiboot or one of the supported native formats (Linux zImage or bzImage, FreeBSD, or NetBSD). which I fail to understand. There should not be a kernel there, but grub2. Attached is the information from bootinfoscript. In partition sda9 is installed Leap 42.2 RC2, and grub "should" be installed just there, but I am not sure it was. The RC2 installer has changed and I'm unsure what it did. I'll describe it. Leap 42.2 RC2 boot settings (installation settings window) (/dev/sda9) (photos available) +++---------------- Booting The installer will not modify the MBR of the disk. Unless it already contains boot code, the BIOS won't be able to boot from this disk. * Bot loader type: grub2 * Enable trusted boot: no * Change location: * Do not install bootcode into MBR (install) * Warning: No location for bootloader stage 1 selected. Unless you know what you are doing please select another location * Order of hard disks: /dev/sda, /dev/sdb - ----------------++- This is wrong, so I click on "Booting" and modify it. +++---------------- Boot code options (photo available on request) Boot loader Location [ ] Boot from master boot record [X] Custom boot partition [/dev/sda9 ] [ ] Set active flag in partition table for boot partition [ ] Write generic boot code to MBR [ ] Enable trusted boot support - ----------------++- Notice that changing the tab clears the modification in this tab. I have to select "Accept", which renders: +++---------------- Booting The installer will not modify the MBR of the disk. Unless it already contains boot code, the BIOS won't be able to boot from this disk. * Bot loader type: grub2 * Enable trusted boot: no * Status location: /dev/sda9 ("/") * Change location: * Do not install bootcode into MBR (install) * Order of hard disks: /dev/sda, /dev/sdb - ----------------++- On previous years, there was a list of choices to boot from, like "boot from root partition", which is what I wanted to do. I can not permit the installer to modify the MBR, which is customized. Touch it and booting breaks. Now there is a line where to type the "custom boot partition". It is possible that YaST did not write the grub images at all anywhere. So I'm not totally sure of what happened. If the problem is in grub1 in the main system (13.1) or in the new 42.2 grub 2. - -- Cheers Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlgnxsIACgkQja8UbcUWM1xXggD/ZRWPgYKEdW2H5sI/39j0Qn/Q EHb/YonqT53lEuhAnzoA/14bToOg4IfgPvIZCGnfpIebK8wH1Qk9Ox2bXyY83Pgn =hom6 -----END PGP SIGNATURE-----
Will it boot if you try to load the new kernel and initrd directly from 13.1's Grub instead of chainloading? title openSUSE TW default kernel on sda9 root (hd0,8) kernel /boot/vmlinuz showopts root=/dev/sda9 splash=0 initrd /boot/initrd TW still provides Grub Legacy. All my TW installations have Grub2 tabooed and boot either from chainloading TW's Grub Legacy, or directly from Grub Legacy on a primary that I maintain and never mount as /boot. One other possibility, without trying to digest your attachment, is that EXT4 recently acquired a new filesystem option that (AFAIK, but maybe only applicable to Debian?) Grub Legacy does not support. Maybe your new XFS has done similarly? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2016-11-13 03:14, Felix Miata wrote:
Will it boot if you try to load the new kernel and initrd directly from 13.1's Grub instead of chainloading?
title openSUSE TW default kernel on sda9 root (hd0,8) kernel /boot/vmlinuz showopts root=/dev/sda9 splash=0 initrd /boot/initrd
Good idea. So I added the entry and rebooted. Fails: Error 17: Cannot mount selected partition 17 : Cannot mount selected partition This error is returned if the partition requested exists, but the filesystem type cannot be recognized by GRUB. Maybe XFS is not supported? I thought it was.
TW still provides Grub Legacy. All my TW installations have Grub2 tabooed and boot either from chainloading TW's Grub Legacy, or directly from Grub Legacy on a primary that I maintain and never mount as /boot.
It is not TW, but Leap. True, the old entry in menu.lst says "Factory" because sda9 is the partition where I tried factory when it was called that way, years ago. I installed Leap 42.2 RC2 there to try it, in the same partition: thus no changes needed to grub1, I thought.
One other possibility, without trying to digest your attachment, is that EXT4 recently acquired a new filesystem option that (AFAIK, but maybe only applicable to Debian?) Grub Legacy does not support. Maybe your new XFS has done similarly?
Dunno, maybe I should install to ext4 as always. - -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" (Minas Tirith)) -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iF4EAREIAAYFAlgn1asACgkQja8UbcUWM1y/OQD+OqK5MkKpIyDJLQ6IQcVrQw3f Cj/dwc1BhGxxrZC5ZxMA/2ezZmAhgb68QPM3xBttwcwxpcHyzFcBWAt3X48BdrJT =wwoO -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Carlos E. R. composed on 2016-11-13 03:53 (UTC+0100):
...maybe I should install to ext4 as always.
I've yet to try XFS (or BTRFS) for anything. EXT2/3/4 WFM. I don't remember what that new EXT4 filesystem option is, so I format in advance of installation with something older than 42.1. Formatting in advance I've done already for many years for other reasons. Is the Grub you're booting from actually 13.1's and not a relic from an older release? BTDT -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-11-13 04:34, Felix Miata wrote:
Carlos E. R. composed on 2016-11-13 03:53 (UTC+0100):
...maybe I should install to ext4 as always.
I've yet to try XFS (or BTRFS) for anything. EXT2/3/4 WFM.
I use XFS a lot, but it is the first time I attempt to boot from it. Perhaps I tried several (many?) years ago. There was a problem long time solved. Usually I would have used a separate small boot partition with ext2, but this time I don't have space for it. So I wanted to try it.
I don't remember what that new EXT4 filesystem option is, so I format in advance of installation with something older than 42.1. Formatting in advance I've done already for many years for other reasons.
I know, but I never do. I prefer to format with the same release as the installed system. The exception is when the install media will not boot and requires a swap in advance.
Is the Grub you're booting from actually 13.1's and not a relic from an older release? BTDT
Indeed 13.1's Grub. It is the second big bug/problem I find with 42.2, in the same machine. The first one: you can not install using Labels, the installer crashes. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
13.11.2016 05:53, Carlos E. R. пишет:
On 2016-11-13 03:14, Felix Miata wrote:
Will it boot if you try to load the new kernel and initrd directly from 13.1's Grub instead of chainloading?
title openSUSE TW default kernel on sda9 root (hd0,8) kernel /boot/vmlinuz showopts root=/dev/sda9 splash=0 initrd /boot/initrd
Good idea. So I added the entry and rebooted. Fails:
Error 17: Cannot mount selected partition
17 : Cannot mount selected partition This error is returned if the partition requested exists, but the filesystem type cannot be recognized by GRUB.
Maybe XFS is not supported? I thought it was.
On-disk XFS format has changed since grub legacy. grub2 was patched (by SUSE employee) to support it. If anyone cares about grub legacy, this should be done too.
Carlos E. R. composed on 2016-11-13 03:53 (UTC+0100):
Felix Miata wrote:
Will it boot if you try to load the new kernel and initrd directly from 13.1's Grub instead of chainloading?
title openSUSE TW default kernel on sda9 root (hd0,8) kernel /boot/vmlinuz showopts root=/dev/sda9 splash=0 initrd /boot/initrd
Good idea. So I added the entry and rebooted. Fails:
Error 17: Cannot mount selected partition
17 : Cannot mount selected partition This error is returned if the partition requested exists, but the filesystem type cannot be recognized by GRUB.
Maybe XFS is not supported? I thought it was.
I guess not. If you need it booted before reinstalling to EXT4, or whatever else it takes, you could copy the kernel and initrd to a supported partition and use Grub to load the copies. On host gx62b I created a new XFS partition, rsync'd its 42.2 installation to it, updated target's fstab, grub.conf and menu.lst, created master partition boot entries for direct, configfile and chainload, and tried booting it from whatever grub package was created 2012-07-16 and installed on the host's master boot partition. I'm guessing it's 12.2RC1 or 2. Interesting difference in space usage for identical 5600.8 MiB partition sizes: /dev/sda27 5655815 4057708 1311350 76% /disks/s422 (EXT3) /dev/sda30 5724932 4274664 1450268 75% /mnt (XFS) Booting loading directly from Grub failed, initializing, but dumping at emergency shell unable to mount /sysroot. I guessed initrd needed XFS support that wouldn't have been included, since xfsprogs was not installed, so via chroot I installed it, rebuilt initrd and tried again. Success (with root=LABEL=30xfstst on cmdline). From there I ran grub 0.97-208.3 setup on sda30, without noticing anything that looked like an unexpected error message (I'm used to seeing 2 "embed...failed...this is not fatal" messages from every setup command), then rebooted to try chainloading. That dumped me back at the text version of the master Grub boot menu, but configfile works as expected. I upgraded my master grub to 13.1's, but chainloading to the XFS from it still doesn't work. Instead of dumping me back to the master's text menu, I get a grub> prompt. :-p Worse, loading directly as previously no longer works, dumping me back to the master grub text menu. Same with configfile. Trying directly via the text menu instead of gfxboot, I get the Error 17: Cannot mount selected partition you got. :-( Looks like trying to setup Grub on sda30 from 13.1 destroyed it. Nothing seems to be able to find any filesystem on it. blkid simply says /dev/sda30: PTTYPE="dos". Too bad I didn't see Andrei's replies first. :-p But, it was only a test. Not sure the lesson here. At least its original 42.2 and 13.1 still work as expected. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
13.11.2016 04:49, Carlos E. R. пишет:
Hi,
In my laptop I have Win 10, OS 13.1, and 42.2 RC2; the later just installed and doesn't boot.
In 13.1 I have grub 1, with this entry that has worked for years:
title openSUSE Factory (/dev/sda9) via chainloader rootnoverify (hd0,8) chainloader +1
but now produces this error:
Error 13: Invalid or unsupported executable format press any key to continue
The documentation says:
13 : Invalid or unsupported executable format This error is returned if the kernel image being loaded is not recognized as Multiboot or one of the supported native formats (Linux zImage or bzImage, FreeBSD, or NetBSD).
which I fail to understand. There should not be a kernel there, but grub2.
Attached is the information from bootinfoscript.
First question offtopic: => No known boot loader is installed in the MBR of /dev/sda. Do you remember how you installed MBR here? I would like to add this boot block to the list of know ones. sda9: __________________________________________________________________________ File system: xfs Boot sector type: - Boot sector info: XFS does not support booting from partition - it does not have any place to put boot block into. ...
+++---------------- Booting
The installer will not modify the MBR of the disk. Unless it already contains boot code, the BIOS won't be able to boot from this disk.
* Bot loader type: grub2 * Enable trusted boot: no * Status location: /dev/sda9 ("/") * Change location: * Do not install bootcode into MBR (install) * Order of hard disks: /dev/sda, /dev/sdb ----------------++-
On previous years, there was a list of choices to boot from, like "boot from root partition", which is what I wanted to do. I can not permit the installer to modify the MBR, which is customized. Touch it and booting breaks.
Now there is a line where to type the "custom boot partition". It is possible that YaST did not write the grub images at all anywhere.
This is a bug. Installer should not offer XFS for first stage install. Please open bug report.
13.11.2016 09:56, Andrei Borzenkov пишет:
First question offtopic:
=> No known boot loader is installed in the MBR of /dev/sda.
Do you remember how you installed MBR here? I would like to add this boot block to the list of know ones.
OK, this is Syslinux altmbr. Could you please test https://github.com/arvidjaar/bootinfoscript/tree/altmbr (note, this is different branch) - it should now detect it and also display embedded boot partition. Thank you!
On 2016-11-13 07:56, Andrei Borzenkov wrote:
Attached is the information from bootinfoscript.
First question offtopic:
=> No known boot loader is installed in the MBR of /dev/sda.
Do you remember how you installed MBR here? I would like to add this boot block to the list of know ones.
Yes, of course. :-) https://nwrickert2.wordpress.com/2015/06/15/generic-boot-code/ It is altmbr.bin from syslinux with this modification: echo -e -n '\004' > x ### should create x as a 1 byte binary 4 cat /usr/share/syslinux/altmbr.bin x > altmbr.4 which is then installed in the MBR. It boots partition 4, ignoring the boot mark, which is on partition 1, as you saw, which would boot Windows. This manner Windows is fooled and happy and does its updates without complain, but boot is handled by Grub in partition 4 :-) From this thread: Message-ID: <5718D8DF.1050702@ameritech.net> https://lists.opensuse.org/opensuse/2016-04/msg01023.html
sda9: __________________________________________________________________________
File system: xfs
Boot sector type: -
Boot sector info:
XFS does not support booting from partition - it does not have any place to put boot block into.
I thought that had been solved ages ago. :-?
+++---------------- Booting
The installer will not modify the MBR of the disk. Unless it already contains boot code, the BIOS won't be able to boot from this disk.
* Bot loader type: grub2 * Enable trusted boot: no * Status location: /dev/sda9 ("/") * Change location: * Do not install bootcode into MBR (install) * Order of hard disks: /dev/sda, /dev/sdb ----------------++-
On previous years, there was a list of choices to boot from, like "boot from root partition", which is what I wanted to do. I can not permit the installer to modify the MBR, which is customized. Touch it and booting breaks.
Now there is a line where to type the "custom boot partition". It is possible that YaST did not write the grub images at all anywhere.
This is a bug. Installer should not offer XFS for first stage install. Please open bug report.
Installer did not offer anything at all except MBR. I had to type the entry. I have photos of the sequence. Maybe I can email them to you, off list, so that you understand what happened? -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
13.11.2016 16:52, Carlos E. R. пишет: ...
XFS does not support booting from partition - it does not have any place to put boot block into.
I thought that had been solved ages ago. :-?
Solved what exactly? The first sector in XFS partition cannot be used and grub2 installs boot sector in the first sector of partition. So it cannot install boot sector on XFS partition. ...
Now there is a line where to type the "custom boot partition". It is possible that YaST did not write the grub images at all anywhere.
This is a bug. Installer should not offer XFS for first stage install. Please open bug report.
Installer did not offer anything at all except MBR.
So installer behaved correctly.
I had to type the entry.
Well, it does not change the fact that you cannot install grub2 on XFS partition. I expect installer to at least warn you at this point. Which turns it into feature request. I have photos of the sequence. Maybe I can email them to you, off
list, so that you understand what happened?
I do understand what happened.
On 2016-11-13 15:47, Andrei Borzenkov wrote:
13.11.2016 16:52, Carlos E. R. пишет: ...
XFS does not support booting from partition - it does not have any place to put boot block into.
I thought that had been solved ages ago. :-?
Solved what exactly? The first sector in XFS partition cannot be used and grub2 installs boot sector in the first sector of partition. So it cannot install boot sector on XFS partition.
Well, I thought that had changed.
...
Now there is a line where to type the "custom boot partition". It is possible that YaST did not write the grub images at all anywhere.
This is a bug. Installer should not offer XFS for first stage install. Please open bug report.
Installer did not offer anything at all except MBR.
So installer behaved correctly.
But said nothing to clarify the situation.
I had to type the entry.
Well, it does not change the fact that you cannot install grub2 on XFS partition. I expect installer to at least warn you at this point. Which turns it into feature request.
I have photos of the sequence. Maybe I can email them to you, off
list, so that you understand what happened?
I do understand what happened.
Now _I_ understand, after I repeated the installation to an ext4. When done on an ext4 partition, the installer has a proposal to place grub in the partition. It was not clear to me at all why this line was missing when the partition was XFS. I thought it was a bug of the installer, not an intentional thing. However, the proposal also wanted to write generic code to the MBR and set active partition for the boot partition (which is a logical partition). This would have destroyed the ability of my computer from booting. I also miss on the initial proposal the possibility of "replacing" a previous installation. This would mean reading and importing fstab entries, users (this it does), patterns, ssh keys (it imported the ssh from _another_ install), boot settings... Having to enter all that data several times is, er... entertaining. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
14.11.2016 00:05, Carlos E. R. пишет:
However, the proposal also wanted to write generic code to the MBR and set active partition for the boot partition (which is a logical partition). This would have destroyed the ability of my computer from booting.
Generic code is Syslinux that is capable of booting from logical partition, so I am not convinced this would have destroyed the ability to boot.
On 2016-11-14 04:20, Andrei Borzenkov wrote:
14.11.2016 00:05, Carlos E. R. пишет:
However, the proposal also wanted to write generic code to the MBR and set active partition for the boot partition (which is a logical partition). This would have destroyed the ability of my computer from booting.
Generic code is Syslinux that is capable of booting from logical partition, so I am not convinced this would have destroyed the ability to boot.
Yes. Mmmm. It would have marked partition 9 as bootable. The main Grub might be inaccessible (#4). I would have perhaps to restore the MBR from backup in another partition, and restore the boot mark. I think that the default should be not to touch the MBR if it exists (not new disk). The fact that was going to be written was not on the main screen, but on the second, hidden from view. -- Cheers/Saludos Carlos E. R. (testing openSUSE Leap 42.2, at Minas-Anor) -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
13.11.2016 16:52, Carlos E. R. пишет:
On 2016-11-13 07:56, Andrei Borzenkov wrote:
Attached is the information from bootinfoscript.
First question offtopic:
=> No known boot loader is installed in the MBR of /dev/sda.
Do you remember how you installed MBR here? I would like to add this boot block to the list of know ones.
Yes, of course. :-)
https://nwrickert2.wordpress.com/2015/06/15/generic-boot-code/
It is altmbr.bin from syslinux with this modification:
echo -e -n '\004' > x ### should create x as a 1 byte binary 4 cat /usr/share/syslinux/altmbr.bin x > altmbr.4
which is then installed in the MBR. It boots partition 4, ignoring the boot mark, which is on partition 1, as you saw, which would boot Windows.
I released new bootinfoscript version that detects it and displays embedded partition number. Thank you for testing!
Andrei Borzenkov composed on 2016-11-14 20:07 (UTC+0300):
I released new bootinfoscript version that detects it and displays embedded partition number. Thank you for testing!
On https://sourceforge.net/projects/bootinfoscript/ only the raw file https://raw.githubusercontent.com/arvidjaar/bootinfoscript/master/bootinfosc... has changed. https://github.com/arvidjaar/bootinfoscript has no obvious compressed archive. Raw 0.75 is 3.78X the size of 0.61 .tar.gz. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, Nov 14, 2016 at 11:27 PM, Felix Miata
Andrei Borzenkov composed on 2016-11-14 20:07 (UTC+0300):
I released new bootinfoscript version that detects it and displays embedded partition number. Thank you for testing!
I use github, I do not have write access to sf project and maintainer did not respond since years.
only the raw file https://raw.githubusercontent.com/arvidjaar/bootinfoscript/master/bootinfosc... has changed.
https://github.com/arvidjaar/bootinfoscript has no obvious compressed archive. Raw 0.75 is 3.78X the size of 0.61 .tar.gz. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-11-14 18:07, Andrei Borzenkov wrote:
13.11.2016 16:52, Carlos E. R. пишет:
I released new bootinfoscript version that detects it and displays embedded partition number. Thank you for testing!
Welcome :-) -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
participants (3)
-
Andrei Borzenkov -
Carlos E. R. -
Felix Miata