Snappy prebuilt images have very non-unique filesystem identifiers

Bug #1477178 reported by Zygmunt Krynicki
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
snapd
Triaged
Medium
Unassigned

Bug Description

The prebuilt images that we have have non uniquer filesystem identifiers, see:
 - https://twitter.com/zygoon/status/623612134648377345
 - https://twitter.com/zygoon/status/623612496226689024

This has some interesting, bad consequences:
 - if you reboot a snappy system with a snappy image on a USB stick, you may boot into that image (depending on bios enumeration) as snappy grub configuration uses UUIDs as boot targets
- the snappy grub configuration is also wrong as the shipped system has hd1 entries (not hd0) and in result it only works by accident and because of those non-unique identifiers are used in the fist place.

I would suggest that we re-write them on first boot. This should be probably coupled with https://trello.com/c/EdWkd2UW/181-use-cloud-init-to-extend-resize-the-writable-partition-during-first-boot

Revision history for this message
Ricardo Salveti (rsalveti) wrote :

I believe the grub config issue is probably fixed on rolling already, since we're not calling update-grub anymore on it. Please give it a try.

Now about the fs identifiers, this is currently by design since we're only using labels instead of UUIDs. So changing the UUID of the partitions are not going to really affect anything at the moment (but I agree we should avoid having the same set of uuids for every pre-built images, if there is an easy way to update it during runtime).

Michael Vogt (mvo)
Changed in snappy:
status: New → Triaged
importance: Undecided → Medium
Michael Vogt (mvo)
affects: snappy → snapd
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.