[This email is primarily meant for anonym, with additional bits near
the end for those who want to comment on how we could handle the
"Upgrade from ISO" mess for 1.0.1-->1.1, from a "communicating with
users" perspective.]
I've spent quite some time implementing what I believe is the proper
solution to #7345 ("Tails 1.1~beta1 created by upgrade from ISO from
a 1.0 USB does not boot").
I'm not done yet, but that's a relatively large piece of work, and
I expect it will take a bit of time to review this all, so it would be
good if anonym (or anyone else) could start ASAP.
In "short", the root of #7345 is that Tails Installer runs the running
system's syslinux against the target device. In cases when the running
system is older than the newly upgraded one (which is usually the
case, else one would simply "Clone and Upgrade"), the target drive
then gets a mix of new COM32R (*.c32) modules, a probably old MBR, and
old ldlinux.sys (put in place by running syslinux). This kind of mix
is generally unsupported: it *might* work when mixing files coming
from close-enough versions of syslinux (untested, and upstream is
explicitly not recommending that), but it definitely doesn't work when
mixing 4.x and 6.x files.
Unfortunately, we can't simply use a new, working ldlinux.sys that
could be found in the ISO, as this file depends on the filesystem
layout (it contains the block number at which another bit of syslinux
can be found). So, any proper, long-term-proof solution seems to imply
to run the version of syslinux found in the just-upgraded system.
My initial idea was to simply loop-mount it, chroot and boom, but this
requires root privileges, and I'd rather not even try to do it safely.
So, my solution is to copy the syslinux binary and its MBR, at ISO
build time, into a new "utils" directory at the root of the ISO
filesystem. Then both liveusb-creator and tails-iuk run that
(presumably newer) copy of syslinux, and setup that (presumably newer)
MBR, at the end of the upgrade process. If I get it right, then the
only tricky part we'll have to be careful about in the future is that
the syslinux binary shipped in Tails version N+1 must run fine in
Tails version N. E.g. we need to ship a *Squeeze* backport of
syslinux 6 in Tails 1.1, which is actually what we're doing already.
Ideally, this binary should also run fine on Tails version N+1.
Given that this binary is currently only linked to glibc, this should
not be too much of a hassle.
Thoughts?
I've successfully tested "Upgrade from ISO", from Tails 1.0.1, after
installing liveusb-creator 3.11.6+tails1-5.bugfix.7345~3.gbp21039c
from the bugfix-7345-upgrade-from-iso-from-1.0-to-1.1 APT suite,
feeding it with an ISO built from yesterday's
bugfix/7345-upgrade-from-iso-from-1.0-to-1.1 branch. The resulting
device boots just fine, and has the expected files and MBR in place.
It would be good if someone else could try and reproduce this.
I'll also have to test all other installation and upgrade scenarios,
to make sure I didn't break anything else.
I've not tested my changes to tails-iuk in a live environment yet.
The test cases I've added to its test suite should cover most of it,
but we'll see.
I'm not sure when exactly I can complete this work, that has already
taken me a lot of time. I hope I can do this on Friday/Saturday, else
it may have to wait until next Tuesday (June 24) or Wednesday (June
25). Same for the UEFI doc, by the way.
Left to do: think how we announce to our users either that they must
*not* use "Upgrade from ISO" in 1.0.1, to upgrade to 1.1; or, that
they must first upgrade the liveusb-creator package somehow.
Obviously, the first solution is easier for us, and given that the
second one implies steps that many of our users may find too hard to
follow, perhaps it's not worth the hassle of documenting it.
