Try Boot

[zwvk]

Raspberry Pi OS has this A-B boot option
https://www.raspberrypi.com/documentation/computers/config_txt.html#the-tryboot-filter

I'm not totally clear on how best to use this with an image generated with sdm.

What I want to do is while the product is in our building, run sdm --burn to make the partitions and setup the device with all my customizations. This is the burn command I am currently using:
sudo sdm --burn-plugin parted:"rootexpand=37684|addpartition=0,ext4" --burn $file $dev --nowait-timesync
I use a separate call to sdm to make the image.

Later when the device is in the field I want to be able to provide the same or a similar image to the device and run a script to overwrite just one partition in the device with an updated OS so I can get the latest kernel and add some features. I figure I can just us "dd" to copy the partition out of the image file, and maybe I'll have to update the fstab file in the image to account for the part UUID, but I'm not sure if there is some other magic going on in sdm that will be missed by doing this manually. Ideally I'd like the device to be in a basically identical state after updating this way as it would have been if I had actually run sdm and given it permission to write to the whole disk instead of just the one partition. If sdm can do just that I've simply missed how to go about that.

Obviously this process I am describing wouldn't allow me to update things in the raspberry pi config.txt, and other files in this config partition, I'm content with that limitation.

[gitbls]

There was a discussion earlier (blushes...much earlier) this year about tryboot, and it's been on my list to figure out how best to implement it.

The biggest issue in implementing some sort of tryboot support is fixing the core sdm code to properly accommodate the tryboot partition. sdm is quite certain that there are exactly two partitions on the disk. No more, no less.

I've done quite a bit of thinking about this. Tentative plan:

• Ability to create a "tryboot-enabled" disk with --burn or --burnfile (e.g., add --tryboot on the burn command)
• Probably support mount and explore of an OS on tryboot-enabled disk (Partitions 2 and 3), since it's VERY handy. But this would probably NOT include the special tryboot FAT32 partition (partition 1); you'd need to use mount/umount to access that partition
• Expand partition and shrink will not be supported on a "tryboot-enabled" disk

I think the above provides you what is needed to create the tryboot enabled disk, and of course you'd be able to use the same customization in-house. Only the burn operation would be different.

Also see more info here: #202

Would this meet your needs?

[zwvk]

I'm not sure what you are presenting would be ideal for my situation. We're using an overlayfs to hopefully prevent system logging from wearing out the SSD. This overlay is frustrating to work with, so we've added a separate partition for the home directory which is not masked behind an overlay. Basically what I think I actually need to have at least 4 partitions: 512 MB fatfs for boot configuration Root Partition A Root Partition B Home Partition I want to put a full copy of the OS in B when I do an OS update, run tryboot and if that succeeds I'll remap it in autoboot.txt to be the boot partition. Partition A will then be dormant until a future update, or if the update fails it will simply still be the default partition so the update could be attempted again later. This setup is unique to my requirements, I'm not asking for you to structure everything around my goals, but I do think the approach you are favoring might prove to be less flexible, and thus harder to use in varying situations. I think everything in sdm that you already have in place is working fine for me to achieve what I want. The only piece I don't have is how to write the OS to partition B for the update such that all the sdm customizations still take full effect in the updated partition, without effecting the other partitions. Basically what I would like is a way to run sdm and give it just an image to burn and an individual partition, instead of a full block device.

…

On Tue, Dec 3, 2024, 6:53 p.m. Benn ***@***.***> wrote: There was a discussion earlier (blushes...much earlier) this year about tryboot, and it's been on my list to figure out how best to implement it. The biggest issue in implementing some sort of tryboot support is fixing the core sdm code to properly accommodate the tryboot partition. sdm is quite certain that there are exactly two partitions on the disk. No more, no less. I've done quite a bit of thinking about this. Tentative plan: - Ability to create a "tryboot-enabled" disk with --burn or --burnfile (e.g., add --tryboot on the burn command) - Probably support mount and explore of an OS on tryboot-enabled disk (Partitions 2 and 3), since it's VERY handy. But this would probably NOT include the special tryboot FAT32 partition (partition 1); you'd need to use mount/umount to access that partition - Expand partition and shrink will not be supported on a "tryboot-enabled" disk I think the above provides you what is needed to create the tryboot enabled disk, and of course you'd be able to use the same customization in-house. Only the burn operation would be different. Also see more info here: #202 <#202> Would this meet your needs? — Reply to this email directly, view it on GitHub <#275 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AINCDPLGVBUDAE2OHPA74MT2DY77HAVCNFSM6AAAAABS6YYDRSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNBVGUZDCMQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[gitbls]

I think I understand what you're trying to do, but I have a few questions (of course 🤣)

• Why are you not using a separate boot partition as partition 1 that has only the autoboot.txt in it, and then separate boot partitions for each of the bootable systems? It would allow the 2 root partitions to have independent boot partitions for each rootfs, eliminating a whole class of errors. (Of course it's possible that I still misunderstand how tryboot partitions are laid out...)
• It's unclear to me what overlayfs has to do with it, other than perhaps it's the motivation for using this technique
• I don't understand this comment: "he only piece I don't have is how to write the OS to partition B for the update such that all the sdm customizations still take full effect in the updated partition, without effecting the other partitions."
  • The partitions don't affect each other. If you want them both to be customized a particular way you'll need to do that before you blast them onto the disk in their destinations
  • If you want to update a system by pushing to it (via TBD mechanism) a whole new rootfs, it will need to be customized before pushing to the device

Re this comment: "Basically what I would like is a way to run sdm and give it just an image to burn and an individual partition, instead of a full block device."

• I don't see whacking at sdm to solve this as the correct solution, as it's rather niche
• Instead, you can create a new IMG that has the partitions laid out as desired and dd using seek=n or conv=append to blast the partitions onto the disk in the correct order.

Also, I see that I failed to mention that sdm would also grow a mechanism to add additional IMGs to be copied to the output. So, one could, for example:

• burn with --tryboot the first IMG
• Use the TBD command with --tryboot-add to append an additional bootfs and rootfs to the just-burned disk
• Manually edit autoboot.txt in the first partition as appropriate
• The partitions on the disk (with 2 bootfs/rootfs) would be:
  • Partition 1: has autoboot.txt
  • Partition 2: IMG-1 bootfs
  • Partition 3: IMG-1 rootfs
  • Partition 4: IMG-2 bootfs
  • Partition 5: IMG-2 rootfs

[zwvk]

I think the premise of my original question was simply does
sudo sdm --burn-plugin parted:"rootexpand=37684|addpartition=0,ext4" --burn $file $dev --nowait-timesync
do anything fundamentally different than dd would to a specific partition. I assumed that --burn must somehow modify the SD card after write to add in the flag --nowait-timesync, and I assumed it is probably doing other things as well.

When scanning the source code I noticed calls to writediskids and other things to write messages to the device, I'm not sure If I would miss any of that if I used dd

I don't think this is a niche requirement, anyone that wants to use tryboot would need a way to write to part of the disk instead of the whole thing to install an update to a partition.

Regarding your other comments, I think it is more likely that I am misunderstanding the best way to use tryboot. having two config partitions makes sense if I can then update the system more completely. I hadn't considered that...

The primary motivation I have for needing tryboot is that my device will usually not have network connectivity. I want to be able to package a full OS update that I can test in house before sending to my customers.

overlaysfs has little to do with this other than being my motivation to have a separate home partition that is not effected by the OS updates. I think I can see more clearly the idea you are proposing. If it would still be possible to add this additional partition I need after the --tryboot command has done it's thing then I think your plan would suit me very well.

The thing that concerns me is If I would still have control of the size allocated to the rootfs partitions. Right now you start at the beginning of the block device and it uses space as it needs to. This won't work for tryboot, you need a way to determine the size of each bootable partition.

for my needs I would like to be able to supply additional sizing information with the new command, something like --tryboot=10GB which would allocate partitions as you have proposed in the following layout:
Partition 1: has autoboot.txt
Partition 2: IMG-1 bootfs (512 MB)
Partition 3: IMG-1 rootfs (10 GB)
Partition 4: IMG-2 bootfs (512 MB)
Partition 5: IMG-2 rootfs (10 GB)
the rest of the disk would be unallocated

If a user doesn't need this unallocated portion the default could be just --tryboot and it would have to detect the size of the disk and use about half for each partition. This would have to be done during the burn obviously.

[gitbls]

Sorry for the delay in getting back to you, was chasing some fires and posting sdm V13.4

The burn process in the no-tryboot scenario is:

• dd the IMG to the SD card
• Update the now-written disk with the newly-fabricated disk ID
• Mount the disk (both partitions)
• Expand the root partition unless --no-expand-root
• More fiddling
  • Disable unnecessary RasPiOS services if we can (firstboot and resize)
  • Write the disk IDs to cmdline.txt
  • Write the hostname
  • Run plugins specified on the --burn command line (Phase 0, Phase 1, and post-install)

After all the above, any specified burn plugins are run. Burn plugins run in the context of the sdm host, with access to the just-burned disk as a mounted disk, rather than running inside the disk container.

So, yes, it does a bunch of stuff after the dd command.

When tryboot is implemented, writing the 2nd OS IMG onto a disk will do all these steps as well, so that the resulting IMG (regardless of whether it's the first, second, or Nth OS on the disk) is complete per your request.

"The thing that concerns me is If I would still have control of the size allocated to the rootfs partitions." -- You have control over it, and can do one of:

• Leave the rootfs partition the size it was in the source IMG (no extension whatsoever)
• Expand it a specified amount using the post-burn plugin parted
• Expand it to consume the rest of the disk (not very useful with the tryboot first IMG!)

So, for instance you could:

• Burn the first IMG to the disk with sdm and the --tryboot switch. This would
  • Create Partition1 (autoboot.txt).
  • dd "append" following partition 1 the bootfs/rootfs from the IMG you specify (creating partitions 2 and 3)
  • If you want the first rootfs to be larger than it is in the IMG use the parted post-burn plugin to size it as desired
• "append burn" the 2nd IMG to the disk, creating partitions 4 and 5
  • If you want the 2nd rootfs to be larger than it is in the IMG use the parted post-burn plugin to size it as desired
• If desired, run the parted plugin to create the home partition as partition 6

This does what you want, I think???

Lastly, you mentioned "I don't think this is a niche requirement, anyone that wants to use tryboot would need a way to write to part of the disk instead of the whole thing to install an update to a partition."

If you are referring to doing this after the tryboot-ed system is booted and running and you want to update the "other partition", yes a method will be needed to burn a replacement rootfs partition for the partition that is not running. IOW, OS1 (partition 3) could update OS2 (partition 5) using dd.

TBH I haven't thought much about this other than to convince myself that it's doable, given sufficient disk space for everything. You'll clearly want to have some "expansion space" at the end of each rootfs to allow for a future update of the rootfs to be larger than what you initially write to the disk.