subject:"Re\: hdparm"

Re: hdparm ignoring spindown_time in config when called with by-id symlink

2019-01-02 Thread Andrea Borgia


Il 02/01/19 14:35, Reco ha scritto:



So udev is not to blame here. It's shell-based config parsing library.


Possibly an upstream issue for hdparm, then.
Nice :(



Whitelist it. A file should be called
/etc/apparmor.d/local/usr.bin.thunderbird.


Thanks for the tip, saving for later.



echo 1 > /sys/block/sdb/device/delete
Assuming that your SATA controller is sane, it'll powerdown the drive
until the next reboot or SATA bus scan.


Interesting!

Re: hdparm ignoring spindown_time in config when called with by-id symlink

2019-01-02 Thread Reco

Hi.

On Wed, Jan 02, 2019 at 01:34:14PM +0100, Andrea Borgia wrote:
> Il 02/01/19 12:15, Reco ha scritto:
> 
> > What about this:
> > DEVNAME=/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ \
> > sh -x /lib/udev/hdparm  >> /tmp/hdparm.log 2>&1
> 
> I had tried it, too, and it looks in line with the results:

Good news are - your configuration file comes into play:

> + OPTIONS= -B1  -S6

Bad news are - /lib/hdparm/hdparm-functions screws you over:

> + read KEY SEP VALUE
> + [ -z /dev/sdb ]
> + [ -n  -B1  -S6 ]
> + [ /dev/sdb = /dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ 
> ]

This corresponds to line 222 of aforementioned script:

if [ -n "$OPTIONS" ] && [ "$DISC" = "$WANTED_DISK" ]
then
echo $OPTIONS
return 0
fi

You have options defined, but second comparison fails. $DISC seems to be
defined at line 113:

DISC=$(readlink -m "$KEY")
DISC=${DISC%%[[:digit:]]*}

And readlink 'helpfully' transforms your 'persistent' HDD name to
/dev/sdb.

So udev is not to blame here. It's shell-based config parsing library.

> (copypasted because I found out only later that Thunderbird could not attach 
> files from /tmp because of AppArmor)

Whitelist it. A file should be called
/etc/apparmor.d/local/usr.bin.thunderbird.

> > > 2) am I wrong in testing with the symlink instead of the real device name?
> > I'd rather remove this HDD via /sys interface as it's unused.
> 
> Apart from the fact I don't know (yet) how to do that, what good would it do?

echo 1 > /sys/block/sdb/device/delete

Assuming that your SATA controller is sane, it'll powerdown the drive
until the next reboot or SATA bus scan.

Reco

Re: hdparm ignoring spindown_time in config when called with by-id symlink

2019-01-02 Thread Andrea Borgia


Il 02/01/19 12:15, Reco ha scritto:



What about this:
DEVNAME=/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ \
sh -x /lib/udev/hdparm  >> /tmp/hdparm.log 2>&1


I had tried it, too, and it looks in line with the results:

+ set -e
+ [ -n /dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ ]
+ . /lib/hdparm/hdparm-functions
+ [ -e /proc/cmdline ]
+ grep -wq nohdparm /proc/cmdline
+ raidstat=OK
+ [ -e /proc/mdstat ]
+ egrep -iq resync|repair|recover|check /proc/mdstat
+ [ OK = OK ]
+ hdparm_options 
/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_
+ local 
WANTED_DISK=/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_

+ local DISC= DEFAULT= DEF_QUIET= COMMAND_LINE=
+ local OPTIONS OPT_QUIET KEY SEP VALUE
+ egrep -v ^[[:space:]]*(#|$) /etc/hdparm.conf
+ hdparm_try_apm 
/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_

+ [ -z  ]
+ udevadm info -n 
/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ -q property

+ sed -n s/^ID_PATH=//p
+ local ID_PATH=pci-:15:00.1-ata-2
+ [ -z  ]
+ udevadm info -n 
/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ -q property

+ sed -n s/^ID_ATA_FEATURE_SET_APM=//p
+ local ID_ATA_FEATURE_SET_APM=1
+ [ 1 = 1 ]
+ return 0
+ hdparm_is_on_battery
+ on_ac_power
+ [ 255 -eq 1 ]
+ hdparm_set_option -B254
+ local NEW_OPT= NEW_DEF=
+ test -n
+ DEFAULT=  -B254
+ read KEY SEP VALUE
+ [ -h /dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ ]
+ readlink -m /dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_
+ DISC=/dev/sdb
+ DISC=/dev/sdb
+ OPTIONS=  -B254
+ OPT_QUIET=
+ read KEY SEP VALUE
+ hdparm_is_on_battery
+ on_ac_power
+ [ 255 -eq 1 ]
+ hdparm_set_option -B1
+ local NEW_OPT= NEW_DEF=
+ test -n /dev/sdb
+ test x-B != x-B
+ NEW_OPT=
+ OPTIONS=  -B1
+ read KEY SEP VALUE
+ hdparm_set_option -S6
+ local NEW_OPT= NEW_DEF=
+ test -n /dev/sdb
+ test x-B != x-S
+ NEW_OPT= -B1
+ OPTIONS= -B1  -S6
+ read KEY SEP VALUE
+ [ -z /dev/sdb ]
+ [ -n  -B1  -S6 ]
+ [ /dev/sdb = 
/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ ]

+ COMMAND_LINE=
+ read KEY SEP VALUE
+ [ -n   -B254 ]
+ echo -B254
+ return 0
+ OPTIONS=-B254
+ [ -n -B254 ]
+ /sbin/hdparm -B254 
/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_


/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_:
 setting Advanced Power Management level to 0xfe (254)
 APM_level  = 254
+ exit 0

(copypasted because I found out only later that Thunderbird could not 
attach files from /tmp because of AppArmor)




1) am I wrong in using the by-id link to achieve a stable configuration?

You might get a race here. by-id symlinks are created by udev, so it's
possible to call hdparm udev script before actual symlink creation.


Right, I had not considered that. However, in real life it seems to be 
working: I rebooted to check the DEVNAME, the script is being called 
with the actual "sd" name (now /dev/sda, before /dev/sdb... I might have 
had a USB stick plugged in during the previous reboot)




2) am I wrong in testing with the symlink instead of the real device name?

I'd rather remove this HDD via /sys interface as it's unused.


Apart from the fact I don't know (yet) how to do that, what good would 
it do? I'm not worried about unauthorized access, I just want to spin it 
down in order to, possibly, preserve it. Would removing it via /sys 
achieve this goal? Other benefits to your suggestion?




3) if not, should I file a bug on hdparm?

I've tried to reproduce your problem, but 'sh -x' invocation with your
configuration file got me this:
/sbin/hdparm -B1 -S6 \
/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_
I suspect that your problem cannot be explained by hdparm bug.


Hmm, you don't have that disk in your system so the readlink call in the 
script will return the by-id name unchanged (I've tried that) and the 
comparison isn't really valid, I'm afraid. What happens if you try with 
an existing "id" for your system?




To recap, persistent names in the config seem to be ok, but the script 
apparently must be invoked with the actual name. This is what udev does 
and it works.



Thank you, Reco, for your help.

I'm CC'ing the maintainer for one quick feedback, if possible: SNAFU on 
my part, right?




Regards,
Andrea.

Re: hdparm ignoring spindown_time in config when called with by-id symlink

2019-01-02 Thread Reco

Hi.

On Tue, Jan 01, 2019 at 08:39:13PM +0100, Andrea Borgia wrote:
> My PC has two disks, a NVME for Debian/testing and an old 2.5 drive for an OS 
> that shall remain nameless :)
> 
> Since the 2.5 disc isn't at all used by Linux, I figured I might as well set 
> a very aggressive spindown time of, say, 30s and I wrote this in hdparm.conf:
>
> Then I tried checking whether hdparm would work when run via udev, with the 
> following command:
> DEVNAME=/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ 
> /lib/udev/hdparm  >> /tmp/hdparm.log 2>&1
> (suggestion taken from: 
> https://stackoverflow.com/questions/49841690/hdparm-conf-settings-dont-seem-to-run-at-boot)

What about this:

DEVNAME=/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_ \
sh -x /lib/udev/hdparm  >> /tmp/hdparm.log 2>&1

> Now, the questions:
> 1) am I wrong in using the by-id link to achieve a stable configuration?

You might get a race here. by-id symlinks are created by udev, so it's
possible to call hdparm udev script before actual symlink creation.


> 2) am I wrong in testing with the symlink instead of the real device name?

I'd rather remove this HDD via /sys interface as it's unused.


> 3) if not, should I file a bug on hdparm?

I've tried to reproduce your problem, but 'sh -x' invocation with your
configuration file got me this:

/sbin/hdparm -B1 -S6 \
/dev/disk/by-id/ata-Hitachi_HTS543225A7A384E2024242DBNGWJ_

I suspect that your problem cannot be explained by hdparm bug.

Reco

Re: hdparm reporting a different serial number

2017-09-19 Thread Ben Caradoc-Davies


On 20/09/17 14:53, Bhasker C V wrote:

Hi all,
  I have a seagate backup plus 5TB.
  When I plug-in the hdd, I see the serial number (as printed in the
back of the HDD) in dmesg.
usb 2-1.1: SerialNumber: 
[5.244161] usbcore: registered new interface driver usb-storage
[5.245790] scsi host6: uas
[5.246015] usbcore: registered new interface driver uas
[5.247071] scsi 6:0:0:0: Direct-Access Seagate  BUP BK
   0108 PQ: 0 ANSI: 6
[5.285452] sd 6:0:0:0: [sda] 9767541167 512-byte logical blocks:
(5.00 TB/4.55 TiB)
[5.285458] sd 6:0:0:0: [sda] 4096-byte physical blocks
[5.285786] sd 6:0:0:0: [sda] Write Protect is off
[5.285790] sd 6:0:0:0: [sda] Mode Sense: 53 00 00 08
This serial number is correct ! (Actuial serial number is obfuscated)
Whereas, when I do a hdparm or smartctl -i , I get a different serial number.
ATA device, with non-removable media
 Model Number:   ST5000LM000-2AN170
 Serial Number:  YYY
 Firmware Revision:  0001
 Transport:  Serial, ATA8-AST, SATA 1.0a, SATA II
Extensions, SATA Rev 2.5,
(actual serial number obfuscated)
Can someone explain why please ?
When I use seagate seatools, it reports both the USB-STORAGE and also
the internal HDD with the same  serial number (on windows).


Your USB hard drive consists of a USB to SATA bridge and a SATA HDD. My 
guess is that the kernel reports (via dmesg/journalctl) the USB iSerial 
of the bridge as "SerialNumber" and hdparm reports the SATA serial 
number of the HDD.


Kind regards,

--
Ben Caradoc-Davies 
Director
Transient Software Limited 
New Zealand

Re: hdparm consulta

2015-07-25 Thread Ricardo Delgado

El día 25 de julio de 2015, 10:59, Camaleón noela...@gmail.com escribió:
El Sat, 25 Jul 2015 10:40:01 -0300, Ricardo Delgado escribió:

hace un corto tiempo atras lei (no recuerdo si en este foro) que los
discos SSD no se pueden borrar completamente, es decir, no se puede
hacer un borrado seguro.

Ni los SSD ni los mecánicos (el borrado seguro al 100% no existe), pero
vamos, se puede intentar que quede lo más vacío posible.

mas alla de eso, hoy leyendo este articulo (0) me encuentro con un
parametro que me genera dudas y es el siguiente

hdparm -I /dev/sda me da como resultado (entre otros)

Security:
Master password revision code = 65534
supported
notenabled notlocked
frozen
notexpired: security count
supported: enhanced erase
104min for SECURITY ERASE UNIT. 106min for ENHANCED SECURITY ERASE
UNIT.

o sea, puedo borrar de forma segura un disco mediante hdparm, lo cual
seria algo asi como

hdparm --user-master u --security-erase Eins /dev/sdb
security_password=Eins

esto es asi? alguien me puede corroborar?

Pues es lo que dice la guía para definir una contraseña, paso previo al
borrado. El borrado de datos es el paso 3.

OJO. Según la salida del comando que envías más arriba *NO tienes
activado* el uso de contraseña.

la verdad aun estoy releyendo y buscando mas para enteder mejor el
concepto:

entre otras dudas que me surgen son; a.- si cambio la contraseña que
parece ser por defecto

Master password revision code = 65534

No, no... eso no es la contraseña, es sólo el código de revisión de la
función.

por otra a mi gusto, se mantendra? o sera de un solo uso.

Si lees el artículo completo, verás que dice que tras realizar todos los
pasos que detalla la contraseña queda desactivada pero entiendo que se
podrá habilitar esa funcionalidad después, con una contraseña de libre
elección.

b.- el borrado es como un shred (por dar un ejemplo) o secure delete?

Pues dependerá de cómo haya definido en el firmware esa función el
fabricante del disco duro. El artículo habla de algunos modelos de discos
Intel, no sé si será aplicable para todos.

c.- hay otras mas pero seguire leyendo.

(0) https://www.thomas-krenn.com/en/wiki/SSD_Secure_Erase

Si no estás seguro de lo que vas a hacer (es lo que parece) no lo hagas a
menos que tengas un backup completo de todos los datos.

El documento original:

https://ata.wiki.kernel.org/index.php/ATA_Secure_Erase

Saludos,

--
Camaleón

--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2015.07.25.13.59...@gmail.com

gracias por responder, no pienso hacer nada aun, simplemente estoy
leyendo documentacion, y si con respecto a la contraseña que no esta
habilitada lo se, queria corroborar y mas que nada escuchar (leer)
comentarios de alguien que haya hecho lo que reza el articulo y sus
experiencias.

lo de borrado seguro se que no es tal, pero se puede hacer que sea
dificil recuperar datos.

--
Windows? Reboot
Debian? beRoot

--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/ca+0kpa1rujy5d5kp71wf5qgggqyfiza5ns6ybcc-adx0pvp...@mail.gmail.com

1 2 3 4 5 >

1 - 100 of 432 matches

Mail list logo