I've started testing out a port for the Devuan release of debootstrap. The port files will probably need some work before I can publish a patch - I'd like to patch it on as a flavor for the existing debootstrap port (sysutils/debootstrap). It's hanging up during testing, however.
Devuan does not use systemd. It seems that they're using a form of eudev for the Linux udev support.
The devuan bootstrap for the devuan chimaera release continues up to the point of installing the devuan
That is with the partial Devuan installation. The installation gets stuck at the
I'm seeing the same behavior when running 'mkfifo -m600 /any/file' under chroot to a linuxulator + debootstrap filesystem with Debian 11 installed.
The Debian mkfifo command does not return. Trying to run gdb on mkfifo under chroot for the Debian installation also fails - the console become unresponsive.
Running the same mkfifo without '-m600', it succeds however - albeit then creating a file relative to the emul_path from sysctl at the time of the call
Here it was when run outside of the chroot environment and without -m600
Running the Debian or Devuan mkfifo with -m600 and outside of a chroot environment, it fails to return then too.
Short of creating any one or more new Debian packages for this environment, I'm not certain if it would be possible to patch the Devuan
This is only with with the mkfifo from Debian (Debian 11) or from the Devuan chimaera relase. It's not happening with the mkfifo from the linux-c7 ports, where 'mkfifo -m600 /tmp/lxfifo' returns successfully.
Build info for my local build:
An excerpt of running the Debian mkfifo under truss, to the point where it just stops:
The tail of the output from ktrace/kdump, running the Debian mkfifo and then interrupting with
At least the c7 ports are not affected.
Probably none of the following remarks would affect the matter of the mkfifo call not returning when provided with a file permissions mask. Although it's showing up with the mkfifo from Debian, but it doesn't appear to be used in the default debootstrap installation for Debian 11. Of course, there are other Linux distributions.
I suppose it's time to test out some tooling for keeping a series of ports for CentOS 8-stream updated. They've stopped making single releases now. The CentOS 8-stream series might be a lot like Debian 'sid', as a distribution. I'm certain that this could be difficult to track for RPM dependencies, source files, and then the mk-files for porting on FreeBSD. Maybe it could be possible to create some tooling that would simplify that process. I'm not certain if I'm anywhere close to arriving to such tooling, though I've started working on some Ruby scripting for reading the CentOS RPM repository information.
Alternately, noticing the selinux code referred in that kdump output, perhaps a build of a Linux distribution without systemd and without selinux could be of some use for this support under FreeBSD, at least assuming that it would be used with any upstream code that doesn't have any linkage onto the systemd libraries.
The debootstrap code seems to support a 'fakechroot' variant, albeit developed for Debian tooling of some kind. This release variant does not pull in the
Devuan does not use systemd. It seems that they're using a form of eudev for the Linux udev support.
The devuan bootstrap for the devuan chimaera release continues up to the point of installing the devuan
sysvinit-core pkg. At that point, it seems that it gets stalled running mkfifo -m 600 /run/initctl apparently under a chroot environment for the bootstrapped root directory. So, this would be the mkfifo from the Devuan release.That is with the partial Devuan installation. The installation gets stuck at the
sysvinit-core postinst script, never returning from that mkfifo call.I'm seeing the same behavior when running 'mkfifo -m600 /any/file' under chroot to a linuxulator + debootstrap filesystem with Debian 11 installed.
Code:
$ sudo chroot /opt/linux/debian-11 bash
# mkfifo -m600 /run/nop.fifo
^CThe Debian mkfifo command does not return. Trying to run gdb on mkfifo under chroot for the Debian installation also fails - the console become unresponsive.
Code:
$ sudo chroot /opt/linux/debian-11 bash
# gdb -- mkfifo -m600 /run/nop.fifo
Excess command line arguments ignored. (/run/nop.fifo)
GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<https://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from mkfifo...
(No debugging symbols found in mkfifo)
/-m600: No such file or directory.
(gdb) run
Starting program: /usr/bin/mkfifo
warning: linux_test_for_tracefork: unexpected result from waitpid (30744, status 0x57f)
^C^C^C^C^C^C^C^C^C^C^C^C^CRunning the same mkfifo without '-m600', it succeds however - albeit then creating a file relative to the emul_path from sysctl at the time of the call
Here it was when run outside of the chroot environment and without -m600
Code:
$ /opt/linux/debian-11/usr/bin/mkfifo /tmp/lxfifo
$ ls /opt/linux/devuan-chimaera/tmp/lxfifo
/opt/linux/devuan-chimaera/tmp/lxfifo
$ sysctl -qn compat.linux.emul_path
/opt/linux/devuan-chimaeraRunning the Debian or Devuan mkfifo with -m600 and outside of a chroot environment, it fails to return then too.
Short of creating any one or more new Debian packages for this environment, I'm not certain if it would be possible to patch the Devuan
sysvinit-core package, such as to prevent it from trying to run mkfifo there.This is only with with the mkfifo from Debian (Debian 11) or from the Devuan chimaera relase. It's not happening with the mkfifo from the linux-c7 ports, where 'mkfifo -m600 /tmp/lxfifo' returns successfully.
Build info for my local build:
Code:
$ uname -a
FreeBSD xt 12.3-STABLE FreeBSD 12.3-STABLE stable/12-n1855-ce99de0241e RIPARIAN amd64An excerpt of running the Debian mkfifo under truss, to the point where it just stops:
Code:
$ truss /opt/linux/debian-11/usr/bin/mkfifo -m600 /tmp/lxfifo.new600
linux_brk(0x0) = 16990208 (0x1034000)
linux_newuname(0x7fffffffcd00) = 0 (0x0)
linux_access("/etc/ld.so.preload",R_OK) ERR#-2 'No such file or directory'
linux_openat(0xffffff9c,0x801055b67,0x80000,0x0) = 3 (0x3)
linux_newfstat(3,0x7fffffffc2f0) = 0 (0x0)
linux_mmap2(0x0,0x127e,0x1,0x2,0x3,0x0) = 34376908800 (0x801060000)
close(3) = 0 (0x0)
linux_openat(0xffffff9c,0x80105fe00,0x80000,0x0) = 3 (0x3)
read(3,"\^?ELF\^B\^A\^A\0\0\0\0\0\0\0\0"...,832) = 832 (0x340)
linux_newfstat(3,0x7fffffffc340) = 0 (0x0)
linux_mmap2(0x0,0x2000,0x3,0x22,0xffffffff,0x0) = 34376916992 (0x801062000)
linux_mmap2(0x0,0x2b608,0x1,0x802,0x3,0x0) = 34376925184 (0x801064000)
linux_mmap2(0x80106b000,0x19000,0x5,0x812,0x3,0x7000) = 34376953856 (0x80106b000)
linux_mmap2(0x801084000,0x8000,0x1,0x812,0x3,0x20000) = 34377056256 (0x801084000)
linux_mmap2(0x80108c000,0x2000,0x3,0x812,0x3,0x27000) = 34377089024 (0x80108c000)
linux_mmap2(0x80108e000,0x1608,0x3,0x32,0xffffffff,0x0) = 34377097216 (0x80108e000)
close(3) = 0 (0x0)
linux_openat(0xffffff9c,0x8010624e0,0x80000,0x0) = 3 (0x3)
read(3,"\^?ELF\^B\^A\^A\^C\0\0\0\0\0\0\0"...,832) = 832 (0x340)
((.. sic ..))
read(3,"\tmsdosfs\nnodev\tdevfs\n\tnfs\n"...,4096) = 163 (0xa3)
read(3,0x1034500,4096) = 0 (0x0)
close(3) = 0 (0x0)
linux_access("/etc/selinux/config",F_OK) ERR#-2 'No such file or directory'
linux_openat(0xffffff9c,0x801221b90,0x80000,0x0) ERR#-2 'No such file or directory'
linux_openat(0xffffff9c,0x7fffffffcc70,0x80000,0x0) ERR#-2 'No such file or directory'
linux_openat(0xffffff9c,0x10345e0,0x80000,0x0) ERR#-2 'No such file or directory'
linux_openat(0xffffff9c,0x1034800,0x80000,0x0) ERR#-2 'No such file or directory'
linux_openat(0xffffff9c,0x1034670,0x80000,0x0) ERR#-2 'No such file or directory'
linux_openat(0xffffff9c,0x1034750,0x80000,0x0) ERR#-2 'No such file or directory'
linux_openat(0xffffff9c,0x1034890,0x80000,0x0) ERR#-2 'No such file or directory'
linux_openat(0xffffff9c,0x10346e0,0x80000,0x0) ERR#-2 'No such file or directory'
umask(0x0) = 18 (0x12)
umask(0x12) = 0 (0x0)
linux_mknod(0x7fffffffd572,0x1180,0x0) = 0 (0x0)The tail of the output from ktrace/kdump, running the Debian mkfifo and then interrupting with
C-c
Code:
$ sysctl -qn compat.linux.emul_path
/opt/linux/debian-11
$ ktrace -f mkfifo-d11.out /opt/linux/debian-11/usr/bin/mkfifo -m600 /tmp/fifo.$$
^C
$ ktrace -f mkfifo-d11.out
$ kdump -E -f mkfifo-d11.out
31059 ktrace 0.000000 RET ktrace 0
31059 ktrace 0.000033 CALL execve(0x7fffffffe4d1,0x7fffffffe148,0x7fffffffe168)
31059 ktrace 0.000076 NAMI "/opt/linux/debian-11/usr/bin/mkfifo"
31059 ktrace 0.000304 NAMI "/opt/linux/debian-11/opt/linux/debian-11/lib64/ld-linux-x86-64.so.2"
31059 mkfifo 0.000430 RET linux_execve JUSTRETURN
31059 mkfifo 0.000503 CALL linux_brk(0)
31059 mkfifo 0.000529 RET linux_brk 16990208/0x1034000
31059 mkfifo 0.000594 CALL linux_newuname(0x7fffffffccc0)
31059 mkfifo 0.000622 RET linux_newuname 0
31059 mkfifo 0.000656 CALL linux_access(0x8010589b0,0x4)
31059 mkfifo 0.000680 NAMI "/opt/linux/debian-11/etc/ld.so.preload"
31059 mkfifo 0.000719 NAMI "/etc/ld.so.preload"
31059 mkfifo 0.000746 RET linux_access -1 errno -2 No such file or directory
31059 mkfifo 0.000775 CALL linux_openat(0xffffff9c,0x801055b67,0x80000,0)
31059 mkfifo 0.000799 NAMI "/opt/linux/debian-11/etc/ld.so.cache"
31059 mkfifo 0.000827 NAMI "/opt/linux/debian-11"
31059 mkfifo 0.000856 NAMI "/opt/linux/debian-11/etc/ld.so.cache"
31059 mkfifo 0.000887 RET linux_openat 3
31059 mkfifo 0.000918 CALL linux_newfstat(0x3,0x7fffffffc2b0)
31059 mkfifo 0.000944 STRU struct stat {dev=17641383549324237605, ino=87240, mode=0100644, nlink=1, uid=0, gid=0, rdev=18446744073709551615, atime=1645446885.350270
000, mtime=1645446885.350556000, ctime=1645446885.351749000, birthtime=1645446885.350270000, size=50228, blksize=50688, blocks=33, flags=0x800 }
31059 mkfifo 0.000969 RET linux_newfstat 0
31059 mkfifo 0.001006 CALL linux_mmap2(0,0xc434,0x1,0x2,0x3,0)
31059 mkfifo 0.001050 RET linux_mmap2 34376908800/0x801060000
31059 mkfifo 0.001085 CALL close(0x3)
31059 mkfifo 0.001108 RET close 0
31059 mkfifo 0.001140 CALL linux_openat(0xffffff9c,0x80105fe00,0x80000,0)
31059 mkfifo 0.001164 NAMI "/opt/linux/debian-11/lib/x86_64-linux-gnu/libselinux.so.1"
31059 mkfifo 0.001203 NAMI "/opt/linux/debian-11"
31059 mkfifo 0.001231 NAMI "/opt/linux/debian-11/lib/x86_64-linux-gnu/libselinux.so.1"
(...)
31059 mkfifo 0.009937 CALL umask(0)
31059 mkfifo 0.009959 RET umask 18/0x12
31059 mkfifo 0.009996 CALL umask(0x12)
31059 mkfifo 0.010029 RET umask 0
31059 mkfifo 0.010062 CALL linux_mknod(0x7fffffffd532,0x1180,0)
31059 mkfifo 0.010088 NAMI "/opt/linux/debian-11/tmp"
31059 mkfifo 0.010119 NAMI "/opt/linux/debian-11/tmp/fifo.67349"
31059 mkfifo 0.010251 RET linux_mknod 0
31059 mkfifo 0.010281 CALL linux_openat(0xffffff9c,0x7fffffffd532,0x2a0000,0)
31059 mkfifo 0.010317 NAMI "/opt/linux/debian-11/tmp/fifo.67349"
31059 mkfifo 0.010357 NAMI "/opt/linux/debian-11"
31059 mkfifo 0.010386 NAMI "/opt/linux/debian-11/tmp/fifo.67349"
31059 mkfifo 4.249811 RET linux_openat -1 errno -4 Interrupted system call
31059 mkfifo 4.249923 PSIG SIGINT SIG_DFL code=SI_KERNELAt least the c7 ports are not affected.
Probably none of the following remarks would affect the matter of the mkfifo call not returning when provided with a file permissions mask. Although it's showing up with the mkfifo from Debian, but it doesn't appear to be used in the default debootstrap installation for Debian 11. Of course, there are other Linux distributions.
I suppose it's time to test out some tooling for keeping a series of ports for CentOS 8-stream updated. They've stopped making single releases now. The CentOS 8-stream series might be a lot like Debian 'sid', as a distribution. I'm certain that this could be difficult to track for RPM dependencies, source files, and then the mk-files for porting on FreeBSD. Maybe it could be possible to create some tooling that would simplify that process. I'm not certain if I'm anywhere close to arriving to such tooling, though I've started working on some Ruby scripting for reading the CentOS RPM repository information.
Alternately, noticing the selinux code referred in that kdump output, perhaps a build of a Linux distribution without systemd and without selinux could be of some use for this support under FreeBSD, at least assuming that it would be used with any upstream code that doesn't have any linkage onto the systemd libraries.
The debootstrap code seems to support a 'fakechroot' variant, albeit developed for Debian tooling of some kind. This release variant does not pull in the
sysvinit-core pkg. As a workaround, If that can be patched somehow for installing under linuxulator, maybe there's another possible approach for installing Devuan with linuxulator on FreeBSD.