When trying to build my own live-cd using catalyst, my pc got extremely slowly after some time, then the desktop was killed by the kernel and any other program, finally killing mksquashfs too. It seems as if mksquashfs tries to allocate more and more memory. I built a livecd one month ago on the same pc without a problem. I guess the switch from gcc-3.3.4 to gcc-3.4.2 was the problem.... Reproducible: Always Steps to Reproduce: 1. mksquash .. .. -noappend 2. 3. Actual Results: kernel killed every process on computer and in the end mksquashfs Expected Results: mksquashfs should have built the squashfs file :) The problem occurred not only when running the whole Desktop environment, but also when nothing else than mysquashfs was running on the computer Portage 2.0.51_rc6 (default-x86-2004.0, gcc-3.4.2, glibc-2.3.4.20040808-r0, 2.6.9-rc2 i686) ================================================================= System uname: 2.6.9-rc2 i686 Intel(R) Pentium(R) 4 CPU 2.20GHz Gentoo Base System version 1.5.3 distcc 2.17 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [disabled] Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux26-headers-2.6.8.1 Libtools: sys-devel/libtool-1.5.2-r5 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs distlocks fixpackages sandbox" GENTOO_MIRRORS="ftp://127.0.0.1 http://gentoo.inode.at http://gentoo.oregonstate.edu http://www.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aalib acpi alsa apache2 audiofile avi bitmap-fonts cdparanoia cdr cryptcscope cups curl dga directfb divx4linux doc dv dvb dvd dvdr emacs encode expat faac faad fam fbcon fbdev flac foomaticdb gatos gd gd-external gif gimpprint gphoto2 gpm graphviz gstreamer gtk gtk2 gtkhtml guile idea imap imlib innodb ipv6 jabber jack java javamail jikes jpeg junit kde lcms ldap libg++ libwww live lzo lzw-tiff mad mikmod mmx mng monkey motif mozdevelop mozilla moznocompose moznoirc moznomail mozsvg mpeg mysql ncurses nptl nvidia oggvorbis opengl pam pdflib perl pic png postgres ppds python qt quicktime readline rtc samba scanner sdk sdl slang slp speex spell sqlite sse sse2 ssl svg tcltk tcpd tetex tga theora tiff truetype usb v4l v4l2 vim-with-x wifi wmf x86 xine xinerama xml xml2 xmms xprint xv xvid xvmc yv12 zlib zvbi linguas_de"
I forgot to mention that I've already tried version 2.0 and 2.0_p2 of squashfs, both appear to have the same problem. I just compiled squashfs using gcc-3.3.4-r1 ( eval 'gcc-config -E 1'; emerge squashfs-tools ) and the problem is still there. The problem only seems to occur, when dealing with rather big files, atm, the final squashfs-build should have a size of about 300Mib
Reassigning to the maintainer adding embedded@ cuz we care about squashfs solar@simple ~ $ metadata.py sys-fs/squashfs-tools Package: sys-fs/squashfs-tools Herd: livecd Maintainer: livecd
I'm just curious, but how much swap/RAM do you have?
256MB memory + 256 MB swap
Sounds invalid to me. Somebody with >=1G Ram should test.
I honestly think there's a good possibility that you're memory-starving catalyst. I build LiveCDs almost daily and I can tell you that I eat through a *lot* more memory than that pretty easily with my system doing nothing else. Are you sure you just aren't running out of memory?
Works fine here on 512MB RAM + 1.5GB swap (and I swap on this machine when building minimal ISOs), on my laptop with 1GB of RAM (no swapping), and on my main machine with 2GB.
ok, I mistyped my swap-space in the last comment, I have 512 MB of swap space, so about 768MB virtual memory. At the moment I solved my particular problem by simply putting this ~300mb bzipped tar-file into the isolinux-directory, instead of the squahfs-dir structure. Now mksquashfs works without a problem. So the problem hast to be this large file. the memory usage of mksquashfs with the 300mb file in the directory structure looks roughly like that: Most of the time it has a memory usage according to 'top' of about 3 to 4%, seems to be perfectly normal, then after about 2 minutes, it suddenly starts to allocate memory very quickly. five seconds later I can hear heavy disk access => the kernel is starting to swap and I can't interact with either mksquashfs nor with top after a few seconds.( Ctrl + C and q don't work ) Well, sounds like a bug to me... And I don't really think that more than 750 mb of virtual memory is needed for creating a ~320 mb squashfs....
Are you running mksquashfs while in X? Have any high-load daemons running? Gnome? KDE? I've been working on the 2004.3 LiveCD and I'm not quite sure that you aren't running out of RAM/swap. I have 2GB in my machine and making the squashfs image seems to sake quite a bit of power. I'll perform another run of just making the squashfs image and post here.
I just compressed a 1G system down to 258M on my laptop just now with only 512M and no swap. vote WORKSFORSOME
Sounds good to me... considering we've been building releases like crazy wit it and have seen no such problems.
I'll give it another try on the weekend, I'll report the results then
