Karmic desktop CD fails to boot because of different squashfs versions

[Joachim Frieben]

Binary package hint: squashfs-tools

The AMD64 desktop snapshot of Ubuntu 9.10 as of 2009-05-12 fails to boot because the squashfs versions of the live image [3.1] and that of the kernel [4.0] are different. During boot, the kernel complains

    "SQUASHFS error: Major/Minor mismatch, older Squashfs 3.1 file systems are unsupported." ,

and the user is dropped to the busybox shell.

Kernel version: 2.6.30-2-generic.

[Jim10 (g-van-zweeden)]

Confirmed

Gr,
Jim

[Goldy (sutrdudk)]

This bug valid also in 2009-05-15 .
Please give it a high priority: I want to at least BOOT the system.

Before that, I get an error that the device ata1 isn't ready.

Thanks.

[bonehead (braindead729)]

I can confirm the Kubuntu 64 bit install does this too. Tries to boot then drops to shell.

[bonehead (braindead729)]

I forgot to add to the above ^^^

I get the error 'Loading AppArmour module failed'

[Goldy (sutrdudk)]

Valid for 2009-05-19 as well.

Please solve it! don't you want me to upgrade?
How is it possible that "booting the system" is not a no. 1 praiority? Don't you want users to AT-LEAST get a non-graphic interface? How do you expect the bug "Microsoft has a majority market share" (no. one!) to be solved, if the simplest user must be a programmer? (fix his own bugs)

8.04 was perfect. 8.10 can be solved with acpi=off or pci=nomsi. 9.04 was RELEASED WITH the .dep BUG, & now it seems you broke all previous records by giving me the clue: "go back to windows".
I thought "ubuntu" is for the people, now I feel like paying for red-hat.

[Joachim Frieben (jfrieben)]

RE: Goldy wrote ..

Please stop spamming this bug report! Your ranting is complete nonsense given that Ubuntu 9.10 (which is -not- Ubuntu 9.05) is at an early alpha stage. Btw, it is still possible to install from the alternate install media which is what I have done successfully. If you want to upgrade a running system, then a dist-upgrade is also possible.
The squashfs issue will certainly be fixed for the next milestone release.

[Goldy (sutrdudk)]

You are so right! complaining about a bug that prevent boot is worng, but complaining about bugs for poor graphic, mouse pointer, wirless undetect etc. is very right... again: 9.05 was realese with bug that prevent booting!

Don't worry; I won't bother your system developers anymore: have fun explaining yourself how you benifit from loosing users.

[Geir Ove Myhr (gomyhr)]

Still present for daily-live 20090520. I don't think this really is a bug in squashfs, though. Squashfs is the source package for the binary package squashfs-tools that you receive with your ubuntu installation. While it would be nice if this was upgraded to version 4.x for Karmic, the real problem here is that the automatic building of the daily-live images uses squashfs 3.x instead of 4.x. This is not a bug in ubuntu per se, but in the part of Launchpad responsible for making the CD-images. I think that part is Soyuz, so I have added that package to the bug report (I also considered launchpad-buildd, but from the description on https://launchpad.net/launchpad-buildd it seemed that Soyuz was the right place to file).

[Geir Ove Myhr (gomyhr)]

Actually, this seems to be a known issue. From the "Known issues" on http://www.ubuntu.com/testing/karmic/alpha1 : "There are no desktop CDs with live systems available, since the current kernel still lacks support for the "aufs" file system."

So apparently aufs instead of squashfs will be used for the LiveCD in karmic.

[Celso Providelo (cprov)]

Soyuz isn't yet in charge of building CD images. The problem is elsewhere.

[Geir Ove Myhr (gomyhr)]

Making another guess: adding casper as a source package. There was an update to that package today, so maybe there's a change in tomorrow's daily-live. https://launchpad.net/ubuntu/karmic/+source/casper/1.175

PS: I've learned since my last comment that aufs is not a replacement for squashfs, but that both are required for the LiveCD to work properly.

[Geir Ove Myhr (gomyhr)]

I tried unpacking the <iso>/casper/filesystem.squashfs, unpacking it with unsquashfs, installing the 4.0 version from debian (http://packages.debian.org/unstable/admin/squashfs-tools) and remaking filesystem.squashfs with mksquashfs from that package. Booting got past the point where it stops now, but it does not work properly. It seems that the file system isn't in place. gdm complains about some directory missing and when being dropped to a shell, /bin/bash is missing.

[Colin Watson (cjwatson)]

casper isn't responsible for this - the bug is simply in the squashfs package. It should have been left there rather than bounced around all over the place. :-)

Although this bug is fairly trivial in itself, the reason we hadn't fixed this until now was that there was basically no point in doing so until we had a reasonable solution for a union filesystem in Karmic, given that aufs is apparently no longer particularly sanely supportable on the 2.6.30 kernel. I've been on the road, which slowed things down, but I got unionfs-fuse working earlier this week as a stopgap measure until we get proper VFS-level union mounts in the kernel (which are coming soon), so it's now worthwhile to deal with this.

[Colin Watson (cjwatson)]

I'm syncing squashfs from Debian unstable, which should deal with this. I'll be keeping an eye on things over the next couple of days.

[Updating] squashfs (1:3.3-7ubuntu2 [Ubuntu] < 1:4.0-1 [Debian])
 * Trying to add squashfs...
  - <squashfs_4.0-1.diff.gz: downloading from http://ftp.debian.org/debian/>
  - <squashfs_4.0.orig.tar.gz: downloading from http://ftp.debian.org/debian/>
  - <squashfs_4.0-1.dsc: downloading from http://ftp.debian.org/debian/>
I: squashfs [main] -> squashfs-tools_1:3.3-7ubuntu2 [main].

[Colin Watson (cjwatson)]

Geir: just for the record, the tool (livecd-rootfs) that builds our live filesystems simply installs the squashfs-tools package from karmic to do so ...

[Geir Ove Myhr (gomyhr)]

Thank you for clearing this up, Colin. Where is the best place to file a bug report when a LiveCD doesn't boot (next time, for some other reason)? Is the process of how the LiveCD documented somewhere? I found the logs at http://people.ubuntu.com/~ubuntu-archive/livefs-build-logs/ and http://people.ubuntu.com/~ubuntu-archive/cd-build-logs/ .

I have tried to find a bug report on the aufs support in the 2.6.30 kernel, but couldn't find one. The only thing I found was this thread: https://lists.ubuntu.com/archives/kernel-team/2009-February/004509.html .

[Colin Watson (cjwatson)]

In this case, the Karmic live CD was completely screwed, we knew about it and considered it just about top priority, but work on it was made difficult due to us all travelling to our developer summit and other related events. At the start of a release cycle you can usually expect that total across-the-board breakage such as this is already being handled.

In general, casper is a reasonable place to file live CD problems, and https://wiki.ubuntu.com/DebuggingCasper offers some advice on collecting debugging information.

The live filesystem is built by livecd-rootfs, which is packaged; the actual ISO is built by a somewhat shakier pile of scripts that isn't packaged (http://people.ubuntu.com/~cjwatson/bzr/cdimage/mainline/ and the stuff listed in configs/devel from there; you probably don't want to attempt to set this up unless you really REALLY have to ...).

The lack of aufs support in the 2.6.30 kernel is not a bug; it's deliberate, since aufs has been repeatedly refused for merge upstream and current available patches don't apply to 2.6.30. We're going to get 'mount --union' pretty soon, which will be a proper solution available in the upstream kernel and should be far preferable to any of the previous options.

[Geir Ove Myhr (gomyhr)]

On Thu, May 28, 2009 at 12:51 PM, Colin Watson wrote:
> In this case, the Karmic live CD was completely screwed, we knew about
> it and considered it just about top priority, but work on it was made
> difficult due to us all travelling to our developer summit and other
> related events. At the start of a release cycle you can usually expect
> that total across-the-board breakage such as this is already being
> handled.

I know we can't expect a working Live CD at the start of a release
cycle, but it would be nice to have an open bug report in launchpad
when it doesn't work. This way eager testers may subscribe to that
report and know when the Live CD is expected to work and start filing
bug reports for real bugs. Would you consider this for Karmic or LL?

Thank you for all the information about how the Live CD is built. Hope
you have good time in Barcelona!

[Colin Watson (cjwatson)]

On Fri, May 29, 2009 at 02:48:32AM -0000, Geir Ove Myhr wrote:
> I know we can't expect a working Live CD at the start of a release
> cycle, but it would be nice to have an open bug report in launchpad
> when it doesn't work. This way eager testers may subscribe to that
> report and know when the Live CD is expected to work and start filing
> bug reports for real bugs. Would you consider this for Karmic or LL?

Well, of course we will often file bugs for our own reference, but to be
honest I don't think testers would find such reports any easier to find
than the current situation. They would typically be filed on packages
currently believed to be actually causing a problem, rather than on some
general "live CD" package (we don't want to have such a general "live
CD" package because it would end up being a real nightmare to handle
since everyone would file bugs on it any time they had any problem at
all with the live CD), and I wouldn't want testers to have to trawl the
entire bug database before getting started.

I *am* sensitive to the amount of time that eager testers put in and I
don't want them to waste their valuable time, neither by testing things
that we already know don't work nor by having to trawl through the bug
database before they even get started. I think the best policy, really,
is for testers to assume that the entire world is broken at the start of
a release cycle (which it often is; it sometimes turns out to be more
efficient for us to just drop in all the new code from Debian and then
fix it up as necessary, rather than being slow and careful at each
step), and to only start testing once the release manager or somebody
coordinating testing activities says it's worthwhile doing so.

We're usually reasonably clear about this through such channels as
iso.qa.ubuntu.com and #ubuntu-testing, I think; once you see a CD up for
testing at an early alpha, you can fairly safely assume that by then
it's received very basic smoke-testing and is not a complete waste of
time.

If there's anywhere where we're being unclear about this right now, I'd
like to know about it so that we can fix it up.

[Joachim Frieben (jfrieben)]

Today's karmic-desktop.iso image file boots just fine.

[razor7 (ghiamar)]

Hello...I have downloaded Karmic Desktop AMD64 ISO image from here http://cdimage.ubuntu.com/releases/karmic/alpha-5/, burned it with brasero to a RW CD and testes in another PC.

When tries to boot, there is a blank screen, after that screen of aobut 1/2 second, the system falls into normal windows bootloader.

Any idea to solve this?

Thanks a lot!

[Colin Watson (cjwatson)]

You have some other problem, and it would be best to ask it elsewhere;
you aren't suffering from the bug you're replying to.

[panticz.de (panticz.de)]

The creation and boot of Ubuntu 9.10 LiveCD works fine unless you use the Koala version of
squashfs-tools http://packages.ubuntu.com/karmic/squashfs-tools. On my Ubuntu Jaunty I have to upgrade (see my script: http://www.panticz.de/LiveCD) squashfs-tools to 1:4.0-1, this fix all the boot problems.

[Colin Watson (cjwatson)]

I think you mean "works fine *if* you use the Karmic version of
squashfs-tools", not "unless".

[panticz.de (panticz.de)]

The creation and boot of Ubuntu 9.10 LiveCD works fine >> IF << you use the Koala version of
squashfs-tools... (of course IF and not unless, sorry!)

[razor7 (ghiamar)]

Hello...Tested with different CD-RW and worked OK without any problems.

Best regards!