Open xplshn opened 10 months ago
what fails with busybox?
Changing the coreutils to Busybox makes the booting process fail misserably. Not even the emergency shell works. I installed busybox to /opt/Busybox/ and added the PATH to my /etc/profile, and I ensured every Runit script used those PATHS, then the system PATHS. For example, the 04-swap script needs to be rewritten for compatibility with toybox/busybox. the 99- script also needs revisions. I can't point them all out because I simply don't know how to fix them. So my current "solution" is to have coreutils and delete them one by one, checking what works and what doesn't as I go. (Its really stupid, I know.)
Also, I recently discovered that someone maintains the S6/66 supervision suite for Void, it seems to work with it just fine.
is this issue about toybox or busybox? you seem to have buried the lede
as mentioned in https://github.com/void-linux/runit/issues/29#issuecomment-1864334838, busybox swapon does work
Busybox, I mentioned Toybox because of the similarities, I did try with both. But maybe my approach is flawed and I should just install to / and not /opt/Busybox/.
I highly doubt it's related to the location of the busybox utilities
I can't point them all out because I simply don't know how to fix them
you don't need to know how to fix it to report it, but making a report with just a vague "it doesn't work!" makes it impossible for us to know what apparently needs fixing.
Failing that, not describing how someone else could reproduce this non-standard setup also makes it impossible to know what to fix.
Okay. Sorry, I will provide a more appropriate step by step guide on how to reproduce.
So, I downloaded Void Linux Musl XFCE4 and installed it into a USB hard drive (Primitive, should have used QEMU and used serial output. I know, but my hardware is not appropriate for even that, so much for living in Argentina), I the proceeded to clone the source of Busybox, make menuconfig, checked that everything was okay, then did a make install on "/", I then reinstalled runit and void-runit to ensure commands like reboot where not a symlink to busybox's but rather the real command. After that, I rebooted and I was greeted with a shell in the middle of the init process, after typing exit some more errors poped up but nonetheless, lightdm did start, however, TTY1 was unusable, all other TTYs were okay. When I did init 0 some help pages for pkill did show up (2 times) implying that a script might be using an incorrect or non valid flag.
The easiest way to provide support for Busybox is just sticking to using standard, POSIX flags from the coreutils and not the GNU extensions.
Sorry for the primitive pics:
Please understand that I just cannot get a better PC and virtualization is not a viable option it seems with this hardware, at least on Linux, on Windows I haven't tried, I've not used Windows in 3 years.
I am okay with this not being supported or being added to the backlog, it is not what Void caters to be and I understand that perfectly.
Also, I pointed out that I was using Toybox, the emergency_shell not working issue was with Toybox, which is less mature than Busybox and is still not as stable as Busybox. So, do not mind that.
Busybox, I mentioned Toybox because of the similarities, I did try with both. But maybe my approach is flawed and I should just install to / and not /opt/Busybox/.
The early boot step only has /usr/bin:/usr/sbin
in PATH
, so it neer consider anything elsewhere (unless you changed it too):
https://github.com/void-linux/void-runit/blob/32893ea380f756534c919d2b4d2c47cd9242eaa0/1#L4
The invalid ELF header bits show that you have something badly wrong!?
Yes I did that, initially. But this time I installed to "/" by setting CONFIG_PREFIX=/
The ELF related errors are weird, it says that the binaries are not valid, however, they execute and work as intended, they only show up at boot.
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!