eselarm

Sounds a bit like with My ROCK3A. Bought it last yer and with a SATA breakout board. That breakout board was a newer HW version with a but flatter and simpler (and cheaper of course) SATA connector, such that I could get a SATA cable connected as the MIPI DSI conector was in the way, just slightly too high. So for the 3 euros that it costed I thought, time to warm up the soldering iron and lift it a bit so a SATA cable fits. Radxa apologized and I think the idea was that I would get some new SATA thingy or so for free. Yeah right, trust is gone. That proved a second time as they did not take any further initiative. For example how do they think they can reach me (being at the at the other side of the world). Also now that combination is is just removed from the products page. Indeed they sell now own ASM1166 M.2 M-key modules, of course at a higher price that the generic ones on Aliexpress. No surprise form a Chinese a company, they just throw new boards on the market and hope someone will be their guinea-pig.
 
Also your ROCK4C (non-plus) is not listed anymore. Also note it has no PCIE, so my guess is it uses some USB3 connection. I personally avoid it like a plague. Maybe it can save you in this case, maybe try to get a schematics of the PCB, then the whole thing might work with the HAT off and just GND+5V with own soldering/wiring. Else sell it befor it is too late. That is what  also have advised a RPi5 + SATA HAT user who had trouble. As separate components, loss it not too big maybe. My ROCK3A+breakout board was 40 euros, great for replacing old PC for 1 SATA HDD. 
 
That those HATs are covering all GPIO, I know, that is why I never will buy a HAT again, also not a Raspberry I think who 'invented' it. I soldered extra wires on top. In your case I would solder the USB console cable on the underside, drop of hotglue and done. Faster than I can write this message. Or else look for a PUKE (Peripheral Under Kernel Environment module that is meant for debugging low-level U-Boot and kernel issues).

I think there is something wrong with the whole chain from 'computer-RAM down to SD-card itself'. I state it like this because there can be many points where the root-cause is.
An issue like this I have seen several times before, and I think I also have had it myself, but was several years ago. /dev/sdc means you use some USB attached mmc, so even if sequential reads and writes work fine, certain pseudo random scattered small blocks can maybe hit some corner-case in the whole Linux I/O in combination with out-of-spec hardware; can be power issue internally in the SD-card adapter, anything.  Also the SD-card itself might do very strange things internally, you don't know, it is some micro-controller firmware. Even if not counterfeit or just fake. Check CID and/or post here maybe.
 
So to avoid at least USB adapter issues, I have used my RPI4 that runs from USB3-SATA SSD  as SD-card reader/writer for images for for example a nanopineo. So then in the RPi4 , it is /dev/mmcblk0 you operate on. My NanoPi-R6C runs from eMMC+NVME, so also there /dev/mmcblk0 is free to use for image writing. Advantage is also that those SBC native slots do support trim, so to also internally wipe SD-card I do 'sudo blkdiscard /dev/mmcblk0' sometimes first, than all is fast and freely available. This command actually failed on some details for some SD-card brand when in ROCK3A SD-card slot for some kernel version. Also A2 SD-card and faulty queuing can randomly corrupt things.
 

What is easiest depends on the situation. If you feel comfortable enough to use dd to write bootloader, I just downloaded the -edge package from the beta apt package pool, extracted the .bin file and wrote it to correct location on SD-card, after saving the first 32k sectors also with dd to a backupfile. Then reboot and you know it. The qemu experiment was to boot directly from U-Boot to Btrfs raid1 filesystem, it took a lot of time browing through U-Boot config/compile options.
Better/formal method is to install -edge package, it will remove -current package, then use armbian-config to write the bootloader explicitly.

sudo apt-mark hold linux-image-vendor-rk35xx
sudo apt-mark hold linux-dtb-vendor-rk35xx

I never used Ext4 directly on a whole block device. Linux in general assumes partitions.  Advice is to use partitions. So create one first wit fdisk.

Knowing this means your options are to return the case+NVMe back to shop. Or do a cross-check; case with other NVME and NVME in M.2 slot of some other computer.
But this is a typical Raspberry problem; storage via USB (SATA or NVME nowadays) easily leads to trouble. Mostly power related, but also many just the chipset in the adaptor. In case of Pi5, you could get an NVMe adaptor board, but also that is not always working out-of-the box. Only if you buy RPi adaptor and RPI NVME it should work out-of-the-box. Or other SBC that has M.2 slot already on the board. 

it all depends on what your plan is what the device should do; I have a R6C for about 18 months now and bought it as an alternative/better more integrated alternative for existing RPi4 (and also RPi5 that still has no M.2 socket). I see many people on for example RPi forum who want to create some router thing, so they buy HATs and USB stuff for an RPi, but this NanoPi series has even WRT preinstalled. I removed it as I wanted generic server box (virtual machines host mainly). I do not really need the 2x RJ45 currenlty, but the metal case is great.  Is simple passive cooling and insect/animal proof. It is mainly bootloader and kernel (and DTB/overlays) that matter. The userspace can be taken from elsewhere if you know how to. I currently use the R6C as desktop as well in another cooler room (summer hot here). EDK2-UEFI v1.1 bootloader, Armbian edge 6.16-rc3 kernel, Opensuse Tumbleweed for Btrfs rootfs to drive a DVI monitor KDE plasma 6.4.x. It means various Rockchips HW blocks do not work like NPU and video codecs HW accel block, but that is a choice. If you need those, use vendor kernel and see what exctly you need/want. The 2x RJ45 might be a chalenge, see maybe also: 
 

check those files
/usr/lib/systemd/system/armbian-resize-filesystem.service
/usr/lib/armbian/armbian-resize-filesystem
 

OK, as I thought, not enough 'headroom'
 
rock5b:/local/ssdata/nocow # btrfs inspect-internal list-chunks 2 btrfs inspect-internal list-chunks 2 Devid PNumber Type/profile PStart Length PEnd LNumber LStart Usage% ----- ------- ----------------- -------- --------- -------- ------- -------- ------ 1 1 System/single 1.00MiB 4.00MiB 5.00MiB 4 2.30GiB 0.39 1 2 Metadata/single 5.00MiB 8.00MiB 13.00MiB 1 5.00MiB 35.74 1 3 Data/single 13.00MiB 8.00MiB 21.00MiB 2 13.00MiB 100.00 1 4 Data/single 21.00MiB 1.00GiB 1.02GiB 3 21.00MiB 53.20 1 5 Metadata/single 1.02GiB 208.00MiB 1.22GiB 5 2.31GiB 23.51 1 6 Data/single 1.22GiB 512.00MiB 1.72GiB 6 2.51GiB 84.35 1 7 Data/single 1.72GiB 512.00MiB 2.22GiB 7 3.01GiB 86.48 1 8 Metadata/single 2.22GiB 256.00MiB 2.47GiB 8 3.51GiB 33.67 1 9 Metadata/single 2.47GiB 256.00MiB 2.72GiB 9 3.76GiB 14.43 1 10 Data/single 2.72GiB 1.00GiB 3.72GiB 10 4.01GiB 83.88 1 11 Data/single 3.72GiB 1.00GiB 4.72GiB 11 5.01GiB 97.23 1 12 Data/single 4.72GiB 1.00GiB 5.72GiB 12 6.01GiB 55.02 1 13 Data/single 5.72GiB 1.00GiB 6.72GiB 13 7.01GiB 85.21 1 14 Data/single 6.72GiB 1.00GiB 7.72GiB 14 8.01GiB 58.04 1 15 Data/single 7.72GiB 1.00GiB 8.72GiB 15 9.01GiB 82.03 1 16 Data/single 8.72GiB 1.00GiB 9.72GiB 16 10.01GiB 28.15 1 17 Metadata/single 9.72GiB 256.00MiB 9.97GiB 17 11.01GiB 10.30 1 18 Data/single 9.97GiB 1.00GiB 10.97GiB 18 11.26GiB 99.83 1 19 Metadata/single 10.97GiB 256.00MiB 11.22GiB 19 12.26GiB 0.58 1 20 Metadata/single 11.22GiB 256.00MiB 11.47GiB 20 12.51GiB 5.22 1 21 Metadata/single 11.47GiB 256.00MiB 11.72GiB 21 12.76GiB 0.49 1 22 Metadata/single 11.72GiB 256.00MiB 11.97GiB 22 13.01GiB 0.27 1 23 Metadata/single 11.97GiB 27.00MiB 12.00GiB 23 13.26GiB 0.06 Then doing various balance actions, then again replace action, see result below:
[334356.515225] [ T207531] BTRFS info (device loop0p2): balance: start -mlimit=3 -slimit=3 [334356.516261] [ T207531] BTRFS info (device loop0p2): relocating block group 14236516352 flags metadata [334356.608520] [ T207531] BTRFS info (device loop0p2): found 1 extents, stage: move data extents [334356.655369] [ T207531] BTRFS info (device loop0p2): relocating block group 13968080896 flags metadata [334356.882397] [ T207531] BTRFS info (device loop0p2): found 44 extents, stage: move data extents [334356.974962] [ T207531] BTRFS info (device loop0p2): relocating block group 13699645440 flags metadata [334357.145812] [ T207531] BTRFS info (device loop0p2): found 77 extents, stage: move data extents [334357.223337] [ T207531] BTRFS info (device loop0p2): balance: ended with status: 0 [334402.346978] [ T207580] BTRFS info (device loop0p2): balance: start -mlimit=6 -slimit=6 [334402.347912] [ T207580] BTRFS info (device loop0p2): relocating block group 13431209984 flags metadata [334403.120645] [ T207580] BTRFS info (device loop0p2): found 841 extents, stage: move data extents [334403.372968] [ T207580] BTRFS info (device loop0p2): relocating block group 13162774528 flags metadata [334403.613848] [ T207580] BTRFS info (device loop0p2): found 94 extents, stage: move data extents [334403.743610] [ T207580] BTRFS info (device loop0p2): relocating block group 11820597248 flags metadata [334404.526435] [ T207580] BTRFS info (device loop0p2): found 1666 extents, stage: move data extents [334404.798554] [ T207580] BTRFS info (device loop0p2): relocating block group 4035969024 flags metadata [334406.059117] [ T207580] BTRFS info (device loop0p2): found 2363 extents, stage: move data extents [334406.374011] [ T207580] BTRFS info (device loop0p2): relocating block group 3767533568 flags metadata [334407.879438] [ T207580] BTRFS info (device loop0p2): found 5433 extents, stage: move data extents [334408.284506] [ T207580] BTRFS info (device loop0p2): relocating block group 2475687936 flags metadata [334413.884083] [ T207580] BTRFS info (device loop0p2): found 9463 extents, stage: move data extents [334414.690177] [ T207580] BTRFS info (device loop0p2): balance: ended with status: 0 [334530.694011] [ T207693] BTRFS info (device loop0p2): balance: start -dlimit=2 [334530.694839] [ T207693] BTRFS info (device loop0p2): relocating block group 12089032704 flags data [334534.205097] [ T207693] BTRFS info (device loop0p2): found 1897 extents, stage: move data extents [334534.491352] [ T207693] BTRFS info (device loop0p2): found 1897 extents, stage: update data pointers [334534.625126] [ T207693] BTRFS info (device loop0p2): relocating block group 10746855424 flags data [334536.605759] [ T207693] BTRFS info (device loop0p2): found 16316 extents, stage: move data extents [334537.056028] [ T207693] BTRFS info (device loop0p2): found 16316 extents, stage: update data pointers [334537.361629] [ T207693] BTRFS info (device loop0p2): balance: ended with status: 0 [334614.951029] [ T207803] BTRFS info (device loop0p2): dev_replace from /dev/loop0p2 (devid 1) to /dev/loop1p2 started [334654.572435] [ T207803] BTRFS info (device loop0p2): dev_replace from /dev/loop0p2 (devid 1) to /dev/loop1p2 finished So  I would need to do the same with vendor kernel on same images, I made exact copies, so can be done, however starting with vendor kernel requires system reboot (and other bootloader), so not sure when I can do this. 

You could run:
sudo apt list | grep linux-image
Besides the vanilla Debian/Ubuntu ones, there are Armbian ones: vendor, current, edge
 
In your case your installed U-Boot might be incompatible with kernel 6.1.84, I had that for my Rock3A, I installed mainline U-Boot.
 
If you want all kernels, use http://beta.armbian.com in /etc/apt/sources.list.d/armbian.list

Or build yourself from source. The Armbian build runs fine on my NanoPi-R6C Armbian Bookworm

I found the reason for the crash:  the 6.1.84-vendor-rk35xx doesn't work together with the 2024.10 mainline U-boot.
 
Earlier the SPI-flash was empty and the Rock3a booted from SD-card, a U-boot version from 2017 (Armbian_24.11.1_Rock-3a_noble_current_6.6.62-kisak.img.xz). I put that image in 'beta' mode so I got the 6.1.84-vendor-rk35xx (+ rock-3a-sata.dtbo). That all still worked.
I then put the 2024.10 mainline U-boot in SPI and wiped the sector range 34-32767 from the SD-card. Then I discovered that the 6.1.84-vendor-rk35xx always crashed, independent of SATA modules etc.
 
I now disabled the SPI and took sector range 34-32767 from the official Radxa image (rock-3a_debian_bullseye_cli_b25.img.xz) and put that on the SD-card with the Armbian Noble (latest beta channel trunk.201) and rebooted. That does not crash and works same as with 6.12.6-edge-rockchip64 that I used before the reboot to write the sector range 34-32767.
Version is:  latest-2023.07.02-3-b1eb2bde-gb1eb2bde (Aug 29 2023 - 10:43:04 +0000) 
 
So I guess I need to look at differences in uboot configs and likely also uboot sources.
 
The other thing is that If I want to be able to boot from a single SATA device with the Rockchip on-chip SATA, the uboot In the SPI-needs to default to SATA for M.2 E-key connector and not the default PCIe-2x1.
Or wait till I got an extra NVME to put in the M.2 M-key  connector and load rock-3a-sata.dtbo after uboot together with kernel. That is preferred I think looking at possible future use-cases.
 

I do not use quotas, so the fix for this issue is: https://github.com/openSUSE/snapper/issues/894#issuecomment-2054220427