Yesterday I wanted to suggest you to debug udev(7), but beng not at home, subsequently I couldn’t access a Linux pc. As I’m not the
udev pro (much more confident with
devd and relatively
eudev), I was not sure about the correct syntax to use.
Anyway, let’s begin with systemd-udev, the device event managing daemon which is framed to be the culprit. This daemon takes note of Kernel events, then looks over udev rules to find matching attributes and execute a corresponding instruction (worker), such as loading the correct driver, according to specified rules.
First of all, as root (with
su), let’s raise the info level printed by systemd-udevd to debug level:
echo udev_log="debug" >> /etc/udev/udev.conf
then append debug and delay flag to udevd(8) runit service ( thus to prolong the wait for the worker to be executed, and hold back child process from exiting earlier and abort boot process).
/var/service/udevd/run and replace
exec udevd with:
exec udevd --debug --event-timeout=240
I case those flags happened to not be applied, they can also be set as kernel params:
In any case, replace 240 with the maximum time in secs you’d want to wait.
Now, let’s check which devices are associated to the suspected
00:11.0 BusID for SATA controllers:
ls -al /sys/block/s* | grep -i '00:11.0'
The output should include all your SATA devices (HDDs, SSDs, optical drives for CD-ROMs). In my case they are located at BusID
00:17.0, so here’s my output:
lrwxrwxrwx 1 root root 0 Jan 13 11:42 /sys/block/sda -> ../devices/pci0000:00/0000:00:17.0/ata5/host4/target4:0:0/4:0:0:0/block/sda/
lrwxrwxrwx 1 root root 0 Jan 13 11:42 /sys/block/sdb -> ../devices/pci0000:00/0000:00:17.0/ata6/host5/target5:0:0/5:0:0:0/block/sdb/
lrwxrwxrwx 1 root root 0 Jan 13 12:56 /sys/block/sr0 -> ../devices/pci0000:00/0000:00:17.0/ata3/host2/target2:0:0/2:0:0:0/block/sr0/
Which expectably matches my 3 SATA controllers: the Seagate HDD (
sda), the Kingston M.2 SATA SSD (
sdb) and the optical drive (
Default rules for those are stored inside:
May any problem arise, probably it’s those rules you’ll have to check out, as well as any specific ruleset crated by programs you installed, which may refer to the former by default.
To better print rules related to any of those SATA devices, you can use udevadm(8)…using a bash syntax:
udevadm -d info -a -p $(udevadm info -q path -n /dev/sda)
And replace sda with any
sr0 you have.
To understand those (I’m not very competent in that yet), you shall read carefully udev(7).
Now, in order to reproduce events related to cold-plug devices (such as those SATA controllers), we can use the udevadm’s
udevadm -d trigger --verbose --dry-run --type=devices --subsystem-match=scsi_disk
NOTE: Replacing scsi_disk with scsi will trigger events for all SATA ports (including empty ones and optical drive if present).
You can also run a debug test for any of your SATA controllers which
ahci module is suspected to fail attaching to:
udevadm -d test /block/sr0
Again, replace sr0 with the wanted drive.
Oh, yes, I should have figured that since system has never carried out a single complete boot with 4.14.13_1 Kernel, dmesg has never been invoked yet to write a
/var/log/dmesg.log for the latter.
Recently someone pointed me out how to activate a log daemon for void (which doesn’t provide one by default). The log service recommended it’s the highly portable socklog which has been developed by Runit creator. Fetch, install and activate it:
xbps-install -Sy socklog-void
ln -s /etc/sv/socklog-unix /var/service/
ln -s /etc/sv/nanoklogd /var/service/
Add you user to the socklog group in order to be allowed to cat the logs as standard user:
usermod -aG socklog <your username>
In case socklog group happened not o have been created first:
groupadd -f socklog
to see message buffer (like dmesg) for the current kernel and session:
Replacing most with your $PAGER
to quickly display current boot’s kernel logs from command-line:
svlogtail kernel | $PAGER
Current session errors are displayed at
Side Note: you may also want to retry a initramfs build, and see if the problem encounter last time still persist
good luck with this