failed to rollback from 15.04 alpha #4 to #3
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| Snappy |
Critical
|
Oliver Grawert |
Bug Description
I flashed snappy 15.04 alpha #3 in my beaglebone black. Today there's a new image on that channel, so I updated.
I rebooted and got into alpha #4. Then I tried to rollback to #3, but after the reboot, it fails to boot and I end up in #4 again. So it's no possible for me to rollback.
My test log with the steps to reproduce: http://
This is the serial console after the reboot: http://
Ricardo Salveti (rsalveti) wrote : | #1 |
Changed in snappy: | |
status: | New → Confirmed |
importance: | Undecided → Critical |
Ricardo Salveti (rsalveti) wrote : | #2 |
(BeagleBoneBlac
Setting ubuntu-core to version 3
Name Date Version Developer
ubuntu-core 2015-06-10 3 ubuntu!
Reboot to use the new ubuntu-core.
(BeagleBoneBlac
baae473daca1d9f
(BeagleBoneBlac
c42761096016a6a
(BeagleBoneBlac
(BeagleBoneBlac
(BeagleBoneBlac
(BeagleBoneBlac
(BeagleBoneBlac
Then I was able to successfully boot image 3 again (partition a), which clearly shows that the kernel and initrd were indeed corrupted.
Ricardo Salveti (rsalveti) wrote : | #3 |
Now the question is why the vfat partition is getting into this weird/broken state, maybe not unmounted properly during reboot?
Oliver Grawert (ogra) wrote : | #4 |
probably fatwrite does something to it when it re-writes the snappy stamp file during first boot after update ...
Changed in snappy: | |
milestone: | none → 15.04.2 |
assignee: | nobody → Oliver Grawert (ogra) |
Michael Vogt (mvo) wrote : | #5 |
We are almost ready to replace the broken fatwrite with using a uboot environment file for the state handling.
Changed in snappy: | |
status: | Confirmed → In Progress |
Changed in snappy: | |
status: | In Progress → Fix Committed |
Changed in snappy: | |
status: | Fix Committed → Fix Released |
(BeagleBoneBlac k)ubuntu@ localhost: /boot/uboot$ ls -l a/
total 19616
drwxr-xr-x 2 root root 512 Jul 13 16:02 dtbs
-rwxr-xr-x 1 root root 114 Jul 13 16:02 hardware.yaml
-rwxr-xr-x 1 root root 13574238 Jul 13 16:02 initrd.img
-rwxr-xr-x 1 root root 6510264 Jul 13 16:02 vmlinuz
(BeagleBoneBlac k)ubuntu@ localhost: /boot/uboot$ md5sum a/vmlinuz a2c2e998aab1c0b cc a/vmlinuz k)ubuntu@ localhost: /boot/uboot$ md5sum a/initrd.img 8813a3f718b24f7 77 a/initrd.img k)ubuntu@ localhost: /boot/uboot$ sudo md5sum /boot/vmlinuz- 3.19.0- 18-generic a2c2e998aab1c0b cc /boot/vmlinuz- 3.19.0- 18-generic k)ubuntu@ localhost: /boot/uboot$ md5sum /boot/initrd. img-3.19. 0-18-generic 8813a3f718b24f7 77 /boot/initrd. img-3.19. 0-18-generic
baae473daca1d9f
(BeagleBoneBlac
c42761096016a6a
(BeagleBoneBlac
baae473daca1d9f
(BeagleBoneBlac
c42761096016a6a
After updating to image 4 and booting again: k)ubuntu@ localhost: /boot/uboot$ ls -l a/ k)ubuntu@ localhost: /boot/uboot$ md5sum a/VMLINUZ eb9055ffde9c9c5 ec a/VMLINUZ k)ubuntu@ localhost: /boot/uboot$ md5sum a/INITRD.IMG 51d6de9ab520635 af a/INITRD.IMG
(BeagleBoneBlac
total 19616
drwxr-xr-x 2 root root 512 Jul 13 16:02 DTBS
-rwxr-xr-x 1 root root 114 Jul 13 16:02 HARDWA~1.YAM
-rwxr-xr-x 1 root root 13574238 Jul 13 16:02 INITRD.IMG
-rwxr-xr-x 1 root root 6510264 Jul 13 16:02 VMLINUZ
(BeagleBoneBlac
26e74d8bbae82f6
(BeagleBoneBlac
f52e6affb217282
So it did end up modifying the kernel (maybe via fsck?).