larch-5.2 released

gradgrind · 2008-05-12 06:03:22

wantilles wrote:

OK putting "loop" in "MODULES=" in "mkinitcpio.conf" worked.
LArch 5.2 can produce kernel 2.6.25 live CDs.
It only needs from testing the kernel and aufs.
Tested successfully on both architectures.

Great, thanks for the testing and report.

wantilles · 2008-05-13 20:59:25

gradgrind wrote:

wantilles wrote:
OK putting "loop" in "MODULES=" in "mkinitcpio.conf" worked.
LArch 5.2 can produce kernel 2.6.25 live CDs.
It only needs from testing the kernel and aufs.
Tested successfully on both architectures.
Great, thanks for the testing and report.

The same configuration also works with today's 2.6.25.3 from testing.

metalfan · 2008-05-13 22:48:11

pacman -S testing/kernel26
warning: kernel26-2.6.25.3-1 is up to date -- reinstalling

 pacman -S testing/aufs
warning: aufs-20080421-2 is up to date -- reinstalling

grep "loop" /opt/larch/profiles/mini2/mkinitcpio.conf 
MODULES="loop"

larchify -p /opt/larch/profiles/mini2/ /

somehow this does not work and produces this:
http://metalfan2.me.funpic.de/2008-05-1 … _scrot.png

Sigi · 2008-05-13 23:40:52

metalfan wrote:

pacman -S testing/kernel26
warning: kernel26-2.6.25.3-1 is up to date -- reinstalling

 pacman -S testing/aufs
warning: aufs-20080421-2 is up to date -- reinstalling

grep "loop" /opt/larch/profiles/mini2/mkinitcpio.conf 
MODULES="loop"

larchify -p /opt/larch/profiles/mini2/ /

somehow this does not work and produces this:
http://metalfan2.me.funpic.de/2008-05-1 … _scrot.png

Hm, I haven't used larch in a while but looking at the error it seems to me as if tar and lzop might need to be installed.

gradgrind · 2008-05-14 05:05:02

Well, that's a strange one. I'm not sure what's going on there, I haven't seen that error before. I'll give it a try sometime, it's just that I'm a bit reluctant to get too deeply into bug hunting before the new kernel gets out of testing.

And Sigi, if the squashfs is not getting mounted properly, tar and lzop won't be available even if they were installed.

Atticus · 2008-05-18 21:45:00

I'm not sure if I did this wrong, but I've been messing around creating a liveCD with this, and what I was trying to do was create custom packages in my /root/larch/custom directory. Then I edited the /root/larch/pacman.conf file and added the following lines:

[custom]
Server = /root/larch/custom

But this didn't work when I tried to do mklarch because when it tried to sync with my "custom" repo, pacman gave an error like "no address found". It only worked when I put the repository on an FTP. Reading the larch documention, I was lead to believe that a local repository like I wrote above would work. Did I do something wrong?

wantilles · 2008-05-18 22:14:40

Correct entry in pacman.conf would be:

[custom]
Server = file:///root/larch/custom

Also pacman must find a file in there named:

custom.db.tar.gz

Last edited by wantilles (2008-05-18 22:15:40)

Atticus · 2008-05-18 23:18:23

Ah I see, I didn't have the file:// part. But I did have the custom.db.tar.gz file there. Thanks for your help!

paraflu · 2008-05-22 21:20:43

Hello, gradgrind

i do not have to much time at the moment, so i could only test 5.2 one time in a larchify test for an usb stick.
It did work and i examine your docs too. This was a longer time ago and some things you change in the larch structure could be different. After reading your docs it was very nice to see you mention the customizing of the scripts. I only looked into them a longer time ago , so my status of larch could be i little bit outdated. But nevertheless i thought about some things and it would be nice if can tell me if they are possible.

So here we go...

I. When i use larch on an usbstick, i often thought about using it in different hardware enviroments. Let`s say i want to take my usbstick with archlinux to another hardware with different network parameters etc and after that i want to
take the stick to another hardware and configuration and so on.
so how can i archieve this. You gave me one script where the user is asked for input. I would like to use this before
the larch2?-script looks for the squashfs like sda and so on. So i thought if i put this before the script look
for other devices and then take it as variable for scripts. So the input is written to a file /bootchoosen.txt in the tmpfs of the initram and then is taken a set parameter in the scripts, it would be an easy way to point to the choosen squashfs.
So how the structure on the usb have to look to archieve that. First i thought putting the kernel and initrd in the / of the usbstick and the different systems in different dirs. That would be ok but what about the kernel. So second solution would be to have the different systems on different partitions on the usbstick so everything is seperate and the different systems and kernels could be easily choosen at the grub entry and menue. This would be cleaner i think.
Mmm i don`t know even if the usbsticks get bigger there is a good argument against this.: ` use different usbsticks stupid!!!` :-) so i think it would only be done if its easy and nice to archieve.

II.
Now comes something which is little bit weird but thinkable.
If i remember correctly at larch3 you save every overlay seperate with different numbers like overlay.001 and
so on. Nowerdays you have got one overlay squashfs and a lzop archive which could be merged. But lets stay for a moment at the larch3 state. If every change of the system got an overlay file numbered and maybe some md5 hash to make them unique, this bring us to some nice possibilities. If i could somehow relate the overlays to another like in the filename , so overlay.001 is before overlay.002 and so on i`ve got a hierachy. Now if i want to choose another way at lets say overlay.077 to another state of configuration i could split the overlay hierachy to lets say overlay.007.A001
where A001 is the new direction and all changes would go into A002 and so on. I don`t know how complicated this is
, but i think this could be done at a text references file where every overlay got its entry, md5 and tree hierachy, without using a database which i don`t have any clue about. I think this could be interesting.

III.
Loose statements, questions and thoughts.

1.
What i really like about the structure of larch is the use of big squashfs to hold the system and the overlay read only state which you could only archieve on live cds, but the choice to save my changes. The is a result of my behavior that i don`t really change to much if my system is properly configured all downloaded media goes to another devices and don`t really like that my os is exposed to changes when i my regular changes are updating the system nothing more really change. Exxept for maybe the bookmarks of firefox. I know there are apllications which can do this like diffsbackup , dd and so on, but i don`t really like to use if i only want to check some applicatons or do something risky.

2.
A. I think larch is really good for internet cafes, because of the live system character.
B. I told you about my thought in the mounting the squashfs over sshfs. This has one thought behind it i wanted to
make the hardware of a diskless clients unique. After i look into diskless clients system i found that they only seperates clients and there configurations with mac-addresses. I don`t know if this is secure so i thought do it over
ssh which has the advantage to secure and make the clients different. But i think this was to much to implement this
security at the system bootup level maybe it is better to implement the ssh security at user-level. I( don`t know
this i s all a big mmmmmmmh but to make the clients unique for the diskless server is still in my mind. ;-)
C. Why i wanted to use the larch structure to serve as diskless server is easy. Because larch is small because of sqashfs it is easy to hold it into ram, so the network should be saturated. What is also very nice is that if i change the distributed system it is only an copy task and if the new system has bugs i can easyly restore the old system or maybe i can have more systems into ram which could be distributed to separate clients with different demands.
(apllications does not work with the upgrade but work with the former system and so on.)
D. Could you tell me how many fs aufs can union and would it be possible to reduce the / fs to only the system.sqfs and after that mount another overlay unionfs?
E. If i remember right you mentioned that you could not update the kernel. Couldn`t you write with with mkinicpio_larch
to another location and then overwrite it at shutdown. I think the larch scripts are still in the system or is this wrong.

Thanks for your answers.

Last edited by paraflu (2008-05-22 21:26:18)

gradgrind · 2008-05-23 05:38:17

paraflu wrote:

I. When i use larch on an usbstick, i often thought about using it in different hardware enviroments. Let`s say i want to take my usbstick with archlinux to another hardware with different network parameters etc and after that i want to
take the stick to another hardware and configuration and so on.
so how can i archieve this. You gave me one script where the user is asked for input. I would like to use this before
the larch2?-script looks for the squashfs like sda and so on. So i thought if i put this before the script look
for other devices and then take it as variable for scripts. So the input is written to a file /bootchoosen.txt in the tmpfs of the initram and then is taken a set parameter in the scripts, it would be an easy way to point to the choosen squashfs.
So how the structure on the usb have to look to archieve that. First i thought putting the kernel and initrd in the / of the usbstick and the different systems in different dirs. That would be ok but what about the kernel. So second solution would be to have the different systems on different partitions on the usbstick so everything is seperate and the different systems and kernels could be easily choosen at the grub entry and menue. This would be cleaner i think.
Mmm i don`t know even if the usbsticks get bigger there is a good argument against this.: ` use different usbsticks stupid!!!` :-) so i think it would only be done if its easy and nice to archieve.

What I don't understand is why - if you only want to have different network parameters and other such hardware related configuration changes - you need to think about different overlays, initramfs configurations and even different kernels. I would have thought for most such situations, relatively simple changes to the normal (post-initramfs) boot sequence would be enough. Maybe something in /etc/rc.local if that is not too late.

paraflu wrote:

II.
Now comes something which is little bit weird but thinkable.
If i remember correctly at larch3 you save every overlay seperate with different numbers like overlay.001 and
so on. Nowerdays you have got one overlay squashfs and a lzop archive which could be merged. But lets stay for a moment at the larch3 state. If every change of the system got an overlay file numbered and maybe some md5 hash to make them unique, this bring us to some nice possibilities. If i could somehow relate the overlays to another like in the filename , so overlay.001 is before overlay.002 and so on i`ve got a hierachy. Now if i want to choose another way at lets say overlay.077 to another state of configuration i could split the overlay hierachy to lets say overlay.007.A001
where A001 is the new direction and all changes would go into A002 and so on. I don`t know how complicated this is
, but i think this could be done at a text references file where every overlay got its entry, md5 and tree hierachy, without using a database which i don`t have any clue about. I think this could be interesting.

Well I'm sure it's not too difficult to do anything you like with the overlays - though bear in mind that writing stuff in dash for the initramfs environment is sometimes quite a tough constraint. At first sight, though, this scheme looks a bit difficult to keep an overview of (at least to an old head like mine).

paraflu wrote:

D. Could you tell me how many fs aufs can union and would it be possible to reduce the / fs to only the system.sqfs and after that mount another overlay unionfs?

I think it can handle quite a lot of layers (branches) if that's what you mean. As to later mounting something over a single system.sqfs, that might depend on when you want to mount it. I'm not sure about this, but I think once you have entered the main boot sequence (i.e. run /sbin/init) there might be difficulties adding layers (but maybe only if they affect key system binaries). That is something you would have to test. In principle it is certainly possible to add and remove layers at any time.

paraflu wrote:

E. If i remember right you mentioned that you could not update the kernel. Couldn`t you write with with mkinicpio_larch
to another location and then overwrite it at shutdown. I think the larch scripts are still in the system or is this wrong.

Yes, of course it is possible to update the kernel, but not with a simple pacman call alone. The correct mkinicpio.conf file must be used and the new kernel and initramfs must be moved to the appropriate place on the usb-stick. Maybe something else would need doing too, but I can't think of anything at the moment. Doing this would of course invalidate all your old overlays (which you wanted to save so elaborately above)!

paraflu · 2008-05-24 00:18:44

Hello gradgrind,

Yes you are right, if i only want to have another configuration at software level or even some hardware
level i could use scripts in the after-initrd. I didn`t thought about that. It would have even the character
of that if i don`t save the session (bad english here) i have the system like before (i hope you understand that,
if i read it again- i not so much(very bad english here)). What i thought could be a problem could be
incompatible files. If i remember right nvidia has some problems with libdri or something like that. So
there could be the problem that applications for different computers cannot be installed at the same time.
But i think to have the pkg`s in the pkgcache combined with a configuration script could also archieve that. :-)

I have to make something clear here because i didn`t seperate it to much in my former
post. The numbered overlay is absolute different from the other posts. It was an idea which has to be seperated
from my other thoughts. This was only an idea i came upon. The goal was to have something like the snapshot
function in zfs or something like timevault (????) in ubuntu, so if you want a state recovery system based on

diffs backup which is the equivilant of the combined overlays. I don`t know, but i think they only save in
time-linear fashion and don`t have the ability to have branches (anybody correct me here). Organized with
txt files. Like a main overlay >
overlay.001
overlay.002
....
Then a branch file >
ref overlay.066
overlay.A001
overlay.A002
overlay.A003
...

So lets make it active.
When i want a specific state, i choose overlay.a003, then it reads the branch txt collect the overlays.AXXX
in the speficific order, then at the first line it has a reference to read the main overlay txt at the line where
the branch gets into the main tree and read the overlays before. The result has to be written into a new txt
file which is used as an argument for aufs to mount the new overlays at a state where the overlays are
totally unmounted (only system.sqfs is mounted).
I repeat this is totally separated from other sugestions for larch. i am happy with your changes. But this
was an idea, a theory and totally vapourware (no steam behind it :-) ). But i like to think about this, if it
has any advantages to the other solutions i mentioned before.

Some other thing i mentioned was about having seperate larch installions on one usbstick.
The reason why i thought about different partions
, is about the clean approach. When i have two different partitions on my usbstick, i could edit the grub entry
to read the kernel at a different partitions. This could not be reached with the directory approach i mentioned
before. So i thought do it clean way and maybe other possibilltys will turn up ( :-) ). It has also the advantage
at my skill level that i only need to
edit grub to point to other partition, and after that try to edit the larch script to ask for the choosen partition,
where i could find the wanted squashfs`s. The scripts which search for the squashfs are against me at that
point (not really i can edit them).
This is not really needed , i think , especially when i look at the responses from other users (none) , but it is fun for me and the
the benefit of having a real challenge which i could learn with. But its basic stuff, so i hope you don`t get bored.
My goals are
to have for every partition a different entry in grub (i don`t know to archieve this, maybe the last added
partition has to have all kernel entries? But for testing i can edit it at bootup)
To edit the scripts to have larch ask me for the right location of the squashfs like sda2 or sda3 and so on.
( maybe this is possible with the root=/dev/sdX parameter at startup. I know that you can read the c2r
parameter and implement in your scripts. Do you know more?) I don`t want to change the mount command,
like to nfsmount or so. This would be more that i can archieve at the moment. But i think this change could
open more possiblities to mount, even over network.
So the overview over my work would be
1. To ask about how to edit the script which you post about the user input string (asking where to find
the squashfs)
2. Use this input (maybe as a file) , as a variable to implement it into the larch scripts (copy the search-loop
, edit the sd(X) to point to the user-input), before it will search for other partitions,cd`s and so on. so
to make it clear if the input is garbage the script will continue to search for squashfs on various devices.
3. testing testing testing and give feedback if you like it.

So my first question is:
read -t 2 -p "Enter something: " m
if [ "x${m}" != "x" ]; then ...
How can i save input into a file?
questions:
When i save the input at the larch script state as /.xxxx.txt is it still there when the overlays get mounted(so
the at result system)? (i don`t think so, it will be a new tmpfs?)
where should i insert it(which line?)

That is the first step and i will handle it step for step. It is easier for me to understand
and to handle it with my decreasing spare time.

By the way. I this is not something which is is an demand. I like to have fun with a constructive goal
, where i can learn something and it is nice to have somebody to get some advice and to improve my
english, even if i talk to someone who has the same native language.
Also nichts fuer ungut. I find das sehr gut , dass sie mir so viele tips geben und sich so sehr um ihr
eigenes projekt kuemmern und selbst dumme fragen beantworten. Das heisst natuerlich nicht,
dass ich keine dumme fragen mehr stellen werde , insofern diese nicht beleidigend erscheinen.
But lets keep it in english, so that others can benefit too and i can improve my english.

So my questions will be in a longer term and step by step.
Maybe you could help there and i repeat this is not a demand for larch. I`s more about a possibility/theories
what could be archieve.
Wenn ich den eindruck habe, dass sie mich besser verstehen, wenn ich deutsch rede, werde ich
in deutsch weiter reden. But i don`t reach the point yet.

So thanks for your answers and nichts fuer ungut, its all fun for me and a maybe a learning course.

gradgrind · 2008-05-24 09:01:36

paraflu wrote:

...
So my first question is:
read -t 2 -p "Enter something: " m
if [ "x${m}" != "x" ]; then ...
How can i save input into a file?
questions:
When i save the input at the larch script state as /.xxxx.txt is it still there when the overlays get mounted(so
the at result system)? (i don`t think so, it will be a new tmpfs?)
where should i insert it(which line?)

It is possible to save files so that they will be accessible when you want them (though I'm not sure exactly what you want and when here). You can save stuff using the 'echo' command with output redirection (I would suggest looking for a shell tutorial if you're not comfortable with these concepts).

But I would also ask whether it might not be more convenient to have your selection done via the grub menu? You could have an entry for each choice that you want to present, the information (boot device, or just a flag) could then be used to determine how to proceed within the start scripts (all boot command line parameters are available within the scripts). The user wouldn't need to type anything, he could just select from the menu.

As to selecting boot devices, it might be better to use something like disk labels or UUIDs rather than /dev/sdbx (etc.), because with usb devices the naming can change from system to system and even according to what else is plugged in at boot time. I'm afraid I don't know anything about that yet, I would suggest looking at the grub documentation.

paraflu wrote:

... and it is nice to have somebody to get some advice and to improve my
english, even if i talk to someone who has the same native language.

Well actually I'm a native Brit., I've just been living in this beautiful country for quite a few years. But if you want to write in German, feel free, but please do it via mail as this is (apart from that one day) an English forum.

Arch Linux

#26 2008-05-12 06:03:22

Re: larch-5.2 released

#27 2008-05-13 20:59:25

Re: larch-5.2 released

#28 2008-05-13 22:48:11

Re: larch-5.2 released

#29 2008-05-13 23:40:52

Re: larch-5.2 released

#30 2008-05-14 05:05:02

Re: larch-5.2 released

#31 2008-05-18 21:45:00

Re: larch-5.2 released

#32 2008-05-18 22:14:40

Re: larch-5.2 released

#33 2008-05-18 23:18:23

Re: larch-5.2 released

#34 2008-05-22 21:20:43

Re: larch-5.2 released

#35 2008-05-23 05:38:17

Re: larch-5.2 released

#36 2008-05-24 00:18:44

Re: larch-5.2 released

#37 2008-05-24 09:01:36

Re: larch-5.2 released

Board footer