Persistence doesn't work with Ubuntu 23.04

[pbatard]

• Ubuntu changed their kernel options in 23.04 and no longer uses file=/cdrom/preseed.
• Because of this, we can no longer detect Ubuntu configuration files to add the persistent keyword.
• Because of this persistence does not work.

Hopefully, trying to detect layerfs-path=minimal.standard.live.squashfs as well as file=/cdrom/preseed will work, and Ubuntu won't be shuffling these options too much for subsequent releases...

[evstratios]

This must be the reason Rufus erased my external SSD.
I'm screwed now.

I was building Ubuntu 23.04 on a 64 GB USB stick.
I had my all-important bootable SSD drive connected
and I found the persistence was on my now empty drive
with all my information gone!

I have done this a million times with Rufus
and now my drive is gone! I don't know what to do.
I'm trying testdisk but it's lvm2.

partition 1 - ext4 enclosing two lvm2 partitions.
partition 2 - linux swap

HELP

[pbatard]

This must be the reason Rufus erased my external SSD.

It's not.

Because you are not elaborating, I'm pretty sure that you are under the impression that Rufus somehow looks all over the disks that are accessible on your system and may somehow mistake such a disk for something it can/should write to.

That is not the case,

The above describes detecting that happens with the ISO that is loaded in Rufus, and that ISO only. It does not apply to anything but the ISO selected, and especially it is NOT being performed on anything that is a physical or virtual disk.

In other words:

1. After the user selects an ISO, Rufus looks for the GRUB config files on that ISO image, and only on that ISO image to see if there is a text line there that says layerfs-path=minimal.standard.live.squashfs.
2. If there is, then, when it copies the file to the disk YOU have selected as the target media in Rufus, it adds a persistent option to that file.
3. That is all Rufus does, and all my post above implies.

Which means that, no, Rufus had no play in somehow selecting the wrong drive. I'm afraid that you did. And you happened to select your all-important bootable SSD drive instead of the actual USB drive you wanted to use.

It should be noted that Rufus does attempt to avoid listing drives that don't look like regular USB Flash Drives by default, but there's only so much we can do there (because there's nothing that really differentiates a USB pendrive from a USB SSD in an enclosure), and, as people report that such or such drive is not being listed by default, and we obviously cannot test every USB media out there, we try to add the ones that people request (eg. #2247). So it may happen that an SSD drive in a USB enclosure will be listed by default. Or you may have used the option to list USB HDDs/SSDs per https://github.com/pbatard/rufus/wiki/FAQ#user-content-Help_my_USB_drive_is_not_detected.

As a result, the only advice I can offer is once I provide in the FAQ at https://github.com/pbatard/rufus/wiki/FAQ#user-content-Help_I_formatted_the_wrong_drive_by_mistake_How_do_I_recover_it.

In short, while I do appreciate that losing data sucks, I'm afraid that, no, it had nothing to do with any recent changes and especially not this one, since it does not, in any way, even remotely imply that Rufus will somehow look at connected disks to see if it looks like they have Linux content or Linux configuration files, and automatically select one such drive if it does (and feel free to have a look at the code and experiment with Rufus if you want to dispute that very factual statement), and that, if you want to attempt to recover the data you lost after you happened to select the wrong drive in Rufus, you will have to ask data recovery specialists,

[evstratios]

I selected my USB Flash Drive. I found the persisistence folders on my ssd drive. Was it magic?
I'll elaborate as much as you want, in private if that helps.
It's an error and not some malicious thing.

[pbatard]

I'd rather do this in public, as I have nothing to hide and I stand by my assessment that you happened to select the wrong drive by mistake,

If what you state is true, then it should be easy to replicate:

1. Reformat your SSD in the manner it was set up before you used Rufus
2. Plug your USB flash drive and recreate the Ubuntu 23.04 drive with persistence, making sure that you do have that USB drive selected.
3. Let Rufus complete its job.
4. If you happen to have compelling evidence that Rufus may format the wrong drive for persistence, by having replicated what you state happened above (which if Rufus has an issue as you state should be replicable) then attach the FULL log of Rufus' operations, so that I can attempt to replicate your conditions.

The problem is that there are 2 elements that go strongly against your assertion here:

1. The Rufus code is hardened to perform all its formatting operations based on the Windows drive index, which is unique for each disk connected to your system (NB: If you want to assert that Windows systems' drive indexes may somehow not be unique, then you will need to open a bug with Microsoft). There are checks all over the code to, one, make sure the drive index we are working with does match the drive index of the disk you selected as well as detect potential corruption of the internal drive index we use (e.g. here for the persistence partition formatting code). So, even if there was a memory overflow somewhere and the drive index being used for creating the persistence partition was corrupted, it would require that this corruption produces an index that Rufus sees as valid (because Rufus does not just accept any index value, and especially, since we offset all our indexes internally, a zeroed index will be instantly detected as invalid) and that also happens to match the index of the selected drive, which we never alter after the user selects the target media).
2. Furthermore, you have to realise that Rufus is downloaded about 3 million times a month and persistence partition support has been provided as a feature for many years. Yet, you will not find a single issue in this very public issue tracker that even remotely hints at what you describe, and I can also assure you that I have never received any e-mail or seen any report, on public social media forums, that appear to indicate that what you describe may happen when using Rufus. Surely, if there was the alleged application error you assert, there would be other reports, just like yours, of Rufus somehow formatting the wrong partition by mistake.

As such, until you do replicate your issue and can provide a log that appears to back your claim (and I'll be more than happy to provide you with more verbose versions of Rufus that describe exactly how they select the target partition, what drive index they used for it, and so on, if your log appears to corroborate your claim because, of course, if that it the case, this is something I would be eager to fix), I have to continue to assert that the most logical explanation is that you happened to select the wrong drive by mistake.

[evstratios]

It put the Ubuntu 23.04 installer on the usb drive
so I didn't pick the wrong drive.
It didn't put Ubuntu on the ssd it formatted.
Just the persistence was on the SSD.

As far as replicating my issue, I have but one ssd to give for rufus.
I still need to recover my data. I'm heartbroken.
I'm less interested in replicating it than recovering my data.

You seem to have the wrong attitude about this.
Somehow you want to say "it's perfect and it can not be in error".

I love Rufus and I use it all the time.

[pbatard]

You seem to have the wrong attitude about this.

And you don't seem to be willing to demonstrate that you didn't select the wrong drive by mistake and that, as you claim, it is in the application that is responsible for your data loss.

I'm afraid I can only work with facts, not claims. And until I see evidence, from your side (since, again, nobody else has ever claimed that Rufus could format the wrong drive on its own, despite millions and millions of users), that seems to corroborate your claim, along with a log (since I have personally formatted persistent partitions multiple times, often with more than one USB drive plugged in, and never seen the issue either, so I need to see data that might allow me to replicate the issue, if issue there is), I have no choice but not to embark on a crusade to try to replicate an issue with little to no data to help me replicate it.

Somehow you want to say "it's perfect and it can not be in error".

No. I am saying: "Here are, with verifiable evidence, the steps we take in Rufus to ensure that what you claim should never happen. Therefore, if, despite what we publicly show for scrutiny, you want to assert that it can, in fact, happen, we will require evidence, such as your reproducing the issue a second time and producing the Rufus log. Unless you want to do that, and since we have provided verifiable evidence that what you claim should not happen, we have to no choice but to conclude that your data loss was very likely due to user error"

I love Rufus and I use it all the time.

I appreciate that. And I hope that, if you do, then you can appreciate that the developer of an application can only fix an alleged issue if the reporter can provide enough evidence and data to help the developer replicate the issue. The only information I have from you at this stage is that you "had a bootable SSD drive connected", with no details about its type of connection, size, file system, partition type, and whether it was even listed by Rufus in the first place (which is data I would get from your log). So, despite how it may appear to you ("Just spend days with random data drive plugged in and create persistent Ubuntu 23.04 USB flash drives until you happen to run into the issue — How hard can it be?") I just don't have enough data to start investigating your issue and the ball is entirely in your camp, if you believe you do have a case, to provide such data.

[patrick2k12]

@pbatard Kudos, you are doing a great job. Everything is working perfectly. 👍

[github-actions]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.