Formatting SD Card ext4 partition fatal error

[rambo2_981]

I've an SD Card mounted on an Ubuntu 20.04.5 VM (Virtualbox Version 7.0.4 r154605 (Qt5.15.2)). I created two partitions on the SD Card; the first is vfat (the boot partition since this SD Card is intended for a Xilinx adapter), and the second is ext4 (the root filesystem). I've done this before in an earlier version of Virtualbox, but for some reason when I attempt to format the ext4 partition I get the following error and the VM freezes (the vfat partition formats fine and I can mount and write to it):

Code: Select all

The I/O cache encountered an error while updating data in medium "ahci-0-1" (rc=VERR_ACCESS_DENIED). Make sure there is enough free space on the disk and that the disk is working properly. Operation can be resumed afterwards.
Error ID:
BLKCACHE_IOERR
Severity:
Non-Fatal Error

When I inspect the SD Card on Windows with AOMEI, it shows both partitions and the second is listed as ext4 (partition type 0x83). I found other similar posts and have done the following:

Code: Select all

sudo chmod 666 /dev/sdb
sudo usermod -a -G disk $USER

When I restart the Ubuntu VM, and don't attempt to format it, I get the following when I try mounting it (it's obviously not formatted):

Code: Select all

sudo mount /dev/sdb2 ./media/sdb2
mount: /home/jramsey/media/sdb2: wrong fs type, bad option, bad superblock on /dev/sdb2, missing codepage or helper program, or other error.

Virtualbox is running as Administrator. Does anyone know what else needs to be done in order to get this ext4 partition formatted? By the way, when I was copying files to the vfat partition, I left this vfat partition mounted after copying two files and after a few minutes I got the same error.

[rambo2_981]

I tried it again with the latest version, Version 7.0.6 r155176 (Qt5.15.2), with the same results.

[rambo2_981]

I ran the following in an Admin PowerShell:

Code: Select all

DISKPART> attributes disk
Current Read-only State : No
Read-only  : No
Boot Disk  : No
Pagefile Disk  : No
Hibernation File Disk  : No
Crashdump Disk  : No
Clustered Disk  : No

DISKPART> attributes disk clear readonly

Disk attributes cleared successfully.

DISKPART> attributes disk
Current Read-only State : No
Read-only  : No
Boot Disk  : No
Pagefile Disk  : No
Hibernation File Disk  : No
Crashdump Disk  : No
Clustered Disk  : No

DISKPART>

Restarted the Ubuntu VM and creating the ext4 formatted partition worked. I cannot explain this as from the output above, it seemed as though the Read-only option was disabled even before the attribute was set.

Code: Select all

~$ sudo mkfs.ext4 /dev/sdb2
mke2fs 1.45.5 (07-Jan-2020)
Creating filesystem with 13007616 4k blocks and 3252224 inodes
Filesystem UUID: 580fdd3f-d775-48dd-a1ef-0a9867203473
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (65536 blocks): done
Writing superblocks and filesystem accounting information: done   

[rambo2_981]

This is still a problem and I'm not sure why this fatal error is occurring.

[scottgus1]

This one's way beyond me. How are you doing this:

I've an SD Card mounted on an Ubuntu 20.04.5 VM

[arQon]

This one's way beyond me. How are you doing this:

I've an SD Card mounted on an Ubuntu 20.04.5 VM

No idea, but the only sane scenario I can think of is a USB SD card adapter: I've used one to create / backup / restore SD cards for phones, tablets, and Pis on 1804, 2004, and 2204, and never had a problem with it. (It's especially useful for repairing the inevitable corruption of Pi SD cards every few months... )

I'm not entirely sure how it could go wrong though if so: you plug in the adapter, capture it, and that's it. I suspect either Random Windows Shenanigans or something iffy in 7.x, but since we don't even know what the host OS is that sort of guesswork is a waste of time right now.

[rambo2_981]

This one's way beyond me. How are you doing this:

I've an SD Card mounted on an Ubuntu 20.04.5 VM

No idea, but the only sane scenario I can think of is a USB SD card adapter: I've used one to create / backup / restore SD cards for phones, tablets, and Pis on 1804, 2004, and 2204, and never had a problem with it. (It's especially useful for repairing the inevitable corruption of Pi SD cards every few months... )

I'm not entirely sure how it could go wrong though if so: you plug in the adapter, capture it, and that's it. I suspect either Random Windows Shenanigans or something iffy in 7.x, but since we don't even know what the host OS is that sort of guesswork is a waste of time right now.

The host OS is Windows 11. I inserted the SD Card into the Dell XPS15 SD Card slot, and ran the following in a PowerShell as Administrator:

Code: Select all

wmic diskdrive list brief
Caption                        DeviceID            Model                          Partitions  Size
SDXC Card                      \\.\PHYSICALDRIVE2  SDXC Card                      2           64083156480

The drive listed for the SD Card was used to create a rawdisk with:

Code: Select all

cd "C:\Program Files\Oracle\VirtualBox\"
.\VBoxManage.exe createmedium disk --filename C:\sdcard.vmdk --format=VMDK --variant RawDisk --property RawDrive=\\.\PHYSICALDRIVE2

The drive was added to the VirtualBox VM configuration in Settings/Storage/Controller:SATA

Then, once Ubuntu 20.04.5 boots, the two partitions that are on the SD Card are available to mount at /dev/sdb1 and /dev/sdb2.

Note that this used to be stable before I upgraded to VirtualBox 7.0. Do you think a USB adapter for SD Cards would be a better solution?

[scottgus1]

this used to be stable before I upgraded to VirtualBox 7.0.

7.0 did have some changes to Raw Disk Access. A Bugtracker ticket might be in order, with a log from the failing 7.0 and a log from the working earlier version, each showing an attempt, failed or successful, to do what you're trying to do.

[arQon]

Do you think a USB adapter for SD Cards would be a better solution?

Absolutely. What you're doing to get to the same end result is using raw disk access to a host drive, which judging by a decade or so of posts here is something that roughly one user per year cares about. Passing a generic USB device through to a guest is functionality which (objections of a few local experts notwithstanding ) gets exercised at least several hundred times as often. I know which of the two I'd be more inclined to put my faith in, regardless of how terrible the USB spec is.

On top of that, you're running VBox itself as Admin solely because Windows won't let you *have* raw disk access otherwise. That's not exactly great either, not least because people often *think* they're running it as root when VBoxSVC is in fact running under their own account, which would cause exactly the error you're getting.

AFAICT, what you're doing shouldn't *not* work (assuming you actually are running as Admin, and your PS commands are right, which is outside of my area) but ISTM like this is the worse of the two options in multiple ways and by quite a large amount. Given the problems you're running into with something that you used to be able to get to work, right now that assessment is looking pretty reasonable, no?

If you're desperate enough, you could try passing your internal SD card to a gparted ISO and seeing what that says. At a minimum, it would let you see if W11 has botched the partition table in some weird way. fdisk would be helpful too, assuming you know how to use that. I think it's more likely that the problem is with your using raw disk access in the first place, but since you're currently going nowhere it would at least remove one set of potential causes from what is currently much too large a list. gl.

[mpack]

(objections of a few local experts notwithstanding )

Methinks that would be me. Generally I find that people often resort to USB without good reason, e.g. going for direct ownership of folders and printers when standard network shares are much easier and are purposely designed to solve such problems.

In this case however I agree that direct ownership of a USB SD card reader is likely to be the easiest solution, given that the raw disk solution is likely to leave you fighting permissions problems with whatever version of Windows you happen to be using this week. Also my experience is that Windows gets upset when you insert a host drive which has an alien filesystem on it. If the VM owns the USB SD reader then Windows will never see the SD card.

However... (this comment intended for future readers, not the OP): if the purpose of formatting the SD card is for (say) a Raspberry Pi or similar, then there are Windows host tools that will perform that task quite easily. No need for VMs or formatting in a separate step, just copy a ready-made image using Win32DiskImager.

[rambo2_981]

This effort is to build up the vfat and ext4 partitions required for a Petalinux build that boots on a Xilinx RFSoC Arm processor. The Petalinux kernel is built on an Ubuntu VM under Virtualbox. I agree, the process of using raw disk access and running Virtualbox as an Administrator is not optimal, but this did work in the past for building Petalinux SD Cards before I upgraded to Virtualbox 7. I bought an Uni USB C SD Card adapter and Ubuntu doesn’t recognize it. I’m going to dig into this to see what needs to be done before Ubuntu will recognize the USB. Thank you for the responses.

[arQon]

Methinks that would be me.

It would - and joking aside you're certainly not wrong, but this a fairly exceptional use case and (we agree) it would be unwise not to treat it as such.

Rather than write pages of advocacy, I'll offer a rule of thumb that people can take or leave as they see fit. If you're just moving files and file content from A to B, use a system designed to move files and file content. Once you start dealing with something as a block device, treat it uniquely as a block device.
Mixing the two takes you into expert territory, which is somewhere you really don't want to be unless you are one.

> Also my experience is that Windows gets upset when you insert a host drive which has an alien filesystem on it.

Ah, thank you: I knew I'd missed one.

> However... (this comment intended for future readers, not the OP): if the purpose of formatting the SD card is for (say) a Raspberry Pi or similar, then there are Windows host tools that will perform that task quite easily. No need for VMs or formatting in a separate step, just copy a ready-made image using Win32DiskImager.

Agreed, but there's a critical detail here I touched on in my original reply. Writing an image is fs-agnostic, i.e. it's just block use. Accessing - and especially, manipulating - the *content* of that image once written is an entirely different story, especially once you start bringing host/guest capabilities into it. While many users can indeed get by with just the first part, being able to do both has immense value, and a captured adapter really is the only sensible way for a normal user to handle this particular scenario.
(To take a recent real-world example, Ubuntu's Pi image is missing HW RNG support, but is recent enough to use the "new" unified /dev/(u)random. On a headless server it thus hangs at boot indefinitely, waiting for entropy that will never come from a mouse that is not attached).

Which, regrettably, brings us to OP's continuing problems, which have managed to go from "Well, it's Byzantine, but yeah, it should work" to "erm, what?!"
I've done my time in embedded. I drove to a store one afternoon to buy dozens of SD card adapters for almost this exact purpose years ago: no-name plastic USB 2.0 junk at about $3 a piece, distributed to five different development teams running at least four different OSes on a dozen different machines. All of which Just Worked, because that is literally the point of USB! :/

I think I'm rapidly becoming suspicious of this really being a VBox problem. I'm not running 7.x myself, but ISTM staggeringly unlikely that not only has your old approach ceased to work properly but you also can't interface with a trivial USB device. Not impossible, but not particularly credible at this point either. If I was in your position, it would be time to boot from an Ubuntu ISO (and/or even a different PC entirely) and start bisecting from there. Something here just doesn't smell right.