/etc/init.d/rcS is missing? What gives?

I’m trying to understand the boot process on the Omnia. Som great OpenWRT docs exist, notably:

https://wiki.openwrt.org/doc/techref/process.boot

And following it this is a pretty deep mystery:

# cat /etc/inittab
::sysinit:/etc/init.d/rcS S boot
::shutdown:/etc/init.d/rcS K shutdown
ttyS0::askfirst:/bin/ash --login

# cat /etc/init.d/rcS
cat: can't open '/etc/init.d/rcS': No such file or directory
# 

The inescapable conclusion is that inittab is not being used. Or?

So if not, what is the boot process of TurrisOS (a form of OpenWRT)?

Bump. Surely someone has some input here?

Current OpenWRT/Lede including Turris OS boots using procd init. It handles this little bit differently. It doesn’t expects file but it requires rcS S boot as command for it self. Prepended path is just for backward compatibility. So no there is no file /etc/init.d/rcS but at some point there was and so procd reads only end of that argument (allowing this hybrid inittab).

I might be wrong as I invested only just about 10 minutes and just briefly looked on to the procd sources.

Thanks for the tip. Pointed me in a new direction. Alas the documentation is poor in this area:

https://wiki.openwrt.org/doc/techref/procd
https://wiki.openwrt.org/inbox/procd-init-scripts

and far from complete. Hmmmmm.

One is left assuming that procd implements internally the old rcS script with S and boot as args:

https://wiki.openwrt.org/doc/howto/notuci.config#etcinitdrcs

The doc as it stands (dated as it is given procd has changed the landscape):

https://wiki.openwrt.org/doc/techref/process.boot

suggests:

S10boot starts hotplug-script, mounts filesystesm, starts .., starts syslogd, …

meaning filesystems are mounted by S10boot.

The relevant code there is:

boot() {
	[ -f /proc/mounts ] || /sbin/mount_root
	[ -f /proc/jffs2_bbc ] && echo "S" > /proc/jffs2_bbc
	[ -f /proc/net/vlan/config ] && vconfig set_name_type DEV_PLUS_VID_NO_PAD

	mkdir -p /var/run
	mkdir -p /var/log
	mkdir -p /var/lock
	mkdir -p /var/state
	mkdir -p /tmp/.uci
	chmod 0700 /tmp/.uci
	mkdir -p /tmp/.jail
	touch /var/log/wtmp
	touch /var/log/lastlog
	touch /tmp/resolv.conf.auto
	ln -sf /tmp/resolv.conf.auto /tmp/resolv.conf
	grep -q debugfs /proc/filesystems && /bin/mount -o noatime -t debugfs debugfs /sys/kernel/debug
	[ "$FAILSAFE" = "true" ] && touch /tmp/.failsafe

	REG="`sed -n 's|.*cfg80211.freg=\([A-Z0][A-Z0]\).*|\1|p' /proc/cmdline`"
	if [ -f /lib/wifi/mac80211.sh ] && [ "$REG" ] &&\
	   [ "`sed -n 's|.*freg=||p' /etc/modules.d/00-wireless`" \!= "$REG" ]; then
		echo "cfg80211 freg=$REG" > /etc/modules.d/00-wireless
	else
		rm -f /etc/modules.d/00-wireless
	fi
	/sbin/kmodloader

	# allow wifi modules time to settle
	sleep 1
	[ -z "$REG" ] || iw reg set $REG

	/sbin/wifi detect > /tmp/wireless.tmp
	[ -s /tmp/wireless.tmp ] && {
		cat /tmp/wireless.tmp >> /etc/config/wireless
	}
	rm -f /tmp/wireless.tmp

	feed_urandom
	/bin/board_detect
	uci_apply_defaults
	
	# temporary hack until configd exists
	/sbin/reload_config

	# create /dev/root if it doesn't exist
	[ -e /dev/root -o -h /dev/root ] || {
		rootdev=$(awk 'BEGIN { RS=" "; FS="="; } $1 == "root" { print $2 }' < /proc/cmdline)
		[ -n "$rootdev" ] && ln -s "$rootdev" /dev/root
	}
}

And given /var exists as a link to /tmp which is a tmpfs, fourth line, the conclusion I’m tempted to draw is that /sbin/mount_root mounts the root partition, and the /tmp partition and links /var to it. Yet, if this is the source (just a guess, as I can’t find any better candidate easily):

Then that supposition is wrong. Puzzles. Is there a complete git repository of Turris OS? I can’t find mount_root here:

or here:

Hmmm. Why not I wonder?

Hmmm this is a convincing source for mount_root:

http://git.openwrt.org/?p=project/fstools.git;a=blob;f=mount_root.c;h=dffb0a6c48ee9d9581baba626359005c956f874d;hb=HEAD

Alas it seems only to mount the root filesystem and not the tmpfs or make the /var to /tmp link.

Leaving me thinking they may already be in place on the mounted root image.

Uh I am kind of lost in what you are trying to do. Are you looking to when var is linked to tmp? It’s done in base filesystem already. That link is shipped with initial root. See my script generating such root using updater-ng https://gitlab.labs.nic.cz/turris/openwrt/blob/test/scripts/updater-medkit.sh#L54. I am not sure if there is any script renewing this link if it’s removed, but as far as I knot there should be none.

Yep, that’s my goal. I want to relink /var to a persistent USB drive at the right time, before anything is written to it. Thanks very much for the insight. Given that it seems the clear hook to relinking it (or mounting a drive onto it) is in S10boot just after /sbin/mount_root is called. That should have presented the linked /var to /tmp with an empty /tmp I guess. At which point linking /var elsewhere would be cleanly happening before any logs are started?

I guess I can find out by experimenting but I’m trying to minimise that cost (restarting the router takes me off-line each time alas ;-).

I actually wonder too when fstab is processed in the scheme of things. If /var is mounted there does it happen before anything is written to it? And would it mount over the symbolic link (presume no, mount generally wants an empty directory).

Well the right time is pretty much as soon as possible. And yes you want to do it after the root is mounted. But you shouldn’t be editing /etc/init.d/boot file as that is not configuration. But there is no other sane way.

Well you could create service with START=11 that would mount new var to somewhere else and copied all files from /var (so from /tmp) to there and than just removed link, created directory and mounted it there. And on exit it should unmount it, remove directory and create symbolic link.

Fstab service has START=40 so way after the root mount.

No it wouldn’t. In such case I suspect that it would be then mounted on tmp too. But mount happily mounts over non-empty directory.

Sheesh, why on earth is it so hard to simply get /var onto persistent storage. I call that rather poor design personally.

Would be awesome if Turris OS bore that in mind and implemented a nice simple way to do it.

Agreed! On all counts.

Problem is that S10boot and S10system have both been happily creating things in /var and /tmp by then with all distinction as to which belonged where lost! So alas the only sane place I can see to do it in S10boot right after /sbin/mount_root is called. Hmmm …

I agree it’s not config, but perhaps to future proof it until such time as Turris OS maybe improves this and makes it easier I can script a patcher … It only has to check the line immediately after the line containing “/sbin/mount_root” to see if it’s already patched and if not insert the patch line. And the patch line can be as simple as “ln -s /mnt/mydrive/var /var” or “rm /var && mount … /var” - whatever really. Of course it may need a fallback position if the persistent store is not found (given it’s a USB drive and removable)

I would however recommend Turris OS building a config line into that spot. For example leaving /var as an empty dir on the static root image you store perhaps and then in S10boot yourselves reading a /etc/config file of your definition that tells the next line to either build the link to /tmp or link to some other dir or mount something onto it as defined in the config.

Worse still it says it’s deprecated:

# cat S40fstab 
#!/bin/sh /etc/rc.common
# (C) 2013 openwrt.org

START=40

start() {                            
	echo "this file has been obseleted. please call \"/sbin/block mount\" directly"
	/sbin/block mount
}

stop() {                            
	echo "this file has been obseleted. please call \"/sbin/block umount\" directly"
	/sbin/block umount
}

Although it still calls block mount even though it says it’s deprecated. Oddities.

Doubly bizarre I find that OpenWRT designers have chosen to mount the fstab devices after starting a pile of services like dsnmasq. I would have thought fstab mounts are prioritised.

Thanks by the way, immensely for your attention and kind advice thus far! It is very much appreciated. If this wasn’t my connection to the internet and I had it off-line I’d be far more ready to experiment in this zone knowing comfortably I can reset if I soft brick it ;-).