OpenSUSE 12.2 RC 2 Grub 2 removal of dangerous boot entries?

[please_try_again]

@GirlGeek

Well, If I let OpenSUSE to install grub in the boot record of a partition, there will be no changes in the MBR.

No. OpenSUSE by default overwrites the MBR with its own generic boot code. To prevent this from happening, you have to uncheck “write generic boot code to MBR” … but this option is hidden 3 click aways from the setup menu.

findgrub since version 3.7.2 can tell you which kind of generic MBR is installed. See this post which shows both openSUSE and WIndows generic MBRs: http://forums.opensuse.org/english/other-forums/development/programming-scripting/447138-looking-grub-windows-bootloader-all-partitions-17.html#post2443638

@GirlGeek

The original Windows boot code gives control to whichever partition happens to be marked active. This is the very reason I can recover just by clearing the active bit for the Windows partition and then setting the same bit for my grub partition.

Yes… but you rely on a boot flag to boot Linux and on the position of stage2 on disk. If stage2 has moved, you have to reinstall Grub. You don’t have this problem with Grub in MBR (because it contains enough code to read the file system and doesn’t care about disk sectors). Generally speaking Grub (Legacy or Grub2) should be installed in MBR whenever possible. When you use Windows, it is better not to do that though, because Windows will overwrite it sooner or later (or even not be able to install some updates).

@GirlGeek

Had I chosen MBR things would be a little different since I would have to reintroduce grub in the MBR.

Yes, that’s right. It would be more work actually in this case.

@GirlGeek

I suppose it is as you say: diskpart does not let you set an extended partition as active. If so this is just a limitation in diskpart.

That’s true. But it’s not the only limitation when booting from a partition boot sector in general (in the absence of stage1.5*, you rely on block lists, as I just explained above) and especially from the extended one (you can not chainload any OS or any other Grub from there).

You can use **findgrub -a **to re-activate the Linux partitiion. Well, there are many ways to do it.

[please_try_again]

@please_try_again

No. OpenSUSE by default overwrites the MBR with its own generic boot code. To prevent this from happening, you have to uncheck “write generic boot code to MBR” … but this option is hidden 3 click aways from the setup menu.

actually 2 clicks now in 12.2 that I’m just installing. So … some progress after all! In 12.3, there might be just 1 click … and in 12.4, maybe they will finally agree to install Grub in MBR, because Windows will have ceased to exist* on PCs and thus, there won’t be any reason anymore to install the boot loader in the extended partition.

• well, actually no … because Microsoft will still be needed to sign Linux secure boot keys. >:(

[nrickert]

@GirlGeek

In my case there are actually three Windows 7 partitions. 1st Windows boot, 2nd rest of Windows, 3rd Windows recovery.

I think that 3rd partition is the equivalent of the Dell partition on my laptop. If I boot that, I does try to recover windows. Or it would have. I have long since decided to reformat that and use for “/boot” in linux.

In any case, you might do better to setup the Windows boot manager to boot linux. That means writing the boot record of the linux partition to a small file, and configuring it in BCDEDIT in Windows 7. That way, if you are stuck only booting Windows, you have a way back to linux.

[please_try_again]

@"please_try_again

@jdmcdaniel3

openSUSE has been updated to grub 2 version 2.00, the latest version as far as I know.

Ouuuh… Don’t tell me the uncompressed core size has changed … and findgrub won’t detect it!
As usual … evrerything breaks or changes at the same time.

Indeed.

 - reading bootsector  /dev/sda9      (LINUX)         ... --> Grub2 (1.99) found in /dev/sda9   => sda**? **  0x**??** (openSUSE)

But it’s not surprising. I will have to add support for this version. There is more work to come.

[GirlGeek]

@GirlGeek

So here is what I ended up in doing:

1. Removed the executable bit from /etc/grub.d/30_os-prober. This prevents the auto detection of Windows rescue partitions.

2. Added an entry into the /etc/grub.d/40_custom file. This allows booting the Windows partition. In my case the added lines look like this (/dev/sda1):

menuentry “Windows 7” {
set root=‘(hd0,1)’
chainloader (hd0,1)+1
}

Grub2 uses new numbering for partitions but not for drives. Therefore (hd0,1) = /dev/sda1.

3. Run “grub2-mkconfig -o /boot/grub2/grub.cfg” to make the changes to take effect.

Please read /usr/share/doc/packages/grub2/README.OpenSUSE. OpenSUSE uses specific naming for some grub2 files.

This strategy with removing the executable bit fails whenever there is an update to the os-probe -file. Allready failed for me with 12.2. So as I earlier stated the prober way is to set the parameter GRUB_DISABLE_OS_PROBER=true in /etc/default/grub and to run “grub2-mkconfig -o /boot/grub2/grub.cfg” to make the changes to take effect.

[arvidjaar]

@please_try_again

You don’t have this problem with Grub in MBR (because it contains enough code to read the file system and doesn’t care about disk sectors).

Sorry, but it is wrong (clarification for the sake of anyone reading this thread). Whether we speak about stage1 in Grub Legacy or boot.img in GRUB2, both of them can do exactly one thing - which is load next block and jump to it. Period. It absolutely does not matter whether stage1/boot.img is written into MBR or partition boot sector - it does exactly that. And code to which it jumps can also only load a list of disk sectors. For Grub Legacy this may be stage1.5 or stage2 (which is basically the whole Grub1 code) directly; for GRUB2 this is core.img. And only now we do have enough code to actually access file system.

And as far as I can tell, having GRUB stage1 code in MBR is far less resilient exactly because it points directly to disk which stage1.5/stage2; and any change in disk configuration may break this pointer leaving you with black screen. I do not so far expect much difference with GRUB2 (nor is Grub at fault, this is how BIOS booting work )

So in case if several operating systems having generic MBR which jumps to active partition makes sense indeed.

Or use UEFI system

[please_try_again]

@arvidjaar

Sorry, but it is wrong (clarification for the sake of anyone reading this thread). Whether we speak about stage1 in Grub Legacy or boot.img in GRUB2, both of them can do exactly one thing - which is load next block and jump to it. Period. It absolutely does not matter whether stage1/boot.img is written into MBR or partition boot sector - it does exactly that. And code to which it jumps can also only load a list of disk sectors. For Grub Legacy this may be stage1.5 or stage2 (which is basically the whole Grub1 code) directly; for GRUB2 this is core.img. And only now we do have enough code to actually access file system.

For the sake of evrone, I have been repeated this for years already. So I don’t know what troubles you.

@arvidjaar

And as far as I can tell, having GRUB stage1 code in MBR is far less resilient exactly because it points directly to disk which stage1.5/stage2; and any change in disk configuration may break this pointer leaving you with black screen. I do not so far expect much difference with GRUB2 (nor is Grub at fault, this is how BIOS booting work )

Yes it points to a partition number. Otherwise it points to a sector offset, and if stage2 has moved, it won’t boot either. The probability that stage2 moves after a brutal fsck is higher than the probabibily that disk partitions get added or removed by themselves. Installing Grub (especially Grub2) in a partition is also discouraged and required the --force option (which openSUSE uses by default).

Try** findgrub -v** and (since version 4.0) findgrub -c on a machine with several Grub installed in different places. There are plenty of examples and screenshots in the findgrub thread: http://forums.opensuse.org/english/other-forums/development/programming-scripting/447138-looking-grub-windows-bootloader-all-partitions-17.html#post2481798.
Doesn’t have full support for Grub2 v 2.0 yet.

@arvidjaar

So in case if several operating systems having generic MBR which jumps to active partition makes sense indeed.

If you consider that an emply glass is better than a full glass, maybe - and if you use Windows, definitely.

[please_try_again]

@arvidjaar

I do not so far expect much difference with GRUB2 (nor is Grub at fault, this is how BIOS booting work )

Well, since you’re asking, the difference it that Grub2 doesn’t care (am I allowed to say “doesn’t care”?) about partition numbers in its boot menu as long as the UUID of the root partition is correct. Otherwise none of the entry in the grub.cfg of the 12.2 system I’m working on would boot, because all the partition numbers in this file are simply wrong, including the one for the host system (openSUSE). It has nothing to do with os-prober.

Have a look (just for fun).

os-prober (1.55 availalbe in my repo now) is correct:

# os-prober
  No volume groups found
/dev/sda1:Windows NT/2000/XP (loader):Windows:chain
**/dev/sda13:Fedora release 16 (Verne):Fedora:linux**
/dev/sda15:Debian GNU/Linux (squeeze/sid):Debian:linux
/dev/sda6:Ubuntu 12.04.1 LTS (12.04):Ubuntu:linux
/dev/sdb1:Windows NT/2000/XP (loader):Windows1:chain
/dev/sdb3:FreeBSD:FreeBSD 8.1-RELEASE:freebsd
/dev/sdb6:Arch Linux (rolling):archlinux:linux

# cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.4.6-2.10-desktop **root=UUID=aa192116-690d-4420-af5f-544d1e58b46c** video=1600x900 nomodeset resume=/dev/disk/by-uuid/c224505c-6233-404f-a706-308138573fce splash=silent quiet showopts

# lspart -U
Dev  Boot Maj Min  Bsize/Start         Size    Fs    ID    Ver                                  Uuid   Model/Mount

sda         8   0        512 B       465.76 GiB     mbr    ata                                     -   WDC_WD5000AAKS-00A7B0
sda1        8   1           63       514017  vfat    06  FAT16                             46EB-E757 
sda2        8   2     73947195    285282270  ufs1    a5      1                      4c1ebb2e8fdfd1e4 
sda3        8   3    361398240    100663290  ufs1    a5      1                      4a849d06e775e28d 
sda4    *   8   4    462061591    514706474     -    0f      -                                     - 
sda5        8   5    462061593      4192902  swap    82      2  89874e59-5191-41fb-b010-970e14f0d8a2 
sda6        8   6    466254558     52707217  ext4    83    1.0  821e7c2b-aeac-4a48-a131-6e141911b52d 
sda7        8   7    518963823     16782737  ext4    83    1.0  978a9075-f97b-45f9-9d6d-107a21b712b1 
sda8        8   8    535748608     33554432  ext3    83    1.0  c908a06a-b97c-4aa6-b829-a4f6823be367   /home, /export/nfs4/home
**sda9 **       8   9    569305088     64487424  ext4    83    1.0  **aa192116-690d-4420-af5f-544d1e58b46**c   /export/nfs4, /
sda10       8  10    633794560     16777216  ext4    83    1.0  4e58426d-244a-497d-b523-b22d91b643d2   /usr/local, /export/nfs4/  usr/local
sda11       8  11    650573824     45359104  ext4    83    1.0  d695818b-a79b-4c53-a539-81290bc68a67 
sda12       8  12    695934976      8400896  ext4    83    1.0  98e31d64-63f3-4ae8-817b-1e7589d62908   /tmp, /export/nfs4/tmp
**sda13       8  13    704337858     64487486  ext4    83    1.0  01a7cb76-434b-4eeb-9fac-c8b5c8229835 **
sda14       8  14    768827392     14710784  ext4    83    1.0  a177d95f-9d7b-4a8d-89a0-27202cbc8c60 
sda15       8  15    783538308      8658972  ext3    83    1.0  7d7cfb4b-ae82-4f6c-b9f1-ff531c912877 
sda16     259   0    792197343    184570722  ext4    83    1.0  9b498d58-08dc-48ef-a349-b30c8b7715b5   /srv, /export/nfs4/srv
sda17     259   1     82335803    285282270     -    a5      -                                     - 
sda18     259   2    149444667    134284651  ufs1    a5      1                      4acc090324ac775c 
sda19     259   3    283729318     16777216  ufs1    a5      1                      4c1ebb302e0bac5d 
sda20     259   4    300506534     16777216  ufs1    a5      1                      4acc091650732a9c 
sda21     259   5     73947195      8388608  ufs1    a5      1                      4c1ebb2e8fdfd1e4 
sda22     259   6    325672358     33557107  ufs1    a5      1                      4c1ebb36c4324af1 
sda23     259   7    317283750      8388608  ufs1    a5      1                      4c1ebb3b41d65297 
sda24     259   8    361398240            ?  ufs1    a5      1                      4a849d06e775e28d 
sda25     259   9    369786848            ?  ufs1    a5      1                      4a849d138a6e0c07 
sda26     259  10    378175456            ?  ufs1    a5      1                      4a849d0e56389218 
sda27     259  11    411729885            ?  ufs1    a5      1                      4af57ab11bc8e970 
sda28     259  12    420118493            ?  ufs1    a5      1                      4af57ab32eb44a7a 
sda29     259  13    453672925            ?  ufs1    a5      1                      4af57ab83c92c74a 

sdb         8  16        512 B       465.76 GiB     mbr    ata                                     -   WDC_WD5000AAKS-00TMA0
sdb1        8  17           63       514017  vfat    06  FAT16                             476A-FA21 
sdb2        8  18     18539010    534016665  ufs1    a5      1                      4773dd451d97f645 
sdb3        8  19    554724450     79698465  ufs2    a5      2                      4cf5f01e3b3c5733 
sdb4        8  20    634422976    342345089     -    0f      -                                     - 
sdb5        8  21    634422978      4192902  swap    82      2  c224505c-6233-404f-a706-308138573fce 
sdb6        8  22    638615943     42281032  ext3    83    1.0  d0f134b3-a468-4f72-95aa-cd09c498ba8c 
sdb7        8  23    680899023     12578832  ext4    83    1.0  0e9cefcd-5e38-4ac7-8de8-749433ac9f59 
sdb8        8  24    693477918     16803927  ext4    83    1.0  7ccc6cbb-89dd-4e5e-827e-4ae23d3f19b3 
sdb9        8  25    710281908     33559722  ext3    83    1.0  bbc5c1b6-56f6-4af1-a482-0d3a674df9b5 
sdb10       8  26    743841693      8385867  ext3    83    1.0  245f9ef8-3937-4baa-9748-4664bec34d67 
sdb11       8  27    752227623      8385867  ext4    83    1.0  222c7f62-2a7f-41a1-aa39-95167768d853 
sdb12       8  28    760613553    216154512  ext3    83    1.0  a556486d-f7fe-4161-8a97-6daff6b03a87   /misc, /export/nfs4/misc
sdb13       8  29     18539010    251658240  ufs1    a5      1                      4773dd451d97f645 
sdb14       8  30    270197250    240412710  ufs1    a5      1                      496b164831d164a0 
sdb15       8  31    510609960     12582912  ufs2    a5      2                      4cf5ff21b59da81a 
sdb16     259  14    523192872     16777216  ufs1    a5      1                      4c200308d3b18ed5 
sdb17     259  15    539970088      4194304  ufs1    a5      1                      4c20030fb9d386ff 
sdb18     259  16    544164392      8391283  ufs2    a5      2                      4cf5ff2cb23acb98 
sdb19     259  17    554724450            ?  ufs2    a5      2                      4cf5f01e3b3c5733 
sdb20     259  18    630221919            ?     -    a5      -                                     - 
sdb21     259  19    563113058            ?  ufs2    a5      2                      4cf5f02034b778cc 
sdb22     259  20    571501666            ?  ufs2    a5      2                      4cf5f01faddc43e8 
sdb23     259  21    605056095            ?  ufs1    a5      1                      4bc2b81325d896e5 
sdb24     259  22    621833311            ?  ufs2    a5      2                      4bc2b816430be504 

As you can see, openSUSE root is sda9. However, here’s the entry in grub.cfg:

menuentry 'openSUSE' --class opensuse --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-simple-aa192116-690d-4420-af5f-544d1e58b46c' {
	load_video
	set gfxpayload=keep
	insmod gzio
	insmod part_msdos
	insmod ext2
	**set root='hd0,msdos13'**
	if  x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos13 --hint-efi=hd0,msdos13 --hint-baremetal=ahci0,msdos13 --hint='hd0,msdos13'  aa192116-690d-4420-af5f-544d1e58b46c
	else
	  search --no-floppy --fs-uuid --set=root aa192116-690d-4420-af5f-544d1e58b46c
	fi
	echo	'Loading Linux 3.4.6-2.10-desktop ...'
	linux	/boot/vmlinuz-3.4.6-2.10-desktop **root=UUID=aa192116-690d-4420-af5f-544d1e58b46c**   video=1600x900 nomodeset resume=/dev/disk/by-uuid/c224505c-6233-404f-a706-308138573fce splash=silent quiet showopts
	echo	'Loading initial ramdisk ...'
	initrd	/boot/initrd-3.4.6-2.10-desktop
}

Why did it take msdos13 here? After several years of using Grub2 (since it became the default boot loader in Ubuntu), it’s the first time I see this error. sda13 would actually be Fedora root partition. But looking at Fedora’s boot entry:

menuentry 'Fedora release 16 (Verne)' --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-01a7cb76-434b-4eeb-9fac-c8b5c8229835' {
	insmod part_msdos
	insmod ext2
	**set root='hd0,msdos21'**
	if  x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos21 --hint-efi=hd0,msdos21 --hint-baremetal=ahci0,msdos21 --hint='hd0,msdos21'  01a7cb76-434b-4eeb-9fac-c8b5c8229835
	else
	  search --no-floppy --fs-uuid --set=root 01a7cb76-434b-4eeb-9fac-c8b5c8229835
	fi
	linux /boot/vmlinuz-3.4.9-2.fc16.x86_64 **root=UUID=01a7cb76-434b-4eeb-9fac-c8b5c8229835** ro rd.md=0 rd.lvm=0 rd.dm=0 KEYTABLE=us quiet SYSFONT=latarcyrheb-sun16 rhgb rd.luks=0 LANG=en_US.UTF-8 nouveau.nomodeset=0 rd.driver.blacklist=nouveau
	initrd /boot/initramfs-3.4.9-2.fc16.x86_64.img
}

What else can I say? It’s just a mess. I have to put this problem aside for now and see what I can do later. No time.
Actually the point was to say that partition numbers can be wrong in Grub2 (as in my case) unlike in Legacy Grub.

[please_try_again]

I’m aware that the issue described above would deserve more attention but …
Grub2 always had problems with BSD disk labels. For years the only way I’ve found to install Linux - first Ubuntu, but later Fedora and now openSUSE since they’re all using Grub2 now - was to delete 0xA5, 0xA6 and 0xA9 (FreeBSD, openBSD and NetBSD) partitions from the partition table. Otherwise, Grub2 would fail to install and I would have to boot from a live system and install it manually. I established that deleting the Unix partitions and writing the entries back by booting a Legacy Grub from somewhere was faster.

Example of an ArchLinux boot entry (Legacy Grub) which also rewrites FreeBSD partitions:

# (0) Arch Linux
title Arch Linux - kernel 3.5.3-1
    partnew (hd0,0) 0x06         63     514017
    **partnew (hd0,1) 0xA5   73947195  285282270
    partnew (hd0,2) 0xA5  361398240  100663290
    partnew (hd1,1) 0xA5   18539010  534016665 
    partnew (hd1,2) 0xA5  554724450   79698465 **
    root (hd1,5)
    kernel /boot/vmlinuz30 root=/dev/disk/by-uuid/d0f134b3-a468-4f72-95aa-cd09c498ba8c ro vga=791
    initrd /boot/kernel30.img

The function “partnew” has been dropped in Grub2 .

I wouldn’t be surprised if this new bug in Grub2 (2.0) has to do with BSD disklabels. I never had this problem before with Grub2 (1.99) on Ubuntu, Fedora or openSUSE 12.1. Once it is installed, it doesn’t care (Oh sorry, again) about the BSD partitions. Although mine does (updateGrub2 -b would add BSD support, which only works with my patched os-prober - but it’s unrelated).

Ok, ok, ok … just forget it!