Hi, On Wed, 13 Aug 2025 22:03:37 +0100 Luca Boccassi <bluca@debian.org> wrote: > This was meant to be applied only in the read-only portion of the live > image filesystem, as it contains image IDs that makes sense for an > immutable image to identify it, but not for an upgradable rootfs. If it > gets copied to an installed disk then something went wrong somewhere > and yeah it should be fixed. > > I am not really familiar with calamares so not surprised I missed it, > if you know what to do would you be able to send a MR on Salsa to fix it > please? I wonder about the rationale of the diversion. Is this to guard against upgrades of base-files that happen *during* image creation? If the diversion is somehow useful during image creation, the easiest fix might be to just remove the diversion at the end of the image creation process. If the diversion does not end up in the live system, then calamares cannot copy it over. Also: this is just addressing how to fix the problem going forward. The more pressing fix (I think) is to think about how to fix existing installations which have the wrong /etc/os-release because of this. Somebody (and not me within the next few days because I'm attending my brother's wedding on the weekend) would have to come up with a clever postinst script to clean up the mess and then get that into the next point release and hope that users uprade their Bookworm before upgrading to Trixie... Thanks! cheers, josch
Attachment:
signature.asc
Description: signature