-
-
-
I expect this should be possible. It probably shows as /dev/mmcblk… something and we’ve got a couple of devices in the house that have swap on a mmcblk device, though only the Raspberry Pi one is removable.
However, I often find that slotted mmcblk speeds are rather lower than they “should” be… in many computers the card slot is just slow, and reliability problems are common too, either of which would severely hinder using it for swap. Though I suppose if there ever was a brand name that I’d expect good SD-slot performance from, Sony would be it.
Also the filesystem type of your SD card might be meaningful. Swap to a file on ExFAT or NTFS might not work, and old-style FAT has that file size limit… Linux has no problems with partitions on SD cards so, depends on if you want to use that card with other systems too? I’d probably use a swap partition if not.
1 user thanked author for this post.
-
-
-
-
-
We have also tried to delete the folders from our email providers web site with no luck.
This looks like a possible server-side issue, then.
Could be a server bug, a configuration error (permissions), or a particularly weird “feature”. Seen all three.
May need to talk to the server admins (as in your mail provider’s backend technical folks) to get it fixed.
1 user thanked author for this post.
-
How much of that is related to secure boot?
Oh, that was all without going into the Secure Boot hassle at all.
Which is another apparently good idea but the implementation leaves a lot to be desired.
-
There’s an overview at the usual place – Wikipedia. https://en.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface
Then there’s a security / threat analysis paper over at https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI%20with%20Linux.pdf that refers to several of the details. (Along with SMM and Management Engine issues.)
-
(digressing on to UEFI)
How exactly is it unforgiving?
Essentially, it’s just too complex to unscramble if something unexpected happens to it.
Well, first there’s the UEFI non-volatile memory… which is essentially opaque and once something gets there, removing it can be very difficult. And aside from exploits, even honest errors have the capability of essentially making UEFI fail to run itself.
So yeah, a random device driver updater probably has the capability to permanently brick UEFI-enabled motherboards.
Then there’s all the extensions loaded from elsewhere… like the system partition on disk… which can become resident in memory and change important things in the system. Failure to copy one of those when replacing a disk is one place where hard-to-trace issues can come from. Also this can happen when disks are just reordered if you have multiple with EFI partitions, and this in turn can happen when motherboard firmware changes…
And then there’s the actual boot process itself. Any number of devices have a nonstandard UEFI boot process, so using the UEFI standard interfaces to set your boot path is not reliable. And again this is firmware version dependent and can also be permanently changed in non-volatile memory by device driver installers…
So yeah. Any number of possible situations that can only be fixed by reflashing your motherboard’s non-volatile memory in an external device and wiping the EFI system partitions on any disks, and that in turn may also cause things to break. Anyone want to count how many current motherboards have that chip socketed versus soldered in, anyway?
And then there’s all the gymnastics you have to do to make boot from software RAID work in a sane way on UEFI. What usually happens is that you rely on nonstandard manufacturer-specific firmware and drivers to work with that (making it a “fakeraid”), and that in turn is vulnerable to incompatible updates in the boot code that go in the ESP… was a spectacular self-wipe on that one server once. (Windows Server 2016, if anyone’s interested.)
1 user thanked author for this post.
-
-
-
-
Author
