Massflash/flash differences

Hey,

we got a system where we create an additional partition after the UDA partition on firstboot.
This works flawlessly when using the initrd flash command.

When using initrdflash in the massflash package however, the contents of the additional partition are not deleted and remain the same as before flashing. I would expect a flash command to wipe the whole device to revert it to a factory state. As this does not happen that is a big issue for us in production.

Is this a know issue? How could we fix this behavior? Adding own scripts does not seem to be an option as the flash script connects the device and disconnects it when it is done.

What L4T version do you use?

How did you achieve this? Can you please give more detail?
Like some sorts of system service?

YES, it should.
A new GPT will be written into the disk so ideally nothing will be left.

We have a service that runs a script in the same method like the nvidia firstboot.
The script checks if the parition table contains a partition with a certain name and alters the partition table.

I figured the massflash script would not overwrite the content of the partition, as the partition table does not contain it, but it is not overwritten. So the mfks is forced to run the partitioning again after modifying the partition table. Still we see old data in the partition when mounting it. Technically that should not happen, so I am wondering what we might do wrong here…

Can you give more detail on this?
There should be no mkfs involved as it is only run to format the APP partiton, but not others.

Please also give the complete log when you do massflash.

I use the mkfs to create an ext4 partition for the new partition located after the UDA partition. If I would not rerun the command after the massflash, the data would of course not be deleted (Massflash only writes the partition table)

The massflash does not show anything about it as I did not modify the partition table for flashing. I figured as I could not create a partition that would use the whole available space of the nvme I can also create the partition initially after the first boot.

The behavior should not be different for normal initrd flash or massflash though I think.

OK, I know what you mean now.

You are saying that even after the partiton table is overwritten, when you manually create that partition again, the data is still there? Like it is physically still there before you create the parition, but just nowhere to be accessed?

I don’t think our script do any sort of wiping on the disk as it’s very time consuming.
It only overwrites the partiton table, and most of the time it’s enough for the majority of use cases.

Okay, thanks for your answer, that kind of confirms my initial assumption.
So I’ll have to deal with it myself. Still wondering why it does not happen when flashing a single device. Technically massflash should do the same as the normal flashing, just on more than one device, right?

How did you do it with initrd flash so the data is not preserved after flashing?
Like the command you used?

Thats my big issue here, technically what you told me makes sense, the data is not deleted, just the partition table is modified. So the script should always find the data from the previous running instance and refuse to make a filesystem as it already exists. Somehow the mkfs.ext4 runs through with normal flash, as if the data is not present while it is present when using the massflash.

Procudure:

  • flash
  • run initial script if partition with the expected name is missing
  • recreate the partition table
  • mkfs.ext4 on the new partition

With normal initrd flash I should observe the same issue, but I don’t. So something must be different.
But If you do not know any difference I don’t want to waste your time anymore. It is something which I must be able to solve after flashing. Just wanted to be sure that I understand entirely what the flash scripts do before taking any action.

Sure, that’s fine.
I think writing zero data into UDA with dd before your operation should be a feasible solution.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.