[solved] Intenso SSD not recognized


#1

Now, this one is a difficult one, I assume.

The installer of my beloved archlabs won‘t recognize my Intenso SSD.

lsblk sees the ssd, partprobe sees the ssd, ls /dev/sd* sees the ssd, the linux mint installer sees the ssd, gparted sees the ssd after I installed Mint on it.

But the Archlabs installer won‘t. I changed from UEFI to legacy, I switched from sata to usb, I even switched to a whole set of new hardware (different computer/mainboard).

The archkernel spits out some errors while booting, if you like to help you might want to have a look on the dmesg output in one of my posts below.


#2

Can you please post the output of lsblk


#3

aaaaand it’s gone (the lsblk entry):

liveuser@archlabs ~ % lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
loop0 7:0 0 862.1M 1 loop /run/archiso/sfs/airootfs
sdb 8:16 1 979M 0 disk
├─sdb1 8:17 1 973M 0 part /run/archiso/bootmnt
└─sdb2 8:18 1 64M 0 part
liveuser@archlabs ~ % ls /dev/sd*
/dev/sda /dev/sdb /dev/sdb1 /dev/sdb2
liveuser@archlabs ~ % partprobe -s
liveuser@archlabs ~ %

Meanwhile I have resetted the SSD’s partition scheme to gpt and the bios to UEFI again.

The kernel obviously recognizes /dev/sda though… when I remember correctly, gparted and lsblk showed me the lvm-devices of the installed Linux Mint - after Thunar mounted the lvm-devices. As far as I know Thunar i.e. gvfs does this differently as in comparison with the kernel.

And then the arch installer saw the /dev/mapper/foobar but not the /dev/sda, which didn’t help me with the installation.

I’m sure this can be fixed with some driver or kernelmod magic.


#5

If the output of fdisk -l is like this example:

/dev/sda1            2048   1050623   1048576   512M 83 Linux
/dev/sda2     *     1052672 312580095 311527424 148,6G 83 Linux

I think you need another partition on ssd ( previously prepared partition /dev/sda3 ) to install AL. Then with an update-grub in mint, I think it might work. Sorry if I’m not helpful @zaphod


#6

root@archlabs /home/liveuser # fdisk -l
Disk /dev/sdb: 979 MiB, 1026555904 bytes, 2004992 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x01cfe6b7

Device Boot Start End Sectors Size Id Type
/dev/sdb1 * 0 1992703 1992704 973M 0 Empty
/dev/sdb2 164 131235 131072 64M ef EFI (FAT-12/16/32)

Disk /dev/loop0: 862.1 MiB, 903974912 bytes, 1765576 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
root@archlabs /home/liveuser # ls /dev/sd*
/dev/sda /dev/sdb /dev/sdb1 /dev/sdb2
root@archlabs /home/liveuser #

@negata: you are helpful, every bit of meaningful input is welcomed and appreciated.


#7

@negata: that would be a funny workaround… to install mint, erase the lvm and install archlabs… however, the chance that archlabs won’t boot - due to the communication problem with the Intenso SSD - seems rather high to me.

It’s just a guess, but I suppose I need to include a kernel module (like i915 with certain intel graphics) in the initramfs in order to get the arch up and running.


#8

And if you only format the SSD and create a boot partition and another free partition dedicated to AL? I thought you were on dual boot.


#9

root@archlabs /home/liveuser # udisksctl info -b /dev/sda
/org/freedesktop/UDisks2/block_devices/sda:
org.freedesktop.UDisks2.Block:
Configuration: []
CryptoBackingDevice: ‘/’
Device: /dev/sda
DeviceNumber: 2048
Drive: ‘/org/freedesktop/UDisks2/drives/drive’
HintAuto: false
HintIconName:
HintIgnore: false
HintName:
HintPartitionable: true
HintSymbolicIconName:
HintSystem: true
Id:
IdLabel:
IdType:
IdUUID:
IdUsage:
IdVersion:
MDRaid: ‘/’
MDRaidMember: ‘/’
PreferredDevice: /dev/sda
ReadOnly: false
Size: 0
Symlinks: /dev/disk/by-path/pci-0000:00:1f.2-ata-2
UserspaceMountOptions:

root@archlabs /home/liveuser # udisksctl info -b /dev/sdb
/org/freedesktop/UDisks2/block_devices/sdb:
org.freedesktop.UDisks2.Block:
Configuration: []
CryptoBackingDevice: ‘/’
Device: /dev/sdb
DeviceNumber: 2064
Drive: ‘/org/freedesktop/UDisks2/drives/TOSHIBA_TransMemory_0C9027509081E9B3’
HintAuto: true
HintIconName:
HintIgnore: false
HintName:
HintPartitionable: true
HintSymbolicIconName:
HintSystem: false
Id: by-uuid-2018-07-29-20-31-03-00
IdLabel: AL_201807
IdType: iso9660
IdUUID: 2018-07-29-20-31-03-00
IdUsage: filesystem
IdVersion:
MDRaid: ‘/’
MDRaidMember: ‘/’
PreferredDevice: /dev/sdb
ReadOnly: false
Size: 1026555904
Symlinks: /dev/disk/by-id/usb-TOSHIBA_TransMemory_0C9027509081E9B3-0:0
/dev/disk/by-label/AL_201807
/dev/disk/by-path/pci-0000:00:14.0-usb-0:2:1.0-scsi-0:0:0:0
/dev/disk/by-uuid/2018-07-29-20-31-03-00
UserspaceMountOptions:
org.freedesktop.UDisks2.PartitionTable:
Partitions: [’/org/freedesktop/UDisks2/block_devices/sdb2’, ‘/org/freedesktop/UDisks2/block_devices/sdb1’]
Type: dos

Size: 0
Symlinks: /dev/disk/by-path/pci-0000:00:1f.2-ata-2
UserspaceMountOptions:

looks broken to me…

@Negata: dual boot as a work around? I’ll think about it. However, I’m still skeptical, either the arch kernel knows how to speak to the ssd or it does not. In that case booting the mint kernel would work, booting the arch kernel wouldn’t.


#10

Hmmm, look what I’ve found, looks kind of familiar:

https://wiki.archlinux.org/index.php/Solid_state_drive#Troubleshooting

Some SSDs and SATA chipsets do not work properly with Linux Native Command Queueing (NCQ). The tell-tale dmesg errors look like this:

[ 9.115544] ata9: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x10 frozen [ 9.115550] ata9.00: failed command: READ FPDMA QUEUED [ 9.115556] ata9.00: cmd 60/04:00:d4:82:85/00:00:1f:00:00/40 tag 0 ncq 2048 in [ 9.115557] res 40/00:18:d3:82:85/00:00:1f:00:00/40 Emask 0x4 (timeout)

To disable NCQ on boot, add libata.force=noncq to the kernel command line in the bootloader configuration. To disable NCQ only for disk 0 on port 9 use: libata.force=9.00:noncq

Alternatively, you may disable NCQ for a specific drive without rebooting via sysfs:

echo 1 > /sys/block/sdX/device/queue_depth

If this (and also updating the firmware) does not resolves the problem or cause other issues, then file a bug report.

So I did a

root@archlabs /home/liveuser # dmesg | grep ata
[ 0.000000] BIOS-e820: [mem 0x00000000bafbf000-0x00000000baffefff] ACPI data
[ 0.000000] Memory: 3897852K/4092272K available (10252K kernel code, 1290K rwdata, 3488K rodata, 1476K init, 608K bss, 194420K reserved, 0K cma-reserved)
[ 7.576350] Write protecting the kernel read-only data: 16384k
[ 7.770263] libata version 3.00 loaded.
[ 7.801990] ata1: DUMMY
[ 7.801995] ata2: SATA max UDMA/133 abar m2048@0xd0617000 port 0xd0617180 irq 26
[ 7.801997] ata3: DUMMY
[ 7.801999] ata4: DUMMY
[ 7.802000] ata5: DUMMY
[ 7.802002] ata6: DUMMY
[ 8.114110] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 8.115299] ata2.00: ATA-9: Intenso SSD Sata III, P0510E, max UDMA/133
[ 8.115305] ata2.00: 234441648 sectors, multi 1: LBA48 NCQ (depth 31/32), AA
[ 8.116338] ata2.00: configured for UDMA/133
[ 40.623574] ata2.00: exception Emask 0x0 SAct 0x4 SErr 0x50000 action 0x6 frozen
[ 40.623693] ata2: SError: { PHYRdyChg CommWake }
[ 40.623756] ata2.00: failed command: READ FPDMA QUEUED
[ 40.623832] ata2.00: cmd 60/08:10:00:00:00/00:00:00:00:00/40 tag 2 ncq dma 4096 in
[ 40.623997] ata2.00: status: { DRDY }
[ 40.624052] ata2: hard resetting link
[ 45.980138] ata2: link is slow to respond, please be patient (ready=0)
[ 50.626806] ata2: COMRESET failed (errno=-16)
[ 50.626892] ata2: hard resetting link
[ 55.983470] ata2: link is slow to respond, please be patient (ready=0)
[ 60.630138] ata2: COMRESET failed (errno=-16)
[ 60.630244] ata2: hard resetting link
[ 65.986803] ata2: link is slow to respond, please be patient (ready=0)
[ 95.680134] ata2: COMRESET failed (errno=-16)
[ 95.680243] ata2: limiting SATA link speed to 3.0 Gbps
[ 95.680247] ata2: hard resetting link
[ 100.696801] ata2: COMRESET failed (errno=-16)
[ 100.696909] ata2: reset failed, giving up
[ 100.696977] ata2.00: disabled
[ 100.697020] ata2: EH complete

and a

echo 1 > /sys/block/sda/device/queue_depth

which didn’t help, and finally a

BOOT_IMAGE=boot/x86_64/vmlinuz archisobasedir=arch archisolabel=AL_201807 cow_spacesize=1G libata.force=noncq initrd=boot/intel_ucode.img,boot/x86_64/archiso.img

as a command line in grub during reboot. And a

root@archlabs /home/liveuser # fwupdmgr get-devices
No detected devices

didn’t get me much further, either. Anyway, help is appreciated, since I’m at my wits’ end for now.


#11

run your hard drive smartctl


#12

Have done that before.

root@archlabs /home/liveuser # smartctl -d ata -a /dev/sda/
smartctl 6.6 2017-11-05 r4594 [x86_64-linux-4.17.10-1-ARCH] (local build)
Copyright © 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

Smartctl open device: /dev/sda/ failed: No such device
root@archlabs /home/liveuser # smartctl --scan
/dev/sdb -d scsi # /dev/sdb, SCSI device
root@archlabs /home/liveuser # ls /dev/sd*
/dev/sda /dev/sda1 /dev/sda2 /dev/sdb

Let me try a smartctl from a Mint live system to check the health of the SATA-SSD.


#13

I might have a look at the grub menu , from terminal;

sudo nano /etc/default/grub

Might help you out somehow.


#14

No, I don’t think so. Googling

PHYRdyChg CommWake

helped out kind of. “SATA cable or power supply weak” says the so called all-knowing trash heap. Doesn’t explain why it works with Mint. :wink:

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


#15

Gee, it s weird one, hope all SSDs arent like that !


#16

Oh, no. Try to see this differently, it’s a special one, a lovely one. Just needs some cuddles.


#17

your error
These bits are set by the SATA host interface in response to error conditions on the SATA link. Unless a drive hotplug or unplug operation occurred, it is generally not normal to see any of these bits set. If they are, it usually points strongly toward a hardware problem (often a bad SATA cable or a bad or inadequate power supply).


#18

Oh, understood.


#19

@altman: how exactly have you interpreted my words?

@ector: indeed, my fault.

SATA-Controller-Mode in the BIOS had to be set to compatible instead of AHCI.

Works like a charm now. Not quite as difficult as expected. Still we might wan‘t to keep this thread as a reminder or an assistance for other newbies.