Busybox init for LFS

stoat · 11-17-2014, 09:37 PM

The experiment to adapt Runit to LFS that was discussed often around here was a great success. I'm glad that I was allowed to participate in that. But I am still interested in other init schemes out there. Next for me was Busybox init. I found it to be simple in concept, small in size, and easy to install. Like most of Busybox's utilities, its init is a pared down init but still adequate for an LFS system. Anybody can look up Busybox, so there's no need to talk about the general features and uses of Busybox here.

Installation

I built Busybox to have only init support which produces an executable 17 KB in size. Installation consisted only of copying that busybox executable to /sbin and creating the four relevant symlinks to it: init, halt, reboot, poweroff. I did all of that manually instead of running "make install".

Configuration

Busybox init has a default internal inittab as a fallback when /etc/inittab does not exist. That obviously is not suitable for LFS. I created my own simple inittab from the example provided in the source tree. The Busybox inittab syntax has only a few differences from SysV's inittab (no runlevels meaning the runlevel field is ignored, the id field is for specifying ttys only, etc.).

Scripts

The inittab I created is configured to start the exact same initialization scripts that I use with Runit. I even used /1 and /3 almost "as is" (except for removing references to reboot, stopit, and sv). I didn't even bother to rename them. The /2 Runit script is of no use here, so I modified it to do something else (clear the console and print an ASCII graphic during shutdown). I also had to create some new initialization scripts for my daemons that had been started by run scripts in Runit, seven of them. I have the inittab start and stop those directly.

Service Supervision

I didn't think trying inittab's respawn for daemons was a good idea. So I'm using a custom script that is run as a recurring Fcron job for service supervision. That script detects if a service is not running and restarts it (if it was not intentionally stopped). It also can display the current status of the daemons. Sort of like Runit's runsv and sv.

Conclusion

This will not interest many people. Nevertheless, I like it for its simplicity. It's not hard to tell what it's doing at all times. The components are few in number and small in size, yet they still function well to start and shut down my LFS system. This method doesn't have runlevels (or the symlinks, the Ss, the Ks, and so on), but I don't need that stuff. The daemon supervision of Runit can be imitated with a bash script and Fcron. And finally, Busybox is well known and actively maintained. Anyway, after several days with it I can't find anything wrong with it.

P.S.: One of Busybox's included utilities is Runit. Ha.

ReaperX7 · 11-18-2014, 04:27 PM

Yep. Runit is quite used well by BusyBox, but I think it's more of the service supervisor portion only.

Arthur, on a side note, you should look into BusyBox's mdev as well.

Keith Hedger · 11-19-2014, 07:16 AM

Nice one stoat!
Just given it a whirl and it all works nicely, at least after correcting a few typo's etc ( at my end ).
I used to use busybox a LOT when I was learning Linux, as I like to fiddle and was forever hosing my system, and a full statically linked busybox can get get you out of all sorts of brown sticky stuff! I'd forgotten all about busybox.

I'm gonna dig out the custom start up scripts I was writing at the beginning of the runnit cycle and have my own init system, who needs systemd! ( begin flame war now

).

Keith Hedger · 11-19-2014, 10:21 AM

Could be my imagination but it seems to boot faster as well

ReaperX7 · 11-19-2014, 03:32 PM

BusyBox will flow faster through execution states as well. It's very optimized for embedded systems but you can use it on desktops very well. I've been tinkering with the mdev sections of CLFS to see if anything might be useful in B/LFS. BusyBox's init structure is more akin to a startup of sysvinit or bsdinit, but then switches over to Runit style for anything else. And yes, it's very underused in GNU/Linux. To be honest, it can serve as a damn good rescue system if you have it setup.

Keith Hedger · 11-22-2014, 11:45 AM

Been running this init system for a few days now and I must say I like it, I have kept and tweaked the three main boot scripts from runit, 1 start's the system stuff as normal, 2 starts my services gpm, ssh etc, and 3 does all the shutdown stuff, rather than have all the shutdown commands in the inittab I decided to use the 3 script I already had as it keeps the inittab clean plus I have the advantage of just adding/changing/removing symlinks to to do different stuff.

As a bonus I can now shutdown/restart from xfce using the menu/pnale items instead of having to go to a shell and shutdown manually which I had to do with runnit, never could get xfce to play nicely with runnit!

Also I finally managed to fix a long running problem with not being able to remount / as read only on shutdown ( as I was fiddling with the boot/shutdown process anyway ), which meant I couldn't auto run cleanfs as / was not unmounted properly seems it was a couple of problems again related to xfce that tried to shutdown before closing x which was leaving some log files open, so just had to wait for x to exit and manually kill syslogd.

ReaperX7 · 11-22-2014, 08:09 PM

Yeah, we got part of that problem solved with the new package, but there's still a few scripts that don't like to behave themselves.

I think I might have something on mdev, but I don't know yet. I salvaged this off cross-lfs.org through Archive.org:

Code:

cat > ${CLFS}/etc/mdev.conf<< "EOF"
# /etc/mdev/conf

# Devices:
# Syntax: %s %d:%d %s
# devices user:group mode

# null does already exist; therefore ownership has to be changed with command
null    root:root 0666  @chmod 666 $MDEV
zero    root:root 0666
grsec   root:root 0660
full    root:root 0666

random  root:root 0666
urandom root:root 0444
hwrandom root:root 0660

# console does already exist; therefore ownership has to be changed with command
#console        root:tty 0600   @chmod 600 $MDEV && mkdir -p vc && ln -sf ../$MDEV vc/0
console root:tty 0600 @mkdir -pm 755 fd && cd fd && for x in 0 1 2 3 ; do ln -sf /proc/self/fd/$x $x; done

fd0     root:floppy 0660
kmem    root:root 0640
mem     root:root 0640
port    root:root 0640
ptmx    root:tty 0666

# ram.*
ram([0-9]*)     root:disk 0660 >rd/%1
loop([0-9]+)    root:disk 0660 >loop/%1
sd[a-z].*       root:disk 0660 */lib/mdev/usbdisk_link
hd[a-z][0-9]*   root:disk 0660 */lib/mdev/ide_links
md[0-9]         root:disk 0660

tty             root:tty 0666
tty[0-9]        root:root 0600
tty[0-9][0-9]   root:tty 0660
ttyS[0-9]*      root:tty 0660
pty.*           root:tty 0660
vcs[0-9]*       root:tty 0660
vcsa[0-9]*      root:tty 0660

ttyLTM[0-9]     root:dialout 0660 @ln -sf $MDEV modem
ttySHSF[0-9]    root:dialout 0660 @ln -sf $MDEV modem
slamr           root:dialout 0660 @ln -sf $MDEV slamr0
slusb           root:dialout 0660 @ln -sf $MDEV slusb0
fuse            root:root  0666

# dri device
card[0-9]       root:video 0660 =dri/

# alsa sound devices and audio stuff
pcm.*           root:audio 0660 =snd/
control.*       root:audio 0660 =snd/
midi.*          root:audio 0660 =snd/
seq             root:audio 0660 =snd/
timer           root:audio 0660 =snd/

adsp            root:audio 0660 >sound/
audio           root:audio 0660 >sound/
dsp             root:audio 0660 >sound/
mixer           root:audio 0660 >sound/
sequencer.*     root:audio 0660 >sound/

# misc stuff
agpgart         root:root 0660  >misc/
psaux           root:root 0660  >misc/
rtc             root:root 0664  >misc/

# input stuff
event[0-9]+     root:root 0640 =input/
mice            root:root 0640 =input/
mouse[0-9]      root:root 0640 =input/
ts[0-9]         root:root 0600 =input/

# v4l stuff
vbi[0-9]        root:video 0660 >v4l/
video[0-9]      root:video 0660 >v4l/

# dvb stuff
dvb.*           root:video 0660 */lib/mdev/dvbdev

# load drivers for usb devices
usbdev[0-9].[0-9]       root:root 0660 */lib/mdev/usbdev
usbdev[0-9].[0-9]_.*    root:root 0660

# net devices
tun[0-9]*       root:root 0600 =net/
tap[0-9]*       root:root 0600 =net/

# zaptel devices
zap(.*)         root:dialout 0660 =zap/%1
dahdi!(.*)      root:dialout 0660 =dahdi/%1

# raid controllers
cciss!(.*)      root:disk 0660 =cciss/%1
ida!(.*)        root:disk 0660 =ida/%1
rd!(.*)         root:disk 0660 =rd/%1

sr[0-9]         root:cdrom 0660 @ln -sf $MDEV cdrom 

# hpilo
hpilo!(.*)      root:root 0660 =hpilo/%1

# xen stuff
xvd[a-z]        root:root 0660 */lib/mdev/xvd_links
EOF

That's the mdev configuration script, but as far as how to use it with the bootscripts, I'm still working on that one. The CLFS bootscripts unfortunately were lost when the website went down.

ReaperX7 · 11-22-2014, 08:28 PM

Little bit of a break through:

I managed to scavenge a copy of the clfs-embedded-bootscripts from an FTP site and found the startup and shutdown scripts.

The mdev configuration looks to use this in the bootscript:

Code:

/bin/echo "/sbin/mdev" > /proc/sys/kernel/hotplug
/sbin/mdev -s

Seems very simple.

Keith Hedger · 11-23-2014, 05:53 AM

Unless mdev has had some major revamping since the last time I tried it, it is not really suitable f0r a full desktop system it was designed with embedded systems in mind with a small number of permantly attached devices, which is not the same as a desktop environment, that's not to say it can't be done but the extra fiddling with conf scripts is proably going to be beyond most normal users, and in my experience it's not worth the amount of time spent configuring it compared to eudev which is designed to be used with a full desktop.

brebs · 11-23-2014, 06:35 AM

I use busybox init - here it is

Getting a reliable unmount was tricky, but it's stable now.

Edit: I use it with eudev.

Keith Hedger · 11-23-2014, 07:38 AM

I actually use a wrapper script for shutdown instead of an alias like so:

Code:

#!/bin/sh

if [ "$1" = "-r" ];then
	/sbin/reboot
fi

if [ "$1" = "-h" ];then
	/sbin/poweroff
fi

I ignore the parameters passed to shutdown as I have never had to do a scheduled shutdown/reboot.
A wrapper script is more versatile than using an alias I find.

ReaperX7 · 11-23-2014, 08:35 PM

Gentoo got mdev working on their end and for desktop systems. I'm not sure how well it works as it tends to behave more akin to hotplug and devfs rather than udev, but it does sport some udev capabilities.

http://wiki.gentoo.org/wiki/Mdev

They also recommend a module loader as such:

Code:

cat > /sbin/hotplug << "EOF"
#!/bin/sh
test -n "$MODALIAS" && modprobe "$MODALIAS";
exec /sbin/mdev
EOF

And maybe even use /etc/sysconfig/modules to load modules as well.

They also gave some pros and cons [edited for LFS]:

mdev unlike udev does not support auto-modules loading thus you will need to use /etc/sysconfig/modules and put there all the modules like you used to load (nvidia, wl etc.). Also, /etc/sysconfig/modules have own _args variables as it does not support /etc/modprobe.d. You may need to move your configuration there.
mdev -s does not create /dev/mapper nodes. You may need to manually create them or use 'dmsetup mknodes' from lvm2 (good idea is to add it after mdev -s in init script).
you should use mouse and kbd drivers for xorg inputs. evdev need udev to be built. Mousedrv (mouse) may conflict with synaptics driver, when both are loaded.
Kernel configuration option CONFIG_INPUT_EVDEV not only provides the keyboard and mouse as input device events, it will provide lid and buttons to acpid as well.

stoat · 11-26-2014, 09:39 AM

Quote:

Originally Posted by ReaperX7

http://wiki.gentoo.org/wiki/Mdev

They also recommend a module loader as such:

Code:

cat > /sbin/hotplug << "EOF"
#!/bin/sh
test -n "$MODALIAS" && modprobe "$MODALIAS";
exec /sbin/mdev
EOF

And maybe even use /etc/sysconfig/modules to load modules as well.

I have been working with mdev for several days now. It's been hard sledding so far. A bit like our initial work with Runit was. Anyway, you're right about having to provide for loading kernel modules when using mdev. In a traditional LFS system, the /etc/sysconfig/modules file should do the job. I'm using a clone of our Runit LFS system sans eudev to test all this mdev stuff, and the MODULES array in /etc/runit.conf loads all of the system's modules very well with mdev. I had to figure out some order-of-loading issues and some dependency issues, but it finally loads everything the same as the Runit system does with eudev.

Another important thing is providing for the keyboard and mouse in X. The evdev driver was not going to work without udev. All that was needed was to compile and install xf86-input-keyboard and xf86-input-mouse plus create some config files in /etc/X11/xorg.conf.d for those. But then Xterm and Eterm both don't work. Xterm just won't start, and Eterm starts but closes at the first attempt to type in it. At the moment I have to switch to a tty terminal to run commands. I will eventually get to the bottom of that, but if anybody already knows what the matter is then say it now please.

Ethernet worked fine from the moment the driver modules thing was sorted out.

Next and maybe last is figuring out how to get my USB HP Deskjet printer to work. It's probably obvious, but it's elusive to me at the moment. When that is done, I think everything will be working normally with Busybox init and mdev in charge.

So why would anyone want to do this? Well, for the adventure firstly. And to look deeper into a Linux system to understand it better for another maybe. But for me, I just wanted to know another way to do this business in case Eudev gives up and goes away leaving me with nothing but that other thing that the thundering herd charged off after.

ReaperX7 · 11-26-2014, 01:10 PM

Just a flying thought, but you might actually need to build HAL for some of the X stuff. I think the updated instructions we have should work.

stoat · 11-26-2014, 09:03 PM

Quote:

Originally Posted by ReaperX7

Just a flying thought, but you might actually need to build HAL for some of the X stuff. I think the updated instructions we have should work.

The xterm issue turned out to be permission related. Root can start xterm and Eterm. For now the simplest thing that restores it to the situation ante-mdev is adding my user to the tty group. Is there anything particularly wrong with that?