Problems with 1Tb expansion card on FW16 running Ubuntu 24.04.1 LTS / BIOS 03.05

My FW16 laptop is freezing and has to be forcibly rebooted after a minute or two whenever I attempt to rsync -a my personal folder on my SSD to the 1Tb expansion card which I recently purchased. Both are formatted in Exfat format. The system logs errors are not consistent between such crashes, but “hub_ext_port_status failed (err = -110)”, “device not accepting address 6, error -62” and “reset full-speed USB device number 7 using xhci_hcd” have all occurred. This does not happen when I rsync a copy of the same folder hierarchy on my old 22.04 laptop. I have also tested the device itself pretty exhaustively on my old laptop by using the F3 (Fight Flash Fraud) software to fill the entire microsd with patterned files and verifying that they can all be read back without error.

From this I can only conclude that the latest 1Tb microsd expansion card is somehow incompatible with the USB drivers in Ubuntu 24.04.1 LTS and with BIOS 03.05, which FW officially supports. Has anyone out there encountered similar issues with microsd expansion cards from FW? Or any other USB storage devices?

Just for a point of comparison, I have the 1TB card on FW16 on firmware 03.05 with Ubuntu 22.04 and have had no issues with any sort of data transfers. I’ve also been able to boot Fedora directly from the 1TB card.

This would suggest, as you’ve eluded to, that the issue is isolated to Ubuntu 24.04 in some way.

Thank you for your comparison. For the record, I will also note that I messed with the disk format of the card in a big way before it started freezing my system. Specifically, I encrypted the whole device using veracrypt and created an exfat file system on the resulting (fuse) device. That gave a few read/write errors resulting in minor file system corruption upon doing the rsync, so I decided to reformat the (unencrypted physical) device as exfat and see if that worked. It was then that it started to freeze my system.

I have since read in a few places on the web that in general one should not reformat any microsd from its manufacturer’s original format (usually exfat these days) or it may slow it down. I guess in my case it’s possible that it did something worse than slowing it down, but this is frankly beyond my pay grade, so I’m returning the card.

Ah, yes. Veracrypt hails from the HDD era and, while it appears to have been updated for it, NAND storage types reserve a portion of the total flash storage actually inside the device to leave room for program/erase cycles (entire blocks must be rewritten even if only changing one bit inside), to replace failed blocks as they develop/wear leveling, for write performance by ensuring empty cells already exist to quickly accept new data, and even the controller’s firmware or the firmware’s performance tuning parameters for the NAND chips used in some cases! You may have vaporized some or all of that structure when you encrypted the bare flash if veracrypt didn’t recognize it as such, which would greatly degrade performance of the device and even cause the freeze issues you are experiencing (due to missing firmware parameters). Those params are unique to each manufacturer and NAND chip/size, so I suspect veracrypt has to maintain a DB of each controller’s expectations that needs updated for each new dev ID to prevent blowing all of that up on any given drive…or perhaps they don’t care that they do; I couldn’t find definitive answers in my cursory review of their rather limited documentation (very little on reverting from their format) and I don’t use it, myself. I just know I’ve ruined a few NAND devices over the years by neglecting to preserve the inherent overprovisioning structures and not having the utility specific to those devices to recover them properly.

I also suspect that the only way to fix it would be with a utility from the flash controller manufacturer, as is the case with most major brands of SSDs and the like (Samsung Magician, for example). Such a util would be able to erase the entire NAND and put back the original structure, including the performance-enhancing inherent overprovisioning and tuning parameters. Perhaps Framework Support can facilitate getting that utility to you (if it is even available to the public), since they would have a working relationship with the manufacturer for their product pipeline. Framework also sells “refurbished” flash devices now, which I suspect would require such a util to consistently wipe/reprovision and safely sell as refurb.

Thank you for your knowledgeable remarks. I guess the thing to do in the future, if I’m going to use veracrypt on a NAND device, is to fill it up with a big veracrypt container, which as far as the device is concerned is just one massive file on its native file system, rather than encrypting the device itself with veracrypt. While I was able to return the microsd, I unfortunately also encrypted the Western Digital SSD in my Frameworks laptop. So far, it hasn’t been giving me any problems like the microsd did, but now I’m starting to get nervous …

I wouldn’t worry as much about your WD NVMe, as you didn’t have a USB controller middleman muddying the waters when identifying that drive to the OS. Plus, if veracrypt is maintaining a DB for NAND devices, WD is almost certainly in it. I think WD still has a maintenance util for their drives to factory reformat - the only caveat being that the util is only available on Windows/OSX - but this does mean you should be able to revert the drive from veracrypt later, if you want.

Anyway, if the WD drive is performing fine, it’s probably okay.

@TheWebMachine
You write you’ve been booting from this drive. Is it booting up quickly enough to be usable for daily work? Maybe you can still guess how long it took, perhaps 30s or 60s …?

(thx for answers!)

You misunderstood. I have not been booting from anything but the main ext4 SSD in my frameworks laptop.

I have addressed @TheWebMachine , not you.
He wrote: “I’ve also been able to boot Fedora directly from the 1TB card.”.
I am interested in his experience.

Be nice, Khalid. You did hijack Timothy’s thread. :rofl::hugs:

I’ll give you two metrics for my F41 (K6.12) install:

Cold Boot - from grub to login screen = 16s
Hibernate Resume - grub to login w/32GB RAM = 29s

(Note that the resume time gives you an idea of disk performance because it is mostly a raw data decompression/copy operation from the drive to RAM.)

I have never ran Fedora on my internal NVMe, but my Ubuntu 22.04 install has the following metrics for a comparison:

Cold Boot - grub to login = 12s
Hibernate Resume - grub to login w32GB RAM = 23s

So, the performance is actually quite good for running an OS from the module. If you set the boot order in BIOS to the external first while it is installed, the BIOS remembers that preference between removals and reinsertions, allowing you to boot the NVMe by default without the module inserted and the module by default when it is installed.

Alright, we’ve highjacked this thread long enough. (I’d have split the thread if I had Mod privs; sorry, Timothy!) Feel free to open a new thread on OS performance or the expansion module, and I’ll happily hop on there to discuss further. :wink::wave:

1 Like

Thanks @TheWebMachine , and sorry @Timothy_Havel for stealing the thread here …

Actually, the metrics are quite impressive. I am going to get one of there 1 TB cards now.

:slight_smile:

1 Like