Linux file system woes

Upgraded to NVME via the Hackergadgets kit and AIOv2, thought I’d use my old 256Gb micro-sd boot card for my files, movies, music etc so that system backups would be smaller and go faster…

Issue 1… The rear 256Gb SD card is working after fighting to remove the Linux format (now fat32) yet file manager shows ‘SYSTEM VOLUME INFORMATION’ in the list of folders. How do I hide that or is it safe to delete ? (the option to move to trash is highlighted). ‘Show hidden files and folders’ doesn’t seem to affect it.

Issue 2… Booting from NVME, SD card in the rear slot. All fine so far. Yet when inserting a further SD card (via adaptor in the usb-a side socket) the eject icon only shows the rear SD card so I have to switch off to remove it !.

Issue 3… Backing up the 256Gb NVME card in a bootable format. I had been previously using ‘SD CARD COPIER’ in the Trixie image to create a bootable backup copy onto a 1Tb micro-sd in a USB-A adaptor. Now my movies etc have been moved to the rear SD card I hoped the SD card copy util would run faster, it doesn’t. Seems to be doing some kind of image copy, not format and file copy so no good for routine backups. Is there a faster yet simple alternative that will still boot ?

after fighting to remove the Linux format

Could you be more specific? Are you talking about the filesystem on the partition?

(now fat32) yet file manager shows ‘SYSTEM VOLUME INFORMATION’ in the list of folders

That’s an implementation detail of FAT32; I’m not sure if it’s necessary for the filesystem, but many applications add it, and re-add it if it’s deleted. Hiding it would mean using a file manager that doesn’t show it to you.

Yet when inserting a further SD card (via adaptor in the usb-a side socket) the eject icon only shows the rear SD card so I have to switch off to remove it !.

As a temporary solution, you can use the terminal: lsblk(8), mount(8), and umount(8). man mount will teach you what the command is, or here’s a tutorial about mounting and unmounting on Linux.

On Linux, SCSI drivers or emulation control most block devices, and in the device tree the nodes take the form /dev/sdX, where X is a letter starting at “a”. Because the first drive on a system is usually the internal drive, and SATA drives (currently the most common internal drive type for consumers) go through SCSI emulation, /dev/sda is usually assumed to be the root drive, but because on your system either /dev/mmcblk0 (the SD card) or /dev/nvme0n1 (the NVMe drive) is the actual root, and SCSI emulation still controls USB block devices, /dev/sda is used for your first USB drive, not internal drive, and so applications may falsely assume your first inserted USB drive is a non-removable drive, and won’t give you the option to remove it without configuring them to do so. This issue is common on Chromebooks with eMMC internal drives, which also become the node /dev/mmcblk0 (as SD and eMMC are both descendants of the MultiMediaCard or MMC). This is also why removing that USB drive without ejecting it, and then replugging it, “fixes” the problem; the drive wasn’t unmounted so the node /dev/sda isn’t removed, and on insertion it takes the next available node /dev/sdb.

I had been previously using ‘SD CARD COPIER’ in the Trixie image to create a bootable backup copy onto a 1Tb micro-sd in a USB-A adapter.

I could be mistaken, as it’s been a while, but I believe that utility is intended for classroom or enterprise applications to quickly clone Raspberry Pi root drives. A file transfer (or if moving large trees, rsync(1)) is usually a better option if preserving the structure and permissions of the file tree isn’t necessary.

Both I suppose, had issues getting my Windows10 pc ‘disk management’ to see the drive and also used ‘diskpart’ via a CMD window. Even tried using the windows Raspberry Pi imaging tool to erase the card and reformat as fat32 (failed). Eventually a combo of all worked in the end. My last sd card died completely after trying to revert to fat32. These kind of issues are common apparently…

As I told you last time you were trying to do filesystem work on Microsoft Windows:

Microsoft Windows after 41 years in development supports just a handful of filesystem types; Linux supports around ten times more despite being 9 years younger. Linux needs more advanced filesystems than can be used on Windows - and greatly benefits from journaling, which Windows supports only in strangely incompatible ways - so you really wouldn’t even want to use Linux filesystems from Windows if you somehow could in the first place. WSL is a notable exception.

Windows’ poor filesystem support is due primarily to the business not caring, because NTFS has been “good enough” for the last quarter century. Within the system it is due to the tools used for filesystem administration being woefully out of date and not very good to begin with. It is really like trying to mow a lawn with a chainsaw; technically you can do it some of the time, but if there’s some non-grass object Microsoft didn’t predict like a weed or baseball, dirt and wreckage will get strewn everywhere; Windows auto-mounts drives like a toddler putting everything in their mouth, so it immediately breaks Windows-incompatible NTFS and FAT filesystems if a user dares to put them within biting distance, and because its tooling can’t handle slightly unusual partitioning or filesystem tables, it often can’t even massage drives back into shape when it does bork them.

Issue 1… sorted. Just needed a ‘.’ (full stop) in front of the folder name then deselect ‘show hidden files’ in the file explorer. Will see what windows10 makes of it soon.

that’s just gonna make you end up with a hidden one and a new non hidden one when windows recreates it

No big deal as will sit in the Uconsole 98% of the time and can quickly be deleted/renamed. The other method of creating a ‘.hidden’ file with list of items to be hidden doesnt work with the file manager in Trixie…

It’s a windows thing so just deleting it should be fine

1 Like