The officially official Devuan Forum!

You are not logged in.

#1 Hardware & System Configuration » [SOLVED] How to remove security lock from a password protected SSD » 2024-10-18 12:58:29

VPigEePMUn7X
Replies: 1

I am writing this because I've spent a lot of hours trying to figure out how to remove the password from security-locked SATA SSD. It's very useful to have information at hand when you need it.

What happened:
I was preparing a spare SSD to be installed in another PC. Wanted to wipe everything in 10 seconds using ATA command - Enhanced Secure Erase. Somehow, hdparm enhanced-secure-erase did not finish on my Crucial SSD, and left the drive in password-locked state. This is not unheard of, I read a lot of messages on internet forums with people facing the same problem like me, sometimes because of different reasons, but same problem to solve.
So, on every boot, the computer would ask to enter a password to unlock the drive. Password was empty, I just needed to press enter. The security section in my motherboard BIOS (which could apply or remove a password lock) could not get to this drive, saying that my empty password is incorrect. Crucial Storage Executive program for Windows also could do nothing about it. As I don't use Microsoft Windows at all, I wasted a lot of time at this point, trying to install Windows on another PC, tried different laptops which were incompatible with security-locked SATA drive, even tried VMs, which were incompatible with Crucial Storage Executive program, what a mess it was.

Warning: solution below will wipe all your data from the drive.

Solution (change /dev/sdc drive letter as appropriate)
Install hdparm package in your Linux. Then:

sudo hdparm -I /dev/sdc
(...)
Security: 
        Master password revision code = 65534
                supported
                enabled
                locked
                frozen
        not     expired: security count
                supported: enhanced erase

It should say on the bottom: security enabled, locked and frozen. Meaning, password is enabled, and you can't take it off, because changing of security settings is not permitted. First thing, you need to remove the frozen state. To do that, you must suspend your machine and leave it suspended for a couple of minutes. Less than one minute doesn't work, I've tried.

After you wake up the PC, check status again:

sudo hdparm -I /dev/sdc
Security: 
        Master password revision code = 65534
                supported
                enabled
                locked
        not     frozen
        not     expired: security count
                supported: enhanced erase

It should say not frozen this time.

Now you can remove the locked status:

sudo hdparm --user-master u --security-unlock "" /dev/sdc

And perform secure erase to wipe the drive completely and remove the empty password lock:

sudo hdparm --user-master u --security-erase "" /dev/sdc

When this is done, the drive will be completely blank, and all password and security settings will reset. No more password!

If you did something wrong, for example attempted security-unlock when drive is still frozen state, or security-erase when drive is still in locked and/or frozen state, you will get error like this:

sudo hdparm --user-master u --security-erase "" /dev/sdc
security_password: ""

/dev/sdc:
 Issuing SECURITY_ERASE command, password="", user=user
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 04 51 40 00 21 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 04 51 40 01 21 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

You need to sort it out before you try again, as it will not work.

Hope this helps!

#2 Re: Other Issues » [SOLVED] (username) is not in the sudoers file. » 2024-10-14 23:55:28

> press the [arrow-down] button
    > go to section "# User privilege specification"
    > add a line beneath "root...ALL": "{YourUserName} ALL=(ALL:ALL) ALL", e.g.:

@odie2 that is incorrect advice. sudoers file already has an entry for sudo privileges for all members of sudo group. If you want to use sudo, add your user to sudo group, as mentioned few weeks ago by @stopAI. No need to modify sudoers file.

#3 Re: Other Issues » [SOLVED] libvirt: issue with default route changing to vnet after starting VM » 2024-10-09 18:06:31

Thanks for sharing useful ifupdown page. I've saved it, it may be useful in the future. Right now, this static homeserver which I am configuring, remains connected by one Ethernet cable 24/7/365, there is nothing to configure smile I hope it will stay that way.

#4 Re: Other Issues » [SOLVED] libvirt: issue with default route changing to vnet after starting VM » 2024-10-09 00:23:39

Ok I figured it out.... it's ConnMan. It seems to be incompatible with libvirt. ConnMan is installed by default in Devuan. When I uninstalled ConnMan and installed NetworkManager, the problem went away. Then I uninstalled NetworkManager too and left the built-in, basic ifupdown and /etc/network/interfaces file. It still works. Something in ConnMan causes libvirt to go haywire and spawn all these vnet networks. It's not happening when ifupdown or NetworkManager manages it. That's how it looks like when the host has got internet working and virbr0 NAT for VMs is working too:

$ ip route
default via 192.168.1.1 dev eth0 
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.182 
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1

#5 Other Issues » [SOLVED] libvirt: issue with default route changing to vnet after starting VM » 2024-10-08 23:34:34

VPigEePMUn7X
Replies: 3

I am experiencing connectivity issues on my Devuan host machine when starting a VM using virt-manager.
The VM is configured to use default virbr0 NAT network. It is getting usual 192.168.122.x IP from DHCP.

Upon starting the VM, a new network interface (vnet1) is created in the host. The routing table changes on Devuan host, becoming the default route:
$ ip route
0.0.0.0 dev vnet2 scope link
default dev vnet2 scope link
default via 192.168.1.1 dev eth0
(...)

This change leads to loss of internet connectivity on the host, and it prevents internet from ever working in the guest as well, as it tries to route traffic through the vnet interface, which does not have a valid internet connection. In the example above, we can see vnet2 because I tried adding another NIC to the VM, every time result is the same, guest NIC is activated, vnet is spawned, changing default route for entire host.

I don't know why this happens, I did not experience it on Debian host from which I just migrated.

When all VMs are closed, or their NICs are removed, internet works normally in Devuan host:

$ ip route
default via 192.168.1.1 dev eth0
(...)

Expected behaviour is of course virbr0 NAT network working normally without affecting the host's internet access.
Any insights appreciated!

Board footer

Forum Software