[TriLUG] [eee] post-install, grub OK from external stick but not from internal SSD
Tom Roche
Tom_Roche at pobox.com
Thu Apr 24 12:29:43 EDT 2008
summary: I'm trying to get my eee to again boot from its SSD (which
has the eee version of Xandros installed), without any external drives
attached (and preferably without blowing everything away by restoring
the factory install). The SSD's /boot/grub/menu.lst has
title Normal Boot
root (hd0,0)
kernel /boot/vmlinuz-2.6.21.4-eeepc quiet rw vga=785 irqpoll
root=/dev/sda1
initrd /boot/initramfs-eeepc.img
the contents of which are either factory-installed or altered by the
eeeXubuntu installer, or both. What syntax should I use instead? Or
how else to fix the current inability to boot without the eeeXubuntu
stick?
details:
Brian McCullough Thu Apr 24 11:46:58 EDT 2008
> [I] ask about how to fix these values, and not have to edit them
> manually each time you boot.
Not quite right: I'm only what the correct values are. I know how to
edit the values currently there (from grub as well as general-purpose
editors).
> Simply edit the menu.lst or grub.conf file in /boot on each device
> to have the correct values.
I understand how to persist the values; I even understand how to edit
the files which persist them (amazingly enough :-)
******* What I'm asking is ... what are "the correct values"?! *******
Apologies if these are FAQs, but I *really don't know*. If it's RTFM,
please pass pointers to (preferably-easily-consumable :-) doc.
One more thing, for clarification: The major problem I'm facing (in
this thread) is that, if the eeeXubuntu stick is not inserted @
boot/BIOS time, the SSD not only won't boot, it won't even put up a
grub menu. It just says "Error 21" and sits there like a brick: no
opportunity to edit the values, no hay nada.
Tom Roche Thu, 24 Apr 2008
>>> * SSD's /boot/grub/menu.lst has
>>> title Normal Boot
>>> root (hd0,0)
Joseph Mack Thu Apr 24 09:22:49 EDT 2008
>> this line is redundant, you have a root option in the next line
>>> kernel /boot/vmlinuz-2.6.21.4-eeepc quiet rw vga=785
>>> irqpoll root=/dev/sda1
>> you don't have a disk here. Presumably grub will default to
>> (hd0,0). It would be better to explicitely state a disk.
>> kernel (hd0,0)/boot/vm.....
Just to clarify (and in my own defense :-), all menu.lst given here
are virtually identical to those provided either by the eeeXandros
install or the eeeXubuntu install. The only thing I've done is to
change
root (hd0,0) <-> root (hd1,0)
as needed to boot (where possible).
>>> and no stanzas for booting from USB.
>>> * stick's /boot/grub/menu.lst has
>>> title Ubuntu 7.10, kernel 2.6.22-14-generic
>>> root (hd0,0)
>> mount /dev/sda1 as root after booting
Apologies for the noobiness, but how should I change menu.lst (et al?)
to accomplish that?
>>> kernel /boot/vmlinuz-2.6.22-14-generic
>> again no disk specified. presumably will boot from (hd0,0)
>>> root=UUID=45037d5d-b0f4-4d19-b00c-4f4aebc84a02 ro quiet splash
>> you risk a collision with the root line above. This seems a
>> complicated and error prone way of describing a disk. Is
>> there a reason you don't want /dev/sda1 or (hd0,0)?
Again, I didn't write the above: that's as installed. What's the
preferable syntax?
>>> initrd /boot/initrd.img-2.6.22-14-generic
>>> quiet
>>> and
>>> # This entry automatically added by the Debian installer for an
>>> # existing linux installation on /dev/sda1.
>>> title Normal Boot (on /dev/sda1)
>>> root (hd1,0)
>> does the BIOS know about (hd1,0)?
Yes. The boot device chosen by the BIOS (either first found in the the
boot device order, or user-specified by the Boot Selector Popup) gets
to be hd0. Whatever else is found is hdN. So if I have the stick
inserted @ BIOS time and I don't use the Boot Selector Popup to select
it, SDD=hd0 and stick=hd1.
>> is it in device.map?
Yes, the stick's /boot/grub/device.map is
(hd0) /dev/sda
(hd1) /dev/sdc
(hd2) /dev/sdd
>> I assume it's your flash stick and will be /dev/sdc1 after the
>> kernel boots.
Correct (again, empirically).
Your assistance is appreciated, Tom Roche <Tom_Roche at pobox.com>
More information about the TriLUG
mailing list