[mdlug] Grub error 17

[Dr. Robert Meier]

Stan,

I regret that I don't have a complete answer handy,
but I hope the following will help.

For further details, consider reading the lengthy exchange at
    http://forums.gentoo.org/viewtopic.php?t=120802

I suspect, initrd, the ram disk boot loader[1],
was assembled at grub-install time
with a map of devices different from that at boot time.

<example>
grub was installed on a hard disk in one host,
where directing the bios to download from hd1
loaded the kernel from the hard disk,
and then the hard disk was placed in a different host,
where directing the bios to download from hd1
failed to load the kernel from the cd drive.
</example>

In your case I suspect the usb drive was installed when you
ran grub-install(?) to "setup grub" and its presence
altered the map of bios devices to unix devices
(e.g. hd0 vs hd1 mapped to /dev/hda vs /dev/usb0),
so that it differed from that reported by the bios
during a later boot.  As I would expect the bios
to map all non-removable devices exclusively or
before any removable devices, the only way I
can imagine your problem arising,
requires time-overlapping installation and removal
of an atapi (ide-scsi) or other such transient
device.



<hint>
If my assumptions are correct,
the deterministic solution is to boot an
appropriate[2] rescue system
(e.g. SuSE Rescue Disk) and "boot from hard disk",
thus bypassing the hard disk mbr and initrd.
You can then run grub-install with the correct
device map.
</hint>

<hint>
If my assumptions are correct,
a more practical approach is to repeatedly
   1. boot a rescue system
   2. mount the hard disk, and edit /boot/boot/device.map on hard disk
   3. shut down rescue system and remove live cd
   4. attempt to boot from hard disk (without rescue system)
   5. repeat steps 1-4 until 4 is successful
In step 2 of each repetition, try a different pairing of
   (hd0), (hd1), (hd2), ...
and
   /dev/hda, /dev/hdb, ...
I would expect a successful boot in less than 7 attempts.
(I would expect (hd0) /dev/hda to be most probable.)
</hint>



Once you have a successful build, I suggest that you
use grub to reinstall cleanly so that this vexing
problem does not bite again in future updates.



[1] initrd is a small operating system image used to load a kernel
that cannot be loaded by bios (usually too large or resident on
a device not supported by bios).

[2] Most simpler "rescue disk"s are merely and adjunct
to an installation, probably reboot via bios,
and would not be appropriate.  A better rescue disk will let
you select the bootable partition, act as a "chain loader",
and skip the bios "boot loader".



On 08/19/10 20:09, Stan Green wrote:
> I moved my wife's computer form SUSE 11 to Debian Lenny. I took a minimal
> install approach and added what she needed. I had it almost done, just needed
> to get USB working for a normal user, as I could only mount one as root. (This
> is not the primary issue now! I'll come back to that later.)
>
> So, I was messing around with dbus and hal configuration. Nothing was working so
> I put almost everything back the way it was (I missed a policy section in
> hal.conf that gave her user ID the same rights  as root.)  I then rebooted, but
> I forgot to take the USB flash drive out of the port.
>
> So up come GRUB error 17. My web searching turned up that error 17 is: "This
> error is returned if the partition requested exists, but the filesystem type
> cannot be recognized by GRUB. "  I do not even get to the GRUB menu. After
> spending hours on line trying everthing I can find, I am pulling my (virtual)
> hair out. Using Knoppix, I have run GRUB setup on the first hardrive, I have
> done the fidisk to fix the partation table. I have run fsck on both the boot
> partition and the root partation.  Nothing has worked.
>
> So, could I have messed up something with dbus or hal that would keep the
> machine from booting? Could leaving the USB drive in caused some change?

hal.  Yes, but AFAIK, another "mounted device removal" was required,
e.g. running kernel on atapi mounted partition.

> Is there anything else that might be keeping GRUB from recognizing the file
> system?

A purely coincidental disk corruption of the boot image
could have the same symptoms,
but fsck and grub setup should have corrected the corruption.

Hopefully helpful,
--
Bob