Ok, so the earlier two steps, which drive did you select for the “Transfer” page, and which did you select for the “Select storage drive” page?
transfer from the external 1.9 tb ssd and store on the 3.6 ssd
Ok, and what were the names of the two drives? Were they /dev/sdb and /dev/sda, or were they /dev/sda and /dev/nvme0n1?
I believe so , didn’t record that info
Those are two different scenarios. Can you repeat that step, and get the two specific device names. I need to understand which drive it is trying to write to when it gets that error.
I can retry the transfer again
BTW, do you happen to have a backup, just in case there is something wrong with the old drive? I don’t know why it would be trying to write to the old drive, so that worries me a bit.
Ok, I had to get my LLM to do a little digging to figure this out. Here is what it found after doing some web searches:
What the wizard does under the hood
- It unlocks the encrypted data partition on each drive (
/dev/sda4and/dev/nvme0n1p4). - It adds both partitions to the same volume-group (VG =
EMBASSY_MK…). - It runs
pvmove, which mirrors each extent from the source PV to the destination PV. While that mirror is active, LVM updates the VG metadata on every PV in the group each time it finishes a chunk. That means writes go to the old drive as well as the new one. Red Hat’s docs describe the mechanism: “pvmove… creates a temporary mirror to move each section” – the mirror legs are written on both disks
So seeing “writing device /dev/sda4” is perfectly normal during a healthy transfer.
Why it blows up anyway
bcache_invalidate: block … still dirty / Failed to write metadata means the kernel could not flush a block on the source SSD. Typical reasons:
- The USB bridge or cable is flaking out under heavy I/O.
- The SSD itself has pending or uncorrectable sectors and has switched to read-only.
- The LVM metadata area at the end of the partition is corrupt so LVM refuses to overwrite it.
Because the VG metadata update fails, pvmove aborts and the wizard shows the RPC error.
The usb cable connected to the external drive has a usb3 adapter over a usb C will that cause issues
this external setup is how I run the OS on my laptop, but occasionally it has to be restarted
should I try using the usb C connection
Ok, I think the best path forward will probably be to plug it back into the laptop and run it there, and create a Backup of all your services. Then shut it down, and we will use the “Restore From Backup (Disaster Recovery)” option instead of the Transfer option. You will need another USB thumb drive for this to create the backup on.
I have a 1tb sata ssd I can do the backup to, will that work
Yes, that will be better. The documentation is here: Start9 | Backup Create
They want you to use EXT4, not the default FAT32 or EXFAT. That will be a bit more technical. I need to log off, so I can help you with that tomorrow.
I do have a back on a Sata 250gb hard drive
ok thanks I will see what happens
I decided to try another transfer, but with a usb C connection and the transfer completed with no errors, the issue was not all apps where transfered like Datum gateway, Bitcoin Knots, NextCloud apps.
Do you have a Lightning node on there (Core Lightning or LND)?
I had stoped using my Lighting Node for a while , it was a little to much for me to get it going
I do see in my Update section an update for bitcoin core and bitcoin knots, i had stop using bitcoin core and was using knots with no issues on my old setup.