Grub runs upto stage 1.5 then gives error 17

2006-11-15 Thread Shirish Agarwal

Hi all,
  I have one 80 GB HDD which has Windows XPSP2 (NTFS based)  
Ubuntu 6.06 upgraded to Ubuntu 6.10 (ext2). It had GNU GRUB 0.97 running 
underneath it all. Everything was running fine   suddenly yesterday it 
gave me error 17. Looking in Grub Legacy came to know tht error 17 means :-


http://www.gnu.org/software/grub/manual/grub.html#Stage1_002e5-errors

17 : Cannot mount selected partition
   This error is returned if the partition requested exists, but the
   filesystem type cannot be recognized by GRUB.

 Now in such should I re-install everything or is there some sorta hack 
which can make it good without re-installing the whole thing.
 Lastly when we should be able to see Grub2 being used in 
main-stream distros.  Thnx in advance.


--
This work is licensed under the Creative Commons 
Attribution-NonCommercial-NoDerivs 2.5 License. To view a copy of this license, 
visit http://creativecommons.org/licenses/by-nc-nd/2.5/ or send a letter to 
Creative Commons, 543 Howard Street, 5th Floor, San Francisco, California, 
94105, USA.



___
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub


Fallback for SATA and IDE drives when booting from a CD?

2006-11-15 Thread Russel Hill

I posted the following on grub-devel before I realized that this was
the better list for it...

We are booting from a CD which needs to forward to a bootable hard
drive (if possible). The hard drive might be SATA, might be IDE.

My current menu.lst looks something like this:

#
timeout 10
default 0
fallback 1 2

title boot from SATA drive
root (hd0,0)
kernel /vmlinuz root=/dev/sda2 panic=5
boot

title boot from IDE drive
root (hd0,0)
kernel /vmlinuz root=/dev/hda2 panic=5
boot

title Boot from CD
root (cd)
kernel /boot/vmlinuz root=/dev/ram0 init=/linuxrc
initrd /boot/initrd.img
boot
#

The only difference between entries 0 and 1 is in the
root=/dev/?da2.  If we were booting from writable media, we could
use default savedefault and savedefault fallback commands to chain
from one entry to the other after a kernel panic. Unfortunately,
that's not the situation. As it is this menu.lst works with SATA
drives but not with PATA or IDE drives. I can switch this around by
reordering the entries (or modifying default and fallback) but I can't
seem to get

Is there a way for grub to substitute the correct /dev/* depending on
whether the drive is SATA or not?

Even better would be a way to make this work when booting from a CD:

#
timeout 10
default 0
fallback 1

title boot from hard drive
rootnoverify (hd0)
chainloader +1

title Boot from CD
root (cd)
kernel /boot/vmlinuz root=/dev/ram0 init=/linuxrc
initrd /boot/initrd.img
boot
#

Can this be made to work? If so, what am I missing?

Thanks,
Russel Hill


___
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub


[RFE] Installing grub into an XFS partition

2006-11-15 Thread Keith Owens
Please cc: me, I am not subscribed to bug-grub.

As we all know, you cannot install grub into an XFS partition because
the XFS superblock is in sector 0 of the partition.  grub-install must
not overwrite sector 0 which means that you cannot use 'chainloader +1'
to boot a secondary grub menu from an XFS partition.

This is frustrating when testing multiple distributions in separate
partitions.  It is so much easier to have a top level grub menu that
boots from the MBR and lists the available distributions, then uses
chainloader to boot from each distribution.  Each distribution's
partition contains its own specific second level grub menu.

It turns out that this process can be made to work, even for an XFS
partitions :-

* Create a partition to contain the top level menu.  menu.lst contains
  a list of distributions and uses chainloader to boot from each
  partition.  MBR points at this top level menu.  The partition can be
  any format, and it can be as small as one cylinder.

* For partitions that do not use sector 0, do a normal grub-install
  using that partition's local /boot and writing to sector 0 of the
  partition.  No change.

* The top level menu uses 'chainloader +1' for partitions when the
  secondary stage1 is in sector 0.  No change.

* For partitions that do use sector 0 (e.g. XFS), do grub-install using
  that partition's local /boot.  Instead of overwriting sector 0 of the
  XFS partition, tell grub-install write to sector 0 of any partition
  that is not being used as a secondary stage1.  I use sector 0 of the
  partition that contains the top level menu; its sector 0 is free
  because the MBR contains the stage1 file for the top level menu.  Say
  you write to sector 0 of /dev/sda1.

grub-install --root-directory=/mnt/xfs /dev/sda1

* dd if=/dev/sda1 (say) bs=512 count=1  /mnt/xfs/boot/grub/stage1.copy

* The top level menu uses 'chainloader (hd0,n)/boot/grub/stage1.copy'
  for partitions when the secondary stage1 cannot be installed in
  sector 0.  IOW you chainload from a file instead of sector 0.

AFAICT, there is no requirement that _any_ secondary stage1 must be in
sector 0, it is just an historical convention.  Writing the XFS stage1
to a spare sector then copying the result to a file in the XFS
filesystem works for me (TM).

Now for the RFE.  Could grub-install be enhanced so it can optionally
write the updated stage1 data to a file instead of only being able to
install in sector 0 of a partition?  That would remove the need to
write to a separate partition then dd the result to a file.  IOW

  grub-install --root-directory=/mnt/xfs /mnt/xfs/boot/grub/stage1.copy



___
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub


Re: Doesn't boot Linux on SATA, but OpenBSD

2006-11-15 Thread Uwe Dippel

So, when I root (hd0,1,a) followed by chainloader +1, it boots to
OpenBSD splendidly.
But root (hd0,0) [ext2 filesystem], makeactive, kernel vmliuz--- ro
root=/dev/sda6, initrd ..., boot
dies with pivot_root ... cannot open /dev/console ... Kernel panic.
Yes, /dev/sda6 is '/'

What is it that I make wrong here ?


Though I have yet to solve it, it seems I can absolve grub. After
plenty of research I found the problem to be with Debian, either a
kernel problem (missing driver) or a devfs/udev problem.

Now I am having to sort out a Debian-problem as it seems.

My excuses for the noise on the grub-list,

Uwe


___
Bug-grub mailing list
Bug-grub@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-grub