Busybox init for LFS

ReaperX7 · 11-27-2014, 03:25 AM

I don't see an issue with it.

Btw, the HAL distribution in runit-for-lfs is prepackaged with the patch to build the package against modern kernels, so if you need it Arthur, it's there.

stoat · 11-28-2014, 07:25 AM

Everything's working now with mdev...except the printer. And I think I see what the matter is for that. Anyway the tactic I used was to run tree -pug /dev in a system with eudev and redirect to a file. Repeat that in the mdev system and compare those files line by line looking for things to fix in /etc/mdev.conf. Next I want to get the printer going and then build a new system from scratch with Busybox init and mdev.

ReaperX7 · 11-29-2014, 01:23 AM

Research such as this could be highly valuable if udev ever goes sour.

Arthur, if you and Keith need to use the Runit-For-LFS repository for workspace and hosting project files, feel free to set up a directory for it.

Keith Hedger · 11-29-2014, 06:37 AM

Thanks for the offer! But I have dropbox and my own website for my apps, though if I do any LFS specific stuff I may take you up on it.

stoat · 11-29-2014, 08:15 PM

Quote:

Originally Posted by ReaperX7

Research such as this could be highly valuable if udev ever goes sour.

I never really intended to get involved with /dev population. But I started reading about Busybox mdev when you mentioned it earlier in this thread. It has turned out to be a very interesting project and actually sort of a natural next step after our alternate init experiments for LFS. It been tougher to deal with than init mostly because it's inherently more complex. But also because the existing documentation on the subject is scarcer than init stuff, and what is there is sort of aimed at people who already mostly know what they are doing. Anyway, these references have been very helpful to me so far...

The mdev primer
Gentoo wiki
mdev-like-a-boss

I am fairly confident that I eventually will be able to use Busybox mdev in a BLFS system and understand it enough to write a little summary here of how to do it.

stoat · 11-30-2014, 12:19 AM

YEEEHAW! Printer's working!

As with all the other mdev things so far...it was a permissions issue. I could see the printer appear in /dev/bus/usb as root:root. I knew it should be root:lp from looking at it the eudev system. And I could manually change the group to lp, and it would print. But to get it to be right when discovered or hotplugged required an mdev.conf rule that would be equivalent to the udev rule in the other system. Except the exact syntax wording of an mdev rule is not like a udev rule. I needed the $PRODUCT variable for the printer and figured that out by using printenv while hotplugging the printer...

Code:

DEVTYPE=usb_interface
SUBSYSTEM=usb
DEVPATH=/devices/pci0000:00/0000:00:1a.7/usb1/1-4/1-4:1.0
PATH=/sbin:/bin:/usr/sbin:/usr/bin
ACTION=add
MODALIAS=usb:v03F0pAC11d0100dc00dsc00dp00icFFiscCCip00in00
PWD=/dev
SHLVL=1
HOME=/
INTERFACE=255/204/0
MDEV=1-4:1.0
PRODUCT=3f0/ac11/100
TYPE=0/0/0
SEQNUM=1031
_=/usr/bin/printenv

Then I could use that to create the rule in /etc/mdev.conf that would change the group to lp...

Code:

# This is a sample mdev.conf
#

# Provide user, group, and mode information for devices.  If a regex matches
# the device name provided by sysfs, use the appropriate user:group and mode
# instead of the default 0:0 660.
#
# Syntax:
# [-]devicename_regex user:group mode [=path]|[>path]|[!] [@|$|*cmd args...]
# [-]$ENVVAR=regex    user:group mode [=path]|[>path]|[!] [@|$|*cmd args...]
# [-]@maj,min[-min2]  user:group mode [=path]|[>path]|[!] [@|$|*cmd args...]
#
# [-]: do not stop on this match, continue reading mdev.conf
# =: move, >: move and create a symlink
# !: do not create device node
# @|$|*: run@cmd if $ACTION=add,  $cmd if $ACTION=remove, *cmd in all cases

autofs			root:root	600
console			root:root	600
dri/card[0-9]   	root:video	660
dri/controlD64  	root:video	660
fb0			root:video	660
input/event[0-9]	root:input	660
input/mice		root:input	660
input/mouse[0-9]	root:input	660
kmem			root:kmem	660
loop[0-9]*		root:disk	660
loop-control		root:disk	660
mem			root:kmem	660
null			root:root	666
port			root:kmem	660
ptmx			root:tty	666
sd[a-z]			root:disk	660
sd[a-z][0-9]*		root:disk	660
sg[0,1]			root:disk	660
sg2			root:cdrom	660
snd/control.*		root:audio	660
snd/hw.*                root:audio	660
snd/pcm.*		root:audio	660
snd/timer		root:audio	660
sr[0-9]			root:cdrom	660
tty[0-9]*		root:tty	660
ttyS[0-9]*		root:dialout	660
urandom			root:root	666
usb/lp[0-9]*		root:lp		660
vcs			root:tty	660
vcs[0-9]*		root:tty	660
vcsa			root:tty	660
vcsa[0-9]*		root:tty	660
zero			root:root	666
SUBSYSTEM=usb;PRODUCT=3f0/ac11/100;.*	root:lp		660

I think I'm done. Now I need to repeat all of this, test everything, and try to write up some coherent notes. I will post those somewhere around here.

ReaperX7 · 11-30-2014, 03:56 PM

I sense a new hint on the way

stoat · 11-30-2014, 04:13 PM

Quote:

Originally Posted by ReaperX7

I sense a new hint on the way

Yes, I think so. I'm getting my scripts ready to build a new system with Busybox init and mdev. I think the base LFS system will build okay, but I'm looking for some trouble from some of the BLFS stuff if udev is not there. Anyway, once I get that sorted out and the new system throughly run in, I think this is worth telling about.

ReaperX7 · 11-30-2014, 07:15 PM

The only things that might fail are anything using gudev or evdev. You probably could get around that using hald and libhal, of which we have patches and build instructions, you may want to research hal-info also, and anything else drivewise could be loaded via autofs through the kernel's hotplug and automounter, as well as fstab. Xorg has the mouse, keyboard, and joystick input drivers also.

Getting around udev isn't hard, but it does require some creativity and knowledge of the older toolkits. Once you have that just look at the build instructions in ./configure --help if it has options for hal, and enable as necessary.

Slackware's older versions also used a hotplugd daemon and script. I'd check them out and see if they might be useful.

stoat · 12-01-2014, 09:51 AM

The LFS system built quietly as expected. It boots, looks, and runs perfectly also as expected. It has only Busybox init and mdev for system initialization and /dev population (no SysVinit, no Runit, no Eudev). Everything appears in /dev with the proper permissions, owner, group. Even the printer shows up correctly even though it can't print in LFS, obviously.

Today or overnight I will build the BLFS system. Trouble is expected. I have planned for it as best I can by configuring things like colord, gimp, libgusb, and so on to build without udev support. But I really don't think MesaLib is going to compile without Eudev/Udev. I'll just have to find that out. I'm not against installing Eudev just for libudev and libgudev. In fact, I don't have anything against Eudev. That's not what this is about. I greatly appreciate Eudev and am thankful to its developers. I'm just trying some things here. Learning stuff.

stoat · 12-02-2014, 02:17 PM

I was wrong worrying about MesaLib not compiling without udev. It did. And I made it all the way through Xorg. The startx command brings up the three xterm windows and the clock. Mouse, keyboard, and Ethernet work. There was some trouble along the way though, which is why I haven't finished the whole system yet. But it turned out to be easy stuff. Onward.

ReaperX7 · 12-03-2014, 06:01 AM

Anything in Xfce that may have required udev or at least libudev.so, should equally have a switchoff to use libhal.so as well. I think these will complain most of all:

Thunar (gudev listed as recommended)
thunar-volman (gudev is listed as required)
UPower (gudev listed as required)
xfce4-power-manager (udisks listed as optional)

I think you can substitute hal for those requiring gudev according to the FreeBSD websites, but you also have the option of one of xfce4's plugins, though not listed, xfce4-genmon-plugin can do automounting.

http://goodies.xfce.org/projects/pan...-genmon-plugin

stoat · 12-03-2014, 08:30 AM

Well, I did finish the BLFS system built with Busybox init and mdev for system initialization, /dev population, and hotplugging. I haven't had a chance to test drive it much yet, but it looks right and seems to work normally. Anyway, I don't think I will bother with a howto for the mdev stuff though.

The Busybox init experiment was easy because it drops right in and one only has to learn about its inittab. And Busybox init does at least offer some advantage of simplicity and leanness compared to SysVinit and Runit. But the mdev experiment reguired considerable adjustment to the build steps of several to many packages. Udev is required by a bunch of things in even a modest BLFS system. Most are easy to deal with through configure options; some are not and have to be omitted and replaced with something. Busybox mdev probably would drop right in if the udev libraries and headers existed in the system, but then there would be little to no advantage or point to using mdev in that scenario IMO.

In the end, I found Busybox init to be easy to install, learn, and use. It offers compactness and simplicity as the initialization apparatus of a BLFS system. I probably will go forward with it in my BLFS systems. The mdev experiment was an interesting puzzle to work on for a while, but it probably doesn't offer much in return for the work. Busybox is meant for tiny or embedded systems, but this was fun to try. I plan to continue on with Eudev for devices.

ReaperX7 · 12-03-2014, 02:57 PM

When the hint is completed I plan on expanding it to use mdev with hal on the desktop as an alternative to udev in the case of the unforseen happening but hopefully kdbus will never be included in the kernel.

stoat · 12-03-2014, 03:43 PM

Quote:

Originally Posted by ReaperX7

When the hint is completed...

For now I don't plan on doing any more work on mdev for BLFS or a hint. Even though the experiment worked, it entailed too much distortion and alteration of the base BLFS system for my liking.

But just FYI, the neatest thing I learned was how to handle a hotplugged device with mdev.conf. Something like a USB printer, for example, cannot be modified via mdev.conf in the same manner used for a fixed device that always is enumerated (or whatever the term would be) the same. An external device can, and probably will, pop up in /dev differently if it is turned off and back on or plugged back in to another port. So it has to be found by some unique attribute like a udev rule does. Turns out you can do that in mdev.conf but with slightly different syntax. Much mdev.conf documentation that I found doesn't get into that level of detail. Anyway, the printenv utility is very handy for determining unique environment variables for hotplugged devices that can be used to identify them in mdev.conf. I mentioned this somewhere above in an earlier post.

The rest of what I learned is just packages that needed configure options to disable udev or gudev support (or something related like drm support in Cairo, for example); or packages that I omitted entirely such as the evdev stuff and libgusb (which seems hopelessly fond of udev even though it has a --disable-udev config option); and packages that I had to add such as the "plain" xorg mouse and keyboard drivers. And so on. I can list those specifically and in some detail if you ever need that information.

We already knew that mdev was not going to load modules, but /etc/sysconfig/modules in LFS or /etc/runit.conf in our Runit project is ready to answer that problem. One only has to work out a few dependency issues which can be done in /etc/modprobe.d in LFS and /etc/runit.conf in the Runit project.

It was an interesting experiment. I learned some things. But I think I'm finished with it.

P.S.: The Busybox init experiment is a different matter. Now that I think proved to be very useful for BLFS, and I intend to continue using it in my BLFS systems.