Restoring Leap 42.1 to Bootloader

English Install/Boot/Login
#21

I have followed this thread (and the others which have started) with interest. I have no doubt that Leap42 will be a great distro but, at the moment, it appears to have as many bugs as-all-come-up.

I started using ‘Linux’ in the late '90s (initially as distributed on a 3.5in. floppy as BSD & run under OS/2) but - when OS/2 collapsed - I turned to the free distro’s then beginning to appear with mags like “PC World”. I eventually bought a boxed set (complete with printed manual) of SuSE 6.3 and have (more or less) stayed with it ever since. There was one SUSE release (I can’t remember which - 7.1 or 8.1 maybe) which appeared buggy and I almost defected to Mandriva; but the follow-up (7.2 or 8.2, whatever?) was fine. I have used SuSE (primarily) ever since.

It seems to me that It is not without the bounds of probability that that SuSE is playing an MS on us - launch, say, Vista; get everyone to pay for it; it is full of bugs, which your customers report and which you (MS) sort out; BUT you’ve already got the money and, once the bugs are sorted out, you can charge your customers for an ‘upgrade’ (ie: a version of Vista which has some of the bugs sorted out)

BUT, this is not MS. We have NOT paid $'s or £’s for something that is buggy. We are being offered something which may be terrific (or it might be a complete frost). I believe it will be terrific and our complaints about this iteration will be the thing which makes it so!

And there will be more!

dmk

#22

OrsoBruno -

Thanks - your comments are very helpful.

In all of my machines, “write generic boot code to the MBR” is checked in YaST bootloader. Am I correct that this is the generic code to which you refer?

Further, during install, I did the following:

bootloader options – accepted default offering:
    Booting
        . . .
        Change Location:
            Do not install bootcode into MBR [install]
            Install bootcode into “/” partition [do not install]

So it’s not clear why 13.1 and 42.1 alternately appear to have knocked out the other on the machine.

Further, “set active flag in partition table for boot partition” is also checked. Perhaps this is the culprit – a discussion from 2009 suggest this:https://forums.opensuse.org/showthread.php/428420-openSUSE-Grub-taking-over-the-MBR
In the meanwhile, I am reading up on Grub2, MBR, and other related topics to which I never gave much thought.

I will also look more closely at the file system options. Like many others, I allowed selection of BTRFS as this is the default option during installation. But I was aware of concerns raised in the forums, including Swerdna’s comments (who I greatly respect - he’s helped me on several occasions going back to when I first began using Linux).

I still want to install Leap 42.1 on my main workstation, now running 13.2 (as well as 13.1), but as I have a well-developed VirtualBox installation there, I want to be reasonably certain that I won’t harm that by installing Leap. Although the machine has a triple-boot setup, I rarely go into the other systems. I just need the option during the transition.

As a fallback, I could do what I ultimately did on the 13.1/42.1 machine we are discussing – I just mounted the 13.1 file system in YaST partitioner and then could grab the config files I needed (I don’t store data on any of my OS/program drives). But the virtual machine .vdi files present more of a challenge, as they don’t like to be moved around too much (I need to study this as well). Although the 13.1 system is still not accessible from the bootloader, I don’t care and don’t need to run it except perhaps to see how I configured the desktop.

#23

You can not chain boot OS’s that are not booted in the same way ie all EFI or all legacy. Mixing will hide the OSs that are not the same boot mode.
It appears you boot via legacy/MBR If all OS’s are installed that way the next must be also. So boot the installer in legacy mode. If the installer has option along the bottom you are in legacy mode if not then you are in EFI mode. Next you need to decide which OS will control the boot. Assuming there are no Windows involved then that one should install grub2 to the MBR. Note it is ok to install grub both to MBR and the boot partition. All other OSs should only install to their boot partition. Only the controlling OS should go to MBR. That’s it it is no more complex then that as long as no Windows.

If using small/older drives I recommend not using BTRFS use ext4. One it require less reserved space 20 gig versus 40 gig for BTRFS for root. Two you don’t have to worry about have too small a space for the grub MBR

Optional you can install generic code in the MBR and use the boot flag to indicate the boot partition. In this case all Linux needs to install grub to their boot

The above is true for both legacy grub and grub2. The work the same for legacy booting

EFI
All OSs on an EFI boot system use a common special FAT formatted partition. This is then where all boot code for all OSs are set up. Each OS will have it’s own directory. There is no MBR code or code installed on the boot partition. This partition gets mount in openSUSE as /boot/efi. The grub2-efi boot code is used.

#24

One step at a time, please: stop thinking at your other machines (which are working…) until you understand what’s happening to the one we are discussing here.

I fired up my test laptop just to check and in YaST2-BootLoader (on Leap) my setup is:

  1. Set active Flag in Partition Table for Boot Partition

  2. Write generic Boot Code to MBR (YESSIR! This is what I meant)
    >>comment: the generic boot code jumps to the partition with the “active” flag to look for a bootloader.

  3. Boot Loader Location > Boot from Extended Partition (due to my layout; Boot from Root Partition will do in your case)

  4. Bootloader Options: Probe Foreign OS (checked).

Other entries are the Leap default for MBR booting, IIRC.
With that setup the Leap Grub2 finds the 10 kernels installed at the moment (and boots them, although I didn’t check every one of them just now :wink: and none is from OS 13.1). There are Ext4, Ext3 and NTFS partitions on my test disk, but I don’t think that matters.
The menu even lists (separately) every combination of symlinks like “vmlinuz” that might actually be bootable.

Hints:

  1. Check also the “Advanced options” in your menu: their label might not be always meaningful, but pressing the “E” key at boot shows what they are actually linked to. Check the “13.1” option that doesn’t boot, maybe there is something trivial to edit.
  2. If something seems to be missing, scroll down the menu to the very end: if there are too many options, some are just hidden further down.

While I understand why the 13.1 Grub doesn’t find Leap (on BtrFS…), I see no obvious reason why the Leap Grub should not boot a 13.1 kernel (well, if gogalthorp advice is followed as well); moreover, if 13.1 is on an Ext4 /root, it should be easier to boot it manually or via 40_Custom config starting from the Leap Grub, rather than the other way around.

Hope this helps; since I’m no install guru, I’m running out of ideas…

#25

gogalthorp, thanks. I realize that some of this information is set out above, but for clarification, here is the disk configuration upon installation of Leap 42.1 this past Sunday:

Disk configuration:

Retain sda1: existing Windows XP

device       size            F    type             FS type    mount point

/dev/sda    698.64 GiB        WDC-etc.
/dev/sda1  341.80 GiB         HPFS/NTFS    NTFS       [/z/C]

/dev/sda2  356.84 GiB    F    Linux native   BtrFS       /    [Leap 42.1]

/dev/sdb    465.76 GiB         WDC-etc.
/dev/sdb1   2.01 GiB            Linux swap    Swap        swap    [SuSE 13.1]
/dev/sdb2   230.00 GiB         Linux native   Ext4         /

You mention chain booting. I don’t know how the 13.1 system is configured to boot, but perhaps the details about the 13.1 system before I re-installed Leap and lost access to the 13.1 system might answer this question. Please see the beginning of this thread and: https://forums.opensuse.org/showthread.php/512570-40_custom-file-syntax-and-content
As to size of the drives, I have no feel for whether these are sufficiently large for BTRFS, but I can’t see why they’re not. According to KInfocenter, the 13.1 and 42.1 systems are using nine (9) % and two (2) % of their respective drives.

I am also trying to determine whether I should opt for one file system over the other. I am not now concerned about or desire snapshots, so I don’t see that in itself as a reason for selecting BTRFS. Nevertheless, there might be another reason why BTRFS is preferred over Ext4. I don’t have sufficient knowledge on this subject. Please direct me to any resources you think might assist me.

OrsoBruno, just saw your reply as I’m finishing up this one. Please note that I am focusing only on the 13.1/42.1 machine for the moment. I referred to my main workstation and the other with my first Leap install merely as a point of reference and to see how they are configured. My goal is to resolve the issues on the 13.1/42.1 first before doing anything on the other machines.

I tried the “E” option under advanced on the machine for each OS (thanks - I just learned yet another new thing). Hopefully, these are the relevant entries (the screens present a LOT of information, e.g., vmlinuz, initrd, kernel):
42.1: set root = ‘hd0,msdos2’
13.1: set root = ‘hd1,msdos2’

Thank you.

#26

For completeness, I rebooted, selected Windows XP, and pressed “E.”

Output:
/dev/sda1
set root = ‘hd0,msdos1’
drivemap -s (hd0) ${root}
chainloader +1

From before:
42.1: set root = ‘hd0,msdos2’
13.1: set root = ‘hd1,msdos2’

#27

Now I see it: Grub2 on one disk (hd0 or sda) is unable to boot a kernel on another disk (hd1 or sdb).
There are a few threads in the forum with similar problems; Grub2 on “hd0” and OS 13.1 on the other disk might have a different “opinion” on which is hd0/sda or hd1/sdb.

In the boot line for OS 13.1, there should be a line reading something like:


linux /boot/vmlinuz-<version>-desktop root=UUID=fe8fdc1d-a5a3-496c-bf8c-0dc1e571b389

If that reads something like “root=/dev/sda2” instead, that might be the culprit.

If there still is a bootloader on the hd1/sdb disk MBR, you might be able to boot that via a BIOS menu on your PC (say pressing F9 or F2 or whatever it takes) during the POST phase.

I don’t have the right setup to check, so I’m out on this at the moment.

#28

From grub.cfg for the 13.1 system:

linux    /boot/vmlinuz-3.11.10-29-desktop root=UUID=3408a825-1ebf-43df-ae44-35a28738eb3e   resume=/dev/disk/by-id/ata-WDC_WD5002ABYS-02B1B0_WD-WCASYD506924-part1 splash=silent quiet showopts

The entire grub.cfg is posted at https://forums.opensuse.org/showthread.php/512570-40_custom-file-syntax-and-contentSee the last item in the initial post; the menu options begin roughly half of the way down in that window - the particular line above is from the first entry.

#29

Well, as I understand it this is the entry in the Grub menu installed on hd1/sdb, the one without a Leap entry just to be clear.
You should find an exactly matching section for OS 13.1 on the “Leap” Grub installed on hd0/sda if you want to boot OS 13.1 from there.

#30

Yes, there is an entry but under the os-prober section (which I guess makes sense). Here is an excerpt from grub.cfg on the Leap 42.1 system (i.e., hd0):

### BEGIN /etc/grub.d/30_os-prober ###
. . .
}
menuentry 'openSUSE 13.1 (x86_64) (on /dev/sdb2)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-3408a825-1ebf-43df-ae44-35a28738eb3e' {
    insmod part_msdos 
    insmod ext2
    set root='hd1,msdos2'
    if  x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos2 --hint-efi=hd1,msdos2 --hint-baremetal=ahci1,msdos2 --hint='hd1,msdos2'  3408a825-1ebf-43df-ae44-35a28738eb3e
    else
      search --no-floppy --fs-uuid --set=root 3408a825-1ebf-43df-ae44-35a28738eb3e
    fi
    linux /boot/vmlinuz-3.11.10-29-desktop root=UUID=3408a825-1ebf-43df-ae44-35a28738eb3e resume=/dev/disk/by-id/ata-WDC_WD5002ABYS-02B1B0_WD-WCASYD506924-part1 splash=silent quiet showopts
    initrd /boot/initrd-3.11.10-29-desktop
}
. . .
### END /etc/grub.d/30_os-prober ###
#31

I’m not sure what happened, and more precisely what I did to damage the bootloader initially, but after my last post, it seemed that the PC should boot into both 13.1 and 42.1. And now it does.

I thank everyone for their comments, especially OrsoBruno, as I learned quite a bit.

Should the system decide to stop working (or if I should break it again), I will revisit this thread.

Thank you all again for your patience, assistance, and the education.