The officially official Devuan Forum!

You are not logged in.

#1 2024-01-26 17:44:53

stultumanto
Member
Registered: 2023-12-12
Posts: 68  

iwd Daemon Not Starting at Boot

I searched the forum for iwd but couldn't find anything about this problem specifically. There is apparently a known issue with some Atheros chipsets:

a kernel bug where the NEW_WIPHY event is not emitted because it's too big specifically when using the ath10k driver, so we need to work around it in iwd. Ironically Denis has previously proposed a kernel patch to fix this but it was never accepted.

Later in that thread, some people report a fix. However, the issue persists on my ath9k hardware. The Arch Wiki suggests adding the following to the systemd unit as a fix:

[Service]
ExecStartPre=/usr/bin/sleep 2

Obviously, this fix won't work with sysvinit. The Devuan script at /etc/init.d/iwd sources /lib/init/init-d-script, and calls do_start_cmd to launch the daemon. I tried inserting a 'sleep 2' command before do_start_cmd, and reinstalling the script via update-rc.d, but the problem persisted. Finally, out of sheer desperation, I added the following lines to the end of my /etc/rc.local:

sleep 2
service iwd start

This actually worked, but clearly it's a hack. What's puzzling to me is that, if the rc.local addition worked, why didn't the edit to the init.d script? Could it just be because it comes later in the boot process?

Offline

#2 2024-01-27 03:10:08

GlennW
Member
From: Brisbane, Australia
Registered: 2019-07-18
Posts: 644  

Re: iwd Daemon Not Starting at Boot

Hi, I install iwd like this... For my tethering to iPhone (as a modem...)

apt install iwd

sh /home/glenn/bin/sysd2v-0.3.sh /lib/systemd/system/iwd.service
#rsync -avh /home/glenn/local/other/backup/backup-etc-sys/etc/init.d/iwd.initd /etc/init.d/iwd.initd
rsync -avh /home/glenn/local/other/backup/backup-etc-sys/etc/init.d/iwd.initd /etc/init.d/
rsync -avh /home/glenn/local/other/backup/backup-etc-sys/etc/runlevels/iwd.initd /etc/runlevels/
rsync -avh /home/glenn/local/other/backup/backup-etc-sys/etc/systemd/system/multi-user.target.wants/iwd.service /etc/systemd/system/multi-user.target.wants/
chmod +x /lib/systemd/system/iwd.service
chmod +x /etc/init.d/iwd.initd
service iwd.initd start
update-rc.d iwd.initd defaults

# udev rules for iPhones
rm /lib/udev/rules.d/*-usbmuxd.rules # 85-(?)
rsync -avh /home/glenn/local/data/build/39-usbmuxd.rules /lib/udev/rules.d/
chmod -R 744 /lib/udev/rules.d/39-usbmuxd.rules
chown -Rh root:root /lib/udev/rules.d/39-usbmuxd.rules

As you can see I'm using backups to restore the files.

The sysd2v-0.3.sh script does most of the work. I got this from more experienced users than I.

If you search here for sysd2v script, you should be able to find it.

I hope this helps.


pic from 1993, new guitar day.

Offline

#3 2024-01-27 04:41:51

stultumanto
Member
Registered: 2023-12-12
Posts: 68  

Re: iwd Daemon Not Starting at Boot

Thanks, I believe we may already be using the same script, as the /etc/init.d/iwd script that was installed on my system says it was generated by sys2dv:

#!/bin/sh
# Generated by sysd2v v0.3  --  http://www.trek.eu.org/devel/sysd2v
# kFreeBSD do not accept scripts as interpreters, using #!/bin/sh and sourcing.

I think the sys2dv script would work fine as it is, if it weren't for the known bug with the Atheros hardware, which was apparently fixed for the newer chipset (ath10k) but not my older system (ath9k.) This is a really old system (2008) and I don't think anyone at iwd or the kernel cares about fixing it anymore. I'll have a look at the sysd2v script source and see if I can figure out where I need to introduce the 2-second delay that the systemd unit fix would normally provide.

Offline

#4 2024-01-27 05:13:08

stultumanto
Member
Registered: 2023-12-12
Posts: 68  

Re: iwd Daemon Not Starting at Boot

Sorry to double-post, but this is a semi-separate issue, as I just realized I missed something really obvious. When I updated the script with update-rc.d, it put nothing but kill links in the /etc/rc* directories:

# update-rc.d iwd defaults
insserv: warning: current start runlevel(s) (empty) of script `iwd' overrides LSB defaults (2 3 4 5).
insserv: warning: current stop runlevel(s) (0 1 2 3 4 5 6) of script `iwd' overrides LSB defaults (0 1 6).

I don't understand why it's doing this, as the script has the correct runlevels:

if [ true != "$INIT_D_SCRIPT_SOURCED" ] ; then
    set "$0" "$@"; INIT_D_SCRIPT_SOURCED=true . /lib/init/init-d-script
fi
### BEGIN INIT INFO
# Provides:       iwd
# Required-Start: $remote_fs
# Required-Stop:  $remote_fs
# Should-Start:   $network
# Should-Stop:    $network
# Default-Start:  2 3 4 5
# Default-Stop:   0 1 6
# Description:    Wireless service
### END INIT INFO

Can anyone explain why update-rc.d isn't picking up these runlevels? When I update other scripts on the system, it works fine.

Offline

#5 2024-01-27 05:13:26

GlennW
Member
From: Brisbane, Australia
Registered: 2019-07-18
Posts: 644  

Re: iwd Daemon Not Starting at Boot

One more thing, not about the startup delay, I understand that.

I was also instructed to install orphan-sysvinit-scripts

package description info...

Orphaned System-V-like init scripts
 
This package provides System-V init scripts for packages whose maintainers
have chosen to drop them from the distribution in favour of only supplying
a systemd service file.

It will only put files into /etc/init.d/ when the relevant package is
installed on your system.

rc.local worked for me, but I can't remember what it was now I needed it for, the devuan system has evolved and matured.

<edit> it was for starting nftables.
the files will be at /usr/share/orphan-sysvinit-scripts/...</edit>

Last edited by GlennW (2024-01-27 05:17:27)


pic from 1993, new guitar day.

Offline

#6 2024-01-27 05:24:55

GlennW
Member
From: Brisbane, Australia
Registered: 2019-07-18
Posts: 644  

Re: iwd Daemon Not Starting at Boot

change this to

# Default-Start:  2 3 4 5
# Default-Stop:   0 1 6

to...

# Default-Start:  S
# Default-Stop:   0 6

I hope this helps.


pic from 1993, new guitar day.

Offline

#7 2024-01-27 05:31:05

stultumanto
Member
Registered: 2023-12-12
Posts: 68  

Re: iwd Daemon Not Starting at Boot

Thanks GlennW, I tried changing the runlevels, but I'm still getting the message about empty runlevels. For some reason update-rc.d is not properly parsing the file. It's so strange! I also had to install a script for nftables, and it worked fine.

I wish I'd looked at the rc directories before changing the iwd script to see if it was installed wrong from the start. That could have been the problem from the beginning.

I've got the orphan-sysvinit-scripts package on all my systems now, that's a good one to have.

Edit - update:

I used `update-rc.d iwd enable [runlevels]` to force the service to start when I wanted it to. It still doesn't explain why the default method fails, but at least it works now, and the service starts at boot!

Last edited by stultumanto (2024-01-27 06:14:26)

Offline

#8 2024-01-28 20:29:25

stultumanto
Member
Registered: 2023-12-12
Posts: 68  

Re: iwd Daemon Not Starting at Boot

I kept searching the web for instances of the error message, and eventually I found something helpful:
empty runlevels overide LSB defaults
It turns out that re-installing a script without first removing it can result in this error. So I merely did the following, and it ran without errors, installing the symlinks in the proper locations:

# update-rc.d -f iwd remove
# update-rc.d iwd defaults

The manpage for update-rc.d says that running the `remove' directive while the script is still present in /etc/init.d will result in errors. However, that didn't happen for me. In fact, it was exactly what I needed to do to fix the problem. It removed the symlinks in /etc/rc*.d, which then allowed me to reinstall the script with the default settings.

[Edit to clarify this paragraph] The manpage doesn't mention that running update-rc.d with the `defaults' directive when symlinks are already present in /etc/rc*.d will result in errors. There is a paragraph that says it "does nothing" if files exist at /etc/rc*.d/[SK]??, and I think this information is meant to apply to the `default' action, although the wording isn't really clear. But that's not really what happened either. In my case, installed kill scripts all over the place.

It's all very confusing, but I think I have the proper procedure figured out now.

Last edited by stultumanto (2024-01-28 20:44:42)

Offline

Board footer