Page 2 of 4 FirstFirst 1234 LastLast
Results 11 to 20 of 33

Thread: Lost knowledge: just do not install GRUB2 into Master Boot Record (MBR), though this is the default

  1. #11
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    11,368
    Blog Entries
    2

    Default Re: Lost knowledge: just do not install GRUB2 into Master Boot Record (MBR), though this is the defa

    First,
    It should be noted that very few hyvisor-based virtualization supports UEFI booting well.
    Also Win10 MFT Win10 and IIRC Win8.1 install naturally implementing UEFI and secure boot by default, but support switching to MBR only after installing UEFI.

    At least, the above has been my personal experience, there may be ways to get around the above natural behavior I'm not aware of.

    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  2. #12
    Join Date
    Sep 2012
    Posts
    5,185

    Default Re: Lost knowledge: just do not install GRUB2 into Master Boot Record (MBR), though this is the defa

    [QUOTE=nrickert;2914963]
    But it has been my impression that booting from the MBR avoids these problems with windows updates.
    Some Windows updates replace MBR boot code making Linux unbootable.
    If you have to change the boot flag for Windows updates, then change it back afterwards, then you don't have booting working well.
    If you have to open umbrella and then close it your weather is not working well.

    Yes, sometimes you are forced to do something you are not happy with. It does not mean "something is not working well". It just means "something works as it works - you need to understand how it works and be prepared to deal with it".
    And it solves it, because you can leave windows marked with the boot flag (to keep windows happy), but still get a grub boot menu when you boot.
    There are two problems - MBR code and active partition. You cannot solve both of them at the same time. But it is much more simple to change active partition than restore MBR code once Windows overwrote it.

  3. #13
    Join Date
    Dec 2008
    Location
    FL, USA
    Posts
    1,752

    Default Re: Lost knowledge: just do not install GRUB2 into Master Boot Record (MBR), though this is the defa

    Quote Originally Posted by arvidjaar View Post
    it is much more simple to change active partition than restore MBR code once Windows overwrote it.
    The reason why my comment that the OP quoted.

    BTW, with UEFI what I do differs rather little from that nrickert does with UEFI. With MBR, I'm still using a separate boot partition, but without ever mounting it to /boot/, and still only with Grub Legacy. I build menu.lst myself, using symlinks to kernels and initrds.
    Reg. Linux User #211409 *** multibooting since 1992
    Primary: 42.3,TW,15.0 & 13.1 on Haswell w/ RAID
    Secondary: eComStation (OS/2)&42.3 on 965P/Radeon
    Tertiary: TW,15.0,42.3,Fedora,Debian,more on Kaby Lake,Q45,Q43,G41,G3X,965G,Cedar,Caicos,Oland,GT218&&&

  4. #14
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    12,753
    Blog Entries
    3

    Default Re: Lost knowledge: just do not install GRUB2 into Master Boot Record (MBR), though this is the defa

    [QUOTE=arvidjaar;2914984]
    Quote Originally Posted by nrickert View Post
    Some Windows updates replace MBR boot code making Linux unbootable.
    This is why I prefer to not install grub to the MBR.

    Using syslinux altmbr.bin, I keep a copy of the MBR boot code in a place that I can easily find. So it is then
    • boot from rescue media
    • find my saved copy of the mbr code
    • install that mbr code


    I have not needed to do that in the last few years.
    openSUSE Leap 15.1; KDE Plasma 5;
    testing Leap 15.2Alpha

  5. #15

    Default Re: Lost knowledge: just do not install GRUB2 into Master Boot Record (MBR), though this is the defa

    Another thread reflecting my perception of things about MBR and boot flags is in
    https://forums.opensuse.org/showthre...22#post2378822

    Just this was my experience: unselect "Boot from Master Boot Record" in the openSUSE installer (as long as this had been the default in former times), and your system with a dual boot with windoze will continue to work.

    I can confirm that this stayed like that with windoze 7 - but I didn't have windoze XP.
    No problem at all then installing openSUSE that way.

    Maybe, that with windoze 8 and the upgrade to 8.1 things changed.

    But who would have liked to have windoze 8 or 8.1 ?

    Today the situation is different, after the offer of Microsoft to upgrade windoze 7 to windoze 10.

    OK, not all of that windoze users may want to have openSUSE.

    But because of that "free" upgrade to windoze 10, there will be many legacy systems around with a partition table of the type 'msdos', but despite of that having a windoze 10 installed.

    So better prepare for that, whatever that would mean.

    I would say, NOT to "Boot from Master Boot Record" would just be defensive.

  6. #16

    Default Re: Lost knowledge: just do not install GRUB2 into Master Boot Record (MBR), though this is the defa

    Quote Originally Posted by nrickert View Post
    This is why I prefer to not install grub to the MBR.

    Using syslinux altmbr.bin, I keep a copy of the MBR boot code in a place that I can easily find. So it is then

    boot from rescue media
    find my saved copy of the mbr code
    install that mbr code


    I have not needed to do that in the last few years.
    Hi

    I was interested in how this all would work - I don't mean copying the MBR using dd which would be quickly done - but the other stuff with the /boot partition that I never had, and the boot flag then, because I was always installing openSUSE with / and /home only, as suggested anyway by the openSUSE installer constantly over the years as default.
    And I further was inspired by the thread
    https://forums.opensuse.org/showthread.php/537619-CentOS-7-not-visible-in-grub-menu-made-by-Leap-15-1
    which appeared shortly after this thread here had been opened.

    I decided to do some testing.

    (1)
    On a new USB stick I created the following partitions during the installation of Leap 15.0 on it using the partitioner of the 15.0 installer (the following output of "parted -l" was obtained AFTER the installation on the USB running an openSUSE installed on an internal disk):

    Code:
    Model: SanDisk Ultra USB 3.0 (scsi)
    Disk /dev/sdc: 61.5GB
    Sector size (logical/physical): 512B/512B
    Partition Table: msdos
    Disk Flags: 
    
    Number  Start   End     Size    Type      File system  Flags
     1      1049kB  525MB   524MB   primary   xfs          type=83
     2      525MB   13.4GB  12.9GB  primary   ext4         type=83
     3      13.4GB  26.3GB  12.9GB  primary   ext4         type=83
     4      26.3GB  61.5GB  35.2GB  extended               lba, type=0f
     5      26.3GB  43.5GB  17.2GB  logical   ext4         type=83
     6      43.5GB  61.5GB  18.1GB  logical   ext4         type=83
    In this, during that installation of 15.0 on the USB, partition 1 formatted xfs was assigned the mount point /boot, partition 2 the mount point /, and partition 5 the mount point /home.

    Partitions 3 and 6 have been created for a further installation of a Linux, with the aim to finally obtain a dual boot.

    (2)
    In the bootloader section of the 15.0 installer, I made the following setup

    [ ] Boot From Master Boot Record (here an MBR could be added to make things a bit clearer)
    [ ] Custom Boot Partition
    [X] Set active Flag in Partition Table for Boot Partition
    [X] Write generic Boot Code to MBR

    I did *NOT* get a checkbox for "Boot from Partition", which I usually did find here when installing in partitions / and /home only (i.e. when installing without a separate /boot partition).

    In the installation summary I then did get a warning:
    "Warning: No location for bootloader stage1 selected.Unless you know what you are doing please select above location"



    (3)
    Installation otherwise went smoothly.
    But afterwards it was not possible to boot the installed 15.0 from that USB.
    When I tried, I got a black screen with a blinking text cursor in the upper left corner of the screen.

    As a first very basic check, GParted (running from internal disk) then revealed that the bootloader, the kernel, and the software had very likely been installed successfully, see the amount of space used in the different partitions


    But most astonishing for me from this output of gparted was, that despite that during the installation I had selected to set the boot flag in the boot section of the installer - c.f. point (2) above - *NO* boot flag was set at all, as was as well revealed by the above output from "parted -l" after the installation, given above under point (1).

    Mounting partition 1 ( /boot ) and partition 2 ( / ) things looked well there.
    As well the contents of the 4 files
    /etc/default/grub
    /boot/grub2/device.map (obviously created by the installer)
    /boot/grub2/grub.cfg
    /etc/sysconfig/bootloader
    mentioned in section 17.5.2.4 of
    https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.startup/cha.trouble.html
    which were present on the USB looked good.

    (4)
    Using GParted I set the boot flag to the /boot partition 1 on the USB.
    Code:
    Model: SanDisk Ultra USB 3.0 (scsi)
    Disk /dev/sdc: 61.5GB
    Sector size (logical/physical): 512B/512B
    Partition Table: msdos
    Disk Flags: 
    
    Number  Start   End     Size    Type      File system  Flags
     1      1049kB  525MB   524MB   primary   xfs          boot, type=83
     2      525MB   13.4GB  12.9GB  primary   ext4         type=83
     3      13.4GB  26.3GB  12.9GB  primary   ext4         type=83
     4      26.3GB  61.5GB  35.2GB  extended               lba, type=0f
     5      26.3GB  43.5GB  17.2GB  logical   ext4         type=83
     6      43.5GB  61.5GB  18.1GB  logical   ext4         type=83
    On an internal hard disk I have a similar setup with windoze 7 - if I want to boot that directly for certain updates then I have to put the boot flag on a small 100MB NTFS partition labeled "MSsystem" that was created by the installer of that windoze 7.

    Reboot from USB, again using the boot menu of the BIOS.
    15.0 doesn't boot.

    (5)
    Using GParted I even tried the following, although I was not convinced that it would succeed: I did set the boot flag to the /root partition 2 of 15.0 on the USB.
    Reboot from USB.
    15.0 doesn't boot.
    Moved boot flag back to partition 1 ( /boot ).

    (6)
    Booting from the 15.0 installer, in the upcoming menu I chose: More ... > Boot Linux System .
    Initially that worked fine.
    Under "Select a system to boot" I found and selected sdc2 (label 150root, see GParted window above).
    Under "Select a kernel to boot" I found and selected sdc1 (label 150boot).
    Under "You may select an alternative device name for the system partition" I selected the /dev/disk/by-uuid/e904... version.
    Under "Edit kernel options" the root=/dev/disk/by-uuid/e904... looked well.

    Result: "Sorry, system didn't boot."

    (7)
    Booting the rescue system from the 15.0 installer and following the instructions in section 17.5.2.3 of
    https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.startup/cha.trouble.html
    I successfully chroot'ed to the installed 15.0



    Here I entered
    Code:
    rescue:/ # yast
    and got to the text version of YaST.

    In the bootloader section I checked
    [X] Custom Boot Partition
    and entered the path to the boot partition: /dev/disk/by-label/150boot



    On exiting the bootloader section I got the messages

    Code:
    Saving Boot Loader Configuration
     Prepare system
     Create initrd
     Save boot loader configuration
    After exiting yast, I left the chroot environment with "umount -a" and "exit" and then shut down with "shutdown -h now".
    Power on again and in the BIOS boot menu selecting the USB.

    Result: No boot.

    Repeating the procedure, i.e. chrooting into sdc2 again and calling "yast", in the bootloader section I discovered, that
    [ ] Custom Boot Partition
    was NOT checked anymore, and that the path /dev/disk/by-label/150boot to the boot partition - which I had entered before - had NOT been stored.


    Well, it however was possible to boot that 15.0 from the USB, showing as well that the installation as such had been successful, see next posting.

  7. #17

    Default Re: Lost knowledge: just do not install GRUB2 into Master Boot Record (MBR), though this is the defa

    OK, after all these trials, I did something that I usually abstain from.

    As the very last possibility I chrooted into the 15.0 on the USB again, then again "yast", and bootloader.
    This time I checked
    [X] Boot from Master Boot Record



    Save and exit.
    Shutdown.
    Power on again.
    Guess what:

    Boot !

    After checking out all of this it is not quite clear to me, how at least for openSUSE Leap 15.0 booting from a separate /boot partition could be combined in any way with NOT booting from MBR, i.e. wihout writing non-generic boot code to MBR.

  8. #18

    Default Re: Lost knowledge: just do not install GRUB2 into Master Boot Record (MBR), though this is the defa

    Next test.

    Install an additional openSUSE Leap 15.1 on the USB stick where Leap 15.0 had been installed before with a separate /boot partition with xfs file system.
    This Leap 15.0 could be booted only after "Boot from Master Boot Record" had been selected in the bootloader settings.

    The partition setup on the USB was that shown in the output from "parted -l" in
    https://forums.opensuse.org/showthre...31#post2915231

    In that partition setup the empty (i.e. only formatted) partition sdc3 was to be used for / (or root), and the empty logical volume sdc6 for /home (compare as well the output of GParted AFTER the installation that is shown further down below).
    No separate /boot partition seclected for 15.1, i.e. sdc1 was NOT used for this installation.

    For the bootloader of 15.1 use the default settings.

    The bootloader section during the installation thus looked like



    and the result in the installation summary from this was



    Disk usage after the installation of 15.1 can be seen from the following



    and in this there is a funny detail: the installer of 15.1 did put the boot flag on the extended partition sdc4 in which no root partition is present.
    From the labels of the partitions in that output of GParted it can easily be seen which the single partitions are serving for.

    OK, now, booting from the USB, the following GRUB2 menu shows up



    But in this: where are the entries for the openSUSE Leap 15.0 which was installed beforehand, which is still present, and which booted from the same USB stick until 15.1 was installed on it ?

  9. #19

    Default Re: Lost knowledge: just do not install GRUB2 into Master Boot Record (MBR), though this is the defa

    Quote Originally Posted by ratzi View Post
    But in this: where are the entries for the openSUSE Leap 15.0 which was installed beforehand, which is still present, and which booted from the same USB stick until 15.1 was installed on it ?
    Oooops, sorry, a GLITCH:

    Because the list in the GRUB2 menu at boot was too long, due to the entries from the internal drives, I didn't see the boot entry for the 15.0 on the USB stick and didn't scroll down with the arrow-down-key (there is no scroll bar in that GRUB2 menu).
    In the boot loader settings of 15.1 I then removed the internal disks sda and sdb, however, the list remained just as long.
    I must finally have unchecked the checkbox for "Probe Foreign OS" in the "Bootloader Options" ... I was a bit tired after several hours of installing, chrooting, reading, and trying out.

    I just changed that back a few minutes ago, after thinking about all again.
    The long, long list in the GRUB2 menu is back again, and at the very bottom of that long list, after scrolling down, I find the entry for the 15.0 on the USB stick.

    And 15.0 boots from there.

    Sorry for any inconvenience.

    I think I'll stop posting for a while ...

  10. #20
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    12,753
    Blog Entries
    3

    Default Re: Lost knowledge: just do not install GRUB2 into Master Boot Record (MBR), though this is the defa

    Quote Originally Posted by ratzi View Post
    I was interested in how this all would work - I don't mean copying the MBR using dd which would be quickly done -
    When you configure grub to boot from the MBR, it also stores some code/data in the gap between the MBR and the first partition. Well, that assume legacy partitioning. It doesn't do that with GPT partitioning, but instead stores that in the "bios_boot" partition (sometimes called "bios_grub" partition).

    So copying the MBR with "dd" may miss some of what has to be copied.

    but the other stuff with the /boot partition that I never had, and the boot flag then, because I was always installing openSUSE with / and /home only, as suggested anyway by the openSUSE installer constantly over the years as default.
    You don't really need a separate "/boot" these days, except perhaps with very old computers. Keeping "/boot" part of the root partition should be okay. I still use a separate "/boot" because I use an encrypted LVM, and I keep "/boot" unencrypted. That's not strictly needed either, but it does simplify some things.

    I decided to do some testing.
    You appear to be using "xfs" for "/boot". I'm not sure if that works. There seem to be some restrictions on using "xfs" for booting.

    When I use a separate "/boot", I normally use "ext2" for that, on the principle that grub really doesn't look at the file system journal (with "ext4").
    openSUSE Leap 15.1; KDE Plasma 5;
    testing Leap 15.2Alpha

Page 2 of 4 FirstFirst 1234 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •