Ratler's questions

Summary

I inserted an old internal SSD (which should have been in good health / not corrupted) into a USB enclosure, but I can't get any data from it.

Background

My old Kubuntu laptop with an encrypted (LUKS) SSD (Samsung MZ-VLV5120 512GB M.2 PCIe NVMe 2280) stopped working. I took it into a shop, and they figured that some power-related component was destroyed. They replaced it, and the laptop came back on and booted up to the point of needing to unlock the encrypted SSD, so the SSD seems to have been OK.

Now, because the component they used was not the right size, they couldn't close it up properly, and they've been delaying for weeks. In the meantime, I got a new laptop, so I finally asked them to just give me the SSD, and I inserted it into a Sabrent USB 3.2 Type-C Enclosure for M.2 PCIe NVMe and SATA SSDs to move my data to my new laptop.

There's a fresh install of Kubuntu 20.04 on the new laptop.

Problem

When I connect the enclosure to the laptop, it comes on (enclosure LED comes on), and it shows up as /dev/sda, but I don't seem to be able to do anything with it. For example, it's not detected by KDE Partition Manager.

Also, I tried to take a backup image of it with gddrescue before trying anything else, just to be safe, but that doesn't seem to work either. By the way, I used to back up the SSD when it was still inside the ruined laptop with gddrescue, and it worked fine. But now, the process terminates immediately without doing anything:

GNU ddrescue 1.23
Press Ctrl-C to interrupt
     ipos:        0 B, non-trimmed:        0 B,  current rate:       0 B/s
     opos:        0 B, non-scraped:        0 B,  average rate:       0 B/s
non-tried:        0 B,  bad-sector:        0 B,    error rate:       0 B/s
  rescued:        0 B,   bad areas:        0,        run time:          0s
pct rescued:    0.00%, read errors:        0,  remaining time:         n/a
                              time since last successful read:         n/a
Finished

Questions

1. Is there something else I would need to do in order to access the data in a case like this?
2. Does what I'm seeing mean the drive might now be damaged? To be honest, one of the reasons I asked the shop to give it to me is that I started worrying that they might have been causing additional damage which is why they've been having delays/problems.
3. Is there a chance the enclosure itself is showing up as /dev/sda, but the actual drive is not being read at all?
4. Would there be a point trying to insert it into a different (compatible) PC, rather than trying to access from a USB enclosure?

Any help/suggestions appreciated.

P.S.: The most obvious comment would be: "why don't you just get the data from the backups you've mentioned". Unfortunately, I've lost the most recent backups of the drive, and the ones I do have are missing a lot of valuable information/work.

Is there a situation where a newly-added repository would need to install "dependency" packages before being asked to install anything new?

I just came across the following situation:

While my system was up-to-date, I added the Certbot repository (http://ppa.launchpad.net/certbot/certbot/ubuntu), and after running an update, nine packages were reported to be upgradable. I tried to do an upgrade and got the following:

$ sudo aptitude safe-upgrade
Resolving dependencies...                
The following NEW packages will be installed:
  python3-certifi{a} python3-idna{a} 
The following packages will be upgraded:
  python-chardet python-pkg-resources python-six python3-chardet python3-configobj python3-pkg-resources python3-requests python3-six python3-urllib3 
9 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 906 kB of archives. After unpacking 1,183 kB will be used.

I can understand packages being upgraded: the new repository has newer versions of packages already installed on my system, so they're marked for upgrade. But why is it trying to install new packages? The packages in question certainly seem relevant to the software on the repository, but why would they be installed automatically?

If they are a dependency for something on my system, how was it working before? How can I investigate exactly what's going on?

UPDATE

I checked the reverse dependencies with apt-cache; e.g.,

$ sudo apt-cache rdepends python3-certifi
python3-certifi
Reverse Depends:
python3-requests

With the Certbot repository disabled, I get

$ apt-cache depends python3-requests
python3-requests
Depends: python3-urllib3
Depends: <python3:any>
    python3:i386
    python3
Depends: ca-certificates
Depends: python3-chardet
Depends: python3-urllib3

and when I enable it, I get

$ apt-cache depends python3-requests
python3-requests
Depends: python3-certifi
Depends: python3-chardet
Depends: python3-idna
Depends: python3-urllib3
Depends: <python3:any>
    python3:i386
    python3
Depends: ca-certificates
Depends: python3-urllib3

So, I guess, the real question becomes: are package dependencies a function of available packages/repositories? I thought dependencies should be fixed: a package either requires another package to work (whether it is available to you or not) or it doesn't (in which case, it's not really a dependency).

System:

• Kubuntu 16.04
• Kernel 4.13.0-45-generic #50~16.04.1-Ubuntu 64-bit

I've seen a few questions about linux-headers packages but couldn't find anything to address my specific issue.

I'm on Kubuntu 16.04, and I got the following error (from VirtualBox):

Please install the Linux kernel "header" files matching the current kernel for adding new hardware support to the system. The distribution packages containing the headers are probably:

linux-headers-generic linux-headers-4.13.0-43-generic

I was surprised to see that linux-headers-generic was not installed, although I'm not really sure if it's supposed to be there by default.

In any case, while the kernel is 4.13.0-43-generic, the corresponding headers are, indeed, not installed:

$ uname -r
4.13.0-43-generic

$ aptitude search  linux-headers | grep  ^i
id  linux-headers-4.13.0-32         - Header files related to Linux kernel versi
id  linux-headers-4.13.0-32-generic - Linux kernel headers for version 4.13.0 on
i A linux-headers-4.13.0-37         - Header files related to Linux kernel versi
i A linux-headers-4.13.0-37-generic - Linux kernel headers for version 4.13.0 on
i A linux-headers-4.13.0-38         - Header files related to Linux kernel versi
i A linux-headers-4.13.0-38-generic - Linux kernel headers for version 4.13.0 on
i A linux-headers-4.13.0-39         - Header files related to Linux kernel versi
i A linux-headers-4.13.0-39-generic - Linux kernel headers for version 4.13.0 on

The linux-headers-generic "will always depend on the latest generic kernel headers available", so I thought that installing it would install the latest packages (in this case, linux-headers-4.13.0-43-generic as required by VirtualBox) and keep them up to date.

However, if I try that, I'm asked to install what appear to be really old packages:

$ sudo aptitude install linux-headers-generic
The following NEW packages will be installed:
linux-headers-4.4.0-127{a} linux-headers-4.4.0-127-generic{a} linux-headers-generic 
0 packages upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 10.8 MB of archives. After unpacking 78.4 MB will be used.

There's also a package called linux-headers-generic-lts-xenial, but it does, more or less, the same thing.

So, my questions:

• Should either of the linux-headers-generic packages have been there by default? Which one?
• Do I need to install either of them in my case?
• If I install the necessary linux-headers-4.13.0-43-generic package directly, what happens when the kernel is upgraded?

I have a camera that names files with hexadecimal digits (not sure why, but that's a different question). When I download the files to my Kubuntu PC and open the directory with Dolphin, the order is "unexpected".

For example, let's say I have the following files (extensions dropped for simplicity) created by the camera in this order:

• mov001
• mov002
• mov00A
• mov010
• mov01A

Dolphin sorts them out as such:

• mov00A
• mov001
• mov01A
• mov002
• mov010

I find this very strange; e.g., why would mov002 or mov010 come after mov01A?

On the other hand, if I do ls in Bash, they appear in the expected order.

What confused me even further is that Dolphin will make the following sorting choices:

• 1 (literally, a file named just "1")
• 2
• A

but

• 00A
• 001
• 002

So, how does sorting work exactly?

System:

• KDE Plasma 5.5.5
• Qt 5.5.1
• Kernel 4.13.0-41-generic #46~16.04.1-Ubuntu x86_64 GNU/Linux

I am trying to install a driver for my Brother printer/scanner (DCP-9020CDW). Brother provides Linux drivers (printer drivers are libre; scanner drivers are not). One of the requirements before installing is to run

$sudo aa-complain cupsd

which, according to the manual, means that "security policy is not enforced but rather access violations are logged to the system log".

Asking to disable security policies before installing new packages/drivers from outside the official repositories sounds suspicious to me. Am I being too paranoid, and is there anything sensible I can do apart from just not using my scanner*?

*There's an open-source PPD file for the printer, though I haven't tried installing it yet.

I'm using Kubuntu 16.04 (xenial) on a laptop with an ELAN Touchscreen together with a DELL 750-AAHC active stylus. One of the buttons on the stylus behaves as a mouse middle-button, and I want it to be a right button instead.

I can achieve this by doing

$ xinput set-button-map "ELAN Touchscreen Pen" 1 3 2

(i.e., mapping the function of button 3, which must correspond to the right button, to physical button 2).

This does what I want, but the change is not permanent.

I added the command in ~/.xsessionrc (according to the answer on this post), so it's run automatically when I reboot, but the button mapping "randomly" reverts to default on its own: it's working as expected for a while, and suddenly I discover that it doesn't, so I get

$ xinput get-button-map "ELAN Touchscreen Pen"
1 2 3 4 5

and I have to remap it manually.

I tried a few "suspect" things to see what might be responsible for reverting, but I couldn't figure it out. It's not caused by

• suspending the laptop or turning off the screen
• rotating the screen (this was suspect because xinput is used on rotation to transform the input matrix.)
• toggling touchscreen, touchpad or stylus input on/off (also with xinput).

IMPORTANT UPDATE:

I've discovered that this problem is not specific to the stylus: I disabled the finger-touch capability of the screen ("ELAN Touchscreen") earlier for some reason by doing:

$ xinput disable "ELAN Touchscreen"

and I just discovered that it came back on its own (and the stylus right-click had again reverted). So it seems like all xinput changes revert to default for this unknown reason.

UPDATE 2

I found some suspicious entries in /var/log/syslog when this happened again. The timestamps were during a time I had not actually been using the laptop for some time, so energy-saving features were probably activated (I have "dim screen" at 9 mins and "switch off" at 10 mins; I will experiment with energy saving and update accordingly).

The pattern bellow is actually repeated many times, with only a few seconds difference between each block.

usb 1-8: USB disconnect, device number 18
usb 1-8: new full-speed USB device number 19 using xhci_hcd
usb 1-8: New USB device found, idVendor=04f3, idProduct=2073
usb 1-8: New USB device strings: Mfr=4, Product=14, SerialNumber=0
usb 1-8: Product: Touchscreen
usb 1-8: Manufacturer: ELAN
input: ELAN Touchscreen Pen as /devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:04F3:2073.04EE/input/input7548
input: ELAN Touchscreen as /devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:04F3:2073.04EE/input/input7549
input: ELAN Touchscreen Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:04F3:2073.04EE/input/input7552
hid-multitouch 0003:04F3:2073.04EE: input,hiddev0,hidraw0: USB HID v1.10 Keyboard [ELAN Touchscreen] on usb-0000:00:14.0-8/input0

In each block, almost everything is the same except a few numbers that increase. Here's the next block for comparison:

usb 1-8: USB disconnect, device number 19
usb 1-8: new full-speed USB device number 20 using xhci_hcd
usb 1-8: New USB device found, idVendor=04f3, idProduct=2073
usb 1-8: New USB device strings: Mfr=4, Product=14, SerialNumber=0
usb 1-8: Product: Touchscreen
usb 1-8: Manufacturer: ELAN
input: ELAN Touchscreen Pen as /devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:04F3:2073.04EF/input/input7554
input: ELAN Touchscreen as /devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:04F3:2073.04EF/input/input7555
input: ELAN Touchscreen Keyboard as /devices/pci0000:00/0000:00:14.0/usb1/1-8/1-8:1.0/0003:04F3:2073.04EF/input/input7558
hid-mul itouch 0003:04F3:2073.04EF: input,hiddev0,hidraw0: USB HID v1.10 Keyboard [ELAN Touchscreen] on usb-0000:00:14.0-8/input0

The device numbers wrap around at 128.

System:

• KDE Plasma 5.5.5
• Qt 5.5.1
• Kernel 4.13.0-32-generic #35~16.04.1-Ubuntu 64-bit

• xinput version 1.6.2

  XI version on server: 2.3

• X.Org X Server 1.19.5

  Release Date: 2017-10-12

  X Protocol Version 11, Revision 0

I booted my laptop with a Kubuntu 16.04 live USB and used KDE Partition Manager (version 1.2.1) to look at the internal HDD (/dev/sda). The main partition (/dev/sda3, ext4) was 442.91 GiB and Partition Manager reported that 41.29 GiB was used.

I then used KDE Partition Manager to shrink sda3 to 45 GiB. After shrinking was successfully completed (no errors reported), KDE Partition Manager reported that 35.03 GiB was used. The data on the partition shouldn't have changed, so how did this happen?

A (not particularly informed) guess of mine would be that Partition Manager was actually giving me an "estimate" of used space which improved after thge e shrinking operation; i.e., the actual data was always closer to 35 GiB. Or maybe a lot of data in the trash or temporary folders was removed. But that's still a big difference (about 20 percent), so I was wondering if anybody has seen this before or actually knows why this happens / should be expected.

Update: The laptop seems to be booting up and working fine after shrinking. This is no proof, of course, but there are no indications of data loss.

Update 2: The number of used inodes are the same between shrunk and unshrunk, and a checksum comparison of all files shows no differences, so I'm even more confident that there has been no data loss, which was the main practical concern. The question is still open but is more academic at this point.

I recently installed Kubuntu 16.04 (KDE 5 Plasma) on a new PC and have been doing a lot of customisations, and I just noticed that the F2 shortcut for renaming files is not working on the desktop. It's still working in Dolphin.

Interestingly, the context menu for a file in Dolphin shows "Rename... F2", but on the Desktop, it just says "Rename" (no shortcut). The permissions are fine (755), and in fact, if I open the Desktop folder through Dolphin, F2 renaming works.

I thought it's probably some setting I messed up and I would easily find an answer on the Web, but I can't find anything useful/relevant (including this on askubuntu).

• Widgets and icons on the desktop are unlocked.
• Folder View Settings (from Desktop context menu) > Location is set to "Show the Desktop folder".
• I've searched through Global, Application and Custom shortcuts in case F2 was set to something conflicting but couldn't find anything (again, it works in Dolphin).
• I've tried tweaking other things (such as changing Wallpaper Type from Haenau to plain colour), but nothings seems to have an effect.

I'm listing random things right now because I cannot think what could possibly be the cause of this. Any ideas would be greatly appreciated.

System:

• KDE Plasma 5.5.5
• Qt 5.5.1
• Kernel 4.13.0-32-generic #35~16.04.1-Ubuntu 64-bit