GRUB 2 - Possible problems ahead

[Radvan]

I am about to upgrade to Squeeze. Lenny becomes too "obsolete" now. Why I haven't upgraded so far? Because of GRUB 2.

I have OS/2 (more precisely, eCS v.2) on my computer along with Lenny. So far, no problems: I installed GRUB 0.97 into the Debian partition and added Debian to the boot manager menu. Everything run like hell. GRUB 2 does not seem to allow installation on a partition. It installs into MBR, even if it is commanded to install on a partition. Thus, bye bye, boot manager ...

When installing Debian, GRUB does not find OS/2 and hints, that there aren't any OSes on the disk, so that it should go into MBR. Okay, OS/2 is now an exotics, no wonder that GRUB does not identify it but it should be possible to boot it from GRUB anyway. All what is needed is that GRUB acts like the BIOS: grab the boot sector of the partition, place it at 7C00h, set DX and SI and pass control to the loaded boot sector.

Q: Is it possible to make GRUB to boot a given partition like the BIOS, without additional actions?

When I searched knowledge on the web, I found that it should be possible to add eCS "the hard way":

(file /etc/grub.d/40_ecs, supposing OS/2 is at dev/sda1)

menuentry "eCS"
{
set root=(hd0,1)
chainloader +1
}

Reboot. That's all. From the BIOS point of view, OS/2 boot the same way as DOS. If this works for DOS, why not for OS/2?

Q: That's all?

Another complaint is about LVM compatibility. OS/2 uses LVM. This should affect me only if GRUB 2 damages LVM data in the MBR. I have 2 disks, one of them contains Debian, the other contains OS/2. I do not need to see the Debian disk from OS/2. I have also found that current GRUB is (can be) LVM-avare.

Q: Is it possible to instruct fdisk and GRUB installation that they should be LVM compatible during installation?
Q: Can os-prober find OS/2?

[dasein]

First off, GRUB2 may suggest installing into the MBR, but you don't have to allow it. GRUB2 works just as well when it's installed in the root partition.

I have 2 disks, one of them contains Debian, the other contains OS/2. I do not need to see the Debian disk from OS/2.

I found myself confused by this portion of your post.

If you have two separate physical drives, why do you care if GRUB2 installs to the MBR of your Debian drive? What am I not understanding?

[StanTheMan]

When a grub2 type distro is installed , a set of files are installed in the root partition in " /etc/grub.d " and in " /etc/default/grub " . These are files which will construct the actual boot list when the system is first run. At this point , the command " update-grub " is run , and this constructs a boot list in " /boot/grub " which list will be displayed at start up.
But , when you start up your machine , the BIOS first goes to the MBR for directiions.
The installer normally wirtes the MBR with these target directions.

But if you already have another distro acting as bootloader , you can instruct the install NOT to write to the MBR but rather to write to the new partition.
In this case , at start-up , the BIOS goes to the original MBR , which directs the machine to the original boot list partition.
When the old operating system logs in , yu now need to run (in Root) " update-grub " , and its constructor files " os-prober " will hunt for the newly instralled system and add it to the original boot list.

There are also further ways to edit the original boot list.

Also if the MBR is accidentally written to the wrong boot list partition target , it is possible to re-write the MBR with a command like this - - grub-install root-directory="/media/sda7" /dev/sda . This requires that first the target partitiion be mounted on a created mount point directory. This command is a mis-nomer , as it is not actually installing grub , but merely re-writing the grub target in the MBR .

In your case , you would normally just install the new operating system , let it write the MBR and create its own new boot loader.

[dasein]

In your case , you would normally just install the new operating system , let it write the MBR and create its own new boot loader.

NO. If chaining is truly required, it makes vastly more sense to let OS/2's BootManager "chain" to GRUB2 than vice-versa. (Though I confess I have no experience with GRUB2+BootManager, I have had unhappy experience with legacy GRUB and BootManager.)

No matter what, if it were my machine, the very first thing I would do is backup the MBR from the current boot drive... just in case.

Code: Select all

dd if=/dev/sda of=~/mbr.img bs=512 count=1

[kiyop]

I am not familiar with OS/2.

But I agree with dasein's:

If chaining is truly required, it makes vastly more sense to let OS/2's BootManager "chain" to GRUB2 than vice-versa. (Though I confess I have no experience with GRUB2+BootManager, I have had unhappy experience with legacy GRUB and BootManager.)

No matter what, if it were my machine, the very first thing I would do is backup the MBR from the current boot drive... just in case.

Code: Select all

dd if=/dev/sda of=~/mbr.img bs=512 count=1

You should have kept OS/2's BootManager work well.
But now, your BootManager had been overwritten by GRUB2, had not it?
Or your BootManager is installed in the second(?) HDD where OS/2 is installed or in the partition of your OS/2?

And I found similar question:
http://ubuntuforums.org/showthread.php? ... ost9402586

I am very curious.
I want to know whether GRUB2 can chainload correctly to OS/2's BootManager and/or OS/2's PBR or not.

How about downloading boot info script and running it with Debian and posting the result?
http://bootinfoscript.sourceforge.net/

I wonder if "insmod hfsplus"(?) and "drivemap -s" command in Grub2 may help to chainload to OS/2 boot loader or not.

Edit: I found the following URL though I have not read through.
https://www.ibm.com/developerworks/myde ... s4?lang=ja

You can involve LVM suport at grub command line (or grub.cfg)

Code: Select all

insmod lvm

but I do not know how to enable LVM while installing GRUB2, if default installation of debian has not enabled LVM in your case.

[Radvan]

(1) I have 2 discs physically. Therefore, 2 MBRs but only one of them is on the top of the BIOS boot up sequence data. Wanting to boot from both discs would mean swapping the discs in the BIOS boot sequence data every time I want "the other" disc.

(2) OS/2 does not need a special boot loader. It can be booted "the standard way" by BIOS, like DOS. Boot manager is an option, not a must. Chaining OS/2 BM with GRUB is not needed - if you can instruct GRUB to boot the OS/2 partition.

Also, if you can talk GRUB 2 into booting a given partition then chainloading to OS/2 boot manager should be possible. The BM has its own (bootable) partition, which can be started by BIOS "the standard way".

(3) Installing GRUB 2 on a partition - ah, if only it were possible! No problems, no posts here or elsewhere! But, AFAIK, it is not possible. AFAIK, commanding GRUB 2 to install on a partition = the Linux loader itself installs on that partition but GRUB 2 overvrites MBR still. Installing GRUB on a partition without touching MBR was possible with GRUB 0.97: You made the partition bootable, BIOS booted the partition and GRUB 0.97 got control. Or you installed some BM and added the partition to the boot menu.

It's here, where all problems (and fears) begin. Installing GRUB 2 = losing boot manager. Having GRUB 2 in the MBR of the second disc solves nothing because BM can only boot a partition, not a MBR. With GRUB 2, I have to boot from GRUB 2.

---------------------------------------------------------------------

Kiyop, many thanks for the link to the Ubuntu forum - the story there shows exactly what happens to users/2 when they meet GRUB 2 and why I have started this thread. Now, it is clear that the "hard way" with menuentry will not work but the boot manager mentioned there looks promising. I will try it at any rate.
My bit of knowledge to the discussion: OS/2 does not keep anything special in the MBR. It starts like DOS do: the boot sector searches the root directory for the file OS2BOOT loads it and passes control to it. Then OS2BOOT ... and so on ... the normal "avalanche". The truth seems to be in post 15 (by Oldfred) - GRUB 2 checks something on the partition, meddles with IFS, and does other things that it should not do. Then it concludes, that this is not a bootable partition - even if it is.

[kiyop]

Thanks for your reply. Radvan.

The truth seems to be in post 15 (by Oldfred) - GRUB 2 checks something on the partition, meddles with IFS, and does other things that it should not do. Then it concludes, that this is not a bootable partition - even if it is.

I know that GRUB legacy have useful commands "rootnoverify", "map" and "chainloader".
If MBR of your HDD which includes your OS/2 partition (LVM?) has not been changed, how about chainloading to the MBR?
In grub2 command line,

Code: Select all

insmod part_msdos
insmod lvm
insmod chain
set root="(hd1)"
drivemap -s (hd0) ${root}
chainloader +1
boot

"(hd1)" should be the HDD which contains your OS/2 partition. It may be changed to "(hd1,1)", that is, the OS/2 partition.
To know the name of the device(HDD) and partitions, simply type in Grub2 command line:

Code: Select all

ls

I know that "grub-install" without "-f" option for installing to PBR, such as /dev/sda1, fails in some case, while "grub-install -f" for installing to PBR can install GRUB2 to PBR sometimes.
But recently I had similar problem that "grub-install -f" to PBR failed.
I searched with Google and I found that recently Grub2 is updated to 1.99 especially for Ubuntu and there are some report that grub-install failed with Ubuntu.

I think "grub-setup" is more effective and more customizable than "grub-install".
The default place where Grub2 is installed can be changed by "dpkg-reconfigure grub-pc" or so.

MBM and PLoP boot manager are possible chainloaders which only chainloads to PBR.
MBM
http://elm-chan.org/fsw/mbm/mbm_e.html
PLoP boot manager
http://www.plop.at/en/bootmanager.html

[pcalvert]

I remember reading on the aptosid forum that GRUB2 cannot be installed on a partition, or you can but it won't work. Hoping that it was a temporary problem that had been fixed, I tried installing GRUB2 to the PBR instead of the MBR. There were no error messages during installation, but when I attempted to chainload GRUB2 the result was failure. (GRUB2 is said to be an improvement over the old GRUB, but I am not yet convinced of that.)

You are not required to use GRUB, so why not use something else instead? LILO seems like a good choice. There is also EXTLINUX, but I don't have any experience with that one. On second thought, I believe that the only alternative to GRUB offered by the Debian installer is LILO.

Phil

[Radvan]

(1) rootnoverify: It seems that it has been gone in GRUB 2. The manual for GRUB 2 does not list it. I have found that the only "noverify" is the signature 0AAh 55h. OS/2 partition does have this signature.

(2) part-msdos: The file system for OS/2 is HPFS or OS/2 JFS (slightly different from Linux JFS). Perhaps, it is still possible to install OS/2 on a FAT partition but it is a relic from diluvial times. Perhaps, the reason why the guy from ibm.com has passed with GRUB 2 and OS/2 is just the IFS - the guy has installed Warp 3 (another diluvial relic - year 1992 or so) on FAT16.

FAT16 is not used because of extended attributes (EAs). Each file or directory in OS/2 has EAs, where it stores its "Properties". The Properties in OS/2 are much richer than in Linux or winblows and allow fine customizing the system to your liking. The EAs are foreign to FAT16 and they are emulated: all EAs of all files are stored in a file named 'ea data. sf' and the directory entries contain offsets into this file. Big problems with maintaining such EAs follow sooner or later. Both HPFS and OS/2 JFS support EAs naturally.

This would confirm (along with the failure of the Ubuntu guy) that GRUB 2 really meddles with IFS - FAT16 is good, HPFS is bad, NTFS is good ... why, on earth, why?

(3) drivemap: OS/2 need not be "C:\", it need not be on a primary partition, it need not be on the first partition or on the first disc, it need not be within the int 13h limits. All this is a long forgotten history.

[wayne128]

(3) Installing GRUB 2 on a partition - ah, if only it were possible! No problems, no posts here or elsewhere! But, AFAIK, it is not possible. AFAIK, commanding GRUB 2 to install on a partition = the Linux loader itself installs on that partition but GRUB 2 overvrites MBR still. Installing GRUB on a partition without touching MBR was possible with GRUB 0.97: You made the partition bootable, BIOS booted the partition and GRUB 0.97 got control. Or you installed some BM and added the partition to the boot menu.

It's here, where all problems (and fears) begin. Installing GRUB 2 = losing boot manager. Having GRUB 2 in the MBR of the second disc solves nothing because BM can only boot a partition, not a MBR. With GRUB 2, I have to boot from GRUB 2.

I multiboot a few machines.
I just want to say this, just on my experience, most of the time there is no problem to have grub2 install to its own OS root partition. A few times grub2 ended up wiping MBR was ( I think) some bugs in installer of certain distros.

But then for Debian 6, I do not have such problem of grub2 overwriting MBR ( if I instruct it to install to root partition.)

When grub2 install itself to OS root partition, it made the OS chainloadable by other boot loader or window base boot manager.

For this computer I use grub legacy to control MBR and chainload all other OSes via grub legacy.
Here are the menu.lst just to illustrate.
I keep it simple and easy to understand for myself. Probably if you read it you can tell its simplicity too.
Note that in those OSes, two of them use grub legacy ( PClinuxOS and Pardus), one is windows, the rest are Debian and use grub2.

Code: Select all

# cat /mnt/boot/grub/menu.lst
timeout 5
color black/cyan yellow/cyan
gfxmenu (hd0,0)/boot/gfxmenu
default 0

title windows
root (hd0,2)
makeactive
chainloader +1


title sda6 Liquid Lemur64
root (hd0,5)
chainloader +1

title sda11 pardus xfce
root (hd0,10)
chainloader +1

title sda12 lemur beta3
root (hd0,11)
chainloader +1

title sda1 PCLinux KDE- MBR
kernel (hd0,0)/boot/vmlinuz BOOT_IMAGE=linux root=UUID=8cc7a57c-e98f-4633-add7-a54d45090ce2  quiet nokmsboot vmalloc=256M acpi=on resume=UUID=462c5dae-3c24-496b-8f0c-73b021e30b52 splash=silent vga=788
initrd (hd0,0)/boot/initrd.img


title sda5 Mint 10
root (hd0,4)
chainloader +1


title sda7 1G nothing
root (hd0,6)
chainloader +1

title sda8 Debian Gnome Squeeze
root (hd0,7)
chainloader +1

title sda9 Debian XFCE Wheezy
root (hd0,8)
chainloader +1

title sda10 Debian Sid Gnome
root (hd0,9)
chainloader +1

One final point, if you use any boot manager or boot loader to chainload to partition that has grub2, you have to watch out any upgrade on kernel or grub. When it upgrades, there will be a popup in terminal asking you to choose location of boot loader to install to, I always choose root partition!
if you choose MBR then it will follow your command and overwrite MBR.

[kiyop]

Thanks for many guys' reporting useful information.

I know with Debian Squeeze, with some computers "grub-install -f" to the root partition succeeded, and with the other computers "grub-install -f" to the root partition "failed". "failed" means that apparently "grub-install -f" displays no error, but GRUB2 cannot be booted correctly even when the PBR of the root partition is chainloaded by a boot loader. I cannot understand the reason. The reason may be different version of Grub2, different BIOS, and so on.

To Radvan,

I do not understand well the problem with your computer.

So, could you please answer the following?

1) Can you boot Debian and OS/2 in your HDDs now, by changing BIOS configuration (boot order)?

2) Do you think that GRUB legacy can boot OS/2?
If you think so, how about installing GRUB legacy to the MBR of the HDD involving the root partiton of your debian?

Code: Select all

su
apt-get update
apt-get purge grub-pc grub-common grub2
apt-get install grub-legacy

and reboot debian and

Code: Select all

su
grub-install /dev/sda
grub-install -f /dev/sda1

"sda" should be the MBR of the HDD involving the root partiton of your debian.
"sda1" should be the PBR of the root partiton of your debian.
Even if Grub legacy cannot boot OS/2, You know that you can boot Debian with the following way.
The MBR of OS/2 installed HDD -> OS/2 Boot Manager -> PBR of the debian root partition -> Grub legacy -> Debian.
It is the way you used before "BAD" grub 2 installation, I guess.

Grub4dos is another way besides MBM, PLoP, Grub legacy, and LILO.
Grub4dos can be installed on PBR although it is difficult to understand correctly how to install.
http://diddy.boot-land.net/grub4dos/fil ... indows.htm
http://diddy.boot-land.net/grub4dos/fil ... UB4DOS.txt

3) Can OS/2 boot manager chainload to MBR of different HDD from the OS/2 HDD?
If it can, it is very easy.
You can install GRUB2 into MBR and make "BIOS first boot device" the OS/2 HDD and set the configuration of Boot Manager of OS/2 so that it can chainloads to MBR where GRUB2 is installed.

P.S. I think GRUB2 is being developed extensively now, but is still on the way of development. Frequent updating of GRUB2 made me unable to prefer using it. I use the configuration file made by GRUB2 (grub.cfg) but I do not use GRUB2 as an boot loader except for the testing GRUB2. I found that in some "special?/extraordinary?" conditions GRUB 2 could not set up correctly, for example, with btrfs, with USB-3.0HDD.

[dzz]

Grub 2 is not compulsory in Squeeze; grub-legacy is still in official squeeze repos therefore I assume it's still officially supported. Last time I looked it was still in wheezy and sid as well.

I still use grub-legacy on squeeze and wheezy and see no reason to change from what I have got to know quite well and works well. I found grub2 less user-friendly with either missing or difficult to administer features which I need (installing to PBR, submenus, booting from squash, splash images, quick customisation in a simple text editor, ...... ) Unless there have been recent changes grub2 was also poorly documented.

[eric1959]

....grub2 was also poorly documented.

http://www.dedoimedo.com/computers/grub-2.html

[dasein]

There are multiple solutions to this problem. All are effective. They vary only in level of risk.

From riskiest to least risky, here's the first four that occur to me; there may be more.

Solution 1
1) Listen to the two people (including me) who have reported firsthand experience that grub2 installs quite nicely into the root partition and does not overwrite the MBR without express permission to do so.

(The OP has rejected this solution already, and it's definitely risky to rely on the word of strangers whose competence is unknown. But this solution does work, and relying on strangers who claim grub2 overwrites the MBR has disadvantages all its own.)

Solution 2
1) Test the install scenario in a VM. I have heard tell that OS/2 doesn't virtualize worth a damn, but it doesn't have to. The "test" could involve a SliTaz install (insanely quick to do, and uses grub legacy), followed by a Debian install. This solution allows the OP to verify firsthand that grub2 lives happily in the root partition.

Solution 3
1) Back up MBR from current boot drive.

2) Do whatthehellever.

3) Restore MBR from backup.

Solution 4
1) Disconnect the ECS drive. (If MBR on Debian drive gets overwritten, who cares?)

2) Install. Put grub2 in the root partition. Edit/tweak grub config files as necessary to compensate for "missing" drive.

3) Reconnect the ECS drive and reboot.


When I first migrated from OS/2 to Linux, I opted for Solution 4. It is just as safe and robust as one imagines it to be.

Here's hoping this thread dies a quick and painless death.

[Radvan]

Okay, I have no problems right now. I am running Lenny with GRUB 0.97 - all works as it should. I am trying to avoid the following scenario:

- intall OS/2 (with or without BM)
- install Squeeze
- get stuck

I have seen lot of stories like Keith Myers from the Ubuntu forum. All of them involve GRUB 2 and all of them have ended sadly: give up or, if you have 2 HDs, install Debian on one of them, OS/2 on the second one and swap drives in the BIOS data everywhere you want to swith from Debian to OS/2 or back. This is what I do not want. What is known so far:

(1) GRUB 2 do overwrite MBR even if it is commanded to instal on a partition. At least, some versions of GRUB 2 do (Ubuntu). At least, if you install on '/'. See Keith. Perhaps having /root partition will help. I will try.
(2) Method with "40_custom" does not work. At least in Ubuntu. See Keith.
(3) Trying to recreate boot manager after installing Ubuntu does not work. At least for Ubuntu. You get error 3 - system not found. See Keith.
(4) GRUB does not find OS/2. During installation, it is hinting that you have no operating system on your machine so far so that GRUB shoudl install in MBR. This is true for GRUB 0.97 in Lenny (my experience). GRUB also does not find existing OS/2 BM on the disk (my experience).

What I haven't tried so far: boot OS/2 from GRUB 0.97 (because I need not do it). Chances aren't high if attempting to boot from GRUB 2 fails. I can try but I haven't studied what I should do exactly. Also, when I cause crash, will rescatux save me?

What do I learned so far and what I am about to try after getting stuck:

(1) Have /root partition. What is the recommended size for it?
(2) A boot manager which can boot both Squeeze and OS/2. Kiyop posted some suggestions. Another one (paid) seems to be BootIt Bare Metal boot manager.
(3) LILO - I have no experience with LILO. When I get stuck and boot managers fail, I will ask questions. Also, all are switching to GRUB 2 so that going elsewhere seems to be unwise.
(4) Install OS/2 on FAT partition - this seems to pass but I don't want it. Oh, well ...

Disconnecting drives can be a bit problem in my case. I have a rather impregnable Sony notebook. Saving and restoring MBR will not work, it's the same as recreating BM. OS/2 in VirtualBox - sorry, I do not have VT-X. Otherwise, I have already "gave up", solve no problems, and have OS/2 in VBox

----------------------------------

ehm ... not /root but /boot most likely.

'/' - 15 G
'/boot' - 5 G
'/swap' - 5 G
'/home' - 75 G

[sgosnell]

You do not need to change the BIOS settings. Just press Esc when the BIOS splash screen comes up, and you get a menu which lets you choose the drive you want to boot from, including removable drives. You can also change the default boot drive with the files in /boot/grub/. Read the grub2 documentation, not just the rantings of people who have problems because they won't read it.

[pcalvert]

(3) LILO - I have no experience with LILO. When I get stuck and boot managers fail, I will ask questions. Also, all are switching to GRUB 2 so that going elsewhere seems to be unwise.

You can use LILO as a "bridge" or "stepping stone." Install LILO into the PBR instead of the MBR when you install Squeeze. Then, after you boot into Squeeze for the first time, remove LILO and install the legacy version of GRUB.

Phil

[Radvan]

Debian Squeeze, Attempt #1:

- removing Debian from boot manager menu
- creating partitions using OS/2 fdisk (in fact, using partitions used for Lenny). This can help to prevent incompatibilities with aligning or LVM (Keith from Ubuntu has experienced both problems). The partitions were always okay both Lenny and for OS/2.
- expert install, Debian 6.0.2 netinst, installing on ext4, root ('/') 20G, /home 70 G, /swap 5G
- crash at chroot during downloading files from the net.
- trying again, crashing again. Also noting a strange partition in BM menu which should not be there.
- reinstalling Lenny, okay, rebooting - the strange partition has been gone for a change.
- rebooting, both OS/2 and Lenny work (thanks God)
- a quick attempt to find on the net what has happened. Finding nothing useful ( not finding something useful quick enough)
- writing on the forum

Therefore, what happened? And what should I do when I crash again? And where comes that strange "bootable partition" in the BM menu from? Note that boot manager does not attempt to identify anything or decide what it shoud offer. It uses boot manager data prepared for it by the user. Note also, that OS/2 and boot manager are on /dev/sda while Squeeze was installed on /dev/sdb. During the installation, I haven't touched /dev/sda.

----------------------------------------

next attempt, failed:

chroot /target mount -t proc proc /proc

checking console at ctrl-alt-F4: "segmentation fault", section debootstrap

I have run memtest from rescatux (supposing that "segmentation fault" might be a page fault). After half a hour and (successfuly completed) "test #5", I gave up. It does not seem to be memory problem. If it is page fault then it is a chaos in page tables. I have also run fsck from rescatux. Both partitions (maybe) involved in installation ('/' and '/home') are okay.

[pcalvert]

Instead of trying to install Squeeze again, why not just upgrade Lenny to Squeeze? That way, you can avoid problems with the Debian installer and GRUB2 as well.

Phil

[Radvan]

Yes. A minor problem here: I am a Debian user rather than a Debian guru. I have seen several recipes how to upgrade, all of them involving editing system files, doing all from a console and performing a list of actions without having access to a web, where I could search for advices I don't think I am a coward and I am prepared to undergo such procedure but is there an enough simple recommendation how to upgrade somewhere? A list of instructions which I can put on a bit of paper and then try? Also, can I do the following

- install Lenny
- ctrl-alt-F1
- start upgrading

or should I shut down Gnome first? And if I should, how? And what else should I do first? You see, I am a real greenhorn