Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
GRUB 2 - Possible problems ahead
GRUB 2 - Possible problems ahead
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?
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?
Re: GRUB 2 - Possible problems ahead
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.
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?
I found myself confused by this portion of your post.Radvan wrote: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.
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?
-
- Posts: 114
- Joined: 2009-03-04 18:02
- Location: British Columbia
Re: GRUB 2 - Possible problems ahead
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.
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.
Re: GRUB 2 - Possible problems ahead
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.)StanTheMan wrote: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 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
- Posts: 3983
- Joined: 2011-05-05 15:16
- Location: Where persons without desire to improve themselves fear to tread, in Japan
- Been thanked: 3 times
Re: GRUB 2 - Possible problems ahead
I am not familiar with OS/2.
But I agree with dasein's:
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)
but I do not know how to enable LVM while installing GRUB2, if default installation of debian has not enabled LVM in your case.
But I agree with dasein's:
You should have kept OS/2's BootManager work well.dasein wrote: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
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
Openbox, JWM: Jessie, Sid, Arch / Win XP (on VirtualBox), 10
http://kiyoandkei.bbs.fc2.com/
http://kiyoandkei.bbs.fc2.com/
Re: GRUB 2 - Possible problems ahead
(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.
(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
- Posts: 3983
- Joined: 2011-05-05 15:16
- Location: Where persons without desire to improve themselves fear to tread, in Japan
- Been thanked: 3 times
Re: GRUB 2 - Possible problems ahead
Thanks for your reply. Radvan.
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,
"(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:
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
I know that GRUB legacy have useful commands "rootnoverify", "map" and "chainloader".Radvan wrote: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.
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
To know the name of the device(HDD) and partitions, simply type in Grub2 command line:
Code: Select all
ls
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
Openbox, JWM: Jessie, Sid, Arch / Win XP (on VirtualBox), 10
http://kiyoandkei.bbs.fc2.com/
http://kiyoandkei.bbs.fc2.com/
-
- Posts: 1939
- Joined: 2006-04-21 11:19
- Location: Sol Sector
- Has thanked: 1 time
- Been thanked: 2 times
Re: GRUB 2 - Possible problems ahead
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
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
Freespoke is a new search engine that respects user privacy and does not engage in censorship.
Re: GRUB 2 - Possible problems ahead
(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.
(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.
Re: GRUB 2 - Possible problems ahead
I multiboot a few machines.(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 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
if you choose MBR then it will follow your command and overwrite MBR.
- kiyop
- Posts: 3983
- Joined: 2011-05-05 15:16
- Location: Where persons without desire to improve themselves fear to tread, in Japan
- Been thanked: 3 times
Re: GRUB 2 - Possible problems ahead
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?
and reboot debian and
"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.
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
Code: Select all
su
grub-install /dev/sda
grub-install -f /dev/sda1
"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.
Openbox, JWM: Jessie, Sid, Arch / Win XP (on VirtualBox), 10
http://kiyoandkei.bbs.fc2.com/
http://kiyoandkei.bbs.fc2.com/
Re: GRUB 2 - Possible problems ahead
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.
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.
Re: GRUB 2 - Possible problems ahead
http://www.dedoimedo.com/computers/grub-2.html....grub2 was also poorly documented.
Debian Bits And Snips
Squeeze, Gnome, amd64, Intel Core i3-530, Geforce GT330
Squeeze, Gnome, amd64, Intel Core i3-530, Geforce GT330
Re: GRUB 2 - Possible problems ahead
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.
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.
Re: GRUB 2 - Possible problems ahead
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
- 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
Last edited by Radvan on 2011-08-13 18:07, edited 1 time in total.
Re: GRUB 2 - Possible problems ahead
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.
Take my advice, I'm not using it.
-
- Posts: 1939
- Joined: 2006-04-21 11:19
- Location: Sol Sector
- Has thanked: 1 time
- Been thanked: 2 times
Re: GRUB 2 - Possible problems ahead
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.Radvan wrote: (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.
Phil
Freespoke is a new search engine that respects user privacy and does not engage in censorship.
Re: GRUB 2 - Possible problems ahead
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.
- 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.
-
- Posts: 1939
- Joined: 2006-04-21 11:19
- Location: Sol Sector
- Has thanked: 1 time
- Been thanked: 2 times
Re: GRUB 2 - Possible problems ahead
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
Phil
Freespoke is a new search engine that respects user privacy and does not engage in censorship.
Re: GRUB 2 - Possible problems ahead
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
- 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