Keith,

Did you try i2c HID interface? My usb mice come up on both i2c and usb.

Are the usb modules loading in the right order?

(see bottom) http://www.linuxfromscratch.org/lfs/...08/kernel.html

Not at my machine today but I will give it a try but I dont think its that as I use the same basic config for my kernel builds and
I dont have a problem with my normal system, also this problem is with the keyboard in the basic system, no gpm installed yet.

I know some motherboards auto-assign an IRQ to a P/S2 or USB keyboard at boot but can't reassign them if they lack or have Plug-n-Play disabled. Probably why in every book I've read they recommend shutting down a PC before switching a keyboard.

Sorted it out, for some reason I had been compiling the 3.13.3 kernel but using kmod 17 ( from the LFS svn list ) which I guess is not compatible, recompiled the 3.14.1 kernel and it started working, my bad!
Thanks for the help anyway guys.

No problem Keith. Might be something to document as well.

Well having sussed the problem with the kernel I decided to go to xorg and encountered another kernel problem, seems the 3.14 has reintroduced the problems with radeonfb there were a lot of posts about this with kernel 2.14, so I decided to see if LFS 7.5 with a 3.13 kernel would build OK with eudev, and so far everything seems OK, built using the hint and the udev-lfs-20140408, installed xorg and xrandr set my monitors properly, which I couldn't do with the 3.14 kernel, I am now installing a complete xfce desktop and I'll see how it goes.

As an extra to the hint rather than muck about with vim and altering the bootscripts by hand I used these commands:Had to set the exec bit for init-net-rules.sh for some reason.

And all booted fine with eudev on 7.5, keyboards mouse and network.

Okay. Just reporting that I rebuilt my entire working BLFS system from LFS with Eudev-1.6 installed. I'm still working with LFS SVN-140408 but omitted Systemd and that group of packages related to it. Everything installed quietly and is working normally. The two seds in the installation instructions that fix util.h and udev-test.pl are still needed with Eudev-1.6.

I plan to continue on my own this way. From here on, I will be viewing the LFS book less as an installation guide and more like a reference book like the BLFS book.

RE: the Eudev hint...

1. I recommend updating the hint to Eudev-1.6 and removing the wording to download and install man pages (since there will be no man pages tarball from Bruce now). Those man pages (udev.7, udevd.8, udevadm.8) were installed by Eudev-1.6 when I re-installed Eudev-1.6 in the BLFS system for gudev. Or, as an alternative, those three man page files could be uploaded somewhere and referenced for installation in the hint.

2. Like Keith Hedger, I too use seds to fix the initscripts because I have the whole build scripted anyway. I recommend using seds in the hint to fix the initscripts and also reducing the associated verbiage just to ease the burden on the eyes.

3. "Makefile.lfs" is not capitalized as it should be in the hint. But honestly, I use only two things from the udev-lfs-20140408 tarball (init-net-rules.sh and 55-lfs.rules), and I create those with "sudo tee" in scripts. All of the other things from udev-lfs-20140408 are installed by Eudev anyway. Those two files could be uploaded somewhere and referenced in the hint, or added as a text addendum at the bottom of the hint for manual installation.

Update: I have to revise the above to add that 81-cdrom.rules and 83-cdrom-symlinks.rules also are among the rules installed by udev-lfs-20140408 but not installed by Eudev-1.6. I did not install these two and so far don't notice anything bad about that.

4. That filesystem tree in the hint probably should be omitted. That came from post #34 in this thread. But I used slightly different config options when I created that, so it doesn't perfectly match the situation when the hint's config options are used. But mostly because getting rid of it reduces the verbiage burden on a reader. Anything like that which unnecessarily and inadvertently creates the illusion of complexity would be better off not being in the hint. The reality is that Eudev is easy. It would be a good thing if the hint visually reflected that reality.

5. Thank you, ReaperX7 for your efforts and leadership on this issue around here. I remain willing to help in any way that I know how to.

Thanks Stoat. Eudev 1.6 hint is up here.

Honestly, as long as it takes I'll be keeping this effort alive. I'm hoping to expand this out from a single hint into a conglomerate effort to bring in possibly Runit as a true alternative to SysVinit rather than systemd.

You are right about it now being a guide, but in reality it more or less has always been a guide on some level.

In truth we here at LQ maybe need to get together and get something on the level of our own project going for our sake and benefit.

Keith, I'll add you're suggestion in next round of updates, but thank you for the submitted sed commands. It'll be in the WIP for now for 0.0.7

If as stoat suggests you need somewhere to upload files for general use ( man pages etc ) I have plenty of spare capacity on both dropbox and google drive that I can make available, I also have a google site web site set up if you need a web page(s) to put up a permanent hint page or whatever, just let me know what you need.

Thanks Keith. For now Bruce has it hosted at LFS's website and features eudev as an alternative in the book. For the Tim being everything is okay. The man pages are a worry but at least they are able to be built at some point. I may see about generated man-pages eventually, but that might come down the line with another version. The primary goal is to maintain the working installation at the moment.

I'm also considering stepping up to take on Runit's hint as an alternative to SysV, but that project will be on hold while I sort out the aspect of an alternative Runit script set for BLFS, and other issues at hand with that. I'm prepping for an Runit build this weekend hopefully, so by then I'll be a bit busy. Should be fun.

Systemd is out. Eudev is back...

http://www.linuxfromscratch.org/lfs/view/development/

http://article.gmane.org/gmane.linux.lfs.devel/15311

Sanity starts to creep back in, today eudev tommorrow runit?

There's a good possibility, but for now, this effort has been a great service to LFS, and I continue to hope that when we get the Runit hint finalized for general distribution, Bruce can inspect it, and maybe we can have the first successor to SysV in LFS... maybe.

Yes, I know it is an old topic but I decided to build an LFS as close to Slackware-14.1 as possible.

Got a few hickups and swapped some stuff.
Udev-182 or 181 don't want to build, eudev-1.10 fails because of headers < 3.9.
So I used the old eudev-hint (eudev-1.6), updated to kmod-18 and got it to compile.
I am using the LFS-7.6 bootscripts.

Toolchain is glibc-2.17, linuxheaders-3.8, gcc-4.7.2 with mpc-0.8.2, mpfr-3.1.2, gmp-5.1.3 because gcc-4.8.X failed whatever I tried in chapter 5, binutils 2.23.1.

I followed the book (mixing 6.8 to 7.6) up to ch6 bzip2, then added tar-1.26, xz-5.0.5, libarchive-3.1.2 and pkgutils-5.35.6 from CRUX so I can make binaries to reuse.
Then followed the book again using versioning from Slackware-14.1.

Went for kbd-1.15.5, gdbm-1.10 and perl-5.20.2, did not include libpipeline and man-db but used man instead like Slackware does.

I finished ch6 and now I am upgrading my toolchain to binutils 2.23.2 and gcc-4.8.2, I wanted to use these versions in ch5 but they kept on failing there. I went through all lfs-books and tried every sed command and patch concerning glibc, binutils and gcc ...

Why I use this slackware versioning? This makes it easier to keep track of vulnerabilities.
Anyone tried a similar thing with udev-182?

How does BSD's devd compare to udev/eudev? Or, is the kernel <-> userland device handling to dissimilar to that of Linux?