Tails

#2 Updated by mercedes508 2014-05-30 08:30:05

When trying to boot I get this message, just after the boot scren from the computer:

ifcpu64.c32: not a COM32R image

So when saying it doesn’t boot at all, it means that I don’t see the Tails boot menu, it directly gets to tat error message.

#4 Updated by intrigeri 2014-05-31 05:10:45

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:

1. 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;
2. 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;
3. on 1.0.1->1.1 “Upgrade from ISO”, fully (MBR + *.c32 + 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).

#5 Updated by mercedes508 2014-06-04 09:28:18

A user had the same error (ifcpu64.c32: not a COM32R image) when Tails 1.1 was installed using the Universal USB Installer.

#8 Updated by anonym 2014-06-12 19:00:25

Any update on this?

#9 Updated by intrigeri 2014-06-13 03:36:42

> Any update on this?

That would be my top-priority for today, after reviewing your stuff.
FTR, I’ve started a discussion about it on the syslinux list two days ago.

#15 Updated by intrigeri 2014-06-22 00:10:58

Left to do: a few tests, documented in https://mailman.boum.org/pipermail/tails-dev/2014-June/006177.html.