[opensuse-factory] Leap 42.1 Bootloader/Grub2 installation failed to boot
I have experienced that installation of a second openSUSE version (for dual-boot) looze the menu.lst and fails to boot after the installation. I have also found a work-around to fix this, but I'm afraid unexperienced openSUSE users can give up and drop openSUSE for further testing if and when this happends. Therefore I wonder if the installation can be made more robust to avoid this confusing issue. Scenario: 1) On my hp laptop the SSD disk (sda 150G) was sliced in six partitions and applied as follows for a first installed andworking openSUSE 13.2: /dev/sda1 2G swap /dev/sda2 20G / (root for openSUSE 13.2) /dev/sda3 40G /home /dev/sda4 87G (Extended) /dev/sda5 20G (available for second root) /dev/sda6 67G /data (additional user data) 2) Next I installed Leap 42.1 M2 from the DVD, selected Expert partitioning, imported existing mount points and selected /dev/sda5 formatted ext4 as root for Leap /dev/sda3 unformatted and mounted as shared /home for 13.2 and Leap (yes I know the shared /home has some drawbacks but more benefits in my opinion) Beyond adding some extra appliactions and setup SSH, the installation else was kept as default. I didn't change anything regarding the bootloader installation. The installation went ok until the first reboot, the it stopped on the black console sreen after the word 'GRUB' and nothing else. I tried to startup again and the same happened; no GRUB menu.lst didn't become available. That is, neither the previous working openSUSE 13.2 nor 42.1 could be started. 3) Workaround: What I have found that works (mostly alsways) to fix boot problems, is to run an Upgrade installation from the 13.2 DVD by re-enabling all previous online repositories one by one (there should have been an single option to easier re-enable all !?). The upgrade then doesn't change anything than reinstall the boot-loader at the end. And after first reboot, the GRUB menu is back containing both 13.2 (default) and 42.1 boot options as it should. Can this issue be avoided to make dual or multiboot installations easier? 4) For one or another reason the same boot-issue doesn't happend on my stationary workstation with tripple boot setup between 13.2 - Tumbleweed and 42.1 over more internal disks. Though I have to run Upgrade from the 13.2 DVD afterwards as I want 13.2 to be kept as the be the default boot option (I guess there is another way to edit this). And after upgrade of i.e the TW kernel version I also have to run mkconfig on 13.2 to update the menu.lst Thanks, Terje J. Hanssen -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op zondag 6 september 2015 16:54:33 schreef Terje J. Hanssen:
Running TW in a same kind of setup, i.e. with two TW installs. This doesn't happen here. With the remark that the GRUB2 active config is in the last installed one. menu.lst is deprecated in grub2, so there must be something else in your setup during install that's causing this. -- Gertjan Lettink, a.k.a. Knurpht Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06. sep. 2015 17:34, Knurpht - Gertjan Lettink wrote:
Op zondag 6 september 2015 16:54:33 schreef Terje J. Hanssen: Running TW in a same kind of setup, i.e. with two TW installs. This doesn't happen here. With the remark that the GRUB2 active config is in the last installed one. menu.lst is deprecated in grub2, so there must be something else in your setup during install that's causing this.
Sorry, I meant the 'boot menu' displayed from grub.cfg. My stationary installation works as you describe. Here is an extract from the grub.cfg on my laptop with the installation issue: cat /boot/grub2/grub.cfg | grep menuentry if [ x"${feature_menuentry_id}" = xy ]; then menuentry_id_option="--id" menuentry_id_option="" export menuentry_id_option menuentry 'openSUSE' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-8fb9976c-9970-4397-8c26-b21a43893bf8' { submenu 'Advanced options for openSUSE' --hotkey=1 $menuentry_id_option 'gnulinux-advanced-8fb9976c-9970-4397-8c26-b21a43893bf8' { menuentry 'openSUSE, with Linux 4.1.6-9-desktop' --hotkey=2 --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.1.6-9-desktop-advanced-8fb9976c-9970-4397-8c26-b21a43893bf8' { menuentry 'openSUSE 13.2 (x86_64) (on /dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-ebff1a1c-e6d7-4dcf-987e-5b8f6b288dfb' { submenu 'Advanced options for openSUSE 13.2 (x86_64) (on /dev/sda2)' $menuentry_id_option 'osprober-gnulinux-advanced-ebff1a1c-e6d7-4dcf-987e-5b8f6b288dfb' { menuentry 'openSUSE 13.2 (/dev/sda2) (on /dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-3.16.7-7-desktop--ebff1a1c-e6d7-4dcf-987e-5b8f6b288dfb' { menuentry 'openSUSE 13.2 (/dev/sda2), with Linux 3.16.7-7-desktop (on /dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-3.16.7-7-desktop--ebff1a1c-e6d7-4dcf-987e-5b8f6b288dfb' { menuentry 'openSUSE 13.2 (/dev/sda2), with Linux 3.16.7-7-desktop (recovery mode) (on /dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-3.16.7-7-desktop--ebff1a1c-e6d7-4dcf-987e-5b8f6b288dfb' { menuentry 'openSUSE 13.2 (/dev/sda2), with Linux 3.16.6-2-desktop (on /dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-3.16.6-2-desktop--ebff1a1c-e6d7-4dcf-987e-5b8f6b288dfb' { menuentry 'openSUSE 13.2 (/dev/sda2), with Linux 3.16.6-2-desktop (recovery mode) (on /dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-3.16.6-2-desktop--ebff1a1c-e6d7-4dcf-987e-5b8f6b288dfb' { Thanks, Terje J. Hanssen -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Op zondag 6 september 2015 18:22:27 schreef Terje J. Hanssen:
On 06. sep. 2015 17:34, Knurpht - Gertjan Lettink wrote:
Op zondag 6 september 2015 16:54:33 schreef Terje J. Hanssen: Running TW in a same kind of setup, i.e. with two TW installs. This doesn't happen here. With the remark that the GRUB2 active config is in the last installed one. menu.lst is deprecated in grub2, so there must be something else in your setup during install that's causing this.
Sorry, I meant the 'boot menu' displayed from grub.cfg. My stationary installation works as you describe.
Here is an extract from the grub.cfg on my laptop with the installation issue:
cat /boot/grub2/grub.cfg | grep menuentry
if [ x"${feature_menuentry_id}" = xy ]; then menuentry_id_option="--id" menuentry_id_option="" export menuentry_id_option menuentry 'openSUSE' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-8fb9976c-9970-4397-8c26-b21a43893bf8' { submenu 'Advanced options for openSUSE' --hotkey=1 $menuentry_id_option 'gnulinux-advanced-8fb9976c-9970-4397-8c26-b21a43893bf8' { menuentry 'openSUSE, with Linux 4.1.6-9-desktop' --hotkey=2 --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.1.6-9-desktop-advanced-8fb9976c-9970-4397-8c26-b21a43893bf8' { menuentry 'openSUSE 13.2 (x86_64) (on /dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-ebff1a1c-e6d7-4dcf-987e-5b8f6b288dfb' { submenu 'Advanced options for openSUSE 13.2 (x86_64) (on /dev/sda2)' $menuentry_id_option 'osprober-gnulinux-advanced-ebff1a1c-e6d7-4dcf-987e-5b8f6b288dfb' { menuentry 'openSUSE 13.2 (/dev/sda2) (on /dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-3.16.7-7-desktop--ebff1a1c-e6d7-4dcf-987e-5 b8f6b288dfb' { menuentry 'openSUSE 13.2 (/dev/sda2), with Linux 3.16.7-7-desktop (on /dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-3.16.7-7-desktop--ebff1a1c-e6d7-4dcf-987e-5 b8f6b288dfb' { menuentry 'openSUSE 13.2 (/dev/sda2), with Linux 3.16.7-7-desktop (recovery mode) (on /dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-3.16.7-7-desktop--ebff1a1c-e6d7-4dcf-987e-5 b8f6b288dfb' { menuentry 'openSUSE 13.2 (/dev/sda2), with Linux 3.16.6-2-desktop (on /dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-3.16.6-2-desktop--ebff1a1c-e6d7-4dcf-987e-5 b8f6b288dfb' { menuentry 'openSUSE 13.2 (/dev/sda2), with Linux 3.16.6-2-desktop (recovery mode) (on /dev/sda2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-3.16.6-2-desktop--ebff1a1c-e6d7-4dcf-987e-5 b8f6b288dfb' {
Thanks, Terje J. Hanssen
If you edit manually, a kernel update would destroy those "fixes". Use Yast's bootloader module, or edit /etc/default/grub.cfg,, then run grub2-mkconfig. -- Gertjan Lettink, a.k.a. Knurpht Official openSUSE Member openSUSE Forums Team -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Den 06. sep. 2015 20:37, skrev Knurpht - Gertjan Lettink:
If you edit manually, a kernel update would destroy those "fixes". Use Yast's bootloader module, or edit /etc/default/grub.cfg,, then run grub2-mkconfig.
Ok, I know. This was the from the file created during the 42.1 installation, just to show it exists, even that the boot menu was not displayed after reboot. ---- Terje J. Hanssen -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Отправлено с iPhone
The installation went ok until the first reboot, the it stopped on the black console sreen after the word 'GRUB' and nothing else.
Common reason is having multiple devices for boot location in boot loader setup. But there is not enough information to draw any conclusion. Information had to be gathered when your system failed to boot, not after you have fixed it ...
I tried to startup again and the same happened; no GRUB menu.lst didn't become available. That is, neither the previous working openSUSE 13.2 nor 42.1 could be started.
3) Workaround: What I have found that works (mostly alsways) to fix boot problems, is to run an Upgrade installation from the 13.2 DVD by re-enabling all previous online repositories one by one (there should have been an single option to easier re-enable all !?). The upgrade then doesn't change anything than reinstall the boot-loader at the end. And after first reboot, the GRUB menu is back containing both 13.2 (default) and 42.1 boot options as it should.
Can this issue be avoided to make dual or multiboot installations easier?
4) For one or another reason the same boot-issue doesn't happend on my stationary workstation with tripple boot setup between 13.2 - Tumbleweed and 42.1 over more internal disks. Though I have to run Upgrade from the 13.2 DVD afterwards as I want 13.2 to be kept as the be the default boot option (I guess there is another way to edit this). And after upgrade of i.e the TW kernel version I also have to run mkconfig on 13.2 to update the menu.lst
Thanks, Terje J. Hanssen
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Terje J. Hanssen composed on 2015-09-06 16:54 (UTC+0200):
I have experienced that installation of a second openSUSE version (for dual-boot) looze the menu.lst and fails to boot after the installation. I have also found a work-around to fix this, but I'm afraid unexperienced openSUSE users can give up and drop openSUSE for further testing if and when this happends. Therefore I wonder if the installation can be made more robust to avoid this confusing issue.
In my experience, all Linux installers could and should do better WRT assumptions applied when the installation target lives in a multiboot environment. Likely UEFI will eventually obsolete some of those assumptions, but others will survive, while BIOS systems will be around for a while yet.
Scenario: 1) On my hp laptop the SSD disk (sda 150G) was sliced in six partitions and applied as follows for a first installed andworking openSUSE 13.2:
/dev/sda1 2G swap
Above is one of the more perverse default BIOS installation behaviors. Primary partitions have special significance in BIOS installations. Those shouldn't be wasted on a swap partition. Swap belongs on sdX5 whenever possible, close to front of disk for high speed, but not wasting a primary partition table entry.
/dev/sda2 20G / (root for openSUSE 13.2) /dev/sda3 40G /home /dev/sda4 87G (Extended) /dev/sda5 20G (available for second root)
https://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_u... alludes to the problem with the above partitioning. The default configuration sustains well on a BIOS system only when there is no more than one Linux installation, and when there is no non-Linux installation, on the boot/primary storage media, so that it doesn't matter where the bootloader gets installed. Once a second system is introduced, defaults cause conflict over what does and should control the boot process. When instead at least two primaries are utilized for partitions that can readily host a Linux bootloader, and a third if necessary for a Windows bootloader, damage to be caused by a second or successive operating system installation can be held to virtual zero. Each primary can host a bootloader, and boot control can be selected/managed by the virtually painless process of moving the boot flag to the desired partition, leaving the MBR code block populated by generic startup code rather than any more complicated and dependant code such as that placed there and in the space immediately following by Grub2.
/dev/sda6 67G /data (additional user data)
2) Next I installed Leap 42.1 M2 from the DVD, selected Expert partitioning, imported existing mount points and selected
/dev/sda5 formatted ext4 as root for Leap /dev/sda3 unformatted and mounted as shared /home for 13.2 and Leap (yes I know the shared /home has some drawbacks but more benefits in my opinion)
Beyond adding some extra appliactions and setup SSH, the installation else was kept as default. I didn't change anything regarding the bootloader installation.
The installation went ok until the first reboot, the it stopped on the black console sreen after the word 'GRUB' and nothing else. I tried to startup again and the same happened; no GRUB menu.lst didn't become available. That is, neither the previous working openSUSE 13.2 nor 42.1 could be started.
Sad but typical result of usurpation caused by Gru* instead of legacy code in the MBR, and not thinking ahead from the point of initial OS installation. It's avoidable by thoughtful partitioning in advance of installing anything. ...
Can this issue be avoided to make dual or multiboot installations easier?
1-Boot agnostically from a primary instead of from MBR. 2-Reserve primaries for use by partitions that might ever be booted from. 3-If eventually the system will be true multiboot, more than one Linux, or more than two anything, consider using one primary for a partition to be used mounted to /boot at most only until a second OS will be installed, and afterwards reserve it for what can be crudely described as chainloader-only service, to be managed by the sysadmin instead of directly by any OS. -- "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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sun, Sep 6, 2015 at 9:47 PM, Felix Miata
Terje J. Hanssen composed on 2015-09-06 16:54 (UTC+0200):
I have experienced that installation of a second openSUSE version (for dual-boot) looze the menu.lst and fails to boot after the installation. I have also found a work-around to fix this, but I'm afraid unexperienced openSUSE users can give up and drop openSUSE for further testing if and when this happends. Therefore I wonder if the installation can be made more robust to avoid this confusing issue.
In my experience, all Linux installers could and should do better WRT assumptions applied when the installation target lives in a multiboot environment. Likely UEFI will eventually obsolete some of those assumptions, but others will survive, while BIOS systems will be around for a while yet.
Scenario: 1) On my hp laptop the SSD disk (sda 150G) was sliced in six partitions and applied as follows for a first installed andworking openSUSE 13.2:
/dev/sda1 2G swap
Above is one of the more perverse default BIOS installation behaviors. Primary partitions have special significance in BIOS installations. Those shouldn't be wasted on a swap partition. Swap belongs on sdX5 whenever possible, close to front of disk for high speed, but not wasting a primary partition table entry.
/dev/sda2 20G / (root for openSUSE 13.2) /dev/sda3 40G /home /dev/sda4 87G (Extended) /dev/sda5 20G (available for second root)
https://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_u... alludes to the problem with the above partitioning. The default configuration sustains well on a BIOS system only when there is no more than one Linux installation, and when there is no non-Linux installation, on the boot/primary storage media, so that it doesn't matter where the bootloader gets installed. Once a second system is introduced, defaults cause conflict over what does and should control the boot process.
When instead at least two primaries are utilized for partitions that can readily host a Linux bootloader, and a third if necessary for a Windows bootloader, damage to be caused by a second or successive operating system installation can be held to virtual zero. Each primary can host a bootloader, and boot control can be selected/managed by the virtually painless process of moving the boot flag to the desired partition, leaving the MBR code block populated by generic startup code rather than any more complicated and dependant code such as that placed there and in the space immediately following by Grub2.
/dev/sda6 67G /data (additional user data)
2) Next I installed Leap 42.1 M2 from the DVD, selected Expert partitioning, imported existing mount points and selected
/dev/sda5 formatted ext4 as root for Leap /dev/sda3 unformatted and mounted as shared /home for 13.2 and Leap (yes I know the shared /home has some drawbacks but more benefits in my opinion)
Beyond adding some extra appliactions and setup SSH, the installation else was kept as default. I didn't change anything regarding the bootloader installation.
The installation went ok until the first reboot, the it stopped on the black console sreen after the word 'GRUB' and nothing else. I tried to startup again and the same happened; no GRUB menu.lst didn't become available. That is, neither the previous working openSUSE 13.2 nor 42.1 could be started.
Sad but typical result of usurpation caused by Gru* instead of legacy code in the MBR, and not thinking ahead from the point of initial OS installation. It's avoidable by thoughtful partitioning in advance of installing anything.
...
Can this issue be avoided to make dual or multiboot installations easier?
1-Boot agnostically from a primary instead of from MBR.
2-Reserve primaries for use by partitions that might ever be booted from.
3-If eventually the system will be true multiboot, more than one Linux, or more than two anything, consider using one primary for a partition to be used mounted to /boot at most only until a second OS will be installed, and afterwards reserve it for what can be crudely described as chainloader-only service, to be managed by the sysadmin instead of directly by any OS.
This sounds like a good cookbook having just struggled with a multiboot (that I thought is well setup). Would you have some links describing details of the recipy? Thanks
-- "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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Milan Zimmermann composed on 2015-09-19 16:16 (UTC-0400): (Full parent archive: [ http://lists.opensuse.org/opensuse-factory/2015-09/msg00132.html ] ) ...
Can this issue be avoided to make dual or multiboot installations easier?
1-Boot agnostically from a primary instead of from MBR.
2-Reserve primaries for use by partitions that might ever be booted from.
3-If eventually the system will be true multiboot, more than one Linux, or more than two anything, consider using one primary for a partition to be used mounted to /boot at most only until a second OS will be installed, and afterwards reserve it for what can be crudely described as chainloader-only service, to be managed by the sysadmin instead of directly by any OS.
This sounds like a good cookbook having just struggled with a multiboot (that I thought is well setup). Would you have some links describing details of the recipy?
https://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_u... touches on #1. http://fm.no-ip.com/PC/partitioningindex.html and http://fm.no-ip.com/PC/install-doz-after.html touch directly on some things, and have lots of (mostly duplicated) links. As the multiboot universe offers too many possible permutations, none of which for BIOS systems can be "the right way", other responses from me would have to follow from more pointed questions about a particular system's environment and objectives. -- "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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Sat, Sep 19, 2015 at 3:48 PM, Felix Miata
Milan Zimmermann composed on 2015-09-19 16:16 (UTC-0400):
(Full parent archive: [ http://lists.opensuse.org/opensuse-factory/2015-09/msg00132.html ] ) ...
Can this issue be avoided to make dual or multiboot installations easier?
1-Boot agnostically from a primary instead of from MBR.
2-Reserve primaries for use by partitions that might ever be booted from.
3-If eventually the system will be true multiboot, more than one Linux, or more than two anything, consider using one primary for a partition to be used mounted to /boot at most only until a second OS will be installed, and afterwards reserve it for what can be crudely described as chainloader-only service, to be managed by the sysadmin instead of directly by any OS.
This sounds like a good cookbook having just struggled with a multiboot (that I thought is well setup). Would you have some links describing details of the recipy?
https://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_u... touches on #1.
http://fm.no-ip.com/PC/partitioningindex.html and http://fm.no-ip.com/PC/install-doz-after.html touch directly on some things, and have lots of (mostly duplicated) links.
As the multiboot universe offers too many possible permutations, none of which for BIOS systems can be "the right way", other responses from me would have to follow from more pointed questions about a particular system's environment and objectives.
This is great for now, thanks
-- "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-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (5)
-
Andrei Borzenkov -
Felix Miata -
Knurpht - Gertjan Lettink -
Milan Zimmermann -
Terje J. Hanssen