You are not logged in.
Pages: 1
Having upgraded my laptop with OpenRC, it was time to try my desktop machine, which uses runit, including runit-init. As I am a bit more sensitive about my desktop system, I chose to try a VM first. I use Xen for running VMs.
I first updated/upgraded the existing Chimaera system and then set about the upgrade to Daedalus. I followed the instructions on the Devuan web site and edited /etc/sources.list from Chimaera to Daedalus and was careful to ensure that I added non-free-firmware to each line. I also killed off xscreensaver
# killall xscreensaver
and then did the update/upgrade
# apt update
# apt upgrade
This seemed to go fairly smoothly. I noticed that it has installed runit-services (0.5.4) which should provide a good collection of runit type service scripts.
After it had finished I did
# apt full-upgrade
# apt-get autoremove --purge
# apt-get autoclean
I noticed that the last two lines seem to have removed about 1.7GB.
# reboot
It seems to come up cleanly and vnc works (which is useful for the VM under Xen!)
I still haven't checked everything, but it does work well enough that I can get in and have a look around (I hope that doesn't sound too negative. The main system is fine).
I have things like Postfix and Postgresql running, although Postgresql needed a bit of fiddling with versions, more on that elsewhere as it is not really an installation thing. I think that I will report on Postgresql in the Desktop section,
Geoff
Last edited by Geoff 42 (2023-08-31 14:52:55)
Offline
I did a chimaera-runit upgrade to daedalus over a year ago, before the runit-services package existed. Did you run into any conflicts between extra run scripts you added and the ones from the services package?
Offline
I haven't got round to checking what is available in in runit-services yet as I was looking at a couple of other things, including the start up for Postgresql.
I will get round it that shortly.
Were you running with runit-init when you tried it?
Geoff
Offline
Yes, runit was in use when I did the upgrade. I used a chimaera-runit live iso to install into a VM and then I upgraded the installation. I don't recall any special problems with it.
Offline
Sorry to be a bit pedantic, but when I started looking at runit, some time ago, it was still using SysV init and called up runit from the last line of /etc/inittab.
Once I had that working I then moved to replacing SysV init with runit-init, which is a separate package from runit and completely by-passes inittab. This also affects things such as shutdown. I was being a bit cautious in case having a "non-standard" init program might affect the upgrade.
ls -l /sbin/init /sbin/shutdown
lrwxrwxrwx 1 root root 21 Jul 25 2021 /sbin/init -> /lib/runit/runit-init
lrwxrwxrwx 1 root root 19 Jul 25 2021 /sbin/shutdown -> /lib/runit/shutdown
Geoff
Offline
I have now re-booted with the Xen hypervisor and have fired up the test system so that I can examine it.
For the benefit of any innocent by-standers who are reading this, the "official" runit scripts are installed in /usr/share/runit/sv and also some in /usr/share/runit/meta. The installation is then able to copy over required ones into /etc/sv.
When I examine my test system, I can see from the time stamps on the files, that many files have been copied over to /etc/sv during the installation. Importantly it did not copy over postfix, as I had my own version in /etc/sv, so it spotted this and didn't overwrite it. I had my own version of postgresql, but that does not yet have an "official" set-up and my old version still works (sort of!).
I think that the preload service may be new and this was set up automatically.
There also seems to be a new dbus.dep-fixer which has been set up.
I also had a bunch of gettys set up, which have been overwritten, updating what I think were the original "official" versions, although I tend to add --noclear to tty1 and this has been overwritten.
I have two copies of dhclient running. There is one running from the script in /etc/sv/dhclient. There was a problem with this as it looks for its interface in /etc/sv/conf/interfaces, which was set to eth1 and I had to change it to eth0. I haven't yet tracked down where the other copy is being started from, but it seems to be early in the boot process.
I am not clear on the significance of /usr/share/runit/meta, which contains default-syslog, the gettys and ssh. These seem to have been copied over to /etc/sv.
Geoff
Offline
Yes, runit-init. I have the same symlinks for /sbin/init and /sbin/shutdown.
gettys and ssh had run scripts before the runit-services package existed. My daedalus-runit doesn't have that package. Last time I ran apt-upgrade on that VM was March 2022. It still has kernel 5.15.
My /usr/share/runit/meta has the same as yours plus acpid and irqbalance. I think I got the acpid scripts from the antix collection (run script is identical) but I don't know where the irqbalance script came from.
Offline
One thing that I have been trying is to set up a symlink from /etc/init.d to /usr/bin/sv. This should mean that anything that uses a SysV init syntax should still work.
I have tried this on Postfix. As an extra backup I saved the old init.d scripts to /usr/local/etc/init.d
then :-
root@fluorine:/etc/init.d# mv postfix .postfix
root@fluorine:/etc/init.d# ln -s /usr/bin/sv postfix
root@fluorine:/etc/init.d# ls -alF .postfix postfix
-rwxr-xr-x 1 root root 3368 Mar 16 2020 .postfix*
lrwxrwxrwx 1 root root 11 Sep 1 15:49 postfix -> /usr/bin/sv*
root@fluorine:/etc/init.d# cd
root@fluorine:~# /etc/init.d/.postfix status
postfix is running.
root@fluorine:~# /etc/init.d/postfix status
run: postfix: (pid 1881) 6694s; run: log: (pid 1880) 6694s
root@fluorine:~# sv status postfix
run: postfix: (pid 1881) 6707s; run: log: (pid 1880) 6707s
root@fluorine:~# service postfix status
run: postfix: (pid 1881) 6718s; run: log: (pid 1880) 6718s
So, this shows that calling up the old SysV init script does still work if you know where it is and with the old behaviour
Then if you use what looks like the postfix script in init.d, you get the same result as if you use sv or service.
Geoff
Offline
Pages: 1