I have spotted two copies of dhclient running after upgrading to daedalus.

I am using runit and, clearly, one copy was being started by runit but the other was less easy to track down. I came to the conclusion that one copy was started by the networking software, presumably related to /etc/network/interfaces .

The version started from runit has now been removed

update-service --remove /etc/sv/dhclient

and the VM (under Xen) where I am testing it, still boots ok with just the one copy of dhclient.

Interestingly, the runit copy was earlier complaining even more about not being able to find eth1. I then spotted that the new runit setup for dhclient had a config file in conf/interfaces which contained

INTERFACES=eth1

Changing this to eth0 soon solved that. But this is no longer in use!

Geoff

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

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

Thank you for your encouragement.

I have now performed a few shutdowns and have managed to get a photo of the screen, using my 'phone!
This shows that it fails to unmount both /run/user/1026 and /home, although I have not found this in the log files.
I also spotted that it was recovering at least one of the file systems on booting, although, again,
I have not found this in the log files. /run/user/1026 was a tmpfs, so probably would not need
to be recovered.

I think that this is the sort of problem I found some time ago and which I reported in earlier posts.
I must find them again!

Geoff

Without Googling, I could see the URL and a quick poke around gave :-

https://www.gutenberg.org/cache/epub/16 … -cover.png

which was a bit of a give-a-way!

Geoff

I have now tried your version with :-

Package: *
Pin:  release a=chimaera-proposed-updates
Pin-Priority: 100

and it does not change the priority :-

apt policy libc6

while :-

does change the priority :-

apt policy libc6

My original version also included o=Devuan which also worked, as above.
I originally used n= rather than a= as the output from apt policy gave this :-

and I wanted to use chimaera rather than stable, which generally seems to be the recommended approach.

And I have been able to reboot successfully.

Geoff

Indeed, if I change devuan for merged in sources.list, then following an update, I can see libc6 with version u5.

I presume that it is safe to proceed with that and that there is an error on the web page :-

https://www.devuan.org/os/packages

Geoff

Thank you. You are right that I am still on u3.

With chimaera-proposed-updates enabled apt policy reports that it has a priority of 500 like the rest of the repo, while for libc6 :-

When I ask for it as you suggest I get :-

I have now got a run script working for Xen and will report separately.

The use of sym-linking sv, taken from the link xinomilo gave above, seems to be as follows, assuming you have the foo daemon (food) working via a Runit run file :-

/etc/init.d/food stop
dpkg-divert --add /etc/init.d/food
mv /etc/init.d/food /etc/init.d/food.distrib &&
   ln -s /usr/bin/sv /etc/init.d/food
update-service --add /etc/sv/food

you can then use either of the following styles of command :-

sv status food

or

/etc/init.d/food status

to access the foo service under Runit.

Geoff