larch-5 SVN

UnplayedNamer · 2008-02-23 18:21:35

I've build the xmini profile but it seems that /dev don't get populated properly.

wantilles · 2008-02-23 21:56:35

gradgrind wrote:

wantilles, something just struck me. Do you actually have 'lzop' installed? larch needs that to build the lzo overlay, but I haven't made that clear anywhere. Sorry about that! I'll try to get this done chrooted into the larch system so that the build system doesn't need it, but for now you do need it.

No I hadn't.

Now would I be wrong if I became somewhat "bitchy"?

Why wasn't it listed in the dependencies of the larch-5 PKGBUILD?

It would have saved me about 3-4 hours a few days ago.

shining · 2008-02-23 22:23:14

wantilles wrote:

gradgrind wrote:
wantilles, something just struck me. Do you actually have 'lzop' installed? larch needs that to build the lzo overlay, but I haven't made that clear anywhere. Sorry about that! I'll try to get this done chrooted into the larch system so that the build system doesn't need it, but for now you do need it.
No I hadn't.
Now would I be wrong if I became somewhat "bitchy"?
Why wasn't it listed in the dependencies of the larch-5 PKGBUILD?
It would have saved me about 3-4 hours a few days ago.

Yes, you are wrong, he already said he was sorry. I find your attitude really rude through the whole thread, for a FREE project.

To gradgrind : your patience with wantilles really amazes me

stingray · 2008-02-24 02:19:47

shining wrote:

To gradgrind : your patience with wantilles really amazes me

I'll second that!

gradgrind · 2008-02-24 19:14:13

UnplayedNamer wrote:

I've build the xmini profile but it seems that /dev don't get populated properly.
http://img225.imageshack.us/img225/6264/qemubn0.th.png

The actual problem lies before this, but I'm afraid I can't guess what it might be. Is there any chance of seeing the earlier output? Did you watch during the build process to see if there were any errors?

gradgrind · 2008-02-24 19:33:17

wantilles wrote:

gradgrind wrote:
wantilles, something just struck me. Do you actually have 'lzop' installed? larch needs that to build the lzo overlay, but I haven't made that clear anywhere. Sorry about that! I'll try to get this done chrooted into the larch system so that the build system doesn't need it, but for now you do need it.
No I hadn't.
Now would I be wrong if I became somewhat "bitchy"?
Why wasn't it listed in the dependencies of the larch-5 PKGBUILD?
It would have saved me about 3-4 hours a few days ago.

Yes, I am really sorry about that. I know from my own experience how annoying this sort of thing can be, but I think this sort of oversight can happen to anyone from time to time. And in the case of a test release one should probably expect such problems.

Anyway, thanks to you other guys for your support.

And I hope this particular bug is more-or-less solved now - the latest version should work without lzop on the build system, the compression is done by chrooting to the target system (which must of course have lzop installed). But I am still not sure about how to deal with some aspects of dependencies, so there may still be a gotcha or two lurking somewhere. Please let me know if anything turns up.

wantilles · 2008-02-24 21:05:52

A few more questions:

- Since there is a larch-5 standard PKGBUILD present, why are you building it via a special script, and not with a standard makepkg?

- Except for being easier to build and maintain (1 package instead of 5), what other advantages does larch-5 has over larch-4?

gradgrind · 2008-02-25 06:15:33

wantilles wrote:

A few more questions:
- Since there is a larch-5 standard PKGBUILD present, why are you building it via a special script, and not with a standard makepkg?

It is just to make it easier for me (or anyone else) to maintain a larch package repository - which is needed by 'mklarch'. It is no longer just one package (the bits needed for the live system and the installer have been split off), so I can just export the tree from svn and run the build script to get it all done, including updating the repository. Of course the PKGBUILD could be easily modified to download source code and run in a more standard fashion.

wantilles wrote:

- Except for being easier to build and maintain (1 package instead of 5), what other advantages does larch-5 has over larch-4?

The main advantage is the new overlay system (two layers), allowing more flexible and, in many cases, faster session saving. I am at present working on improving efficiency (space and time) of the overlay merging algorithm, so that also the second layer of session saving (akin to that used in larch-4) is faster and requires less memory. This would be much more difficult in larch-4 because of its complicated union structure. Also because of the simplified union arrangement, customization of the boot process and overlay handling should be easier.

I am also looking at the possibility of making the system more updateable - so that even the kernel can be updated. A complete rebuild of the running system should also be possible. But these are features which are still on the todo list.

Finally (?) there is also the new hard disk installer - but as this should also work on larch-4, it is not really an advantage over larch-4 (warning - still under development, it will be buggy).

wantilles · 2008-02-25 08:22:23

gradgrind wrote:

Of course the PKGBUILD could be easily modified to download source code and run in a more standard fashion.

That is what I had in mind when I asked the above question.

paraflu · 2008-02-25 12:38:36

Hello everbody!

Gradgrind:

trying larch-5 right now
wget the script
look at script and changed the build directory
try to larchify the running system with grub as option
larchify complains about not installed lzop and larch-live
install lzop and wget larch-live from the script ftp://ftp.berlios.de/pub/larch/larch5/i686/ address
Before that i thought about including ftp://ftp.berlios.de/pub/larch/larch5/i686/ in the pacman.conf where
the repository of larch4 is included. Does not work , it seems this is not right way at the moment.
installed ftp://ftp.berlios.de/pub/larch/larch5/i … pkg.tar.gz by pacman -A
worked. :-)
In the beginning of the script larch complains about misssing files at the running system:

ERROR: file `/opt/larch/klibc/rename does not exist
......... /opt/larch/klibc/lodel ......

Builds the iso. Now trying to run it.

Trying to build a profile
choosing xmini
./mklarch -g -p xmini
ERROR: no addedpacks in profile /home/larchb/xmini
Trying again with relative path
./mklarch -g -p larch/profiles/xmini
Worked

Just tried it now ,so there some questions which could be self explaining when i examine the isos.
Some questions about larch-5.

1. The lzop, is it used as an container which you mount as a loop on the live
or is decompressed into the overlay. If this is the case could you tell me the commandline , i hope it
is something like: mount -o loop -t lzop /path/to/container /mnt/whatsoever. I heard about this archivetype the
first time. It should be the fastes decompressing/compressing algo i`ve read so far and i would like to
play a little bit with it , to get used to it and using it for other things where fast comp/decomp is needed or where
the system is rather weak like old or portable systems. -- After looking at the lzop site it seems that there is inloop mounting possible (maybe with fuse- i don`t know). But i like that they ported it to AtariTOS :-D

2. To the larchify process: When i build an image of the running system it ask me about a profile , what does this
mean. Is it meant as an additional changes to the running system which i can specific there. like merging `larchify -g /` + the profile together?

3. What is your opinion about the kernel hooks options to use.? For example to have a universal kernel,
which would run on all system, much like an fallback-image. Or an kernel with autodetect which is specific for the
used (running) system an the underlying hardware. I ask this because if i remember right i had to delete autodetect
because i use qemu-vm for building and after that i tried it on the host system which has an other hardware than
qemu-vm-hardware. This is for sure only the case when you build larch-isos from a running or used system.(larchify).
In an other case if i wanted to build a specific system for a specific hardware ,should i use autodetect much further to accelerate the boot process, because it doesn`t need to check the hardware everytime i boot. I know this not
larch specific but it interest me a longer time now. I have to examine the mkinitcpio part of the wiki again, but
if anybody got an fast hint which i will understand better, that would be nice. I even have some weird thoughts about
first booting into the console and maybe at the login prompt or after login as a user to hibernate the system and
use on second boot only the hibernate-image as the boot process. The hibernate image would be very small if compresse d and loading it would be very fast as the used memory when i`ve logged in is only 8MB. This would only take a second to boot by a hardisk. But this is maybe offtopic, maybe not possible , a security risk, not very flexibel (updating!), or a bunch of rubbish. :-).

4. How do merge the overlays? Do you seperate the overlays from the base system, build a new overlay of them,
and at the shutdown delete the old and rename the new overlay as the first one. I ask this because if thats the
case, the space demanding to do this , is for a moment doubled (old *.sqfs + merged new *.sqfs). Is this correct?

5. For usb-stick or flash install, i would like to know if you for yourself test and install it from a VM or do
mount the qemu-build-image as a loop on the host system cd into it and execute usbboot(_grub) like i do. I ask this
because the scripts had changed location from larch/bin to /larch/run and i don`t know if you know that somebody
use it in this way.

ISOS boot results:
both isos in qemu (with kqemu always) WORKED

///XMINI boots into GUI - nice. Should have tryed it before and not building my own stuff first :-)

Burned cds:
both isos on real system WORKED
one thing : the larchified system told me no ejectingdisk found or something similar after i pressed strg+alt+del
the profile based system didn`t do that an worked fine

Now i will go back to larch-4 to test the live-system installer i mentioned to you, which wasn`t l(archin) but
a different script. I was wrong, but i still don`t know the name. So.. -- Wait a minute. Didn`t you mentioned
there is a gtk installer? :-) . I will test it too. But i test larch-4-live to harddisk first , shouldn`t be so long
:-D

Thank you in advance.

`but I hope it's ready for initial testing by the brave` -- I`m brave -- in qemu-vm :-D

gradgrind · 2008-02-25 21:07:55

paraflu wrote:

Hello everbody!
Gradgrind:
trying larch-5 right now
wget the script
look at script and changed the build directory
try to larchify the running system with grub as option
larchify complains about not installed lzop and larch-live
install lzop and wget larch-live from the script ftp://ftp.berlios.de/pub/larch/larch5/i686/ address
Before that i thought about including ftp://ftp.berlios.de/pub/larch/larch5/i686/ in the pacman.conf where
the repository of larch4 is included. Does not work , it seems this is not right way at the moment.

You tried a pacman.conf with both [larch] and [larch5] entries? Although it should probably be regarded as a bug if it doesn't work, I don't think mixing them is a good idea.

paraflu wrote:

installed ftp://ftp.berlios.de/pub/larch/larch5/i … pkg.tar.gz by pacman -A
worked. :-)
In the beginning of the script larch complains about misssing files at the running system:
ERROR: file `/opt/larch/klibc/rename does not exist
......... /opt/larch/klibc/lodel ......

Could you try to explain more exactly where this appears? These are necessary for overlay management.
Anyway, it looks like I'll have to do some testing of this option.

paraflu wrote:

Builds the iso. Now trying to run it.
Trying to build a profile
choosing xmini
./mklarch -g -p xmini
ERROR: no addedpacks in profile /home/larchb/xmini
Trying again with relative path
./mklarch -g -p larch/profiles/xmini
Worked

Just tried it now ,so there some questions which could be self explaining when i examine the isos.
Some questions about larch-5.
1. The lzop, is it used as an container which you mount as a loop on the live
or is decompressed into the overlay. If this is the case could you tell me the commandline , i hope it
is something like: mount -o loop -t lzop /path/to/container /mnt/whatsoever. I heard about this archivetype the
first time. It should be the fastes decompressing/compressing algo i`ve read so far and i would like to
play a little bit with it , to get used to it and using it for other things where fast comp/decomp is needed or where
the system is rather weak like old or portable systems. -- After looking at the lzop site it seems that there is inloop mounting possible (maybe with fuse- i don`t know). But i like that they ported it to AtariTOS :-D

The top overlay is not mounted, it is just decompressed into the top aufs layer, and recompressed on saving.

tar / lzo:

Compress:
tar -cf - src | lzop > src.tar.lzo

Uncompress:
lzop -d < src.tar.lzo | tar -xf -

paraflu wrote:

2. To the larchify process: When i build an image of the running system it ask me about a profile , what does this
mean. Is it meant as an additional changes to the running system which i can specific there. like merging `larchify -g /` + the profile together?

Essentially, yes. See the chapter in the docs about profiles. Most of it is more concerned with the initial installation part (mklarch), but some things are relevant to larchify.

paraflu wrote:

3. What is your opinion about the kernel hooks options to use.? For example to have a universal kernel,
which would run on all system, much like an fallback-image. Or an kernel with autodetect which is specific for the
used (running) system an the underlying hardware. I ask this because if i remember right i had to delete autodetect
because i use qemu-vm for building and after that i tried it on the host system which has an other hardware than
qemu-vm-hardware. This is for sure only the case when you build larch-isos from a running or used system.(larchify).
In an other case if i wanted to build a specific system for a specific hardware ,should i use autodetect much further to accelerate the boot process, because it doesn`t need to check the hardware everytime i boot. I know this not
larch specific but it interest me a longer time now. I have to examine the mkinitcpio part of the wiki again, but
if anybody got an fast hint which i will understand better, that would be nice.

By default, larch doesn't use 'autodetect' because it should run on any system. If you only use one system, you could put 'autodetect' in. I don't know if the boot will be much faster, but the initramfs will be smaller.

paraflu wrote:

I even have some weird thoughts about
first booting into the console and maybe at the login prompt or after login as a user to hibernate the system and
use on second boot only the hibernate-image as the boot process. The hibernate image would be very small if compresse d and loading it would be very fast as the used memory when i`ve logged in is only 8MB. This would only take a second to boot by a hardisk. But this is maybe offtopic, maybe not possible , a security risk, not very flexibel (updating!), or a bunch of rubbish. :-).

Sorry, I've no idea about hibernation.

paraflu wrote:

4. How do merge the overlays? Do you seperate the overlays from the base system, build a new overlay of them,
and at the shutdown delete the old and rename the new overlay as the first one. I ask this because if thats the
case, the space demanding to do this , is for a moment doubled (old *.sqfs + merged new *.sqfs). Is this correct?

Yes, something like that, but there's a bit more to it. At the moment merging overlays (that's the second level of session saving in larch-5, the only one in larch-4) is rather slow and uses quite a lot of memory, but I'm working on an improvement using a second aufs union. What probably won't change is that I keep a backup of the overwritten overlays, so adequate space is needed on the medium. But it is quite easy to customize the behaviour in this respect. Oh, and the renaming is done at boot time, not shutdown (for reasons connected with the aufs mount).

paraflu wrote:

5. For usb-stick or flash install, i would like to know if you for yourself test and install it from a VM or do
mount the qemu-build-image as a loop on the host system cd into it and execute usbboot(_grub) like i do. I ask this
because the scripts had changed location from larch/bin to /larch/run and i don`t know if you know that somebody
use it in this way.

Err, could you explain that again? I'm not really up on all the many possibilities of VMs. The directory rearrangement was actually prompted by my dislike of the 'standard' directory structure. I generally build directly on my development machine (in spite of recommending that people don't do that!) - though to test larchify on the running system I'll have to go to another system, maybe a VM. I test on VirtualBox, mostly using a USB stick and boot CD, and sometimes a (real) test machine.

paraflu wrote:

ISOS boot results:
both isos in qemu (with kqemu always) WORKED
///XMINI boots into GUI - nice. Should have tryed it before and not building my own stuff first :-)
Burned cds:
both isos on real system WORKED
one thing : the larchified system told me no ejectingdisk found or something similar after i pressed strg+alt+del
the profile based system didn`t do that an worked fine

You'll need to have 'eject' installed.

paraflu wrote:

Now i will go back to larch-4 to test the live-system installer i mentioned to you, which wasn`t l(archin) but
a different script. I was wrong, but i still don`t know the name. So.. -- Wait a minute. Didn`t you mentioned
there is a gtk installer? :-) . I will test it too. But i test larch-4-live to harddisk first , shouldn`t be so long
:-D

Thank you in advance.

`but I hope it's ready for initial testing by the brave` -- I`m brave -- in qemu-vm :-D

Good luck and thanks a lot for the feedback.

paraflu · 2008-02-26 00:14:44

Hello Gradgrind

Thanks for the answers , i hope i don`t get on your nerves to much, because my skills are rather low
especially in scripting. So my questions could be more or less stupid.

1. I`ve used the image before with larch4 (as a standard image which i can modify for testing) and then boot another image and used this image (which used the platform independent script to build a live-system of the first image i mentioned (mklarch -g -x /dev/first_image). They have similar entries in pacman.conf. I really don`t know anymore why i include the larch-repository. I think it complains about missing files on the `to build image`, but i only remember a missing squashfs-tools. I really don`t know. But it worked anyway and i will try building without the entry. For the larch-5 test I thought about including ftp://ftp.berlios.de/pub/larch/larch5/i686/ in the pacman.conf because it complained about the missing larch-live package , so i thought if i include the address of the new larch-5 script, i could do a pacman -S larch-live which didn`t work. After that i downloaded it and pacman -A larch-live-XXX to install it, which worked. So if i understand you right i can use a new normal installed base system without any changes and then use my other image with the script and larchify the `normal installed base system` from it.
for example :
sda1 = the build system with the larch-5 script
sda2 = the to-build system
boot sda1
cd into script directory and execute `larchify /dev/sda2`
and it will not complain about missing packages (mksquashfs etc.) on the to-build-partition . Right?
i am a little confused here because i can`t remember why i included the entry :-) . I think the error is on my side.

2. The error you mentioned occured when i larchify from the running sytem and not if build a profile. Which don`t make sense for me. I will try again.
Commands:
cd into the larch5 script directory
larchify -g /

error occured after :
Parsing hook [larch3]
ERRRO .... klibc/rename
ERROR .... klibc/lodel
Generating module dependencies

i`ve tried to cat the error massage (larchify -g / | cat > message.txt)
but it didn`t occur in it. This is weird. But i can promise it is there and so wrote it by hand above.
Seems to be a path problem. Absolute path to /opt/larch/.... instead of opt/larch (relative to larch5 script directory). I guess.

3. Lzop
Thanks for explaining. Now i understand. It decompressed the top overlay into tmpfs , but wouldn`t this increase the
memory requirements on the system, instead of squashfs the top-overlay and mount it viva the unionfs at the next boot. Or do you think because of the ability to merge squashfs-overlay-filesystems and compress/decompress for example only the home directory by lzop this will not limit the memory requirements to much?

4. kernel and autodetect
By default you mean the build process with profiles, Right? With the option `-a` i can stop the build process and
change the /etc/mkinitcpio.conf and there i can include or exclude the autodedect hook. But this is not the mkinitcpio.conf of larch, it doesn`t have the larch1 larch2 ... hooks for the initram-fs (klibc). For modifying the
mkinitcpio of larch i have to modify larch/initcpio_files/lib/initcpio/mkinitcpio.conf. Right? This is also true for larchify a partition, i think.

5. hibernating
This was only an idea and wanted to push it to the extreme by using it on an live-system. This was not larch specific
but i thought i mentioned it anyway and hoped that anybody else would answer that. I think i will open a seperate thread and will get ripped apart by others. But hey what doesn`t kill me let me became thougher. :-D

6. merging overlays
Ah i understand. When there is no writing changes back at the shutdown, the renaming also is not resistend and if you write back the new overlay the old ones get deleted.

7. Vm and usb
When i build systems i use qemu-image containers in qemu. Execute qemu and build the system inside qemu. It builds the iso with the *.sqfs on the image. After that i quit qemu, mount the image on the host system via loop and put in the usb-stick. Cd into the larch5-script directory on the image and here i execute usbboot_grub with the parameter pointing to the ./larch/cdimage/ here it detects my (at the host) inserted usb-stick and build the live-system to the stick. Qemu has the ability to recognize an usb-stick at the host system from inside the VM, but i don`t trust it. So I use the usbboot_grub script outside of qemu. Which worked for me.

8. eject
I`ve looked into the addedpacks of xmini and i recognize that my first question [1.] about missing installes packages is explained there too : you added larch-live squashfs-tools and lzop. But larch-live is only available via the new
larch5-script address which i wanted to include in pacman.conf. It`s not in core or extra. Is this right? pacman -S live-larch would only work when i include the new address in pacman.conf when i larchify another/the_running system?

9. I tried the gtk-installer. It worked. But i experienced an error message if the harddisk has no partition at all. When i partition the drive it worked. Good Work. The gtk-installer is an option or the default? There is still the possibilty to use archin from the commandline. Right?

10. from the larch4-thread
I`ve looked into the larch-hooks and it is to much for me but i try to learn. I didn`t find the the root=/dev/xxx parameter but i found the c2r parameter and the way you do it.
for the directory suggestion
you first test if there is a device at all:

test_live_data_dir ()
{
/bin/mount -r -t iso9660 "$1" $2 >/dev/null 2>/dev/null || \
/bin/mount -r -t vfat -o noatime,nodiratime "$1" $2 >/dev/null 2>/dev/null || \
/bin/mount -r -t ext2 -o noatime,nodiratime "$1" $2 >/dev/null 2>/dev/null
if [ $? -eq 0 ]; then
if [ -f "$2/larch/larchboot" ]; then
LDEV="$1"
msg_ " ... found at $1"
return 0
else
/bin/umount $2 2>/dev/null
msg_ " ... $1 mounted, but no 'larch/larchboot' found"
fi
else
msg_ " ... not $1"
fi
return 1
}

then try to mount something:

# look for livecd data directory, first try ${root}
LDEV="${root}"
if [ "x${LDEV}" != "x" ]; then
/bin/mount -r -t iso9660 "${LDEV}" "${cdmount}" >/dev/null 2>/dev/null || \
/bin/mount -r -t vfat -o noatime,nodiratime "${LDEV}" "${cdmount}" >/dev/null 2>/dev/null || \
/bin/mount -r -t ext2 -o noatime,nodiratime "${LDEV}" "${cdmount}" >/dev/null 2>/dev/null
if [ $? -eq 0 ]; then
if [ -d "${cdmount}/larch" ]; then
msg_ ":: larch system at ${LDEV}"
else
/bin/umount "${cdmount}" 2>/dev/null
echo "!! No larch system at ${LDEV}"
LDEV=""
fi
else
echo "!! Couldn't mount ${LDEV}"
LDEV=""
fi
fi

My question is : Before the test i would have to insert the prompt where it would ask for a path then wait for a specific time and if there is no input, it would run the standart procedure. Right?
My knowledge reached it limits here how to do this. If it is only a 3 Liner which you can do out of head it would be nice if you have a hint for me how to do it. Better if you have an url for learning basic scripting with an example like that, so i can do it alone. I don`t know for what to google in this case and some sites are more or less complicated for me. :-).

About the boot parameter: I looked at the c2r part of larch3-hook

# Boot option copy-to-ram (c2r)
if [ "${c2r}" = "y" ]; then
msg_ ":: Copying base system to RAM, this will take a while ..."
/bin/cat ${sysSqf} > /tfs/system.sqf
if [ $? -ne 0 ]; then
err "Sorry, not enough RAM"
break="y"
return
fi
sysSqf=/tfs/system.sqf

msg_ ":: Copying mods archive to RAM, this might take a while ..."
/bin/cat ${modsSqf} > /tfs/mods.sqf
if [ $? -ne 0 ]; then
err "Sorry, not enough RAM"
break="y"
return
fi
modsSqf=/tfs/mods.sqf

for [ "${c2r}" = "y" ] i could change c2r to anything like c3r and it would accept c3r as a boot parameter. Right?

This would be the same as the prompt at the larch1-hook only the parameter could be enter as a boot parameter.
I see in the script the klibc initram is limited [busybox] for exeample you losetup to build the loopback device. It seems to me that the way to use an overlay with sshfs etc installed and populated dev and then change to another overlay-rootfs is an easier way me to understand, but i will think about that a little bit longer. But for the directory or path option it would work to use klibc-initram and the scripts.

Thanks for the reply

gradgrind · 2008-02-26 06:26:37

paraflu wrote:

Hello Gradgrind
Thanks for the answers , i hope i don`t get on your nerves to much, because my skills are rather low
especially in scripting. So my questions could be more or less stupid.

When you get on my nerves I'll write something extremely rude and not reply to you any more
Actually I'm grateful for the feedback.

paraflu wrote:

1. I`ve used the image before with larch4 (as a standard image which i can modify for testing) and then boot another image and used this image (which used the platform independent script to build a live-system of the first image i mentioned (mklarch -g -x /dev/first_image). They have similar entries in pacman.conf. I really don`t know anymore why i include the larch-repository. I think it complains about missing files on the `to build image`, but i only remember a missing squashfs-tools. I really don`t know. But it worked anyway and i will try building without the entry. For the larch-5 test I thought about including ftp://ftp.berlios.de/pub/larch/larch5/i686/ in the pacman.conf because it complained about the missing larch-live package , so i thought if i include the address of the new larch-5 script, i could do a pacman -S larch-live which didn`t work. After that i downloaded it and pacman -A larch-live-XXX to install it, which worked. So if i understand you right i can use a new normal installed base system without any changes and then use my other image with the script and larchify the `normal installed base system` from it.
for example :
sda1 = the build system with the larch-5 script
sda2 = the to-build system
boot sda1
cd into script directory and execute `larchify /dev/sda2`
and it will not complain about missing packages (mksquashfs etc.) on the to-build-partition . Right?
i am a little confused here because i can`t remember why i included the entry :-) . I think the error is on my side.

You will need some things installed in the system to be larchified, and adding a [larch5] entry into pacman.conf is a possibility to make this easier, but I think you shouldn't also have a [larch] (from larch-4) entry in there (though I'm not sure why that should cause problems). I guess you've discovered what needs to be installed, but I hope it's in the docs (if not, that's a bug).

paraflu wrote:

2. The error you mentioned occured when i larchify from the running sytem and not if build a profile. Which don`t make sense for me. I will try again.
Commands:
cd into the larch5 script directory
larchify -g /
error occured after :
Parsing hook [larch3]
ERRRO .... klibc/rename
ERROR .... klibc/lodel
Generating module dependencies
i`ve tried to cat the error massage (larchify -g / | cat > message.txt)
but it didn`t occur in it. This is weird. But i can promise it is there and so wrote it by hand above.
Seems to be a path problem. Absolute path to /opt/larch/.... instead of opt/larch (relative to larch5 script directory). I guess.

Thanks, I'll look into this.

paraflu wrote:

3. Lzop
Thanks for explaining. Now i understand. It decompressed the top overlay into tmpfs , but wouldn`t this increase the
memory requirements on the system, instead of squashfs the top-overlay and mount it viva the unionfs at the next boot. Or do you think because of the ability to merge squashfs-overlay-filesystems and compress/decompress for example only the home directory by lzop this will not limit the memory requirements to much?

Yes, this increases the memory requirement. I didn't intend this to be used for large overlays, just to speed up the session saving when smallish changes have been made. The second layer of session saving recreates a squashfs overlay (I have called this overlay merging, as you noticed) and can be done when the first layer gets too big. For people who do a lot of work in /home, I think it might be worth considering a separate partition, with or without compression - it depends on usage patterns. It is not too difficult to customize these things.

paraflu wrote:

4. kernel and autodetect
By default you mean the build process with profiles, Right? With the option `-a` i can stop the build process and
change the /etc/mkinitcpio.conf and there i can include or exclude the autodedect hook. But this is not the mkinitcpio.conf of larch, it doesn`t have the larch1 larch2 ... hooks for the initram-fs (klibc). For modifying the
mkinitcpio of larch i have to modify larch/initcpio_files/lib/initcpio/mkinitcpio.conf. Right? This is also true for larchify a partition, i think.

Yes, I think that's also in the docs somewhere (I hope it is!). Take the larch default as a starting point and put your modified version in your profile.

paraflu wrote:

5. hibernating
This was only an idea and wanted to push it to the extreme by using it on an live-system. This was not larch specific
but i thought i mentioned it anyway and hoped that anybody else would answer that. I think i will open a seperate thread and will get ripped apart by others. But hey what doesn`t kill me let me became thougher. :-D

Good luck!

paraflu wrote:

6. merging overlays
Ah i understand. When there is no writing changes back at the shutdown, the renaming also is not resistend and if you write back the new overlay the old ones get deleted.

I'm afraid I don't understand that.

paraflu wrote:

7. Vm and usb
When i build systems i use qemu-image containers in qemu. Execute qemu and build the system inside qemu. It builds the iso with the *.sqfs on the image. After that i quit qemu, mount the image on the host system via loop and put in the usb-stick. Cd into the larch5-script directory on the image and here i execute usbboot_grub with the parameter pointing to the ./larch/cdimage/ here it detects my (at the host) inserted usb-stick and build the live-system to the stick. Qemu has the ability to recognize an usb-stick at the host system from inside the VM, but i don`t trust it. So I use the usbboot_grub script outside of qemu. Which worked for me.

I used qemu for a while, but have recently switched to VirtualBox, which runs faster - important on my old machines. So far I am very happy with it.

paraflu wrote:

8. eject
I`ve looked into the addedpacks of xmini and i recognize that my first question [1.] about missing installes packages is explained there too : you added larch-live squashfs-tools and lzop. But larch-live is only available via the new
larch5-script address which i wanted to include in pacman.conf. It`s not in core or extra. Is this right? pacman -S live-larch would only work when i include the new address in pacman.conf when i larchify another/the_running system?

Yes.

paraflu wrote:

9. I tried the gtk-installer. It worked. But i experienced an error message if the harddisk has no partition at all. When i partition the drive it worked. Good Work. The gtk-installer is an option or the default? There is still the possibilty to use archin from the commandline. Right?

Yes, but I haven't updated the (old) larchin addition for larch-5, and I am not supporting this any more. If you really want a console installer, I think it would be better to write a console front end for the new larchin (python is much, much nicer than bash for any proper programming).

paraflu wrote:

10. from the larch4-thread
I`ve looked into the larch-hooks and it is to much for me but i try to learn. I didn`t find the the root=/dev/xxx parameter but i found the c2r parameter and the way you do it.
for the directory suggestion
you first test if there is a device at all:
test_live_data_dir ()
{
/bin/mount -r -t iso9660 "$1" $2 >/dev/null 2>/dev/null || \
/bin/mount -r -t vfat -o noatime,nodiratime "$1" $2 >/dev/null 2>/dev/null || \
/bin/mount -r -t ext2 -o noatime,nodiratime "$1" $2 >/dev/null 2>/dev/null
if [ $? -eq 0 ]; then
if [ -f "$2/larch/larchboot" ]; then
LDEV="$1"
msg_ " ... found at $1"
return 0
else
/bin/umount $2 2>/dev/null
msg_ " ... $1 mounted, but no 'larch/larchboot' found"
fi
else
msg_ " ... not $1"
fi
return 1
}

That is a function that is called on a device which has already been found, it is not testing if the device exists but rather if the larch medium is on that device.

paraflu wrote:

then try to mount something:
# look for livecd data directory, first try ${root}
LDEV="${root}"

There is the boot parameter 'root' (the conversion of boot parameters to shell variables is done by the standard Arch initcpio code).

paraflu wrote:

if [ "x${LDEV}" != "x" ]; then
/bin/mount -r -t iso9660 "${LDEV}" "${cdmount}" >/dev/null 2>/dev/null || \
/bin/mount -r -t vfat -o noatime,nodiratime "${LDEV}" "${cdmount}" >/dev/null 2>/dev/null || \
/bin/mount -r -t ext2 -o noatime,nodiratime "${LDEV}" "${cdmount}" >/dev/null 2>/dev/null
if [ $? -eq 0 ]; then
if [ -d "${cdmount}/larch" ]; then
msg_ ":: larch system at ${LDEV}"
else
/bin/umount "${cdmount}" 2>/dev/null
echo "!! No larch system at ${LDEV}"
LDEV=""
fi
else
echo "!! Couldn't mount ${LDEV}"
LDEV=""
fi
fi
My question is : Before the test i would have to insert the prompt where it would ask for a path then wait for a specific time and if there is no input, it would run the standart procedure. Right?

Yes, if you really want a prompt. Wouldn't it be better to handle this using the grub menu and 'root=...'?

paraflu wrote:

My knowledge reached it limits here how to do this. If it is only a 3 Liner which you can do out of head it would be nice if you have a hint for me how to do it. Better if you have an url for learning basic scripting with an example like that, so i can do it alone. I don`t know for what to google in this case and some sites are more or less complicated for me. :-).

read -t 2 -p "Enter something: " m
if [ "x${m}" != "x" ]; then ...

paraflu wrote:

About the boot parameter: I looked at the c2r part of larch3-hook
# Boot option copy-to-ram (c2r)
if [ "${c2r}" = "y" ]; then
msg_ ":: Copying base system to RAM, this will take a while ..."
/bin/cat ${sysSqf} > /tfs/system.sqf
if [ $? -ne 0 ]; then
err "Sorry, not enough RAM"
break="y"
return
fi
sysSqf=/tfs/system.sqf
msg_ ":: Copying mods archive to RAM, this might take a while ..."
/bin/cat ${modsSqf} > /tfs/mods.sqf
if [ $? -ne 0 ]; then
err "Sorry, not enough RAM"
break="y"
return
fi
modsSqf=/tfs/mods.sqf
for [ "${c2r}" = "y" ] i could change c2r to anything like c3r and it would accept c3r as a boot parameter. Right?

Yes.

paraflu wrote:

This would be the same as the prompt at the larch1-hook only the parameter could be enter as a boot parameter.
I see in the script the klibc initram is limited [busybox] for exeample you losetup to build the loopback device. It seems to me that the way to use an overlay with sshfs etc installed and populated dev and then change to another overlay-rootfs is an easier way me to understand, but i will think about that a little bit longer. But for the directory or path option it would work to use klibc-initram and the scripts.

I didn't quite understand that, but the environment available in the klibc based initramfs is indeed really very limited. If you want more you will have to add it yourself.

bastikr · 2008-02-26 11:54:49

I get the same error as Unplayed Namer.
The first sign of the error seems to be:

:: Generating fresh /etc/fstab [done]
:: Mounting Local Filesystems [busy]
mount: mount point /dev/pts does not exist
mount: mount point /dev/shm does not exist
[done]

Do you have any ideas what's going wrong?
If you need more infos let me know.

gradgrind · 2008-02-26 12:17:25

bastikr wrote:

I get the same error as Unplayed Namer.
The first sign of the error seems to be:
:: Generating fresh /etc/fstab [done]
:: Mounting Local Filesystems [busy]
mount: mount point /dev/pts does not exist
mount: mount point /dev/shm does not exist
[done]
Do you have any ideas what's going wrong?
If you need more infos let me know.

Are you sure that was the first sign? Would it be possible to run it in VirtualBox (so that you can pause the execution to get a better look at the output)?

Or maybe you could run the build again and send me the output?

bastikr · 2008-02-26 13:24:51

I just figured out that I have the same problem as paraflu too.

:: Parsing hook [larch3]
ERROR: file '/opt/larch/klibc/rename' does not exist
ERROR: file '/opt/larch/klibc/lodel' does not exist

Does this explain the other error?
Anyway, I loaded the output of the installation to disk and of the installation to usb-stick to: http://bastikr.ba.funpic.de/
(I don't want to spam this thread)
Do you need the output of the boot-up too? I've never used VirtualBox or anything similar, so it would surely take some time. But if it's necessary I'll do it of course.

gradgrind · 2008-02-26 14:15:22

bastikr wrote:

I just figured out that I have the same problem as paraflu too.
:: Parsing hook [larch3]
ERROR: file '/opt/larch/klibc/rename' does not exist
ERROR: file '/opt/larch/klibc/lodel' does not exist
Does this explain the other error?
Anyway, I loaded the output of the installation to disk and of the installation to usb-stick to: http://bastikr.ba.funpic.de/
(I don't want to spam this thread)
Do you need the output of the boot-up too? I've never used VirtualBox or anything similar, so it would surely take some time. But if it's necessary I'll do it of course.

Thanks a lot. I've managed to get the error with the non-existent files, so I'll try to fix that and let you know when I've uploaded new packages. I don't know if that's connected with the boot error yet.

I noticed in your listing that you have enabled the testing repository. I think that is maybe not such a good idea at the moment - it might bring in errors unrelated to larch. Also your 'local' repository: it's probably quite ok, but I think the name is perhaps not very well chosen (as the installed package database is also called 'local' - it could be a little confusing).

As to VirtualBox, I would say it is well worth getting to know it. It is really very useful for testing new systems (I am using the non-free version from AUR). qemu is also good, but slower.

gradgrind · 2008-02-26 18:57:52

The latest version (I have updated larch and larch-live) should have solved the problem with the non-existent files:

:: Parsing hook [larch3]
ERROR: file '/opt/larch/klibc/rename' does not exist
ERROR: file '/opt/larch/klibc/lodel' does not exist

Would somebody with the /dev problem be able to test this to see if we can find out what's going wrong? I have installed a system to (virtual) hard disk using larchin on VirtualBox, and then used this installed system to build a live USB-stick again, this time from the running system, which also worked. So the /dev problem seems a bit elusive. If anyone can reproduce it with the latest packages, please let me know.

bastikr · 2008-02-26 21:34:45

Thanks gradgrind for your fast replies.
You're right, 'local' is really not a good name. It was just the first that came to my mind when I tried out building own packages. I changed that and I also removed testing.
Afterwards I tried to create an usb-stick with larch4 because I needed a running system and I got the same problem when booting. I don't know if there also occurred the "file does not exist" error while building, because I didn't look for it since I've had no problems with larch4 before. (and yes, I changed the pacman.conf back)
So maybe larch4 and larch5 are playing some bad tricks with each other.
After reinstalling archlinux on another partition, larch4 worked great again. I'll try the same with larch5 and tell you if it works. If you want, I can also try the updated larch5 on my old installation.

gradgrind · 2008-02-27 05:56:58

bastikr wrote:

Thanks gradgrind for your fast replies.
You're right, 'local' is really not a good name. It was just the first that came to my mind when I tried out building own packages. I changed that and I also removed testing.
Afterwards I tried to create an usb-stick with larch4 because I needed a running system and I got the same problem when booting. I don't know if there also occurred the "file does not exist" error while building, because I didn't look for it since I've had no problems with larch4 before. (and yes, I changed the pacman.conf back)
So maybe larch4 and larch5 are playing some bad tricks with each other.
After reinstalling archlinux on another partition, larch4 worked great again. I'll try the same with larch5 and tell you if it works. If you want, I can also try the updated larch5 on my old installation.

If you have larch4 packages installed, I think it is probably not surprising that larch5 doesn't work properly, and vice versa. It is possible to build larch4 and larch5 on the same system, but you have to remove all the packages from the other larch version before you start. If you can remove all the larch4 packages from your old installation it would indeed be interesting to hear whether larch5 works on it.

bastikr · 2008-02-27 09:22:53

OK, I removed all larch4 packages I could find, and tried larch5 again without updating to the newest version. Although the "file does not exist" error occurred again, booting went fine. So there seems to be no connection between the two bugs.
Could you tell me why these files ('/opt/larch/klibc/rename', '/opt/larch/klibc/lodel') are nedded and why the system runs well without them?
However, I'll update larch5 and see if your patch works, so that there is no error at all.

gradgrind · 2008-02-27 11:18:57

bastikr wrote:

OK, I removed all larch4 packages I could find, and tried larch5 again without updating to the newest version. Although the "file does not exist" error occurred again, booting went fine. So there seems to be no connection between the two bugs.
Could you tell me why these files ('/opt/larch/klibc/rename', '/opt/larch/klibc/lodel') are nedded and why the system runs well without them?
However, I'll update larch5 and see if your patch works, so that there is no error at all.

lodel is not used (at present) - it allows the detaching of loop devices in the klibc environment, so that squashfs mounts could be unmounted.
rename is used for renaming overlays. So it is needed if you are using session saving.

At some point in the future they should be included in the standard klibc-extras package (in some form or other), but until then I must supply them with larch.

Glad to hear it's working now.

steve___ · 2008-02-27 21:05:18

gradgrind, hi.
I'd like to larchify my current running system and use kqemu to run the image -- after reading your posts about virtualbox being faster, i may switch . Here is what I've done so far:

$ wget ftp.berlios.de/pub/larch/larch5/i686/larch-setup
$ pacman -Sy squashfs-tools lzop aufs syslinux cdrkit
$ wget ftp.berlios.de/pub/larch/larch5/i686/larch-live-5.1.4-1-i686.pkg.tar.gz
$ pacman -U larch-live-5.1.4-1-i686.pkg.tar.gz /
$ umount ~/mnt/{donkey,cgi}  ## sshfs mounts - heh.
$ larchify /

I received this error:
-snip-

// creating compressed image of remaining larch mods: overlay.ovl
// creating isolinux-booting LiveCD ISO image...
File /.larch/cd/system.sqf is larger than 4GiB-1.
-allow-limited-size was not specified. There is no way do represent this file size. Aborting.
ERROR: iso build failed

Full output found here.

Here is the size of the build dir:

# du -ch --max-depth=1 /.larch/
16G    /.larch/cd
4.0K    /.larch/tmp
16G    /.larch/
16G    total

Last edited by steve___ (2008-02-27 21:07:40)

gradgrind · 2008-02-28 06:50:50

steve___ wrote:

gradgrind, hi.
Here is the size of the build dir:
# du -ch --max-depth=1 /.larch/
16G    /.larch/cd
4.0K    /.larch/tmp
16G    /.larch/
16G    total

Are you saying you didn't expect there to be 16GB in /.larch/cd, or that you want a 16GB CD?

(Out of interest, how long did that take to compress?)

steve___ · 2008-02-28 08:40:45

gradgrind wrote:

Are you saying you didn't expect there to be 16GB in /.larch/cd, or that you want a 16GB CD?

First off I apologize for my ignorance.

(Out of interest, how long did that take to compress?)

I am using a duo core 1.83Ghz processor.

real    31m18.531s
user    41m14.639s
sys    2m13.315s

I was expecting a 16GB iso to test with qemu.

Arch Linux

#26 2008-02-23 18:21:35

Re: larch-5 SVN

#27 2008-02-23 21:56:35

Re: larch-5 SVN

#28 2008-02-23 22:23:14

Re: larch-5 SVN

#29 2008-02-24 02:19:47

Re: larch-5 SVN

#30 2008-02-24 19:14:13

Re: larch-5 SVN

#31 2008-02-24 19:33:17

Re: larch-5 SVN

#32 2008-02-24 21:05:52

Re: larch-5 SVN

#33 2008-02-25 06:15:33

Re: larch-5 SVN

#34 2008-02-25 08:22:23

Re: larch-5 SVN

#35 2008-02-25 12:38:36

Re: larch-5 SVN

#36 2008-02-25 21:07:55

Re: larch-5 SVN

#37 2008-02-26 00:14:44

Re: larch-5 SVN

#38 2008-02-26 06:26:37

Re: larch-5 SVN

#39 2008-02-26 11:54:49

Re: larch-5 SVN

#40 2008-02-26 12:17:25

Re: larch-5 SVN

#41 2008-02-26 13:24:51

Re: larch-5 SVN

#42 2008-02-26 14:15:22

Re: larch-5 SVN

#43 2008-02-26 18:57:52

Re: larch-5 SVN

#44 2008-02-26 21:34:45

Re: larch-5 SVN

#45 2008-02-27 05:56:58

Re: larch-5 SVN

#46 2008-02-27 09:22:53

Re: larch-5 SVN

#47 2008-02-27 11:18:57

Re: larch-5 SVN

#48 2008-02-27 21:05:18

Re: larch-5 SVN

#49 2008-02-28 06:50:50

Re: larch-5 SVN

#50 2008-02-28 08:40:45

Re: larch-5 SVN

Board footer