This problemis finally fixed on KDE.

The biggest UX issue, in KDE in particular (though they made some improvements recently), is that a copy process will say it's complete (with a notification), but you could be waiting several seconds or minutes before it's actually done syncing

The sync command will block until it's done so you will know for sure. I believe ejecting the drive will sync before it reports success also.

In my experience, simply waiting for the activity light to stop flashing is a good enough indication, but not all drives have one.

I suppose some filesystems might be slightly faster to write to thus reducing the time it takes for the data to actually end up on the physical device, but while some filesystems are better equipped to gracefully handle the consequences of an interruption, none of them can fix data that doesn't exist because the drive was physically removed whilst being written to.

Always sync before ejecting a removable drive.

I have definitly corrupted data doing that. I wonder if filesystem matters at all. I usually use f2fs for flash drives.

I never had an issue with my card reader and I use Fedora. Did you have a card in the reader? Since Linux doesn't have "drives" like in Windows, it may look like there's nothing there until you plug one in

One word of caution: it is really important that you eject (unmount) the card if you write to it. Linux is more aggressive about buffering writes so you will lose data if you don't.

tried to upgrade from Fedora 44 and the system wouldn't boot because it couldn't find the boot drive. I suspect it's an issue relating to LUKS, but I've rolled back to 44 for now.

In addition to tal's excellent advice, you might also want to open a terminal and run:

journalctl -f

Before you plug in the reader. Might give you some hints as to what the exact problem is.

did not pick up

In what sense?

Like, if you do something like:

$ lsusb > not-in.txt

Then plug it in (I'd have the SD card in, but I don't think that it'd likely matter at the USB level) and do:

$ lsusb > in.txt

And then do:

$ diff -u not-in.txt in.txt

No differences show up?

If the host can talk to the USB drive, then I'd expect it to show up there.

EDIT: If it shows up there, then I'd think that the machine is talking to the device at a USB level. To see whether the host can see the block device corresponding to the SD card, I'd do the same with lsblk (for this one, the SD card probably has to be in the reader):

$ lsblk > not-in-blk.txt

Insert the USB reader into the machine.

$ lsblk > in-blk.txt

And then:

$ diff -u not-in-blk.txt in-blk.txt

If it can see that, then it can see the block device with the data on it, the card. The filesystem or something like that might be corrupt or something, but should still show up at that level.

EDIT2: If the above works and you're wanting KDE Plasma to pop up a window when you plug the thing or something and that's not happening and that's what's you're concerned about that...I don't use KDE Plasma, so I've no idea what expected behavior is there. Maybe someone who uses it could tell you. I imagine that it has some kind of filesystem browser and it's probably visible somewhere there, but...shrugs

In a plain-Jane Linux sense, if you have a block device, you'll probably have one block device, and maybe it'll be partitioned and have smaller block devices for each partition. Maybe /dev/sdb for the main device or something and /dev/sdb1 for the partition. If you can see the block device for the partition (like, you can see it appear and disappear when running lsblk when you plug in and unplug the device), you can mount the block device in the traditional Linux way (with the correct block device where I'm using /dev/sdb1 below):

$ sudo mkdir /mnt/sdcard
$ sudo mount /dev/sdb1 /mnt/sdcard

And then before you unplug it:

$ sudo umount /mnt/sdcard

That'll be independent of any GUI filebrowser or whatever.

The best part:

To facilitate and encourage the particiation of our friends at the BSDs and other Free Software operating systems, we endeavoured to licence as much of our code as possible under the permissive MIT licence.

Unfortunately, this is no longer viable. The malicious practices of the 90s and 2000s have reared their ugly heads once again, this time driven in large part by both the insatiable appetite of frontier AI labs for high-quality training data, and militant animosity toward the Free Software community.

Some time ago, we were made aware of multiple attempts to exploit our permissive licensing to hijack our work, with a direct view to replacing the project and aggressively monetising Linux on Apple Silicon. In some extreme cases, in-development feature code was being lifted straight out of our personal forks and published without attribution or lazily rewritten with LLM assistance to obfuscate its origin. The MIT licence explicitly allows this, and has no carveouts to protect against bad faith actors.

As such, we made the difficult decision to begin the process of transitioning all of our repositories to the GNU General Public License version 2 or later. Going forward all Asahi Linux code will be licenced under strong copyleft licences only. Those who do not learn from history are doomed to repeat it.

I hope more software projects learn from this. What did you expect?

I don't have apple hw (and chances are, I never will), but I'm always happy to hear about Asahi progress.

Too short. I use that to issue a random key long enough to log into SSH.

Very carefully :)

I'm using his birthday, not my own

You were born on day 4?

The Docker Hub base image for Alpine has more than 1 billion downloads.

Okay sure... but most docker images that are using alpine aren't running an ssh server inside that alpine container. I can't say it's zero, because I'm sure someone is doing crazy somewhere, but I bet it's very close to zero.

The non-docker deployments are more legitimate targets, but this number here is basically useless for actual vulnerability, in my opinion.

My password is 4, will I be okay?

I am using the 6th of July, if you are using it American date convention it would still be the same: 06071996

There must be dozens of us using June 7th!

so keys yes, and passwords no still good?

Funny coincidence, I'm also using your birthday as a password!

Second, the target system account must be configured to be passwordless

Finally it pays off to use my birthday as password

It made it possible, it didn’t solve the “pain in the ass“ part

If I was gonna go that route, I would start by trying to switch my entire stack over to podman in the first place. But I don’t even know if that’s possible.

As I said, I’m happy with my current set up

Toolbox solved that.