sudo dinitctl list
[[+] ] boot
<snip>
[{+} ] early-prepare.target
[ {X}] root-ro
[{+} ] pseudofs
<snip>
[{+} ] tty6 (pid: 749)
root-ro?
cat /lib/dinit.d/root-ro
type = scripted
command = /bin/mount -o remount,ro,rshared /
restart = false
search root-ro dinit
https://forum.artixlinux.org/index.php/topic,7409.msg44615.html#msg44615
should the package add..
options = starts-on-console
?
Should I?
Yes if you want to see the log, or try other methods explained there.
I had to remove ro from
command = /bin/mount -o remount,ro,rshared /
to be able to boot in ARMtix.
edited
type = scripted
command = /bin/mount -o remount,ro,rshared /
options = starts-on-console
restart = false
$: sudo dinitctl restart root-ro
cannot restart service; service not started.
$: sudo dinitctl start root-ro
Service 'root-ro' failed to start.
Reason: service process terminated before ready: exited - status 32
$: sudo dinitcheck root-ro
[sudo] password for e:
Checking service: root-ro...
Performing secondary checks...
Secondary checks complete.
No problems found.
I got nothing.
I used the logfile option in my case.
I had error 32 too, this is the log:
mount: /: mount point is busy.
dmesg(1) may have more information after failed mount system call.
@davmac thought options = starts-on-console should fix the 32 error, yes?
That is to show the log in the console.
Because root-ro will prevent things to work.
That's unlikely to fix anything, it may help with debugging the issue though if you don't have any other logging for the service.
Is there an official solution to this? I am facing this exact problem and it is getting annoying. Same log output. My workaround is to go into the recovery, umount /, and then exit it and restart the boot sequence.
Yes I wrote it here:
You can copy the service in /etc/dinit.d folder that has more priority that the original, man dinit:
This seems more like a hack than a solution. The service is called "root-ro", so making it no longer mount as "ro" when there must be a good reason why it is depended on seems risky.
This might be a holdover from Arch (e.g. those who actually migrated their repos instead of fresh install), but sometimes the kernel parameter will mount root as
rw, preventing proper fsck (which needs the filesystems to be either unmounted or mounted
ro).
Note that I didn't reply to this thread at all since I can't reproduce this at all whether on my daily system or a fresh installation of x86_64 Artix.
Oh my god. I didn't even realize but I did have 'rw' in my kernel parameters in my EFISTUB. Removing that solved it.
In ARMtix I was using kernel and some files from Arch cause that machine needs not mainlined driver and quirks, thanks.
After removing "ro" I used that machine for long time without problems, now I do not have that device anymore.