[brokenhead]

Some Linux distros give you the option during install of installing GRUB on your floppy (fd0) instead of on one of your hard drives. If you do this, how do you then boot up your Linux?

[saikee]

Your Linux boots whenever you have that floppy in the drive. \

It is one of the several ways to boot up Linux (or other systems) without touching the MBR of the hard disk. The step can be done at a root console after the Linux has been installed.

In Linux with Grub

grub-install /dev/fd0

In Linux with Lilo

lilo -b /dev/fd0

Pretty flexible too. For MBR change device name to sda or hda (/dev/sda). For in root partition, say sda3, just change the device name to /dev/sda3.

[brokenhead]

Hi Saikee!
That's what I thought - that the Linux will boot whenever I have the floppy in the drive and my BIOS is pointing to the floppy as a boot device.

HOWEVER: All I get is this:

GRUB_

The "_" is flashing as if it is a prompt. But nothing happens and I cannot enter anything! I'm completely stuck at this point.

[brokenhead]

To assist, here are some Partition Magic screen captures of my drives.

I tred Super Grub Disk (SGD) and got the dreaded Grub error 17 message.

As I said, I'm stuck at this point. I'm willing to reinstall Linux - I have Ubuntu 7.10 which I prefer, and I have Mandriva One 2008. Any suggestions?

[RobLinux]

http://users.bigpond.net.au/hermanzone/p15.htm#17

Quoted from the GNU/GRUB manual
17 : Cannot mount selected partition
This error is returned if the partition requested exists, but the filesystem type cannot be recognized by GRUB.
In a computer with more than one hard disk

When booting Windows (if you only have one hard disk)

When trying to boot Linux (if you only have one hard disk)
In a computer with more than one hard disk
GRUB error 17 could be caused by some confusion between your computer's BIOS, the Linux kernel, and GRUB over which hard disk is the first hard disk and which is the second hard disk and so on.
Symptoms include GRUB being installed to MBR on the wrong (non-first) hard disk, and the /boot/grub/menu.lst file having the hard drive numbering wrong in each operating system entry.

This is especially likely to occur if you have IDE hard drives and you made a mistake with the way they are plugged in and jumpered, (master, slave or cable select).
This also sometimes occurs when we have a mixture of IDE and SCSI or SATA hard drives plugged into the same motherboard.
Something else that can definitely cause the mix up is when someone changes their hard disk Boot Priority in their BIOS. Make sure your hard disks are properly detected in your BIOS and set to AUTO, (not LBA, large or normal). Refer to this thread, Grub error 17, thanks AmericanYellow for that information.

This problem only happens when GRUB is installed automatically by a new operating system being installed in a computer.
This never happens, (or people don't complain of it), when GRUB is installed manually from the command line or by Super Grub Disk, because in those circumstances it is the user who directs GRUB to install somewhere.
It doesn't seem to me to be really GRUB itself that makes the mistake, it seems more likely to be the operating system's grub-install script, or whatever the grub-install script queries to determine the order of the devices, (probably the BIOS or another program the queries the BIOS I would guess).

Solutions to this problem are to boot with another GRUB, such as Super Grub Disk, and edit the /boot/grub/device.map and re-install GRUB (to the correct device this time). Here is a link with more details about that, Editing GRUB's device.map

[RobLinux]

I'm thinking that the OS Installer's are having a hard time, with multi-disk configs. Error 17, seems to be frequent issue nowadays with Ubuntu (see google and http://forums.techguy.org/unix-linux...-17-after.html )

I'm using device labels, mke2fs -L UbuRoot, mkreiserfs -l UbuVar, mkswap -L SW-HDDSERIAL and avoiding device names as they bounce between SCSI and IDE, due to libata code and my occasional need to specify "brokenmodules=pata_..."

I like having /boot as a small ext2 partion seperate from /.

May be the BIOSes aren't getting tested with boot floppies anymore, as they're regarded as "legacy devices". Perhaps a Boot CD image would work better?
If there's no joy with GRUB it might be worth trying lilo(8); it is defensive and distrusts the BIOS, using as much info as poss from Linux kernel at install time, rather than querying BIOS at runtime. So it may succeed where GRUB fails.

[saikee]

Your problem is only a matter of boot disk order.

You have 3 hard disks and have instructed the Bios which one is to be booted up first, right?

However your Bios also has a booting queue for the devices too. In order to boot a floppy you would have to instructed the floppy (and CD too normally) to be booted before the hard disks. This means your instruction, of which one of the three hard disks is to be booted first, has not been reached or executed and so the hard disks have been detected according to the the controllers and hardware connection points. Therefore the hard disk booting order is not consistent with the Grub instructions.

Depending on how the floppy was prepared I believe your floppy may have a menu.lst and Grub got stuck possibly due to an instrction to load a splashimage from a partition that it cannot find.

Your Linux is still bootable if you have a Grub prompt, which you can obtained from a selected Live CD as described here.

The long term cure is to amend the menu.lst.

[RobLinux]

But in the orignal thread, his config file was trying to boot off (hd2,0), now he's not doing any BIOS disk re-ordering, so he should be able to use GRUB on the floppy to load the kernel. The devices should be in same order as when it's booted off CD.

Rather than using grub-install, try making the floppy file system by hand and copying advice on this page http://users.bigpond.net.au/hermanzo...ppy_howto_make

The /boot/grub files get copied over, and in the fd0 /boot/grub/menu.lst, the root (hd2,0) ought to allow GRUB to find the Linux kernel and initrd. Ubuntu's use of UUID should avoid problem of '/' changing devices.

There's a file /boot/grub/device.map, relating GRUB disks to device files, and I think that can be wrong and is used by grub-install script. On my system, things are confusing, because to install GRUB the Linux disk is (hd1) and /dev/sdb; but in menu.lst due to BIOS device mapping, it's (hd0).

[brokenhead]

Thanks Saikee and RobL.!!
You have given me a few things to try.
I have just spent some time installing a new power source and now I'm up and running nicely.
FYI - I tried Mandriva instead of Ubuntu, requesting GRUB go to (fd0). That builds a menu.lst on (fd2, 0) as expected. But I still got that GRUB prompt when booting to the floppy:
GRUB_
at which point I can enter nothing.
So it's not just Ubuntu!
When I use the live disk to enter the GRUB shell and verify with the "find" command, I find my menu.lst where it should be, on (fd2, 0). When I look at it, it has picked up my XP just fine.
I then use Super Grub Disk to boot to Mandriva and get the "error 17."
I know my BIOS lists (hd0) as boot device #1. The other devices are (fd0) and my CD drive. (The CD drive is secondary slave.) The hard drives are as follows:
hd0 - Primary Master (160 GB - XP Partition)
hd1 - Primary Slave (80 GB - data storage)
hd2 - Secondary Master (160 GB - Linux install)
cd1 - Secondary Slave
So the boot sequence is hd0, fd0, cd1. Note that ONLY ONE HARD DRIVE IS ALLOWED BY THE BIOS INTO THE BOOT SEQUENCE!
Which hard drive is allowed into the boot sequence is determined by another setting altogether. It lists all the hard drives and asks you to put them in a desired order. IT THEN TAKES THE FIRST ONE LISTED AND SENDS THAT TO YOUR CHOICES FOR THE BOOT SEQUENCE. The other drives are NOT options for your boot sequence in this BIOS.
HOWEVER: The order I choose in this second setting might be the problem. I should keep the Primary Master (XP) as the first in the list (hd0). But I might have my Secondary Master as #2 in the list. Maybe GRUB sees this and thinks it is (hd1)! If I make it #3 in the list, perhaps GRUB will see it as the THIRD HARD DRIVE or (hd2), where it expects to find Linux and menu.lst, specifically on (hd2, 0).

Either way, I have been concentrating on the boot sequence in the BIOS, when maybe the problem is in this other setting.

I'll let you know.
Thanks again. If you don't hear from me today, have a great and peaceful holiday!

[brokenhead]

HOORAY!! Saikee and RobL - you pointed me in the right direction! I made the change in the BIOS I mentioned in my last post. Error 17 is GONE!! I installed Ubuntu to (hd2, 0) and placed GRUB on (hd0, 0), which is the default setting in the Ubuntu 7.10 install.

Ubuntu 7.10 is so far my favorite distro - it sees all my peripherals and the latest kernel includes the drivers to support my wireless router.

As I learn more about GRUB, I want to test more Linux distros as they come out. Maybe not 100 concurrent like Saikee, but several. I'm keeping this thread open while I try to put GRUB on (fd0) and do a fixmbr for (hd0).

But thanks again, guys - I can now get into both XP and Linux, which is what I wanted!!

[RobLinux]

This is very interesting! Congratulations on perservering.

On this Dell box, I have the problem that the BIOS is dumbed down. I have 1 option to select Boot Disk order, but the disks are "named", and I have 2 new WD's which differ only by serial number, about 16 char's in on the IDs. My selection of HD boot priority gets ignored (both disks show same string in BIOS selection). By hitting a key, I get a menu which does let me boot the 2nd disk. I could create a GRUB boot CD, with the options but for now I've tried and failed to get Vista to boot the 2nd disk. I'm wondering if the problem is that the BIOS tries to boot CD first, and then on failing boots Primary Master, rather than the preferred HD selection, or that they simply don't test enough chars on the disk ID's and they used that because they thought it was more user friendly than IDE numbers and Master / slave.

As you've had problem with XP, presumably it is not just a Vista DRM type issue, though may be BIOS changes to supported "trusted" machines are involved. If this is supposed to be User/Customer friendly heads need cracking together.

This may not be relevant, but I wonder if you have Dell or similar?

The problem with your solution, is that Windows (only install disk?) may at some point "fix" your MBR, and you may be depending on having hd2 working, to boot windows. I guess it's no worse than running something like that Easy Boot manager.

[brokenhead]

I have a Gateway, not a Dell. Gateway's BIOS - and editing it - are fairly easy and with good descriptions in all the CMOS option places, so that you at least have a clue as to what you are specifying.

I can't say much about Vista, because I only played around with the Beta a while back. But in general, a fair portion of "user friendly innovations" must be, IMO, referring to some other user, not yours truly.

I think as far as GRUB and error 17 goes, it seems Saikee was leading me in the right direction, in that it has to be an issue with what GRUB thinks is (hd0), (hd1), etc. Is that set by you in BIOS in boot sequence or some other setting as in my case? Or is it primary vs. secondary, and then master vs. slave? I guess all you can do is try different things out until you can a) boot properly, AND b) error 17 goes away. It may be as simple as switching the 2 IDE ribbon cables into each other's jacks on the MoBo!

In my case, I'm safe, because I made a copy of my boot floppy and did a fixmbr on (hd0,0). That way, I will always be able to get into both XP and Linux.

[RobLinux]

The BIOS probes for drives, and determines a boot order based on selection, it assigns the 'boot' hard disk a certain number, 2nd disk the next then 3rd.

When you boot from floppy (or CDR/DVD), it is not the "C:" drive (0x80), so the normal drive numbers are not altered, except that you may undo some boot priority eg) Have the boot drive on a PCI ATA controller usually, now when you boot on floppy it is likely to change BIOS drive number.

The problem I'm having with the Dell BIOS, is that it is hiding all this information. That means you are reduced to "trying things" as you put, without actual understanding of what's actually going on. That is a place I do not like to be. There may be some magic key combo to un-dumb-it-down, but I haven't seriously tried to find out yet.

Building the boot disk, via the steps has the advantage that you are more likely to know what the actual error is, and also unravel the confusion that surrounds drive remappings.

The fundamental problem, was that probe order of the drive, was given some meaning ie. C:; rather than in Bios saying IDE 1 1 (Master) is boot drive or IDE 3 (Slave), SCSI 1 LUN 3 etc. When new devices are added, it can become non-obvious what will happen.

If you've used a BIOS where Boot selection, was via choice between various orders, you'll know how much less convenient that is, than having choice of 1st, 2nd & 3rd boot device.