Ascii: hdparm.conf ignored - udev problem?

kalle-del-haye · 2018-06-18 15:09:13

I'm using Devuan Ascii for my headless file server with 8 HDD's on an LSI SAS2008 based card.

In my hdparm.conf I configure the APM and Standby-Time settings for all the disks. But on start up or on reboot of the server, the settings in the hdparm.conf did not affect any of the disks. I attached a , RUN+="/bin/date >> /home/kalle/udev-hdparm" in the /lib/udev/rules.d/85-hdparm.rules but it has no effect, the file is not created. Using hdparm on the command line is working without issues.

So, I think the udev rule for hdparm is not executed.
Is this a general problem in Ascii?
Or is something wrong with my installation?

How can I further debug this problem? Any Ideas?

Thanks
kalle

golinux · 2018-06-18 15:23:51

Is udev running the show or eudev? IIRC eudev is default in ASCII. If yes, something might have gotten lost in translation. That's the only suggestion I have as this subject is way beyond me technically.

kalle-del-haye · 2018-06-18 15:52:15

Eudev, I think.

eudev/stable,now 3.2.2-13 amd64  [installiert]
eudev-dbgsym/stable 3.2.2-13 amd64
libeudev-dev/stable 3.2.2-13 amd64
libeudev1/stable,now 3.2.2-13 amd64  [installiert]
libeudev1-dbgsym/stable 3.2.2-13 amd64
libudev-dev/stable 1:3.2.2+devuan2.11 amd64
libudev1/stable 1:3.2.2+devuan2.11 amd64
udev/stable,now 1:3.2.2+devuan2.11 amd64  [installiert]

emanym · 2018-06-18 18:42:08

Are there any files in /run/udev/rules.d/?

Does copying the 85-hdparm file to /etc/udev/rules.d/ change anything?

(Those should take precedence over /lib/udev/rules.d/)

Also, you could try changing the loglevel in /etc/udev/udev.conf, probably start by uncommenting, and see what pops up in dmesg.

There are some udev config files in the initrd.img as well, but i'm not sure hdparm would be included in a standard initrd:

root@sybilla:~#  lsinitramfs /boot/initrd.img-4.9.0-6-amd64 | grep udev
 ...
lib/udev/rules.d
lib/udev/rules.d/56-lvm.rules
lib/udev/rules.d/69-lvm-metad.rules
lib/udev/rules.d/50-udev-default.rules
lib/udev/rules.d/60-persistent-storage.rules
lib/udev/rules.d/80-drivers.rules
lib/udev/rules.d/55-dm.rules
lib/udev/rules.d/60-persistent-storage-dm.rules
 ...

kalle-del-haye · 2018-06-19 08:04:02

emanym wrote:

Are there any files in /run/udev/rules.d/?

No, directory is empty.

emanym wrote:

Does copying the 85-hdparm file to /etc/udev/rules.d/ change anything?

No, hdparm.conf (and I think also 85-hdparm.rules) is still ignored.

emanym wrote:

Also, you could try changing the loglevel in /etc/udev/udev.conf, probably start by uncommenting, and see what pops up in dmesg.

Changing the loglevel of eudev to info doesn't give much information, so I used debug.
To me it looks like eudev is reading all the rules included in initramfs, like expected.
But when the real system is loading I can't find that any rule in /lib/udev/rules.d/ is read.

$ dmesg | grep udev
[    0.512563] udevd[83]: starting version 3.2.2
[    0.512571] udevd[83]:  does not exist, please run udevadm hwdb --update
[    0.512649] udevd[83]: Load module index
[    0.512678] udevd[83]: timestamp of '/lib/udev/rules.d' changed
[    0.512712] random: udevd: uninitialized urandom read (16 bytes read)
[    0.512734] random: udevd: uninitialized urandom read (16 bytes read)
[    0.512757] udevd[83]: Reading rules file: /lib/udev/rules.d/50-udev-default.rules
[    0.512896] udevd[83]: Reading rules file: /lib/udev/rules.d/55-dm.rules
[    0.512965] udevd[83]: Reading rules file: /lib/udev/rules.d/60-persistent-storage-dm.rules
[    0.512996] udevd[83]: Reading rules file: /lib/udev/rules.d/60-persistent-storage.rules
[    0.513125] udevd[83]: Reading rules file: /lib/udev/rules.d/80-drivers.rules
[    0.513155] udevd[83]: rules contain 24576 bytes tokens (2048 * 12 bytes), 4213 bytes strings
[    0.513358] udevd[84]: starting eudev-3.2.2
[    0.520022] random: udevd: uninitialized urandom read (16 bytes read)
[    1.524406] udevd: 5990 output lines suppressed due to ratelimiting
[    1.828973] udevd[541]: Failed to symlink /proc/kcore to /dev/core: File exists
[    1.828976] udevd[541]: Failed to symlink /proc/self/fd to /dev/fd: File exists
[    1.828979] udevd[541]: Failed to symlink /proc/self/fd/0 to /dev/stdin: File exists
[    1.828982] udevd[541]: Failed to symlink /proc/self/fd/1 to /dev/stdout: File exists
[    1.828984] udevd[541]: Failed to symlink /proc/self/fd/2 to /dev/stderr: File exists
[    1.829017] udevd[541]: starting version 3.2.2
[    1.831420] udevd[541]: === trie on-disk ===
[    1.831423] udevd[541]: tool version:          3
[    1.831425] udevd[541]: file size:         7195445 bytes
[    1.831426] udevd[541]: header size             80 bytes
[    1.839066] random: udevd: uninitialized urandom read (16 bytes read)
[    1.839104] random: udevd: uninitialized urandom read (16 bytes read)
[    1.839111] random: udevd: uninitialized urandom read (16 bytes read)
[    1.843686] udevd[542]: starting eudev-3.2.2
[    9.036399] udevd[542]: seq 1841 queued, 'add' 'sas_port'
[    9.036462] udevd[542]: seq 1842 queued, 'add' 'sas_device'
[    9.036501] udevd[542]: seq 1843 queued, 'add' 'sas_end_device'
[    9.036695] udevd[542]: seq 1844 queued, 'add' 'bsg'
[    9.165161] udevd[542]: seq 1845 queued, 'add' 'sas_port'
[    9.165178] udevd[542]: seq 1846 queued, 'add' 'sas_device'
[    9.165188] udevd[542]: seq 1847 queued, 'add' 'sas_end_device'
[    9.165278] udevd[542]: seq 1848 queued, 'add' 'bsg'
[    9.403141] udevd[542]: seq 1849 queued, 'add' 'sas_port'
[    9.403158] udevd[542]: seq 1850 queued, 'add' 'sas_device'
[   14.557579] udevd[542]: seq 2001 queued, 'add' 'module'
[   14.557603] udevd[542]: passed 129 byte device to netlink monitor 0x56192f0c1130
[   14.557630] udevd[572]: seq 2001 running
[   14.557651] udevd[572]: no db file to read /run/udev/data/+module:rfkill: No such file or directory
[   14.557693] udevd[572]: passed device to netlink monitor 0x56192f1813a0
[   14.557695] udevd[572]: seq 2001 processed
[   14.557739] udevd[542]: seq 2002 queued, 'add' 'class'
[   14.557750] udevd[542]: passed 127 byte device to netlink monitor 0x56192f0c1130
[   14.557766] udevd[572]: seq 2002 running
[   14.557777] udevd[572]: no db file to read /run/udev/data/+class:rfkill: No such file or directory
[   20.891405] udevd[542]: cleanup idle workers
[   20.891540] udevd[542]: Validate module index
[   20.891633] udevd[564]: Unload module index
[   20.891829] udevd[567]: Unload module index
[   20.892466] udevd[573]: Unload module index
[   20.892502] udevd[542]: worker [564] exited
[   20.892533] udevd[542]: worker [567] exited
[   20.892727] udevd[575]: Unload module index
[   20.893036] udevd[574]: Unload module index
[   20.893360] udevd[566]: Unload module index
[   27.548037] udevd[542]: cleanup idle workers
[   27.548068] udevd[542]: Validate module index
[   27.548117] udevd[2454]: Unload module index
[   27.548275] udevd[542]: worker [2454] exited
[   27.876081] udevd[542]: seq 2022 queued, 'change' 'platform'
[   27.876209] udevd[542]: seq 2022 forked new worker [2615]
[   27.878879] udevd[2615]: seq 2022 running
[   27.878936] udevd[2615]: no db file to read /run/udev/data/+platform:regulatory.0: No such file or directory
[   27.878946] udevd[2615]: IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:15
[   27.878972] udevd[2615]: IMPORT builtin 'hwdb' returned non-zero
[   34.203900] udevd[542]: cleanup idle workers
[   34.203931] udevd[542]: Validate module index
[   34.204043] udevd[2645]: Unload module index
[   34.204258] udevd[542]: worker [2645] exited
[   34.528193] udevd[542]: seq 2024 queued, 'change' 'platform'
[   34.528548] udevd[542]: seq 2024 forked new worker [2680]
[   34.529053] udevd[2680]: seq 2024 running
[   34.529223] udevd[2680]: no db file to read /run/udev/data/+platform:regulatory.0: No such file or directory
[   34.529252] udevd[2680]: IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:15
[   34.529327] udevd[2680]: IMPORT builtin 'hwdb' returned non-zero
[   40.860066] udevd[542]: cleanup idle workers
[   40.860130] udevd[542]: Validate module index
[   40.860293] udevd[2692]: Unload module index
[   40.860697] udevd[542]: worker [2692] exited
[   41.184191] udevd[542]: seq 2026 queued, 'change' 'platform'
[   41.184328] udevd[542]: seq 2026 forked new worker [2704]
[   41.184501] udevd[2704]: seq 2026 running
[   41.184550] udevd[2704]: no db file to read /run/udev/data/+platform:regulatory.0: No such file or directory
[   41.184558] udevd[2704]: IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:15
[   41.184582] udevd[2704]: IMPORT builtin 'hwdb' returned non-zero
[   47.516239] udevd[542]: cleanup idle workers
[   47.516305] udevd[542]: Validate module index
[   47.516456] udevd[2721]: Unload module index
[   47.516889] udevd[542]: worker [2721] exited
[   47.840193] udevd[542]: seq 2028 queued, 'change' 'platform'
[   47.840319] udevd[542]: seq 2028 forked new worker [2748]
[   47.840484] udevd[2748]: seq 2028 running
[   47.840527] udevd[2748]: no db file to read /run/udev/data/+platform:regulatory.0: No such file or directory
[   47.840537] udevd[2748]: IMPORT builtin 'hwdb' /lib/udev/rules.d/50-udev-default.rules:15
[   47.840561] udevd[2748]: IMPORT builtin 'hwdb' returned non-zero

emanym · 2018-06-19 21:03:25

Hmm, this is weird, but anyway:

If udev only processes files from the initrd, it is possible to add what we need, by creating a file in /etc/initramfs-tools/hooks/hdparm, making it executable chmod +x $file), containing the following:

#!/bin/sh

set -e

PREREQ=""

prereqs () {
	echo "${PREREQ}"
}

case "${1}" in
	prereqs)
		prereqs
		exit 0
		;;
esac

. /usr/share/initramfs-tools/hook-functions

copy_exec /lib/udev/hdparm /lib/udev
copy_exec /sbin/hdparm /sbin
cp -p /etc/udev/rules.d/85-hdparm.rules $DESTDIR/lib/udev/rules.d/
cp -p /etc/hdparm.conf $DESTDIR/etc

exit 0

With a simple config in /etc/hdparm.conf:

/dev/sda {
  apm = 64
  spindown_time = 5
}

Next, run update-initramfs -u -k 4.9.0-6-amd64 (or whatever your kernel version is), and check with:

root@iris~:lsinitramfs /boot/initrd.img-4.9.0-6-amd64 |grep hdparm
etc/hdparm.conf
lib/udev/rules.d/85-hdparm.rules
lib/udev/hdparm
sbin/hdparm

And sure enough:

root@iris:~# hdparm -I /dev/sda | grep level
        Advanced power management level: 64

So far, so good, but when I remove the hdparm stuff from my initrd, hdparm still starts at boot, and still reads /etc/hdparm.conf.

I'm reasonably sure I don't understand what happened here, but if you have a fairly high tolerance for nasty hacks you could try this ;-)

kalle-del-haye · 2018-06-20 08:59:38

@emanym: Thanks for your help.

emanym wrote:

So far, so good, but when I remove the hdparm stuff from my initrd, hdparm still starts at boot, and still reads /etc/hdparm.conf.

That's good to know, so eudev and hdparm.conf should usually working in Ascii. I will check that on an other system with a recent Ascii later today or tomorrow. Maybe comparing the eudev debug log with one of a correctly working system gives some hints.

I've never changed anything on eudev. So, before fixing a problem that shouldn't exist with a "nasty hack", I would like to know the reason for this eudev problem.

Maybe I force a reinstall of eudev and see what happend.
Or could it related to openrc, which I'm using?

emanym · 2018-06-20 11:10:48

Or could it related to openrc, which I'm using?

~~I doubt that, I tested yesterday on a clean ASCII install with sysvinit...~~

Actually, is there anything hdparm related in /etc/conf.d/?

The gentoo wiki suggests setting hdparm boot options there:
https://wiki.gentoo.org/wiki/Hdparm#OpenRC

I haven't figured out a way to test anything yet, since hdparm starts at boot even if I remove it from the initrd...

I'm sure there is a sane way to solve this problem, but I'm not that familiar with the inner workings of udev, and only use hdparm to wipe disks anyway....

edit
Funny this, running hdparm at boot seems to work out of the box on some devuan installations (jessie amd64, ascii i386, ascii amd64 upgraded from jessie) but not on every devuan installation I have -- even though they are all installed on the same machine...

Last edited by emanym (2018-06-20 20:58:53)

kalle-del-haye · 2018-06-21 14:45:18

emanym wrote:

Actually, is there anything hdparm related in /etc/conf.d/?
The gentoo wiki suggests setting hdparm boot options there:
https://wiki.gentoo.org/wiki/Hdparm#OpenRC

/etc/conf.d/ didn't exist. I think this directory is for configuration files for openrc init services in /etc/init.d/.
But Devuan with openrc (selected in the installation process) is not a "real" openrc system. All the init services are still classic sysV scripts in contrast to Gentoo, which is using openrc scripts (and conf files) for services. And, maybe, Gentoo uses a hdparm init service, but in Devuan hdparm is started by eudev only. (Except you add your own hdparm init service.)

emanym wrote:

Funny this, running hdparm at boot seems to work out of the box on some devuan installations (jessie amd64, ascii i386, ascii amd64 upgraded from jessie) but not on every devuan installation I have -- even though they are all installed on the same machine...

I think this is really an eudev problem. A simple testing rule in /etc/udev/rules.d/ is executed by udevadm trigger but not at reboot.

$ cat /etc/udev/rules.d/90-test.rules 
KERNEL=="sda", RUN+="/usr/bin/touch /home/kalle/udev-test-sda"
KERNEL=="sdb", RUN+="/usr/bin/touch /home/kalle/udev-test-sdb"
ACTION=="add", SUBSYSTEM=="block", KERNEL=="sdc", RUN+="/usr/bin/touch /home/kalle/udev-test-sdc"

emanym · 2018-06-21 18:04:37

kalle-del-haye wrote:

But Devuan with openrc (selected in the installation process) is not a "real" openrc system. All the init services are still classic sysV scripts in contrast to Gentoo, which is using openrc scripts (and conf files) for services.

I haven't looked at devuan with openrc yet, only a couple of arch versions. I *did* notice the jessie version of hdparm still has a startup script in /etc/init.d/hdparm that disappeared in the ascii version.

The jessie init script may work on ascii, but that's just another nasty hack ;-)

kalle-del-haye wrote:

I think this is really an eudev problem. A simple testing rule in /etc/udev/rules.d/ is executed by udevadm trigger but not at reboot.

Neither udev nor eudev seem to log anything useful beyond the rules files from the initrd, so I can't really help there.

The best idea is probably to file a (eudev) bug report at https://bugs.devuan.org/

~~I'll see if I can find some free partitions for an openrc devuan installation to try and reproduce the problem...~~

Strangely enough it works out of the box for me with an ascii openrc installation:

root@iris:~# hdparm -I /dev/sdb | grep level
        Advanced power management level: 254
root@iris:~# hdparm -I /dev/sda | grep level
        Advanced power management level: 64
root@iris:~# dpkg -s hdparm | grep ersi
Version: 9.51+ds-1
root@iris:~# dpkg -s udev | grep ersi
Version: 1:3.2.2+devuan2.11
root@iris:~# dpkg -s eudev | grep ersi
Version: 3.2.2-13
root@iris:~# dpkg -s openrc | grep ersi
Version: 0.23-1+b1
root@iris:~# uname -a
Linux iris 4.9.0-6-amd64 #1 SMP Debian 4.9.88-1+deb9u1 (2018-05-07) x86_64 GNU/Linux
root@iris:~#

Clean install, no desktop, just added vim, rsync and firmware for my graphics card...

Last edited by emanym (2018-06-22 20:09:16)

kalle-del-haye · 2018-06-23 12:18:32

emanym wrote:

Strangely enough it works out of the box for me with an ascii openrc installation:

OK. Is this installation still existing? Could you please, try the backports kernel?
Thats the only difference I notice

$ dpkg -s hdparm | grep ersi
Version: 9.51+ds-1
$ dpkg -s eudev | grep ersi
Version: 3.2.2-13
$ dpkg -s openrc | grep ersi
Version: 0.23-1+b1
$ uname -a
Linux 4.16.0-0.bpo.2-amd64 #1 SMP Debian 4.16.12-1~bpo9+1 (2018-06-03) x86_64 GNU/Linux

I will try to install a fresh Ascii to an USB stick and will see what hdparm/eudev is doing.

Thanks a lot.

Last edited by kalle-del-haye (2018-06-23 12:18:55)

emanym · 2018-06-23 19:37:59

kalle-del-haye wrote:

emanym wrote:
Strangely enough it works out of the box for me with an ascii openrc installation:
OK. Is this installation still existing?

I will keep it around for a while, openrc was on my todo list anyway ;-)

kalle-del-haye wrote:

Could you please, try the backports kernel?

So I did, and the results are the same (cold boot after disconnected power):

root@iris:~# hdparm -I /dev/sda | grep level
        Advanced power management level: 64
root@iris:~# hdparm -I /dev/sdb | grep level
        Advanced power management level: 254
root@iris:~# cat /proc/version
Linux version 4.16.0-0.bpo.2-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.16.12-1~bpo9+1 (2018-06-03)
root@iris:~#

kalle-del-haye wrote:

Thats the only difference I notice

Actually, there may be another difference, I typically pick a targeted initrd on installations...

And now for the really fun part, I attached a , RUN+="/bin/date >> /home/emanym/udev-hdparm" to /lib/udev/rules.d/85-hdparm.rules, and ....

root@iris:~# ls /home/emanym/
root@iris:~#

(with both kernel versions)

I'm reasonably
sure I don't understand that ;-)

Last edited by emanym (2018-06-23 19:39:54)

kalle-del-haye · 2018-06-25 10:33:41

One week later - I've found the (or my?) fault.

When I upgraded my server from Debian Jessie to Devuan Ascii i reused the working settings in hdparm.conf.
But in Ascii, hdparm.conf is read by a script started by a eudev rule and is working with /dev/sd? definitions only.
No /dev/disk/by-label, no /dev/disk/by-uuid or any other links in /dev/disk.

That's because the little eudev script reading hdparm.conf is using only the $DEVNAME environment variable from eudev to parse the settings. And $DEVNAME is /dev/sda, for example.

The sd? links in /dev can change for a specific disk, so I think its not a good idea to remove the by-label or by-uuid posibilities from hdparm.conf.
As a workaround you can make your own eudev rule for partitions using the variable $ID_FS_LABEL or $ID_FS_UUID for example.
I will try this when I find some time.

ralph.ronnquist · 2018-06-25 13:00:04

Great work. I've lodged a bug on your behalf. https://bugs.devuan.org//cgi/bugreport.cgi?bug=222

kalle-del-haye · 2018-06-27 11:50:41

Not really a workaround, but a serious alternative to using hdparm.conf, is creating a eudev rule for hdparm settings.

$ cat /etc/udev/rules.d/90-hdparm.rules 
ACTION=="add", KERNEL=="sd[a-z]", ENV{ID_MODEL}=="ST4000DM000*", RUN+="/sbin/hdparm -B 127 -S 241 -W 0 /dev/%k"
ACTION=="add", KERNEL=="sd[a-z]", ENV{ID_MODEL}=="ST4000VN000*", RUN+="/sbin/hdparm -B 127 -S 241 -W 0 /dev/%k"
ACTION=="add", KERNEL=="sd[a-z]", ENV{ID_MODEL}=="ST8000AS0002*", RUN+="/sbin/hdparm -S 241 -W 0 /dev/%k"
ACTION=="add", KERNEL=="sd[a-z]", ENV{ID_MODEL}=="ST8000AS0003*", RUN+="/sbin/hdparm -S 241 -W 0 /dev/%k"

For identifying disks you can use any environment variable eudev reported.

$ sudo udevadm info -n sda
...
E: DEVLINKS=/dev/disk/by-id/ata-SanDisk_SDSSDH3250G_174042421026 /dev/disk/by-id/wwn-0x12517096912022949889x
E: DEVNAME=/dev/sda
E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda
E: DEVTYPE=disk
E: ID_MODEL=SanDisk_SDSSDH3250G
E: ID_MODEL_ENC=SanDisk\x20SDSSDH3250G\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20\x20
...

For label or uuid your can use the environment variables of a partition. (Then the eudev rule have to use partitions in KERNEL.)

$ sudo udevadm info -n sda4
...
E: DEVLINKS=/dev/disk/by-id/ata-SanDisk_SDSSDH3250G_174042421026-part4 /dev/disk/by-id/wwn-0x12517096912022949889x-part4 /dev/disk/by-label/base /dev/disk/by-partlabel/base /dev/disk/by-partuuid/4c9b5cce-4bb8-410e-9835-9197d2199a19 /dev/disk/by-uuid/00c7cbb6-7bab-4e11-8f49-8dc5622054df
E: DEVNAME=/dev/sda4
E: DEVPATH=/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda4
E: DEVTYPE=partition
E: ID_FS_LABEL=base
E: ID_FS_LABEL_ENC=base
E: ID_FS_TYPE=btrfs
E: ID_FS_USAGE=filesystem
E: ID_FS_UUID=00c7cbb6-7bab-4e11-8f49-8dc5622054df
E: ID_FS_UUID_ENC=00c7cbb6-7bab-4e11-8f49-8dc5622054df
...

With this, I don't need a hdparm.conf any more. ;-)

@emanym: Thanks for your help.

@ralph.ronnquist: Thanks for reporting this bug.

The officially official Devuan Forum!

#1 2018-06-18 15:09:13

Ascii: hdparm.conf ignored - udev problem?

#2 2018-06-18 15:23:51

Re: Ascii: hdparm.conf ignored - udev problem?

#3 2018-06-18 15:52:15

Re: Ascii: hdparm.conf ignored - udev problem?

#4 2018-06-18 18:42:08

Re: Ascii: hdparm.conf ignored - udev problem?

#5 2018-06-19 08:04:02

Re: Ascii: hdparm.conf ignored - udev problem?

#6 2018-06-19 21:03:25

Re: Ascii: hdparm.conf ignored - udev problem?

#7 2018-06-20 08:59:38

Re: Ascii: hdparm.conf ignored - udev problem?

#8 2018-06-20 11:10:48

Re: Ascii: hdparm.conf ignored - udev problem?

#9 2018-06-21 14:45:18

Re: Ascii: hdparm.conf ignored - udev problem?

#10 2018-06-21 18:04:37

Re: Ascii: hdparm.conf ignored - udev problem?

#11 2018-06-23 12:18:32

Re: Ascii: hdparm.conf ignored - udev problem?

#12 2018-06-23 19:37:59

Re: Ascii: hdparm.conf ignored - udev problem?

#13 2018-06-25 10:33:41

Re: Ascii: hdparm.conf ignored - udev problem?

#14 2018-06-25 13:00:04

Re: Ascii: hdparm.conf ignored - udev problem?

#15 2018-06-27 11:50:41

Re: Ascii: hdparm.conf ignored - udev problem?

Board footer