[SOLVED] Some More Oddness From LFS/BLFS 7.4

Just rebuilt LFS/BLFS 7.4 and found a couple of odd things:

1) Keyboard and mouse don't work in X, fine in the console but when I use startx or startxfce4 sometimes the mouse does/doesn't work and the keyboard doesn't at all, if I plug in a usb keyboard that works, if before starting X i re-run udev like so

/etc/init.d/udev start

it works fine, but this gives me two instances of udevd running.

2) Really annoying error messages from "/lib/lsb/init-functions" about being a read only file system or a non-existent bootlog file.

3) Throws error when shutting down/rebooting when trying to remount '/' as read only

I guess I can hack these problems out but it would be nice if there was an "official" fix.

That's weird. I haven't had that issue. Scary that it might exist, but have you checked for a hardware failure yet such as using a different USB port, or a P/S2 mouse/keyboard?

It is a ps2 keyboard but it works fine on my present system LFS7.2 though as I said runing udev again makes the system recognize it but the problem is only in X anyway from the console it works ok.

Have you attempted to install the legacy non-udev xf86-input-mouse, *-keyboard, *-joystick X11 device driver packages yet and try it instead of evdev and test them?

If udev needs to be ran again, you might want to double check your sysvinit startup script for the udev handler and see if it isn't corrupted or commented out for the extra udev check.

Also, which kernel are you running? I'm currently using 3.10.15 without any issues.

Originally Posted by Keith Hedger ...a non-existent bootlog file.

The bootlog file to which init-functions echoes messages is /run/var/bootlog. You created the /run mount point. The mountvirtfs script creates /run/var. Your /etc/fstab should have the tmpfs line. Your config should have CONFIG_TMPFS=y. No promises.

Originally Posted by ReaperX7 Have you attempted to install the legacy non-udev xf86-input-mouse, *-keyboard, *-joystick X11 device driver packages yet and try it instead of evdev and test them? If udev needs to be ran again, you might want to double check your sysvinit startup script for the udev handler and see if it isn't corrupted or commented out for the extra udev check. Also, which kernel are you running? I'm currently using 3.10.15 without any issues.

Tried installing the old drivers but no joy at all.

Checked the udev script can't see anything wrong and in fact I did a complete re-install but the same thing happens, although 'top' shows that the udevd daemon is running it seems to do nothing manually running the script seems to kick start it into working by launching a new instance of udevd ).

Kernel is 3.10.10
Also tried slackware's huge config to see if that helps but it doesn't, oddly I tried booting to my old kernel that I am running now "3.4.47" and the keyboard started working in X but the video isn't switching modes properly.

I will try 3.10.15 and report back.

Originally Posted by stoat The bootlog file to which init-functions echoes messages is /run/var/bootlog. You created the /run mount point. The mountvirtfs script creates /run/var. Your /etc/fstab should have the tmpfs line. Your config should have CONFIG_TMPFS=y. No promises.

Yes to all I will check that a tempfs is being mounted at /run and report back

Well I got to the point of trying silly stuff and thought I'd copy all the start up files from my working system to the new one and hey presto! it worked so with a bit of work with diff I narrowed it down to the mountfs/mountvirtfs scripts and with few hacks I found that /run was being mounted over which was fubaring every thing but still couldn't work out why the boot scripts were not working for me but were for everyone else, so I checked my scripts that build the directory structure/links etc and checking against the lfs book I FINALLY FOUND IT!

I had created the file /etc/mtab instead of linking it to /proc/self/mounts this line from the book:

ln -sv /proc/self/mounts /etc/mtab

Chapter06 -> createfiles.html

Just goes to prove no matter how many times you do this there's always something that lies in wait to bite you in the derriere!

Thanks everyone for all the suggestions.

Glad to hear you got it fixed Keith.