Tails 1.1~beta1 created by upgrade from ISO from a 1.0 USB does not boot
When doing "upgrade from ISO" from a Tails 1.0 USB stick onto another Tails 1.0 USB stick using a Tails-1.1-beta1.iso, the resulting upgraded USB stick doesn't boot at all.
A manually installed USB with thhe same iso file boots fine
A cloned & installed USB from the previous manually installed one boots fine.
#3 Updated by intrigeri about 5 years ago
- Status changed from New to In Progress
Reproduced. It's caused either by the syslinux 4 / syslinux 6 mixed MBR/modules mismatch, or by the workaround brought by https://bugzilla.redhat.com/show_bug.cgi?id=492370.
#4 Updated by intrigeri about 5 years ago
Basically all ISO-to-USB installers have had this problem in the past. In a nutshell, the version of the syslinux MBR must match the version of
ldlinux.sys, and the version of the
*.c32 modules. What makes things hard is that the syslinux installation command embeds into
ldlinux.sys some data that depends on the underlying filesystem (block numbers), which makes it impossible to mix newer COM32R modules shipped in the ISO, with a
ldlinux.sys and/or MBR installed with an older syslinux provided by the system that runs the isntaller.
Other installers "solve" this by replacing the version of syslinux shipped in the ISO with their own one. It's probably good enough for one-shot usecases such as getting a distro installer to boot from USB, but I'm not sure it's a viable approach for Tails in the long run.
So, the only ways out I can think of are:
- document the fact that "Upgrade from ISO" is not supported for the 1.0->1.1 path; thing is, we're going to upgrade syslinux again soonish (to a newer snapshot of 6.03-preN, probably), and I don't know if its new COM32R modules will be compatible with the MBR and ldlinux.sys installed by our current 6.03-pre1 snapshot; so, maybe "Upgrade from ISO" will be broken again;
- after copying the files from the ISO to the destination drive, do not run syslinux from the running system. Instead, mount the squashfs filesystem from the destination drive, chroot in there, and install the (new version of) syslinux from there;
- on 1.0.1->1.1 "Upgrade from ISO", fully (MBR +
ldlinux.sys) replace the syslinux 6 installation (from the 1.1 ISO) with a syslinux 4 installation (from the 1.0.1 ISO); this could be done in the MBR syslinux installation path only, so EFI boot is unaffected; at this point, there will be users of 1.1 who use syslinux 4, and others who use syslinux 6. The good news is that the next "Upgrade from ISO", presumably run from 1.1, and fed with a 1.1.1 or 1.2 ISO, and meant to upgrade another 1.1 stick, will this time upgrade their installation to syslinux 6 (unfortunately, to the 1.1's version, with the same problem described for solution 1 above).
The 2nd solution might be a bit complicated in practice, but it's probably worth giving it a try: if it works, it could be generalized into a mechanism to run post-upgrade scripts shipped in the ISO at upgrade time, in an environment close to the new version's, before rebooting. This can possibly be useful in the future, to solve other problems that cannot be retroactively fixed in an already released Tails that will be used to upgrade from ISO.
The 2nd solution is also the only one that guarantees that we don't create different sticks with "Upgrade from ISO" (that try to start Tails vN with the syslinux shipped by Tails vN-1), to those created with "Clone and upgrade" (that have the new syslinux).
#7 Updated by intrigeri about 5 years ago
- Subject changed from Tails 1.1-beta1 created by upgrade from ISO from a 1.0 USB does not boot to Tails 1.1~beta1 created by upgrade from ISO from a 1.0 USB does not boot
It's likely that devices that go through a 1.0->1.1 automated upgrade would have exactly the same issue, BTW... but the good news is that we won't propose such an incremental upgrade.
#15 Updated by intrigeri about 5 years ago
Left to do: a few tests, documented in https://mailman.boum.org/pipermail/tails-dev/2014-June/006177.html.