kevwalker wrote:

This sounds like something that will work on all flavors of Ubuntu. Should I worry if I'd like to "squash" my Gutsy install using this technique?

It should work exactly the same on any of the Ubuntu Gutsy variants.

It will work on other distributions, too, provided that they have the necessary modules, but some details will be different.

I'm trying it now. Having installed eeeXubuntu to an SDHC, writing the little endian 3 filesystem takes quite a while. I'll report back if it works.

Wow, just amazing! I did everything according to the blogpost, backing up my /usr dir to /dir.old on a bootable disc.

When I returned to eeeXubuntu, I did an df -h:

epo@eeepo:~$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb1             3.2G  2.0G  1.1G  66% /
varrun                248M   84K  248M   1% /var/run
varlock               248M     0  248M   0% /var/lock
udev                  248M   84K  248M   1% /dev
devshm                248M     0  248M   0% /dev/shm
/.filesystems/usr/usr.sqfs
                      3.6G  2.4G  1.1G  70% /usr
unionfs               3.6G  2.4G  1.1G  70% /usr

As you can see, my / is about 66%. That's the way it used to be. Because everything seems to work, I got rid of the /usr.old directory:

epo@eeepo:~$ sudo rm -rf /usr.old/

Then did another df -h:

epo@eeepo:~$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb1             3.2G  812M  2.2G  27% /
varrun                248M   84K  248M   1% /var/run
varlock               248M     0  248M   0% /var/lock
udev                  248M   84K  248M   1% /dev
devshm                248M     0  248M   0% /dev/shm
/.filesystems/usr/usr.sqfs
                      3.6G  1.2G  2.2G  36% /usr
unionfs               3.6G  1.2G  2.2G  36% /usr

Sweet! I now have 2,2GB free instead of 1,1GB!

threedaymonk: Are there things we should know?

Last edited by Epo (2008-01-06 6:06:22 pm)

Seems very interesting. One question I have - what if I want to remove a package which resides in /usr?

I tend to do a lot of testing and dumping of packages, and would hate to think I'm stuck with something.

Thanks for the info! I tried it and it didn't work though. Manually modprobing squashfs and unionfs doesn't work, I get an error that these modules don't exist. Is there something I should be installing for these modules?

I ran into a problem where my squashed eeeXubuntu was not booting right.  Eventually I managed to figure it out, but it was really frustrating, so I'm posting my experience here with the hopes that I might save someone else the same anguish.

I shrank my /usr with squashfs and unionfs as described above several weeks ago.  It ran fine for a while, but then for some reason, possibly related to a security upgrade, it started to hang on the boot, with the progress bar stalled underneath the "b" in xubuntu.  It took me a while to figure out the problem, since it was okay if I booted into recovery mode from Grub.  I temporarily disabled the splash screen following instructions here: http://www.foogazi.com/2007/10/27/remov … sh-screen/ and eventually discovered that the culprit was likely "readahead," which it turns out has some issues with the old version of unionfs shipped in Ubuntu Gutsy, detailed here: http://thread.gmane.org/gmane.comp.file … focus=2704 

So therefore I decided to disable readahead.  I tried doing an apt-get remove of it (using the -s switch to simulate it first) but it wanted to remove the xubuntu-desktop as well, since it apparently is listed as a dependency.  So I instead renamed the scripts in /etc/rc.d then removed the symlinks using the "update-rc.d" command.  The simple thing (combining both steps) would have been to do

update-rc.d -f readahead remove
update-rc.d -f readahead-desktop remove
update-rc.d -f stop-readahead remove

These would need to be done as the superuser, of course, which is automatic if you are in recovery mode.  After that, I rebooted and everything has been fine since.  The purpose of "readahead" is to speed up the boot time, but I haven't noticed much, if any slowdown in the boot time. Even if there was, though, I'd happily live with it in order to have squashfs saving me all that space.

Thanks for that one enystrom . I applied it to my squashfs xubuntu install, which wasn't actually crashing just pausing for a long time at about 5%. This immediately fixed it and shaved ~15 seconds off the boot.

Could you tell me how fast the squashed system (xandros as well as ubuntu is) regarding boot time and general fluentness (e.g. starting firefox etc.).

Great tutorial, I read this one some time ago and I was thinking about something similar before installing slackware. I just didn't do that because I think the writes would be overkill for the SSD.
I mean: squashfs is a readonly filesystem, how do you keep persistent changes after an update? you'd end booting up the system unionfs mounting usr.squashfs, apply changes and writing back a newer usr.squashfs. If this is done at every shutdown you kill your SSD very swiftly. On the other hand, if you could selectively do it whenever you change something to /usr but it seems a little unfeasible to me, in any case the amount of data written (a compressed usr) doesn't compare too well to the changes you'd end up mading (maybe just a small binary).

Or am I totally wrong and you can get both the squashed mount point and the changes you made without a total rewrite?

ok, now it looks better
sounds very interesting... maybe the "resquashing" can be done at major system upgrade or via a monthly anacron job.

SeeSharp wrote:

Also unionfs writes special hidden 0-sized files in the rw branch, so be sure to remove them after the resquashing and before the new mount

Shouldn't those not appear at all since we do a mksquashfs on the /usr directory after unionfs is already mounted on top of it?

And what is better and easier to use? Unionfs or aufs?

I am very interested in this topic and I will certainly try it out when I get my SDHC back which was bricked by the EEE.

Last edited by MrMage (2008-03-21 1:59:50 pm)

enystrom wrote:

I ran into a problem where my squashed eeeXubuntu was not booting right.  Eventually I managed to figure it out, but it was really frustrating, so I'm posting my experience here with the hopes that I might save someone else the same anguish.

I shrank my /usr with squashfs and unionfs as described above several weeks ago.  It ran fine for a while, but then for some reason, possibly related to a security upgrade, it started to hang on the boot, with the progress bar stalled underneath the "b" in xubuntu.  It took me a while to figure out the problem, since it was okay if I booted into recovery mode from Grub.  I temporarily disabled the splash screen following instructions here: http://www.foogazi.com/2007/10/27/remov … sh-screen/ and eventually discovered that the culprit was likely "readahead," which it turns out has some issues with the old version of unionfs shipped in Ubuntu Gutsy, detailed here: http://thread.gmane.org/gmane.comp.file … focus=2704 

So therefore I decided to disable readahead.  I tried doing an apt-get remove of it (using the -s switch to simulate it first) but it wanted to remove the xubuntu-desktop as well, since it apparently is listed as a dependency.  So I instead renamed the scripts in /etc/rc.d then removed the symlinks using the "update-rc.d" command.  The simple thing (combining both steps) would have been to do

Code:

update-rc.d -f readahead remove
update-rc.d -f readahead-desktop remove
update-rc.d -f stop-readahead remove

These would need to be done as the superuser, of course, which is automatic if you are in recovery mode.  After that, I rebooted and everything has been fine since.  The purpose of "readahead" is to speed up the boot time, but I haven't noticed much, if any slowdown in the boot time. Even if there was, though, I'd happily live with it in order to have squashfs saving me all that space.

i had a similar problem . readahead was copying the entire squashfs to ram on boot,

to solve this i did  sudo mousepad /etc/readahead/boot and removed the line pointing to the squashfs

doing this on Icebuntu has made the install size under 500mb (was 700/800mb to begin with), and made boot tome 4 seconds faster!


mark@eeepc:~$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             3.5G  459M  2.9G  14% /
varrun                248M   60K  248M   1% /var/run
varlock               248M     0  248M   0% /var/lock
udev                  248M   76K  248M   1% /dev
devshm                248M     0  248M   0% /dev/shm
lrm                   248M   34M  215M  14% /lib/modules/2.6.22-14-generic/volatile
/tmp                  2.0M  292K  1.8M  15% /tmp
vartmp                1.0M     0  1.0M   0% /var/tmp
varlog                8.0M  656K  7.4M   9% /var/log
/.filesystems/usr/usr.sqfs
                      3.7G  646M  2.9G  18% /usr
unionfs               3.7G  646M  2.9G  18% /usr
/dev/sdb1             1.9G  486M  1.4G  26% /media/disk
mark@eeepc:~$

Are there any other folders that can be moved to squashfs to save more space?

Edit: i have also done this with /var

mark@eeepc:~$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1             3.5G  382M  3.0G  12% /
varrun                248M   40K  248M   1% /var/run
varlock               248M     0  248M   0% /var/lock
udev                  248M   76K  248M   1% /dev
devshm                248M     0  248M   0% /dev/shm
lrm                   248M   34M  215M  14% /lib/modules/2.6.22-14-generic/volatile
/.filesystems/usr/usr.sqfs
                      3.7G  569M  3.0G  16% /usr
unionfs               3.7G  569M  3.0G  16% /usr
/.filesystems/var/var.sqfs
                      3.6G  410M  3.0G  12% /var
unionfs               3.6G  410M  3.0G  12% /var
varlog                8.0M  500K  7.6M   7% /var/log
vartmp                1.0M     0  1.0M   0% /var/tmp
/tmp                  2.0M  524K  1.5M  26% /tmp
/dev/sdb1             1.9G  2.9M  1.8G   1% /media/disk
mark@eeepc:~$

your tutorial has made a huge difference, it has almost halfed my install size, thankyou!!

not sure how well this will work with var in the long run

Last edited by markp1989 (2008-04-08 1:18:24 pm)

kevwalker wrote:

This sounds like something that will work on all flavors of Ubuntu. Should I worry if I'd like to "squash" my Gutsy install using this technique?

Hi,
It will actually work on any distribution with a Linux kernel that has the squashfs and unionfs modules available.
I did the same on Mandriva 2008.1 on an SDHC card.