void-linux / void-runit Goto Github PK

I use the dispatcher.d functionality from NetworkManager for mounting my NAS when I connect to the correct wifi via UUID. When the NetworkManager stops, the pre-down function from the dispatcher gets triggered and unmounts the NAS safely before disconnecting from the wifi.

This works as expected when I use sv "down, stop or force-stop" NetworkManager on the running system.

When the NM service stops on runit-shutdown however, the pre-down seems to not get triggered.

The shutdown process seems to try to unmount the mountpoint of the NAS but can't do it safely because it can no longer reach the NAS it the network. The shutdown process takes ~5 minutes in this situation because the unmount gives up after sometime.

To check this I let rc.shutdown output STDOUT from mount and I could see the NAS mountpoint was still there after the services stopped.

We talked alot about this in the irc channel but couldn't figure out why this happens.

I hope we can find a solution this way.

If you need more information just ask. 👍

Regards,
Ben

I have dracut configured to mount all my filesystems, so I would like to disable the 03-filesystems.sh core service. Could something like:

[ -e /etc/stage-1-no-mount ] && exit

be added to the start of the script?

Hi! From what I understood after some digging around, kmod's static-nodes command specifically writes it's output exactly to /dev/stdout file, which at the time of this script's execution does not yet exist on raspberry pi and instead a regular file is created in it's place with kmod's output inside.

This leads to modules not being loaded and /dev/stdout symlink not being created, since there's already this file in it's place.

I guess this might as well be a kmod issue, but I don't know how to report it there or fix it, since I'm only dabbling in understanding the boot process.

I believe this comment in ctrlaltdel

# We check for this file in stage3 to halt or reboot
touch /run/runit/reboot

is wrong, because runit checks for it continuously during stage 2 (which is when it's running /etc/runit/2, which is what runs runsvdir), and then reboots the system if it is found. I feel like this comment implies that the file is only used for determining whether the system will reboot or shutdown, when runit gets to stage 3, but instead it just reboots the whole system.

I delete the directory called /var/service , but void Linux can't boot anymore,
how can recreate this folder again, because I try this why but not working

• booting from grub with linux /boot/vmlinuz-5.. root=.... rw loglevel=4 init=/bin/bash
• then

$ mkdir /var/service
$ ln -s /etc/agetty-tty1 /var/service

I haven't tried to produce this crash, but I did notice that there is a potential segfault in these lines of code:

if ((p = strrchr(pwd, '/')) && strncmp(p+1, "log", 3) == 0 &&
(*p = '\0', (p = strrchr(pwd, '/'))) && (*(p+1) != '\0')) {

If someone decided to exec vlogger as ./run from within the directory '/log' then the second call to strrchr above should pass an empty string as the first argument and so this second invocation of strrchr should return a null pointer and then the code (*(p+1) != '\0')) at the end would be expected to segfault.

Hypothetically speaking, a more lightweight, BSD-compatibile SystemD fork is in the works: https://github.com/InitWare/InitWare

What does the Void Linux community at large think about it's potential for fitting it into the Void's BSD inspired philosophy at a later date, over the current runit?

Not sure if it is a bug or a feature. Either way, what's the correct way to accomplish in Void?

This issue is the same as:
openzfs/zfs#8750

Hi,

If I have mounted network shares (nfs, nfs4, cifs), these are unable to be unmounted / re-mounted as read during shutdown / restart, consequently the shutdown process hangs and I need to do a forced shutdown. The reason is that in /etc/runit/3 the network services are taken offline before before the drives are unmounted / re-mounted as read occurs.

I've created my own /etc/rc.pre-shutdown script (below) that is called by /etc/runit/3 before the services are closed that unmounts / re-mounts as read the network shares. This works.

Apologies if I've missed an obvious option / setting that renders my "fix" not needed, I'm just an enthusiastic Linux user, as opposed to developer.

Hope this is useful for someone.

Rob

echo "   trying to unmount network shares..."

umount -a -r -t nfs,nfs4,cifs

if grep -qs -e 'nfs ' -e 'nfs4 ' -e 'cifs ' /proc/mounts; then
   echo
   echo "...... failed to unmount network some network shares ......"
   rem_shares=$(grep -e 'nfs ' -e 'nfs4 ' -e 'cifs ' /proc/mounts)
   if echo $rem_shares | grep -qs 'rw,'; then
         echo "failed to mount read only as well"
         echo "will attempt forced, lazy unmount"
         echo "if this hangs then will need to hard shutdown..."
         umount -a -f -l -t nfs,nfs4,cifs
   elif echo $rem_shares | grep -qs 'ro,'; then
         echo "shares were mounted read only instead."
         echo "hopefully this is ok. If hangs...hard shutdown required"
   else
         echo "I should not be here..."
   fi
   echo
fi

Hi,

03-filesystems.sh contains "vgchange --sysinit -ay". -ay is only supposed to be used by the user when they want to activate all logical volumes.

Init scripts should use "-a ay", which respects the auto_activation_volume_list option in lvm.conf, and only activate LVs that the user has whitelisted as auto-activated.

This is mentioned in the vgchange man page for the -a switch:

ay specifies autoactivation, in which case an
LV is activated only if it matches an item in lvm.conf
activation/auto_activation_volume_list.  If the list is not set,
all LVs are considered to match, and if if the list is set but
empty, no LVs match.  Autoactivation should be used during
system boot to make it possible to select which LVs should be
automatically activated by the system.

Thanks!

Even with default,ro in /etc/fstab for root fs (/) the filesystem is always mounted as read-write. Relevant part of /etc/runit/core-services/03-filesystems.sh:

msg "Mounting rootfs read-write..."
mount -o remount,rw / || emergency_shell

Hi, after I upgraded my void linux machine, i couldn't boot with the latest kernel 5.4.50. Previous kernel 4.19 boots fine.

The system stuck at 'check Ramdisk...' and hangs. I have nvidia Graphics card.

any advice?

After running ZZZ, I got:

Zzzz... /sbin/ZZZ: line 54: echo: write error: Invalid argument

It successfully runs. However, it sounds like there is a bug somewhere.

That's it, could Void's Runit scripts get support for a more POSIX set of programs such as Busybox's? I am on a journey to make an embedded friendly spin of Void, everything works(well, mostly), yet the only part that fails without the coreutils is Runit and /usr/bin/modules-load. Thanks!

As I mentioned here void-linux/void-packages#20452, no package has man pages for how to set up the crypttab file. @daniel-eys has pointed me in this direction, so I can try to write one based on the crypt.awk script, trying to follow the style of the crypttab man pages offered by both systemd and DragonFlyBSD.

If you have any suggestions for this, please let me know.

Currently the cgroup hierarchy is only mounted if not running in a virtualized environment (as added via #58):

However even inside a container it is sometimes preferable to have the guest system initialize cgroups if available¹.
The current situation allows CGROUP_MODE to be set to none (or any other string than hybrid, legacy, or unified) to disable such behavior, but no option to enforce the behavior even in a virtualized environment.
Unless one starts messing with files which are prone to be overwritten on every update, or one duplicates the code which incurs technical debt.

I am not involved with the topic enough to gauge the effects of enabling this in containers by default however, and I expect the solution to be more involved than to remove that if, hence the issue rather than a PR.

¹: In my case lxc.mount.auto = cgroup:mixed:force is not available, so the only reasonable way is for this to be handled by the code there.

This only detects LXC containers, yet other containers will specify container=foo. The check should change to test if the container environment variable is zero length or not.

It seems we are mounting the zfs pool as read-only first, then zfs share -a will attempt to place a lock /etc/exports.d/zfs.exports.lock which causes the issue in the title. I wonder if we should mount the pool as read-write earlier to avoid the error?

Also a separate question, how do I check the log for the runit boot process? I literally took a screenshot during booting to create this issue. I've setup socklog according to the docs, but I couldn't find the error: failed to lock /etc/exports.d/zfs.exports.lock: Read-only file system anywhere in the /var/log.

When I run zzz in DWL my system shows DWL after being resumed but cannot be used and is frozen; I cannot switch TTY, move my mouse or use any keybindings. It is possible this is a DWL issue as it handles all of these things and ZZZ seems to work in a tty although if I run zzz in a TTY and then launch dwl my system also freezes.

I have this in /etc/fstab
proc /proc proc nosuid,nodev,noexec,hidepid=2 0 0

after rebooting I still see everything with top though.
when I do
mount -o remount /proc
top shows me only what I have going on.

in #voidlinux I was given this link, so I report.

Workaround:
putting the "mount -o remount /proc" line in /etc/rc.local

thanks for your time.

I already owe a man page here (#39), but I'd like to add a few more to the pile. As suggested in #58 (comment), we could have a rc.conf(5), maybe together with rc.local(5) and rc.shutdown(5). These would be mostly transferred over from void-docs, from where we would remove explanations and simply add links to the proper man pages.

The advantage here is that information can be found with just man(1) instead of requiring knowledge of void-docs(1) (or, more realistically, opening a browser). One disadvantage I can think of is that this wouldn't take advantage of eventual translation efforts in void-docs. Leaving the information duplicated wouldn't be terrible either, and we'd still get man pages out of it, which is nice.

In a setup where /boot is encrypted and placed onto completely separate encrypted disk, and keyfiles are used in crypttab, runit (03-filesystems.sh) tries to check the /boot partition for a keyfile but fails due to it not being mounted by dracut(initramfs) or anything else.

The cryptdevice of /boot partition is already opened in previous booting steps (I assume by grub), it's just isn't mounted yet, at the very end of 03-filesystems it reads fstab and mounts everything properly.

The end result is that I can see warnings during boot about "Failed to open key file.", but otherwise boot ends and mounts everything just fine.

I've added a couple of lsblk checks before "Activating encrypted devices" and after it, to show the point, and also show my configuration in this video:
https://fastupload.co/1097693

Greetings!

I've been building a Void-ish system using a read-only squashfs root filesystem. Unfortunately, the script /etc/core-services/03-filesystems.sh, at line 67, drops to an emergency shell if root cannot be mounted read-write.

This makes sense for the majority of desktop and server use cases, but for some embedded devices and some desktops/servers, having a read-only rootfs makes sense.

Proposal: have core-services/03-filesystems.sh check if /proc/cmdline contains ro, or readonly, or ro=true, or some such string, to support a wider range of use cases.

My temporary solution is to just remove the || emergency_shell from line 67, but this is undesirable because I wish to stay as close to upstream as possible

I found a bug in the config file of the service named wpa_supplicant, when using some shell, like sh or zsh instead of bash for the root user

$ cat /etc/passwd

root:x:0:0:root:/root:/bin/zsh

this error is in this file : /etc/sv/wpa_supplicant/auto

• Because in bash, we can find in two directories like that

for f in /etc/wpa_supplicant/wpa_supplicant-*.conf /etc/wpa_supplicant-*.conf ; 
do 
   #....
done

but we can't do it in another shell

• my PR is changing this for-loop or adding bash shebang,

***but can't find Void-Linux source in GitHub*** or where is this file : /etc/sv/wpa_supplicant/auto` send a pull request to fix it

System

• xuname: Void 5.12.19_1 x86_64 AuthenticAMD notuptodate rrrrmmnFFFF
• package: cryptsetup-2.3.6_1

Expected behavior

When booting cryptsetup should use a keyfile starting at a specified offset of an USB stick.

Actual behavior

On boot cryptsetup fails complaining about option keyfile-offset (see picture). It seems as though the option gets preceded with only one dash. Position of the option in the option string in /etc/crypttab does not matter so it is specific to this option.

Steps to reproduce the behavior

• Encrypt partition using a keyfile
• Use USB stick containing the key at an offset
• Reboot

#/etc/crypttab
home           UUID=XXX /dev/disk/by-id/usb-USB_Flash_Disk_YYY-0:0 luks,keyfile-offset=512,keyfile-size=512,tries=3

From #musl:

16:53 <arnd> khem, ericonr: they sort-of have a point that the situation is broken: the kernel's behavior is absurdly broken but kept for backwards compatibility with a hack that dates back to the early 1990s.  Whichever program calls settimeofday the first  time after boot decides whether the kernel uses normal UTC behavior or MS-DOS compatible RTC-is-localtime.
16:54 <arnd> If /sbin/init doesn't do this but something else calls settimeofday() with a non-zero TZ offset later, it all goes wrong
16:55 <arnd> So if settimeofday() is either not available (on rv32) or disabled and returns -ENOSYS, the init task should just continue
16:57 <ericonr> arnd: I assume the kernel is hardcoded to use UTC on such on such archs?
16:58 <arnd> yes, the logic to do the timewarp is still there, but there are no other callers
16:59 <ericonr> I guess you still need to call it where available, otherwise some other application can force a sudden time warp >.<
16:59 <arnd> I don't think there are any distros that actually try to use the timewarp code, though setting the kernel timezone is still done sometimes
17:00 <arnd> any sane /sbin/init implementation does the same as the busybox variant

From 03-console-setup.sh:

if [ -n "$HARDWARECLOCK" ]; then
    msg "Setting up RTC to '${HARDWARECLOCK}'..."
    TZ=$TIMEZONE hwclock --systz \
        ${HARDWARECLOCK:+--$(echo $HARDWARECLOCK |tr A-Z a-z) --noadjfile} || emergency_shell
fi

This means that

• we only try to set the kernel timezone when HARDWARECLOCK is set, which means a badly behaved application can force a time warp by calling settimeofday(0, some_tz) as root.
• our init of choice, runit, never calls settimeofday(), which means for safety reasons we should always try to set the kernel timezone, and defaulting to UTC is entirely reasonable.
• On some archs (and maybe at some point even some kernels?), this command can error out, so || emergency_shell is also wrong there.

hi, I couldn't figure out how to start a service like 'cups' in void linux. I've looked up documentation and tried the following:
sh-5.0# sv status cupsd
fail: cupsd: unable to change to service directory: file does not exist

it seems that 'cups' is in /etc/sv/cupsd, tried the following as well.
[erdos@quantum ~]$ sudo sv up /etc/sv/cupsd
warning: /etc/sv/cupsd: unable to open supervise/ok: file does not exist

so how to start a service?

The vlogger (8) man page) says:

-p pri
The pri can be facility.level or just facility.
...
The default is user.notice.

And later:

-t tag

Defines the openlog 3 ident which is used as prefix for each log message or passed as first argument to /etc/vlogger.

The default is the LOGNAME environment variable.

The statements about the default facility and tag are incorrect. In particular, the default tag does not in any way depend on the LOGNAME environment variable.

The actual defaults are:

Facility: "notice" unless vlogger detects that it was exec'd as "./run" from within the directory "runsvdir/service/log" where "runsvdir" is an arbitrary path and "service" an arbitrary directory name -- in that case the default facility is "daemon".

tag: if vlogger detects that it was exec'd as "./run" from within the directory "runsvdir/service/log" where "runsvdir" is an arbitrary path and "service" an arbitrary directory name then the default tag is the name of the service directory. Otherwise, if vlogger is calling /etc/vlogger then the default tag is an empty string, while if vlogger is logging to a socket then the default tag is the current username as reported by getlogin().

Tried diffrerent options in /etc/fstab with no success.
Remote directory doesn't mount on boot while mount -a works just fine.
I suppose it's due to parallel nature of runit.
Of course I can add something like sleep 2 ; mount -a to /etc/rc.local as an ugly workaround but I wander if there's more graceful way to solve this issue.

From this discussion: rickysarraf/laptop-mode-tools#137

It seems that it would be better to allow udev settle in background while system is booting and use something like udevadm settle -t 0 || exit for services that absolutely must start after all devices are settled.

The urandom seeding/storage should be omitted when in containers. This will align behavior with systemd.

https://github.com/systemd/systemd/blob/master/units/systemd-random-seed.service.in#L18

is this the normal behavior?

$ lsblk 
NAME                 MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
nvme0n1              259:0    0 476.9G  0 disk  
├─nvme0n1p1          259:1    0   512M  0 part  /boot
└─nvme0n1p2          259:2    0 476.4G  0 part  
  └─cryptroot        254:0    0 476.4G  0 crypt 
    ├─cryptroot-root 254:1    0    15G  0 lvm   /
    └─cryptroot-home 254:2    0 461.4G  0 lvm   /home
$ doas fsck /dev/nvme0n1p1 
fsck from util-linux 2.38.1
fsck.fat 4.2 (2021-01-31)
There are differences between boot sector and its backup.
This is mostly harmless. Differences: (offset:original/backup)
  65:01/00
1) Copy original to backup
2) Copy backup to original
3) No action
[123?q]? 1
Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
[12?q]? 1

*** Filesystem was changed ***
The changes have not yet been written, you can still choose to leave the
filesystem unmodified:
1) Write changes
2) Leave filesystem unchanged
[12?q]? 1
/dev/nvme0n1p1: 3 files, 6254/130812 clusters

reboot the laptop

$ doas fsck /dev/nvme0n1p1 
fsck from util-linux 2.38.1
fsck.fat 4.2 (2021-01-31)
Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.
1) Remove dirty bit
2) No action
[12?q]? 1

*** Filesystem was changed ***
The changes have not yet been written, you can still choose to leave the
filesystem unmodified:
1) Write changes
2) Leave filesystem unchanged
[12?q]? 1
/dev/nvme0n1p1: 3 files, 6254/130812 clusters

My daily user is not able to run zzz.

Here is the code that prompted the error, which was that permission denied.

https://github.com/void-linux/void-runit/blob/master/zzz#L39

Could the code add a suggestion how one may grant such a permission to a user that is not root?

In the man page, the error was nicely described too.

sleep permission denied
             You lack sufficent privilege to write to /sys/power/state.

I wonder if the man page could be revised also to include a suggestion on how to grant privilege to write to /sys/power/state?

We honor rc.local and rc.shutdown, but these scripts are not accessible for packages to hook into. I propose adding rc.local.d and a corresponding shutdown directory to accommodate these use cases. Comments?

It seems kernel 5.3 changed the default for s2ram to be s2idle, which drains the battery.

To recover the past behaviour, it seems suspend should do

printf deep > /sys/power/mem_sleep

right before it does

printf mem >/sys/power/state

See: https://www.reddit.com/r/voidlinux/comments/drm4nj/severe_battery_drain_in_sleep/
and
https://www.kernel.org/doc/html/v5.3/admin-guide/pm/sleep-states.html#basic-sysfs-interfaces-for-system-suspend-and-hibernation

The current runit script does not seem to take into account encrypted ZFS datasets.

I added a simple zfs load-key -a to the script between the zpool import and zfs mount blocks, but my keyfiles are not loaded. I believe this probably because my keyfile is located outside the / file system.

So I moved the entire block containing zfs code to the end of the script, after all partitions are mounted. However I'm sure this will break systems which rely on ZFS datasets to be mounted before mounting the fstab entries. So maybe the zfs block should be run twice? The first block remains in its original place while the second block serves as a sort of catch-all for the secondary mount points that rely on a mounted partitions.

This also brings me to my second problem: my zfs mounts do not use the auto-sharing properties, so zfs share, as I understand it, does not share my mount points during boot. However I do have the shares configured in /etc/exports and I expect nfs server to share them properly. However the shares are inaccessible unless I restart nfs-server manually after ssh'ing into the server. I do have port 2049 opened in nftables.conf, and my client machine uses the mount option nfs4.

Trying to start services like dbus, bluetooth in void linux arm rootfs, but its missing /run/runit/ folder with all content. So it cant start because

warning: /etc/sv/dbus: unable to open supervise/ok: file does not exist

Its not booted, im running its in chroot because of my needs

The current version of 03-filesystems.sh only attempts to mount ZFS if /etc/zfs/zpool.cache exists. This behavior isn't explained in the commit message that added the ZFS block, and it has never been changed. I have recently had issues with it, because zfsbootmenu set the rootfs for me, but my /home dataset wasn't being mounted. Even the zfsbootmenu guide for ZFS root says that the cache speeds up stuff, not that it is essential if you split up certain volumes (I will add that information there too).

So what we have to determine is the best way for 03-filesystems.sh to find out whether it should attempt to mount zfs volumes or not.

Pinging @ahesford @zdykstra @Vaelatern

I recently stumbled upon the fact that runit does not write a BOOT_TIME time record into utmp after booting the system. Libvirt relies on such an entry being present to determine the host boot time since version 5.7.0 and fails to start VMs otherwise.

Since runit does not provide the functionality itself, perhaps this could be implemented as part of the boot scripts? Instead of just creating the file as an empty file, one could execute a script or binary to create an initial record after booting the system.

Currently it fails and re-execs. However, if this is intended to be
a drop-in replacement for logger, we have existing services that call
logger without a tag. E.G., dcron/log.

/etc/runit/{1,2,3} set PATH as /usr/bin:/usr/sbin. However, in a fresh installed voidlinux on aarch64 machines via rootfs, many binaries locates at /sbin including mount, and this results failing to boot. The complete value should be:

/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin

In particular I was bitten by

[ -x /bin/btrfs ] && btrfs device scan || emergency_shell

Since I don't use it I had blacklisted the btrfs module, causing btrfs device scan to fail.

It's very unfortunate when emergency_shell is triggered without a real cause, since my headless maching gets stuck until I can go to school to fix it (i.e. type "exit" at the shell).

I should point out that this particular server I switched from debian to void when I got fed up with systemd-mount doing exactly that thing... (blocking the boot).

01-static-devnodes.sh should use kmod static-nodes -f devname | cut -d' ' -f1 instead of parsing the default human-optimized output.