Please! If you reply to a digest, change the subject line so that some
semblance of threading is maintained.
Thanks.
martin welsh wrote:
> Thank you for your responses.
> I have tried hda7 and there is no difference to the booting response.
> I will go away and have a read where suggested but perhaps you will be
> good enough to give a little more guidance.
> 1. Where do the NFS filesystems that it is looking for come from. Is
> it a part of the kernel config?
I'm not looking at refs, so take what I say with a grain of salt and
make sure you investigate further.
Based on your previous post, it appeared to me that grub passed a
"root=" parameter to the kernel that specified an NFS volume. An NFS
volume is a file system or directory on another node in a network
(usually a LAN) that has been exported to make it available for mounting
by other nodes on a (usually) LAN. IF your node is in a corporate
environment, this may be the default. You can tell by examining the
/boot directory of your default boot drive, if it uses grub. If it uses
a way that is invisible to you, pull the network connector out and try
to boot.
If it uses LILO, /etc/lilo.conf (?) may tell you.
Grub has a series of stage1_5 modules tailored to different needs. There
are ones for PXE boot, DHCP, ... and different files sytems - ext2, ...
NFS, etc.
If you dive deep enough into the "info grub" I mentioned, you'll find a
good discussion of them and usages.
Why your boot process would be requesting an NFS volume is beyond my
ken. I must assume that either it picked up something from your build
environment (possibly faulty, like leaving it and reentering it with
getting all environmental variables set again properly, forgetting to
mount $LFS, ...?) or when grub was installed it didn't get put where you
think it is? Maybe the stage1/1_5/2 modules installed were wrong or
installed in the wrong place?
Remember that grub can be installed in the MBR or in the partition of a
file system. And it can be split, part in MBR, part in the file system
(IIRC). Since your host system is probably already in the MBR, I expect
that you put the grub parts in the /boot directory of the LFS file
system (IIRC, your listings showed that) and you have something like
this as well in sda7.
/boot/grub
/boot/grub/e2fs_stage1_5
/boot/grub/menu.lst
/boot/grub/stage1
/boot/grub/splash.xpm.gz
/boot/grub/stage2
Of course, in /boot itself (i.e. "above" the grub directory) will be the
kernel image, system maps, initital ram disk image(s), etc. In my
system, this is all in the default /boot, *not* in one specifically for
any of the systems I boot. Here is a more complete listing of my
normally used /boot (others exist on other disks for backup and I *can*
boot from them in an emergency - TG haven't had to, but I have tested
and do keep both disk's /boot directories in sync).
=====================================================
# Begin /boot/grub/menu.lst
# By default boot the first menu entry.
default 0
# Allow 10 seconds before booting the default.
timeout 10
# Use prettier colors.
color green/black light-green/black
# This entry is for latest CentOS 5
title CentOS (2.6.18-53.1.6.el5)
root (hd1,0)
kernel /vmlinuz-2.6.18-53.1.6.el5 root=/dev/VolGroup00/LogVol00 rhgb
hdc=ide-cd
initrd /initrd-2.6.18-53.1.6.el5.img
# This entry is for 1 back CentOS 5
title CentOS (2.6.18-53.1.4.el5)
root (hd1,0)
kernel /vmlinuz-2.6.18-53.1.4.el5 root=/dev/VolGroup00/LogVol00 rhgb
hdc=ide-cd
initrd /initrd-2.6.18-53.1.4.el5.img
# The first entry is for LFS. 7/7/7
title LFS 6.2 ide-cd 7/7/7
root (hd0,0)
kernel /lfskernel-2.6.16.36 hdc=ide-cd root=/dev/sda2
=====================================================
I forgot to change the comment line on the last entry.
Kernel configuration is related to NFS only if you are configuring an
NFS *server* that will share file systems or directories with other
nodes. For boot, it should have no effect.
> 2. When I generated the kernel config I thought that I had enabled
> sata drives. Are there any sign posts in the config compilation that a
> numpty can recognise?
If you can catch the dmesg scrolling by, you'll see the kernel messages
probing various hardware devices, trying to find hard drives, ... and
*tons* of things.
It may go too fast to catch on an attached console, but <CTL-S> and
<CTL-Q> (stop and start scrolling, respectively) should give you at
least a chance. OOPS! May not be a terminal handler there yet. Then the
<Scroll Lock> and <SysRq> keys may do it for you. I know they work when
BIOS has control, not sure if/which/any work during early boot stages.
IIRC, <CTL-ALT> with F2 or F3 will put you in the dmesg console. Again,
I haven't read up on this stuff in ages, so ...
A starting point would be to examine your kernel config file and see if
SATA is enabled, if the drivers for your unit can be identified, and are
they enabled.
In your BIOS, see if the SATA drives are in compatibility or native
mode. If you have a currently working *IX system, there should be a lot
of clues in the /var/log/messages, dmesg, pci, ... logs as to what your
hardware really is and what needs to be (dis|e)nabled in the kernel config.
Further, don't overlook the mention in previous posts about "compiled
in". If the driver(s) for your SATA drives are modules, then they must
reside in an initrd image and your grub menu.lst must use the initrd
clause to pass the file name via grub so that the driver can be found in
the initial ramdisk image.
> 3. Will the system, as it is presently created, tolerate me going back
> to reinstall 8.3 (hence reconfigure) the kernel?
Kernel rebuilds are SOP and should not be a problem.
8.3? It's been so long since I looked at an LFS book I can only vaguely
recall that was related to the kernel.
Regardless, your system is not working now, so you have little to loose.
Just take care that you don't trash your hosts, your environment is
re-established, $LFS is properly mounted, etc.
Consider using the "make oldconfig" method (IIRC, LFS has some verbiage
about that). You can use the config file from your host and then compare
the results to the one you made earlier by hand and look for differences.
You'll need to apply brain power - there are bound to be minor
differences in what parameters are available.
Save your current hand-crafted config first.
> Lastly a few details of the machine. -- mbo Gigabyte
> GA-M61SME-s2`Nvidia6100/405 chipset which are believed to contain MCP61
> sata controller. Two 80G Maxtor HDDs. Two ide CD/DVD drives. AMD 64
> dual core - virtually silent!
I'm not into hardware much, so you'll need help from others if they have
any knowledge of all that.
I do want to iterate another point I made in passing in the earlier post.
kernel /lfskernel-2.6.16.36 hdc=ide-cd root=/dev/sda2
Note that the "hdc=" thing tells the kernel about ide CD drives. I
don't know if it's related, but you'll probably need this down the
road.
You might as well get these in now so you won't forget later.
> Finally I apologise for my hamfisted way of replying to the lists any
> hints and tips here will also be appreciated.
Ham fisting is understood. As long as one keeps improving, tolerance
will be found.
Snipping, as I'm about to do is also encouraged by the list. Reply
*only* in text, *not* HTML. Turn on line wrap at column 70 or so.
Most mailers have configurations that let you reply in text. Usually
something under "Preferences". There will also be a wrap specification.
><snip>
>> Have I wrongly called the hard disc /dev/hda7 in menu.lst?
>> This is how the existing kernel -2.6.18-dcc-smp labels the devices.
>> Can anybody recommend any literature that will explain simply what
>> has gone wrong please.
IIRC, your OP showed sda7, not hda7. Mine uses sda2 OK, there is nothing
wrong with that, if all else is right for it. If your BIOS has SATA set
to PATA mode, then hda7 would be correct, and you *might* not need a
special driver, IIUC.
More thoughts below.
>><snip>
>> martin wrote:
>>
>>> Xandros 4.1 OS, AMD64 SATA disks.
>>> menu.lst - reads;
>>> "
>>> # By default boot the first menu entry.
>>> default 0
>>>
>>> # Allow 30 seconds before booting the default.
>>> timeout 30
>>>
>>> # Use prettier colors.
>>> color green/black light-green/black
>>>
>>> # The first entry is for LFS.
>>> title LFS 6.3
>>> root (hd0,6)
>>> kernel /boot/lfskernel-2.6.22.5 root=/dev/sda7
>>>
>> I have sata disk too and have experienced NP. Here's the pertinent
>> snippet of my menu.lst
>>
>>
>>> # The first entry is for LFS. 7/7/7
>>> title LFS 6.2 ide-cd 7/7/7
>>> root (hd0,0)
>>> kernel /lfskernel-2.6.16.36 hdc=ide-cd root=/dev/sda2
>>>
>> Note that the "hdc=" thing tells the kernel about ide CD drives. I don't
>> know if it's related, but you'll probably need this down the road.
>>
>>
>>> "
>>>
>>>
>>> The LFS system is located in /mnt/lfs which is situated on/dev/sda7.
>>>
>>> The following text is displayed when loading comes to a halt.
>>>
>>> ".......
>>> Root - NFS: No NFS server available , giving up.
>>>
>> The above line is, I *think* your problem. You should not be trying to
>> boot from an NFS (Network File System) volume here? And the line below,
>> I *think*, confirms this as the "root" (no pun intended) of your problem.
Does your host system boot via grub? If so, what does it's menu.lst (or
in some cases, grub.conf) show? Does it have an initrd? What stage1_5 is
it using? There may be valuable clues within a working configuration.
Nose around in there, compare to what you believe you've done.
BIGGEE! Any chance that when the kernel was made, *or* when grub was run
$LFS was not mounted properly? Did you have proper permissions so that
you could actually write stuff where it needed to be written?
>>
>>
>>> VFS: unable to mount root fs via NFS trying floppy
>>> VFS: insert root floppy and press enter
>>> ...."
>>>
>>> Floppy, prepared as in section 8.4, was inserted, pressed return.
>>> The following text was displayed;
>>> "
>>> List of all partitions:
>>> 0200 1440 fd0 (driver?)
>>> 0300 4194302 hda driver: ide-cdrom
>>> 0340 4194302 hdb driver: ide-cdrom
>>> No filesystem could mount root, tried: reiserfs ext3 ext2 msdos vfat iso9660
>>> Kernel panic - not syncing: VFS: Unable to mount root fs on
>>> unknown-block(2,0)."
>>>
>>> I have found it impossible to elicit the significance of the text in either
>>> of these messages.
>>>
>>>
>>> Starting the machine with the root floppy made in section 8.4 provides the
>>> following data;
>>> "
>>> root (hd0,6)
>>> Filesystem type is ex2fs, partition type 0x83
>>> setup (hd0)
>>> Checking if "/boot/grub/stage1" exists ... yes
>>> Checking if "/boot/grub/stage2" exists ... yes
>>> Checking if "/boot/grub/e2fs_stage1_5" exists ... yes
>>> Running "embed /boot/grube2fs_stage1_5 (hd0)" ... 15 sectors are embedded.
>>> suceeded
Is the above correct? I do not know. I am leery of the word "embed", as
IIRC the grub info page uses that in a specific meaning (writing 15
sectors immediately after the MBR? I am unsure of this). Regardless,
*my* expectation would be to see it "embedded" in (hd0,6). Maybe one of
the more knowledgeable folks can clarify the validity of this.
Another thought. Your host system boots. Grub? If so, you need to put
your menu.lst entires into the one for the host system *or* change the
active flag from the default to the LFS partition? Not a good idea.
Maybe the "activate" keyword is needed in the menu.lst? I think this
does like a temporary mark bootable thing. But that might be only for
chain loading, I don't recall for sure. *My* way of doing it was to put
all the menu.lst stuff for the new systems into the existing menu.lst
and put the kernel and initrd images into the standard /boot of the
existing system.
>>> Running "install /boot/grub/stage1 (hd0) (hd0)1+15 p
>>> (hd0,6)/boot/grub/stage2 /boot/grub/menu.lst" ... succeded
>>> Done.
>>> "
>>>
>>> I am at a loss. The grub boot loader says the system is unworkable but
>>> the response from the floppy triggering an unloaded machine says that
>>> there is nothing wrong with the boot loader or the relevant file structures.
>>>
>>> Are there any checks that I can carry out on the build to confirm that
>>> it is healthy?
>>> Have I wrongly called the hard disc /dev/hda7 in menu.lst? This is how the
>>> existing kernel -2.6.18-dcc-smp labels the devices.
>>>
>> <snip my previous reply>
Whew! I'm getting wrung out here! But I really don't want to crack the
book(s) again. ;-)
HTH
--
Wit
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
