Have a nice day, everyone!
Before a yay system update caused my catastrophic boot-failure problem there, I made a copy of the now-failing LUKS ext4 EOS partition from a SATA SSD to a new NVMe SSD via partclone application.
I did that in hopes of having a fully reliable backup of that essential EOS system. But somehow I seem to have misused the partclone application: It only cloned/copyed the original EOS (71 GB used, 46 GB free) by stretching it over the whole 2 TB NVMe drive.
I tried to shrink the replicated partition, but different partition managers under different Linux distributions failed to solve the problem.
That means there was and is no space left for the corresponding esp boot partition. If I had cloned the latter, perhaps I could have solved the aforementioned catastrophe myself.
3 screenshots following:
=== A) original LUKS-encrypted ext4 EOS partition on SATA SSD:
=== B) EOS partition copy spanning whole NVMe drive:
=== C) NVMe-replicated partition impossible to shrink (in this case, while trying to create a new partition):
The error/warning/hinting message after trying to only shrink it is different, but it fails, too.
Would someone please help me in both shrinking the replicated EOS partition and make it bootable? Else, it will remain a quite useless copy on expensive new hardware.
It probably isn’t that hard to fix your original problem with the original disk
It looks like you successfully shrunk the partition. What failed was you trying to create a new partition at the same time
It looks like you cloned the unencrypted volume instead of the luks volume so you may no encryption on the new copy
What type of partition table is on that nvme drive? If you cloned the partition directly to the disk, there may not be a partition table which would mean you cannot create any additional partitions.
My boot-failure problem is highly similar to the other thread opener’s one – and comparable to another forum member’s problem. Noone could help either of them yet. A solution could benefit at least 3 requesters at once.
After clicking “Close”, the “unallocated” space disappears within a second. Then it looks the same as before pseudo-shrinking.
The replicated partition seems unencrypted to me. But that alone would be okay. If I remember correctly, partclone was not able/willing to clone the LUKS partition before decryption.
GParted states for the NVMe: “Partition table: none”. So probably you are right. Is there a way to repair it to get a GPT – maybe via cloning/copying the replicant to a HDD with GPT? The original on SATA has GPT.
There are multiple reasons you can get that error. All should be solvable unless that hardware itself is failing. There are many posts here where people have solved similar issues but we would need to troubleshoot yours specifically.
You would be better off creating a new topic for yourself rather than adding on to the other posters since your issue might not be the same.
Yeah, this probably means you don’t have a partition table. Since there is no partition table, there are no actual partitions. As further evidence of this, the device is named nvme0n1 which is the name of the entire disk.
You could certainly do that if you wanted to.
That being said, I think the safest thing would be to fix the original install instead of messing around with the clone but it is up to you.
Okay, how would someone copy the only 71 GiB large partition which overspreads an entire 1.82 TiB NVMe without a partition table best to get a GPT on its newly created copy?
EDIT: If this thread is related to this other one, ignore what is below and stick to the other thread.
I’m assuming that you have another system which is working properly, since you took 14 days to respond to Dalto’s suggestions. Am I correct?
The reason I actually ask is: For data preservation, try recreating this in a VM of the same OS but with much less space, maybe just 15 GB, and run the operations in said VM.
Then try either rescuing or reinstalling the system, and check if the files are corrupted.
And by test I mean this:
PS: You can probably get away with just 10/8 GB to speed up such a test.
To be clear, the issue is that it isn’t a partition. They copied the data from a partition directly to the block device of the disk. As a result the disk has no partition table and no partitions.
