Drive restore no longer works on Fedora 39 #644
Comments
|
Could be |
|
I tried to install udisks2-2.9.4-7.fc38 on F39, that fails because of dependencies. Then I tried to rebuild it to F39, that also fails because of some "configure" error. If you think this is a problem in udisks2, can you please report a new bug against it, e.g. with some log of attempted operations? I don't know how to do that. But I'm happy to help with debugging, if you tell me how. Thanks. |
|
CC: @tbzatek Tome, the code for restoration is quite simple, we do everything over DBus, see restorejob.cpp. I can see that the new udisks2 use a new library for this and this works on Fedora 38 where we still have older udisks2. Do you know what's going on? |
|
My first guess is that the "Failed to add new partition to the table: No space left on device" error message that is coming from libblockdev that has been rewritten to libfdisk is failing on slight alignment miscalculation (that has changed a little too). Cc: @vojtechtrefny |
|
As a quick fix you may try creating a new partition slighly smaller to accommondate a partition table (MBR is perhaps only 512 bytes). After all, old versions of udisks were complaining about overlapping partitions. |
|
Another hint: if you call |
The newly created partition cannot start on offset 0, previously UDisks was able to compensate for this, but there is a bug in the latest UDisks/libblockdev and this no longer works. But in general offset 0 for a new partition doesn't make sense. We can also use 0 for size to let UDisks calculate the maximal size instead of passing the underlying device size. Fixes: FedoraQt#644
The newly created partition cannot start on offset 0, previously UDisks was able to compensate for this, but there is a bug in the latest UDisks/libblockdev and this no longer works. But in general offset 0 for a new partition doesn't make sense. We can also use 0 for size to let UDisks calculate the maximal size instead of passing the underlying device size. Fixes: #644
|
With the fix tested in #650 this doesn't seem to work completely correctly yet. Sometimes I see screen flashing and it ends up on a wrong screen (not the "Finish" one), but without any error displayed. The drive is restored, though. See here: I think this happens more often when I clean-boot the machine and then restore the drive as the first thing action. I also once saw that the drive was not restored at all (it returned to the home screen), but I couldn't replicate it again and I don't have logs. |
|
Looks that change I did breaks it for some reason. I will investigate. |
The newly created partition cannot start on offset 0, previously UDisks was able to compensate for this, but there is a bug in the latest UDisks/libblockdev and this no longer works. But in general offset 0 for a new partition doesn't make sense. We can also use 0 for size to let UDisks calculate the maximal size instead of passing the underlying device size. Fixes: #644
The "restore" functionality no longer works on Fedora 39 Workstation. It displays an error:
In the background, it formats the drive with a clean MBR partition table (i.e. all partitions are gone), but it doesn't create a new exFAT partition over the whole drive, as expected.
Below is the journal from Fedora 39 Workstation during drive restoration. It happens in two parts (mostly, but sometimes there can be just one step, I don't know exactly why it differs sometimes).
The first time you try the restoration, FMW almost immediately returns back to its home screen, without showing any conclusion. But the drive gets flashed with a new MBR table, all partitions are gone. The journal is:
If you select "Restore" in FMW again, this time FMW shows an error screen, as shown above. The log is:
Now the "Restore" option disappears from FMW. Users can no longer restore the drive using FMW.
For comparison, this is the journal from Fedora 38 Workstation during a successful drive restoration:
Tested with
mediawriter-5.0.7-1.fc39.x86_64(and fc38) in a Fedora 39 (and 38) Workstation virtual machine.The text was updated successfully, but these errors were encountered: