[Clfs-dev] Weirdness.

[Bryan Kadzban]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Ken Moffat wrote:
>  Took a look at the udev rules - the host (running udev-113) had a
> 70-persistent-net.rules file which associated the mac address with
> eth0.  To my knowledge, I never deliberately created that, and the
> timestamp suggests it was generated around the time I had first
> booted the host.

Yep, CLFS doesn't generate that file (which is probably good -- udev-118
doesn't have any way to pre-generate that file anymore; the downside is
that you can't create config files or directories for your NICs until
after you reboot, if you have more than one ethX device, because the
kernel will enumerate them randomly until you have rules to rename
them).  But the udev rules from upstream do create it, assuming the root
FS is writable when that rule runs.  (If not, it'll put them into /dev
and the bootscripts are supposed to copy them to the real root FS
later.)

> Copied it over to the new system, almost booted -
> got a dhcp lease, ntp came up, but then mount.nfs failed 'no such
> device'.  And the keyboard was now inoperative.

That's ... odd.  Having never done NFS myself, I'd guess that the "no
such device" is just a generic error from the mount syscall; the NIC
device obviously does exist if you were able to get a lease on it.  It
looks like something may be going wrong higher up the NFS stack?

The keyboard issue is really odd, since the keyboard doesn't require
udev AFAIK.  (...Well, at least, it doesn't on x86; maybe that's
different on PPC?)

> This is my first
> experience with udev-118, maybe I've missed a change (I got the
> change in the make and install commands, but maybe there is
> something else I should have changed ?)

There are standard udev rule files that get installed now, and there's
the change mentioned above where it can't pre-write NIC-naming rules,
but I don't think either of those are causing your issue.

Without a keyboard, it's hard to do much -- can this box use a serial
console?  It'd be interesting to see whether there are any NFS related
errors in the kernel logs after the mount fails.

Alternately, does it work any differently if you use init=/bin/bash and
run the bootscripts manually, one at a time?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHcpeqS5vET1Wea5wRA2IhAJ94RsZ7hPYCad6EvhWKE7PnmMOVWACggiTG
hrp90rV2MjitfnoBZLTYXUk=
=B5si
-----END PGP SIGNATURE-----