not resolved
K3nn3th
offlineMember
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
kubepc
offlineMember
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.
K3nn3th
offlineMember
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)?
kubepc
offlineMember
@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.
Bellard
offlineKey Master
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.
K3nn3th
offlineMember
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...?
K3nn3th
offlineMember
@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
Bellard
offlineKey Master
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
K3nn3th
offlineMember
@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
christophe
offlineMember
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.
kubepc
offlineMember
@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
K3nn3th
offlineMember
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
You must log in to post.
