SliTaz Forum
You are not logged in.
Pages: 1
hey folks,
as stated, i have issues with cofiguring a rootfs.gz with some software. the files size is around 650mb.
when trying to boot with it, i get an error saying the file is too large.
is there a way to split it to smaller files or to enable larger initramfs files?
thx
Offline
Hallo K3nn3th,
I think, the problem is, that there is not enough memory to unpack such a big rootfs.gz if not using spezial commands for the allocation of memory like in the isolinux.cfg
LABEL slitaz
MENU LABEL SliTaz Live
kernel /boot/isolinux/ifmem.c32
append 192M core 160M gtkonly 100M justx 48M base noram
of SliTaz 4 in 1, but I don't have experience with this.
I successfully manualy splitted the unpacked *.tazpkg into 10 parts like this.
In the 4 in 1 design I renamed
rootfs4.gz -> rootfs9.gz
rootfs3.gz -> rootfs8.gz
rootfs2.gz -> rootfs7.gz
rootfs1.gz -> rootfs6.gz
and added personal rootfs5.gz, rootfs4.gz, rootfs3.gz, rootfs2.gz, rootfs1.gz and rootfs0.gz making a new personal 10 in 1 design with the following lines in my isolinux.cfg
LABEL Personal
MENU LABEL SliTaz Personal
KERNEL /boot/bzImage
append initrd=/boot/rootfs9.gz,/boot/rootfs8.gz,/boot/rootfs7.gz,/boot/rootfs6.gz,/boot/rootfs5.gz,/boot/rootfs4.gz,/boot/rootfs3.gz,/boot/rootfs2.gz,/boot/rootfs1.gz,/boot/rootfs0.gz lang=de_DE kmap=de-latin1 rw root=/dev/null vga=normal autologin
I booted successfully with rootfsx.gz about 25 MB (lzma) or 35 MB (gzip).
lzma packing the rootfsx.gz
in /home/slitaz/rootfsx
like
# find . -print | cpio -o -H newc | lzma e -si -so > ../rootfs.gz
produces smaller files but needs more memory to unpack.
gzip packing the rootfsx.gz like
# find . -print | cpio -o -H newc | gzip -c > ../rootfs.gz
produces biger files but it need less memory to unpack.
Unpacking in shorter time I managed using a DVD instead of a CD.
I don't have experience in splitting into more than 10 parts. My biggist gzip packed rootfsx.gz on CD or DVD was 36 MB. I would try 10 gzip packed rootfsx.gz (x=10,9,8,...,1,0) about 70 MB.
For extracting your *.tazpkg you could copy my extractor to /usr/bin/extractor
#!/bin/sh
#
# Extractor for a directory of taz packages powered by Yad/GTK.
#
# Copyright (C) 2014 SliTaz GNU/Linux - BSD License
#
# Author: nobody@slitaz.org
#
# Common boxes options.
opts=" --height=200 --width=500 --image=computer --image-on-top"
title="Extractor for Packages"
# Main GUI box function with pure Yad spec
extractor_main() {
yad --form $opts --window-icon=computer \
--text="<b>$title</b> - *.tazpkg into file system" \
--title="$title" \
--field="$(gettext "tazpkg directory:")":DIR \
--field="$(gettext "file system dir:")":DIR\
--button="Extract":0 \
--button="gtk-close":1 \
$home $home
}
# Main function
extractor() {
# Store box results
main=$(extractor_main)
# Deal with --button values
case $? in
0) continue ;;
*) exit 0 ;;
esac
# Deal with $main values.
dir1=$(echo $main | cut -d "|" -f 1)
dir2=$(echo $main | cut -d "|" -f 2)
cd $dir1
for f in *.tazpkg;
do
PACKAGE=$(basename $f .tazpkg)
PACK=${PACKAGE%%.*}
PKG=${PACK%-*}
mkdir -p $dir2/fs/var/lib/tazpkg/installed/$PKG
chown root:root /fs/var
chown root:root /fs/var/lib
chown root:root /fs/var/lib/tazpkg
chown root:root /fs/var/lib/tazpkg/installed
chown root:root /fs/var/lib/tazpkg/installed/$PKG
mkdir -p /tmp/cpio
cd $dir1
md5sum $PACKAGE.tazpkg >> $dir2/fs/var/lib/tazpkg/installed.md5
cd /tmp/cpio
rm -rf *
cpio -idmv -F $dir1/$PACKAGE.tazpkg
cp fs.cpio.lzma /tmp
rm fs.cpio.lzma
cp * $dir2/fs/var/lib/tazpkg/installed/$PKG
rm *
cd $dir2
rmdir /tmp/cpio
lzma d /tmp/fs.cpio.lzma $dir2/fs.cpio
rm /tmp/fs.cpio.lzma
cpio -idmv -F fs.cpio
rm fs.cpio
done;
}
#
# Script commands
#
case "$1" in
usage)
echo "Usage: $(basename $0) [command]" ;;
*)
extractor ;;
esac
exit 0
and copy the following file extractor.desktop to /usr/share/applications
[Desktop Entry]
Encoding=UTF-8
Name=Extractor
Exec=extractor
Icon=computer
Type=Application
Categories=Development;
I was even able to install my personal SliTaz4.0 of 210 MB with the SliTaz Panel to harddisk, which does not work when you use complete other names for the rootfs9, ..., rootfs0.gz.
Offline
i managed to spli it into two files, rootfs.gz.aa and rootfs.gz.ab
after updating my menu.lst i still get the error.
does it have anything to do with the names not being rootfsX.gz (X=number) or is it still related to the resulting size after adding them back together?
can anyone tell me the size limit for the rootfs.gz file?
i have another one with 420MB size and it boots fine...
i have 4Gb ram
@kubepc: so i just have to get the tazpkg's for the software i need and convert with your script, then append the .gz's to a normal frugal initramfs (after renaming)?
Offline
@K3nn3th,
yes you can use my extractor as root for unpacking some .tazpkg into a directory called fs, but after this You have to pack the tree as root in its directory with
# find . -print | cpio -o -H newc | gzip -c > ../rootfs.gz
The names of the rootfs.gz are important, if you want to edit the ISO image of SliTaz 4.0 (4 in 1) with isomaster. The SliTaz Panel expects rootfsX.gz (X=number) files for installation from ISO file, CD or DVD. Otherwise it does not install. If you don't care about the installation from ISO, CD or DVD, You don't have to use special names. If You want to unpack Your rootfs.gz files from harddisk with a menu.lst, You can use any names like in this example menu.lst, which I used with grub4dos on (hd0,0) formated with fat32 or ntfs
title SliTaz special
root (hd0,0)/special
kernel /bzImage rw autologin
initrd /base.gz /justx.gz /gtkonly.gz /core.gz /a.gz /b.gz /c.gz
with the rootfs.gz files base.gz, justx.gz, gtkonly.gz, core.gz, a.gz, b.gz, c.gz and the bzImage in the directory named special. But You should not pack too much too tight. If you use the lzma method in the directory of Your tree
# find . -print | cpio -o -H newc | lzma e -si -so > ../rootfs.gz
You get smaller images, because lzma packs very tight, but afterwarts it could be, that You don't have enough memory to unpack. This depends not only on the method, but also on the type of files You pack. Using more but smaller files is more successfull. Packing with gzip is more successfull, you get a higher file size limit and it is faster than with lzma, especially when the files are big.
I also got problems, when the images on harddisk weren't contiguous. I copied big files with Windows to avoid getting discontiguous images on the harddisk.
Offline
The problem may come from the boot loader. Grub legacy assume 256MB max.
The floppy boot loader start a slitaz base with a custom /init, and this /init load the other rootfs.
See: http://hg.slitaz.org/slitaz-tools/file/0e6196e79283/oldstuff/gtkdialog/bootfloppybox#l247
The load loop; http://hg.slitaz.org/slitaz-tools/file/0e6196e79283/oldstuff/gtkdialog/bootfloppybox#l309
This trick should avoid memory limits.
Offline
@Bellard: thanks for the workaround, ill give it a try.
256MB sounds strange though, as i have an uncompressed rootfs.gz with around 400MB size which i can boot from.
could it be 512MB?
Offline
@Bellard: I have no idea how to use the floppy boot loader trick you told me.
is there a way to tell the kernel to support larger initramfs files? maybe theres a wayto compile a new one with a higher limit?
Offline
as stated before i have a 420MB rootfs.gz which i can boot from.
after adding stuff, making a new rootfs.gz without compression gave me a 600MB file.
-> couldnt boot from it.
making a (GZIP)compressed rootfs.gz it results in around 200MB (under 512MB ?!) and ..
-> it works!
i'll have to give the extractor method a try. i have to say im a fan of having uncompressed rootfs.gz's because my machine boots faster with them (no decompressing needed!).
can i just leave out the last pipe in the command
find . -print | cpio -o -H newc | lzma e -si -so > ../rootfs.gz
so it looks like
find . -print | cpio -o -H newc > ../rootfs.gz
?
there should be a way of allowing bigger files, or am mistaking...?
Offline
@kubepc: im doing it your way now.
i wanted to rebuild my distros, but i'm encountering an error while booting.
heres what i did:
started off with the 4-in-1 rolling
added extractor.gz (i made with the two files you gave me and the cpio command) to the initrd line, and after booting i can see it in the menu and use it. so far so good.
now, i added software (VLC player, firmware-rtlwifi) via tazpkg -gi and looked into /var/cache/tazpkg/5.0/packages
there i found the pakages + packages of dependencies.
- extracted them via your extractor
- cd into the fs folder in the output field stated in extractor
# find . -print | cpio -o -H newc | gzip -c > ../standard.gz
# mv ../standard.gz /home/boot/frugal/
appended /home/boot/frugal/standard.gz to my menu.lst entry
then the error occurs:
whats the trouble here? i dont see whats causing the problem cause it worked with extractor.gz
Offline
I think with 4.0 I was able to boot rootfs.gz in excess of 800MB, with the lowram package added to it.
No idea for 5.0 RCs
Offline
The initramfs must be aligned on 32 bits. For each rootfs.gz do :
$ dd if=/dev/zero bs=1 count=$(((4 - ($(stat -c %s rootfs.gz) % 4)) % 4)) >> rootfs.gz
Offline
@Bellard: tried your command but apart from reducing the image size by 2 bytes nothing happened. i still get the error.
what exactly do you mean by the floppy trick?
@cristophe: how did you do that? is the lowram package the key to this?
thanks for the replies guys
Offline
It is an old story I do not remember the specific. it could be loram instead of lowram, (and it could also be V3 instead of V4)
the sad thing is that I do not remember how I got that package. Maybe this will ring a bell for people like Bellard, I had the help from one of these knowledgeable guys.
You may want to investigate somewhat
And, yes, from what I remember, the package was the key to make the whole thing work.
Offline
@K3nn3th,
I testet the rootfs.gz boot issue on 3 personal computers.
I can confirm Your error with SliTaz 5.0 (rolling 2014-11-09) on a computer booting Windows Boot Manager from Windows 7 (32 Bit) and then GRUB4DOS or Windows Boot Manager and then GRUB, but it is fine with SliTaz 4.0 booting Windows Boot Manager and then GRUB4DOS or Windows Boot Manager and then GRUB.
On a computer without Windows having only a FAT32 partition and booting with GRUB4DOS there are no problems booting with the following menu.lst
title SliTaz 4.0 GNU/Linux 1920x1200x24
root (hd0,0)/sl40
kernel /bzImage lang=en_US kmap=us screen=1920x1200x24 rw autologin
initrd /rootfs4.gz /rootfs3.gz /rootfs2.gz /rootfs1.gz
or
title SliTaz 5.0 rolling GNU/Linux Deutsch DE 1920x1200 modified
root (hd0,0)/rolling
kernel /bzImage lang=de_DE kmap=de-latin1 video=1920x1200-32@60 rw autologin
initrd /rootfs4.gz /rootfs3.gz /rootfs2.gz /rootfs1.gz /rootfs0.gz
On a computer with Windows XP booting with ntldr and then GRUB4DOS and then SliTaz as described above everything is fine with SliTaz 4.0 and SliTaz 5.0 rolling.
Booting from ISO like
title SliTaz rolling-2014-11-09a ISO CD image
map --mem /slitaz-rolling-2014-11-09a.iso (hd32)
map --hook
chainloader (hd32)
I was successfull via Windows Boot Manager and the GRUB4DOS after making some changes to slitaz-rolling-2014-11-09.iso which does not boot this way. Because SliTaz 4.0 boots this way, I changed everything with isomaster on the slitaz-4.0 iso but kept /boot/isolinux/isolinux.bin so that it became a
slitaz-rolling-2014-11-09a.iso
with the following isolinux.cfg
UI vesamenu.c32
PROMPT 0
TIMEOUT 80
# Menu settings
MENU TITLE SliTaz GNU/Linux - 5.0-RC2 20141109a
MENU BACKGROUND splash.jpg
MENU WIDTH 78
MENU MARGIN 6
MENU ROW 16
MENU VSHIFT 0
MENU TIMEOUTROW 20
MENU TABMSGROW 18
MENU CMDLINEROW 18
# Menu colors
MENU COLOR border * #00000000 #00000000 none
MENU COLOR title * #ffffffff #00000000 *
MENU COLOR sel 0 #ffffffff #00000000 none
MENU COLOR unsel 0 #50ffffff #00000000 none
#MENU COLOR help 37;40 #c0ffffff #a0000000 std
MENU COLOR help * #ffffffff #00000000 *
MENU COLOR timeout_msg 37;40 #80ffffff #00000000 std
MENU COLOR timeout 1;37;40 #c0ffffff #00000000 std
MENU COLOR msg07 37;40 #90ffffff #a0000000 std
MENU COLOR tabmsg 31;40 #30ffffff #00000000 std
# Labels
LABEL deepsky
MENU LABEL SliTaz Cleerlooks DeepSky
COM32 c32box.c32
append linux /boot/bzImage initrd=/boot/rootfs4.gz,/boot/rootfs3.gz,/boot/rootfs2.gz,/boot/rootfs1.gz,/boot/rootfs0.gz rw root=/dev/null autologin
LABEL 1920x1200
MENU LABEL SliTaz Cleerlooks DeepSky 1920x1200x24
COM32 c32box.c32
append linux /boot/bzImage initrd=/boot/rootfs4.gz,/boot/rootfs3.gz,/boot/rootfs2.gz,/boot/rootfs1.gz,/boot/rootfs0.gz video=1920x1200M-32@60 rw root=/dev/null autologin
LABEL slitaz
MENU LABEL SliTaz Live
COM32 c32box.c32
append ifmem 192M core 160M gtkonly 100M justx 48M base noram
label noram
MENU HIDE
config noram.cfg
LABEL core
MENU LABEL SliTaz core Live
COM32 c32box.c32
append linux /boot/bzImage initrd=/boot/rootfs4.gz,/boot/rootfs3.gz,/boot/rootfs2.gz,/boot/rootfs1.gz rw root=/dev/null autologin
LABEL gtkonly
MENU LABEL SliTaz gtkonly Live
COM32 c32box.c32
append linux /boot/bzImage initrd=/boot/rootfs4.gz,/boot/rootfs3.gz,/boot/rootfs2.gz rw root=/dev/null autologin
LABEL justx
MENU LABEL SliTaz justx Live
COM32 c32box.c32
append linux /boot/bzImage initrd=/boot/rootfs4.gz,/boot/rootfs3.gz rw root=/dev/null autologin
LABEL base
MENU LABEL SliTaz base Live
COM32 c32box.c32
append linux /boot/bzImage initrd=/boot/rootfs4.gz rw root=/dev/null autologin
LABEL help
MENU LABEL Help & Options
MENU HELP help.en
INCLUDE i18n.cfg
LABEL memtest mem ram
MENU LABEL Check memory
KERNEL /boot/memtest
Offline
is there a way to do this without editing the iso file?
i dont understand why adding extractor.gz worked, whereas adding VLC and firmware-rtlwifi additionally seemed to mash things up.
@Bellard: could you explain the floppy method you mentioned earlier? maybe you can shed some light on my error stated above
Offline
@K3nn3th,
to avoid editing iso files and booting them, You should avoid the Windows Boot Manager, which is my problem on one of my computers, and which I think is Your problem on Your current computer.
On my computer, a Quanmx KUBE-8080, I could boot 3 month ago the rootfsx.gz files of SliTaz 5.0 RC2 with both GRUB and GRUB4DOS. This was before I installed Windows 7, which I need for my job. Now this is impossible. I even get the same error on my display with SliTaz 5.0 rolling. I think it is because the computer boots first with the Windows Boot Manager, then it goes to GRUB or alternativly to GRUB4DOS, which I use to start SliTaz 4.0 and ISO files of SliTaz 5.0 rolling. I should have started booting with GRUB.
But there is an alternative. I can still boot the rootfsx.gz files of SliTaz rolling from my USB-Stick (/dev/sdc) on this computer. I have made it bootable with bootlace and had installed GRUB4DOS with the following commands.
X Term Terminal:
su
Password: root
bootlace --time-out=0 /dev/sdc
lzma d /usr/share/boot/grldr.lzma /media/disk/grldr
If You don't like booting from USB-Stick or CD or DVD, You should change to SliTaz 4.0 or should boot with GRUB or GRUB4DOS first of all. With only GRUB4DOS I had no problems booting rootfs.gz files on three different computers. But on a different hardware You can probably have different experiences.
Have You used the Windows Boot Manager?
Can You boot a SliTaz 5.0 rolling via GRUB4OS from Your USB-Stick?
Offline
@K3nn3th,
I found my at least my own error for my kernel panic. In the GRUB menu.lst
title SliTaz rolling English US
root (hd0,0)/boot/rolling
kernel /bzImage lang=en_US kmap=us rw autologin
initrd /rootfs4.gz /rootfs3.gz /rootfs2.gz /rootfs1.gz /rootfs0.gz
I had a wrong letter in the last line. I wrote intitrd and should have written initrd. This wrong letter was the reason for my kernel panic on my PC with the Windows Boot Manager. Now it works even when booting first the Windows Boot Manager then GRUB and then SliTaz rolling (5.0). I should not have blamed the Windows Boot Manager.
Maybe You have a similar error. Try something more simple and do it without the commands for language, keyboard map and video like this simple entry
title SliTaz rolling
root (hd0,0)/boot/rolling
kernel /bzImage rw autologin
initrd /rootfs4.gz /rootfs3.gz /rootfs2.gz /rootfs1.gz /rootfs0.gz
Have You written correctly the key words title, root, kernel and initrd? Maybe You have choosen the wrong root directory or maybe you have forgotten a slash or something like that. Repeat what You have done! Maybe You had a damaged file.
As I see know, a simple wrong letter can crash it all.
Offline
Ill have to spend more time trying around with the extractor-append-method.
at the moment its easier and faster simply rewriting the rootfs.gz file entirely.
im still stuck at the OP situation.
tried with the loram package but no success.
I'm at a point where id really like to use "no compression" because it would speed up booting a lot..
might i have something to do with grub4dos?
havent tried using grub2 yet, cause i dont know the correct parameters/syntax
any ideas? i can imagine this issue being common with huge rootfs.gz's
Offline
grub2 tells me (using a >500mb rootfs.gz)
error: initrd too big
and i can press a key to continue
then i see some kernel messages
and panic.
VFS: Cannot open root device "null" or unknown-block(0,0)
what a pity! it'd make life so much easier for me if i could use one big file..
any ideas what i could try?
thanks
Offline
i tried splitting my filesystem into to 2 rootfs.gz files (qtLess.gz (443 mb) and qt4stuff.gz (130 mb, exctracted qt4-Dev packages)), both of them uncompressed, for perfomance reasons.
adding both into the bootloader line results in kernel panic (initrd too large)
removing qt4stuff.gz from the line (booting only qtLess.gz) works fine. looks like they get appended and then the size check occurs, instead of beforehand.
splitting it up into several smaller files (rootfs1.gz ... rootfsX.gz) would therefor not work IMHO
can anyone give me any tips on this?
Offline
manually adding the contents of qt4stuff.gz to the running filesystem i got from booting qtLess.gz works.
this could be automated with a script executed at startup. this way i could build up a parallel file system which is loaded in after boot.
ive appended the contents of the installed.md5 from the extracted packages to my filesystem's own /var/lib/tazpkg/installed.md5
this is not enough for telling my system the packages were installed. what other files have to be patched at startup in order to have tazpkg "recognize" the manually installed packages? (this would enable me to be notified for updates for those packages)
Offline
Im still struggling about with this, id really like to have my rootfs.gz uncompressed, but over 500mb.
just cant get it to work..
Maybe anyone stumbling across has any ideas?
Offline
@K3nn3th,
I have unpacked as root each rootfs4.gz ... rootfs1.gz of original SliTaz
from the inside of a container directory rootfs4 ... rootfs1 respectively with the command
(zcat rootfs.gz 2>/dev/null || lzma d rootfs.gz -so) | cpio -idmv
and afterwards I have removed the rootfs.gz.
For my own files I use the extractor and rename fs to rootfs0.
Then I execute as root from the inside of each directory rootfs
find . -print | cpio -o -H newc | cat > ../rootfs.gz
for just storing the files uncompressed.
You can copy rootfs4.gz ... rootfs0.gz together with bzImage to a directory
slitaz on Your harddisk (hd0,0)
and boot with grub or grub4dos with the following menu
title SliTaz fast
root (hd0,0)/slitaz
kernel /bzImage lang=en_US kmap=us rw autologin
initrd /rootfs4.gz /rootfs3.gz /rootfs2.gz /rootfs1.gz /rootfs0.gz
.
The receipt and file.list of each package should be in /var/lib/tazpkg/installed/pkg-name.
This does the extractor, but the extractor does not provide /var/lib/tazpkg/installed.info
and does not copy all installed.md5 files in one file.
The file installed.info is a tabulator sepearated text file.
You can edit it with gnumeric and add Your packages to the list.
Then store it again as text file with tabs between the columns. This was too much work for me.
So I installed my packages manualy to the live system.
Afterwards I took the updated installed.md5 and installed.info to
rootfs0/var/lib/tazpkg/ where I finally packed all my files inside rootfs0 to a rootfs0.gz.
I have done this just with slitaz-rolling-core64.iso. The new rootfs.gz is now 168 MB.
I have booted it sucessfully together with my own 33 MB rootfs0.gz (compressed only 9 MB)
in 20 seconds with the following menu
title SliTaz 5.0 rolling 64
root (hd0,0)/rolling64
kernel /bzImage64 lang=de_DE kmap=de-latin1 rw autologin
initrd /rootfs.gz /rootfs0.gz
Offline
Hi kubepc,
My five cents.
I have unpacked as root each rootfs4.gz ... rootfs1.gz of original SliTaz
. . .
You can copy rootfs4.gz ... rootfs0.gz together with bzImage to a directory
SliTaz-Core flavor is more handy it contains inside only one rootfs.gz file instead of four, so it requires 5 times less work.
but the extractor does not provide /var/lib/tazpkg/installed.info
and does not copy all installed.md5 files in one file.
The file installed.info is a tabulator sepearated text file.
You can edit it with gnumeric and add Your packages to the list.
Then store it again as text file with tabs between the columns. This was too much work for me.
TazPkg can re-create “installed.info” file automatically. Just remove it and run “tazpkg” without options as root user:
[c]su
rm /var/lib/tazpkg/installed.info
tazpkg[/c]
Offline
hey guys, thanks for your replies.
@kubepc:
im doing something similar at the moment, when its possible.
i start a fresh rolling frugal install with the compressed rootfs4.gz - rootfs1.gz
when its booted, i do:
$ tazusb writefs none
and have a non-compressed image of the filesystem.
when extending it (adding packages and reissuing the above command) everything is okay, until i reach around 500 mb.
after that i cannot boot from the rootfs.gz anymore, i get
initrd too large to handle
at boot.
i can get it to work though, if i compress my 500mb rootfs.gz via gzip/lzma.
now its around 300mb and it boots (slower, of course, as it has to decompress).
i still dont understand why its "too large to handle", whereas the compressed one is okay, but yields the same result (filesystem) in the end...
can someone explain this size-check to me?
someone mentioned booting ~800mb rootfs.gz files with slitaz 3/4, can anyone confirm or post a workaround?
this would speed things up a lot...
ive got one frugal install where i can choose to add certain .gz files to my live system after boot, via a script that decompresses a .gz file i created using the extractor from kubepc. this enables me too keep the main rootfs.gz uncompressed and allows me to boot faster. however, id just like to have the additional packages in by default and still not compress it..
thanks for any help!
Offline
Pages: 1
[ Generated in 0.020 seconds, 7 queries executed - Memory usage: 1.61 MiB (Peak: 1.77 MiB) ]