You are not logged in.

#76 2008-01-28 17:09:35

foxbunny
Member
From: Serbia
Registered: 2006-10-31
Posts: 759
Website

Re: larch-4 testing, can also 'livify' existing Arch installation

Thanks for the tips, gradgrind. However, I still don't completely understand how I'd create a boot CD for kickstarting the USB. Can I perhaps use the Arch Install disk and pass some arguments at the 'boot:' prompt?

The USB itself I crate the same way as the live CD only I pass '-u' to mklarch?

Like:

# ./mklarch -u -p my_profile

I tried to save session to 3 disks so far, and none of them work. So I gave up. I'll go with the USB (it's more practical anyway).

And a few more little questions. Other than saving the session, how would I modify parts of the live system directly but before burning? You mentioned an '-a' switch. That stops after squashing? If so, how can I stop mklarch before squashing to add or remove individual files form the system (instead of using the overlay)?

Offline

#77 2008-01-28 18:33:34

gradgrind
Member
From: Germany
Registered: 2005-10-06
Posts: 921

Re: larch-4 testing, can also 'livify' existing Arch installation

foxbunny wrote:

Thanks for the tips, gradgrind. However, I still don't completely understand how I'd create a boot CD for kickstarting the USB. Can I perhaps use the Arch Install disk and pass some arguments at the 'boot:' prompt?

No, for various reasons. Just create the USB, then cd to the larch/bin directory (on your build system) and read the comments at the top of the usb2bootiso script, then run it.

foxbunny wrote:

The USB itself I crate the same way as the live CD only I pass '-u' to mklarch?

Like:

# ./mklarch -u -p my_profile

Yes. Maybe. Do you really mean '-p my_profile' (i.e. is my_profile in the profiles directory)? There is also the '-d' option, for a directory path.

foxbunny wrote:

I tried to save session to 3 disks so far, and none of them work. So I gave up. I'll go with the USB (it's more practical anyway).

Quite. That's also why I'm giving up on session saving to optical media.

foxbunny wrote:

And a few more little questions. Other than saving the session, how would I modify parts of the live system directly but before burning? You mentioned an '-a' switch. That stops after squashing? If so, how can I stop mklarch before squashing to add or remove individual files form the system (instead of using the overlay)?

Run 'mklarch -h' to get a description of all options. The '-a' option stops after the Arch installation, before the squashing. You can then make changes. Then use the '-b' option to do the rest.

Offline

#78 2008-01-28 18:57:20

foxbunny
Member
From: Serbia
Registered: 2006-10-31
Posts: 759
Website

Re: larch-4 testing, can also 'livify' existing Arch installation

gradgrind wrote:

No, for various reasons. Just create the USB, then cd to the larch/bin directory (on your build system) and read the comments at the top of the usb2bootiso script, then run it.

Got it.

gradgrind wrote:

Yes. Maybe. Do you really mean '-p my_profile' (i.e. is my_profile in the profiles directory)? There is also the '-d' option, for a directory path.

Well, say I'm building in "~/larch_dir". If I pass a

~/larch_dir # ./mklarch -d ./larch/share/larch/profiles/my_profile

it won't work. I forgot the error message. But if I say:

~/larch_dir # ./mklarch -p my_profile

it works. I don't know if I got the first one right, but I'm quite happy with the latter. smile

gradgrind wrote:

Quite. That's also why I'm giving up on session saving to optical media.

TRK (Trinity Rescue Kit), which is based on Linux, has a neat trick of being able to generate an updated ISO. It can do it at any time (not just before shutdown). Basically, you fire an update script, which fetches the latest software from wherever it says in the script (like ClamAV definitions, F-PROT antivirus software, whatnot), modifies the system, and coughs up the new ISO. The only condition is that you have a mountable partition with enough space. I don't know how it does that, but it works on 512 MB memory machine that I used to own. It's a bit different than saving sessions, but it does the job if you (or anyone else) want to remaster your live system.

gradgrind wrote:

Run 'mklarch -h' to get a description of all options. The '-a' option stops after the Arch installation, before the squashing. You can then make changes. Then use the '-b' option to do the rest.

Thanks, I totally misread that part. tongue

Offline

#79 2008-01-28 19:15:27

gradgrind
Member
From: Germany
Registered: 2005-10-06
Posts: 921

Re: larch-4 testing, can also 'livify' existing Arch installation

foxbunny wrote:
gradgrind wrote:

Yes. Maybe. Do you really mean '-p my_profile' (i.e. is my_profile in the profiles directory)? There is also the '-d' option, for a directory path.

Well, say I'm building in "~/larch_dir". If I pass a

~/larch_dir # ./mklarch -d ./larch/share/larch/profiles/my_profile

it won't work. I forgot the error message. But if I say:

~/larch_dir # ./mklarch -p my_profile

it works. I don't know if I got the first one right, but I'm quite happy with the latter. smile

That's fine. If you put your_profile in the current directory, '-d your_profile' should work. Maybe the './' doesn't work properly.

foxbunny wrote:

TRK (Trinity Rescue Kit), which is based on Linux, has a neat trick of being able to generate an updated ISO. It can do it at any time (not just before shutdown). Basically, you fire an update script, which fetches the latest software from wherever it says in the script (like ClamAV definitions, F-PROT antivirus software, whatnot), modifies the system, and coughs up the new ISO. The only condition is that you have a mountable partition with enough space. I don't know how it does that, but it works on 512 MB memory machine that I used to own. It's a bit different than saving sessions, but it does the job if you (or anyone else) want to remaster your live system.

This sort of thing should be fairly straightforward in larch-5.

Offline

#80 2008-01-29 09:21:36

foxbunny
Member
From: Serbia
Registered: 2006-10-31
Posts: 759
Website

Re: larch-4 testing, can also 'livify' existing Arch installation

gradgrind wrote:

This sort of thing should be fairly straightforward in larch-5.

Oooh! Then I'm looking forward to it! big_smile

Offline

#81 2008-02-12 21:32:20

Sigi
Member
From: Thurgau, Switzerland
Registered: 2005-09-22
Posts: 1,131

Re: larch-4 testing, can also 'livify' existing Arch installation

Hey gradgrind and all the other larch pros out there!

I just got a new 4GB usb-stick *yeah* smile I couldn't resist to put my latest larch live-system on it as the first task with it. It didn't work... It doesn't find the livesystem on boot. Thats the output while putting the image on the stick with mklarch -ui:

German warnings:

// 4: /dev/sdb1 3935 MiB
// Device: 4
//
// "/dev/sdb1" will now be prepared. Continue? [y/N]: y
//
// Formatting /dev/sdb1 (vfat)
Überprüfe, dass niemand diese Festplatte zur Zeit benutzt ...
OK

Festplatte /dev/sdb: 1023 Zylinder, 127 Köpfe, 62 Sektoren/Spur
Alte Aufteilung:
Warnung: Die Partition sieht aus, als sie gemacht worden
  für C/H/S=*/16/32 (anstelle von 1023/127/62).
Für diese Auflistung nehme ich diese Geometrie an.
Einheit = Zylinder von 262144 Bytes, Blöcke von 1024 Bytes, Zählung beginnt bei 0

   Gerät  boot. Anfang   Ende  #Zyl.    #Blöcke   Id  System
/dev/sdb1          0+  15743   15744-   4030448    c  W95 FAT32 (LBA)
        Ende: (c,h,s) erwartet (1023,15,32) gefunden (383,15,32)
/dev/sdb2          0       -       0          0    0  Leer
/dev/sdb3          0       -       0          0    0  Leer
/dev/sdb4          0       -       0          0    0  Leer
Warnung: gegebene Größe (1024) überschreitet maximal erlaubte Größe (1023)

sfdisk: ungültige Eingabe
1+0 Datensätze ein
1+0 Datensätze aus
512 Bytes (512 B) kopiert, 1.7668e-05 s, 29.0 MB/s
mkfs.vfat 2.11 (12 Mar 2005)
// Copying the boot sector
0+1 Datensätze ein
0+1 Datensätze aus
410 Bytes (410 B) kopiert, 0.0967466 s, 4.2 kB/s
// Copying the files

English warnings:

// 4: /dev/sdb1 3935 MiB
// Device: 4
//
// "/dev/sdb1" will now be prepared. Continue? [y/N]: y
//
// Formatting /dev/sdb1 (vfat)
Checking that no-one is using this disk right now ...
OK

Disk /dev/sdb: 1023 cylinders, 127 heads, 62 sectors/track
Old situation:
Warning: The partition table looks like it was made
  for C/H/S=*/16/32 (instead of 1023/127/62).
For this listing I'll assume that geometry.
Units = cylinders of 262144 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start     End   #cyls    #blocks   Id  System
/dev/sdb1          0+  15743   15744-   4030448    c  W95 FAT32 (LBA)
        end: (c,h,s) expected (1023,15,32) found (383,15,32)
/dev/sdb2          0       -       0          0    0  Empty
/dev/sdb3          0       -       0          0    0  Empty
/dev/sdb4          0       -       0          0    0  Empty
Warning: given size (1024) exceeds max allowable size (1023)

sfdisk: bad input
1+0 records in
1+0 records out
512 bytes (512 B) copied, 1.718e-05 s, 29.8 MB/s
mkfs.vfat 2.11 (12 Mar 2005)
// Copying the boot sector
0+1 records in
0+1 records out
410 bytes (410 B) copied, 0.095765 s, 4.3 kB/s
// Copying the files

What's my problem? Is there a limit on the size of the stick/fs?

Cheers Sigi

P.S. Hope you don't mind if I reanimate this thread? :-)

edit: I'm using the latest larch4, btw
Do I have to hack the scripts to set a smaller blocksize?

Last edited by Sigi (2008-02-12 21:34:05)


Haven't been here in a while. Still rocking Arch. smile

Offline

#82 2008-02-13 06:25:31

gradgrind
Member
From: Germany
Registered: 2005-10-06
Posts: 921

Re: larch-4 testing, can also 'livify' existing Arch installation

Hi Sigi,

Yes, it's probably just that fat16 can't handle that size. One possibility would be to make a smaller partition. You could also tweak the usbboot script to use fat32 (which I believe can cope with - nearly - 4GB). I think syslinux is supposed to work with fat32, but I have never got it to boot on my old machine. Or else you could use grub.

Offline

#83 2008-02-13 06:31:55

Sigi
Member
From: Thurgau, Switzerland
Registered: 2005-09-22
Posts: 1,131

Re: larch-4 testing, can also 'livify' existing Arch installation

Well, what I've found so far is that there are some notebooks which are unable to boot from fat32-formatted USB sticks (which most probably includes mine) and that fat16 only supports file systems up to 2GiB. Because gradgrinds scripts are usually quite intelligent in using the best configuration I assume that a USB-stick >2GiB is automatically formatted with fat32. Is there a way to get my laptop to boot fat32?

edit: well, that was quite a coincidence now. I was posting the same time. I don't want to loose the ability to access the stick from win-machines (which makes it impossible to use grub) and I want to use the whole 4GiB of the stick. So there is IMO no point in having a LiveUSB system on this particular stick (I'm glad I still have my 2GiB to play around...) This kind of sucks. This is not meant offensive, I just hate the restrictions of fat16 smile

2nd edit: Eureka, thats a nice one! (Well ok, it wasted at least 1 hour of my "valuable" time but at least I know more now). sfdisk doesn't set the boot flag. After manually changing /dev/sdb1 to 'active' in cfdisk, the USB stick is booting. The filesystem is fat32, 4GiB  cool

3rd edit: I don't know if I got this right but would changing this (line 111 in /usr/bin/usbboot)

sfdisk ${dev} -N${part} <<EOF

to something like this (not tested!)

sfdisk ${dev} -N${part} -A${part} <<EOF

fix this?

Cheers Sigi

Last edited by Sigi (2008-02-13 07:26:38)


Haven't been here in a while. Still rocking Arch. smile

Offline

#84 2008-02-13 08:05:21

gradgrind
Member
From: Germany
Registered: 2005-10-06
Posts: 921

Re: larch-4 testing, can also 'livify' existing Arch installation

If you also look at line 112, you will see the '*', which should set the partition as active, so you shouldn't need '-A':

sfdisk ${dev} -N${part} <<EOF
,,0e,*
EOF

So I wonder what went wrong with yours?

Another thought: What about using two partitions? You could make a small bootable first partition with fat16 (so that it works on as many machines as possible) containing just the boot stuff (syslinux, kernel and larch.img) and a large fat32 2nd partition with all the rest of the larch stuff and whatever else you want. I assume Windows is not limited to single partition USB sticks?

Offline

#85 2008-02-13 14:11:49

raymano
Member
Registered: 2006-10-13
Posts: 357
Website

Re: larch-4 testing, can also 'livify' existing Arch installation

Windows only recognizes the first parition on a USB drive and only if it's FAT(16/32) or NTFS.

Last edited by raymano (2008-02-13 14:12:19)


FaunOS: Live USB/DVD Linux Distro: http://www.faunos.com

Offline

#86 2008-02-13 15:24:54

gradgrind
Member
From: Germany
Registered: 2005-10-06
Posts: 921

Re: larch-4 testing, can also 'livify' existing Arch installation

raymano wrote:

Windows only recognizes the first parition on a USB drive and only if it's FAT(16/32) or NTFS.

Wow, is that true? Do people really still use Windows? wink

Offline

#87 2008-02-17 12:00:47

wantilles
Member
From: Athens - Greece
Registered: 2007-03-29
Posts: 327

Re: larch-4 testing, can also 'livify' existing Arch installation

Is larch-4 pacman-3.1.x-compiliant?

Because larch-5 is so buggy, it is completely unusable.

Offline

#88 2008-02-17 13:01:29

gradgrind
Member
From: Germany
Registered: 2005-10-06
Posts: 921

Re: larch-4 testing, can also 'livify' existing Arch installation

wantilles wrote:

Is larch-4 pacman-3.1.x-compiliant?

Yes. But be aware that running pacman -Sy within larch may result in a crash - this is a problem with aufs built before February. If you use the aufs package from testing you should be ok.

Offline

#89 2008-02-17 13:16:06

dolby
Member
From: 1992
Registered: 2006-08-08
Posts: 1,581

Re: larch-4 testing, can also 'livify' existing Arch installation

in larch download page where it says

Source code
The complete source code including PKGBUILDs is available [b]here[/b].

the link is broken and there are no PKGBUILDs in ftp://archie.dotsrc.org/projects/archie/larch/larch4/


There shouldn't be any reason to learn more editor types than emacs or vi -- mg (1)
[You learn that sarcasm does not often work well in international forums.  That is why we avoid it. -- ewaller (arch linux forum moderator)

Offline

#90 2008-02-17 13:49:01

gradgrind
Member
From: Germany
Registered: 2005-10-06
Posts: 921

Re: larch-4 testing, can also 'livify' existing Arch installation

dolby wrote:

in larch download page where it says

Source code
The complete source code including PKGBUILDs is available [b]here[/b].

the link is broken and there are no PKGBUILDs in ftp://archie.dotsrc.org/projects/archie/larch/larch4/

Sorry about that, an oversight. I've updated it now (to ftp://archie.dotsrc.org/projects/archie … 113.tar.gz).

svn should also work.

Offline

#91 2008-02-23 21:48:13

wantilles
Member
From: Athens - Greece
Registered: 2007-03-29
Posts: 327

Re: larch-4 testing, can also 'livify' existing Arch installation

Larch-4 is pacman 3.1.x compliant on both architectures.

Offline

#92 2008-02-24 03:20:00

paraflu
Member
Registered: 2008-02-23
Posts: 53

Re: larch-4 testing, can also 'livify' existing Arch installation

Hi this is my third post and my english is not the best. i am better at reading but i hope it gets better with time.

1. Thank you all for this great distribution and all the effort the developers and tu`s and everybody who participate in this work have done.
2. thank you gradgrind for larch

about myself : first windows = 3.0  then 98 and after that xp and 2000. After that linux and bsd. started with gentoo and stayed there for maybe 2 years with a little bit of freebsd experience then archlinux.

Gradgrind:
1. I used larch3 and installed it as a live system on a harddisk. Is this still possible, because i used a script of you which done that, but this was a long time ago and i don`t know which one it was. Maybe you could post how you do that. i think it only involves copying the live cd to a partition and then install grub on the mbr if i remember right.

2. Have you ever think about using the initram-image for booting the *.sqf from nfs or elsewhere, if i remember right there is a thread about somebody else who ask you about this. I thought that it would be a nice feature when the system boots to have a prompt where i can enter a partition or path where larch should look for the *.sqf`s. this would also bring the possibilty of having more than one optional live systems on one disk , especially if one is bigger than ram and one smaller than the ram , for burning disks or ejecting the dvd/cd for many reasons.
I don`t know how you build the initram-image. I think that you use ldd for examine which shared libarys to copy. Is it possible to extend the image in the case that i want to include sshfs fuse truecrypt or anything else. I thought about this, because i thought to boot from a server which should crypt the connection and should only include clients which have the right keyfile, after that i thought that the various people who have an account on the net-booted live image could mount an trucrypt-image and use this as an client-side encrypted working directory. This is an idea had for longer time when i thought about larch and thinclient symbiosis. It`s only an idea. i don`t know if i will ever have the chance to test this because of the lack of computers, but maybe in a vm enviroment, which would destroy the possibility to examine if this had an speed improvement, because i thought that the server should offer the *.sqf`s on a ramdisk.







      SERVER -> Ramdisk = *.sqfs
                ip 192.168.1.3
                ssh keyfile for passwordless login
                |
        |-------------------------------------------
        |            |                |
    Client_01        Client02        Client03
    ssh keyfile        ssh keyfile        ssh keyfile
    initram-image        ........        .......
    mounts *.sqfs        .......            ..........
    by sshfs        .....            .....
    after that mount    ......            ......
    truecrypt-image     ......            .......
    from elsewhere        ......            ........

Server starts with maybe dhctp server or static ip. Client boots initram-image, seeks for dhctp-server or use static ip and/or mac address for server allocation then login with known ssh-key-file as user nobody( or any account without shell right, because the client only should mount the *.sqfs as read only and should not have any right whatsoever on the server.) mount *.sqfs with sshfs and use aufs to build system. Real person on the client should have account on the booted live system but thats it, because everything personal and write access should be delivered with a truecrypt container (i know this is slower than direct partion encryption , but it has also an pseudo limited space and an compression of data of the client-person. This has also has the advantage that every client has his own encryption so if one compromise the root then can delete the container (worse enough) but cannot get the content. Maybe use a bin-diff or xdelta to backup the client container fast enough to a secure place , where it can been reconstructed later.


Why? pros:     fast *.sqfs on ramdisk
        admin easy
        fallback easy if new system involves problems
        encrypted so only authorised clients gets connection and sniffing is harder
        maybe initram on flash and maybe updating from server side if bootet into ram (md5 integrity check?)
        client side encrytion because of truecrypt (i have to investigate if an network mounted container             encrypt symmetrical over the network but it should.)
        when the client is not needed, for example after work, it should be possible to boot another special
        image for using as cluster , distributed computing , movie encoding , encryption or anything else.
        Live system so no changes from an attacker are resistend.   
     
      cons:    maybe impossible
        when you update , you have to build the complete system to have changes beeing resistend
        maybe not importend in a secure sub domain?
        encryption over encryption (sshfs with truecrypt) more computing power needed
        maybe not needed at all and has no security advantages at all ( i don not have any big problems with             that because it`s only a theory.)


mmmh i thought that i should think more about it, but i think that i would never post it anyway, so i think i now will g for debate. (think think think - my english = badd)

so wink

ps: mods if this is not right in any way or i should open an own thread , tell me please, because my suggestion are not only larch specific.

Offline

#93 2008-02-24 20:04:43

gradgrind
Member
From: Germany
Registered: 2005-10-06
Posts: 921

Re: larch-4 testing, can also 'livify' existing Arch installation

paraflu wrote:

Hi this is my third post and my english is not the best. i am better at reading but i hope it gets better with time.

1. Thank you all for this great distribution and all the effort the developers and tu`s and everybody who participate in this work have done.
2. thank you gradgrind for larch

about myself : first windows = 3.0  then 98 and after that xp and 2000. After that linux and bsd. started with gentoo and stayed there for maybe 2 years with a little bit of freebsd experience then archlinux.

Gradgrind:
1. I used larch3 and installed it as a live system on a harddisk. Is this still possible, because i used a script of you which done that, but this was a long time ago and i don`t know which one it was. Maybe you could post how you do that. i think it only involves copying the live cd to a partition and then install grub on the mbr if i remember right.

The program to do this was (l)archin. It is still supplied with larch-4, but I don't know how well it works. Basically it is a matter of copying the live system to hard-disk and setting up grub, but there are a few additional points. larch-5 has a new python/gtk installer, which should also work with larch-4, called larchin-5. Please try this if you are interested (it is still under development, but I am keen to get feedback).

paraflu wrote:

2. Have you ever think about using the initram-image for booting the *.sqf from nfs or elsewhere, if i remember right there is a thread about somebody else who ask you about this. I thought that it would be a nice feature when the system boots to have a prompt where i can enter a partition or path where larch should look for the *.sqf`s. this would also bring the possibilty of having more than one optional live systems on one disk , especially if one is bigger than ram and one smaller than the ram , for burning disks or ejecting the dvd/cd for many reasons.
I don`t know how you build the initram-image. I think that you use ldd for examine which shared libarys to copy. Is it possible to extend the image in the case that i want to include sshfs fuse truecrypt or anything else.

Basically, yes, in larch-4. larch-5 uses a simpler boot scheme (and drops session-saving to CD/DVD in favour of simpler and better USB-stick support), which means, for your question, you are essentially limited to the normal (very limited) klibc-based initramfs system until the squashfs system is mounted.

paraflu wrote:

I thought about this, because i thought to boot from a server which should crypt the connection and should only include clients which have the right keyfile, after that i thought that the various people who have an account on the net-booted live image could mount an trucrypt-image and use this as an client-side encrypted working directory. This is an idea had for longer time when i thought about larch and thinclient symbiosis. It`s only an idea. i don`t know if i will ever have the chance to test this because of the lack of computers, but maybe in a vm enviroment, which would destroy the possibility to examine if this had an speed improvement, because i thought that the server should offer the *.sqf`s on a ramdisk.







      SERVER -> Ramdisk = *.sqfs
                ip 192.168.1.3
                ssh keyfile for passwordless login
                |
        |-------------------------------------------
        |            |                |
    Client_01        Client02        Client03
    ssh keyfile        ssh keyfile        ssh keyfile
    initram-image        ........        .......
    mounts *.sqfs        .......            ..........
    by sshfs        .....            .....
    after that mount    ......            ......
    truecrypt-image     ......            .......
    from elsewhere        ......            ........

Server starts with maybe dhctp server or static ip. Client boots initram-image, seeks for dhctp-server or use static ip and/or mac address for server allocation then login with known ssh-key-file as user nobody( or any account without shell right, because the client only should mount the *.sqfs as read only and should not have any right whatsoever on the server.) mount *.sqfs with sshfs and use aufs to build system. Real person on the client should have account on the booted live system but thats it, because everything personal and write access should be delivered with a truecrypt container (i know this is slower than direct partion encryption , but it has also an pseudo limited space and an compression of data of the client-person. This has also has the advantage that every client has his own encryption so if one compromise the root then can delete the container (worse enough) but cannot get the content. Maybe use a bin-diff or xdelta to backup the client container fast enough to a secure place , where it can been reconstructed later.


Why? pros:     fast *.sqfs on ramdisk
        admin easy
        fallback easy if new system involves problems
        encrypted so only authorised clients gets connection and sniffing is harder
        maybe initram on flash and maybe updating from server side if bootet into ram (md5 integrity check?)
        client side encrytion because of truecrypt (i have to investigate if an network mounted container             encrypt symmetrical over the network but it should.)
        when the client is not needed, for example after work, it should be possible to boot another special
        image for using as cluster , distributed computing , movie encoding , encryption or anything else.
        Live system so no changes from an attacker are resistend.   
     
      cons:    maybe impossible
        when you update , you have to build the complete system to have changes beeing resistend
        maybe not importend in a secure sub domain?
        encryption over encryption (sshfs with truecrypt) more computing power needed
        maybe not needed at all and has no security advantages at all ( i don not have any big problems with             that because it`s only a theory.)


mmmh i thought that i should think more about it, but i think that i would never post it anyway, so i think i now will g for debate. (think think think - my english = badd)

so wink

ps: mods if this is not right in any way or i should open an own thread , tell me please, because my suggestion are not only larch specific.

It sounds rather complicated to me, but I can't say whether it would be possible or not. It's not something I have considered, and I'm afraid it's not on my TODO list at the moment. If you really want something like this, I would suggest digging into the boot process and the functioning of live systems and then work on it yourself. If you need any help with anything I have done with larch, I'll do what I can to answer your questions.

Offline

#94 2008-02-24 21:33:23

paraflu
Member
Registered: 2008-02-23
Posts: 53

Re: larch-4 testing, can also 'livify' existing Arch installation

1. shaking my head -> I`m getting old. :-)  yes you right it was (l)archin and if i remember right i had to
    manually point mkinitcpio.conf to the larch-mkinitcpio.conf, because of the larch1 larch2 larch3 hooks otherwise
    it would not build the live initram-image. I will try to copy the files to hardisk from the running live dvd to
    hardisk with the grub directory and then setup grub with root(hdx,x) and setup (hdx). But i will also try
    the larch-5 with the new installer. I hope i understand you right that it will include an live-installer instead of
    only a `normal` install. Ha - maybe larch-5 first big_smile

2. Oh i didn`t thought about klibc. This would probably kill my limited skills (but learning is living). I`ve edited
    the larch1 script from sda to hda because of the pata ide issue which if i remember right you solved with
    mkinitcpio_ide. After editing i was surprised about me - i could change one letter. smile  So i will try but i see   
    this will be limited.
    As you mentioned and if i remember right the klibc-image builds the rootfs as an overlay from the *.sqfs
    and
    then after this is ready it will change the running rootfs to the overlay-rootfs with a specific command. I
    mentioned this , because that could also been done after changing to the overlay-rootfs to another   
    overlay-system. So klibc --> overlay-rootfs (in this case the one with sshfs, fuse and truecrypt or anything
    else) --> mount server *.sqfs --> net-overlay-rootfs. Am I wrong here?
    Yes you right this can`t be a priority  for you , it is more something which i had mind after thinking the
    larch-thinclient thing. Maybe the prompt for the more-than-one live images on dvd thing could be more of 
    an option, because i didn`t only thought about the session-burning problem , more of different configurations for smaller or bigger systems , not compatible installed packages (nvidia introduce another dri lib , if i  remember right. i could be wrong here), special overlays for preconfiguring (themes, home user directorys files, etc confs) and so on. This could be a hybrid approach between the modularity of slax and the all in one solution of larch , but maybe something total different. Problematic to do (How to build them and after that compare them and mksquashfs the difference and the same files as the base system otherwise it would introduce an overhead which is my opinion not a big problem on an dvd or any bigger storage. Mmm i don`t know,  doesn`t sound to easy and light but i think it sounds interesting at least for me).


So i will first try larch-5 and see what new features you introduce and think about all this again. Especially about the server idea, it was more an theory anyway, which i wanted to debate and get more info and feedback, for not getting on a totally wrong track. :-)

Thank you for the reply and effort and we will see us at the larch-5 thread soon.

P.s (I think i should learn about formating my posts first :-)  )

Offline

#95 2008-02-25 06:21:11

gradgrind
Member
From: Germany
Registered: 2005-10-06
Posts: 921

Re: larch-4 testing, can also 'livify' existing Arch installation

Yes, please do have a look at larch-5 first. It is easiest for me to answer questions about that version because it's the one I am presently working on.

Could you explain what you mean here: "I hope i understand you right that it will include an live-installer instead of only a `normal` install."?

Offline

#96 2008-02-25 14:33:13

paraflu
Member
Registered: 2008-02-23
Posts: 53

Re: larch-4 testing, can also 'livify' existing Arch installation

Hello Gradgrind

Here we go:

Ok what i meant by not a `normal` installer, is that i wanted to have the same structure of the
live system on the harddisk. It`s more or less the same when you install the system to an usb-stick.
i tested this. Here is what`ve done, maybe other wanted this too.
All in qemu
Boot the live cd.
cfdisk /dev/yourhardisk
partition it (700MB whatsoever)
format partition
mkdir /mnt/temp
mount /dev/yourpartition /mnt/temp
cp (or use mc) /.larch/medium/* to /mnt/temp
execute grub
root (hd0,0) (your root partition here)
setup (hd0) (install in MBR)
umount /mnt/temp
reboot

That`s it. Worked for me. So it`s only a copy process and grub install
Why? small harddisk :-D (i know it`s stupid, but hey maybe it will not harm the harddisk to much, because
of lesser head movement.). I used this for testing stuff with the possibility to write on the medium or mnt another partion on it. i`ve got question here: If i mount another partition in /mnt/ write on it , don`t unmount it at the
shutdown and answer yes for write changes to the medium, is then the mounted partition included in the mksquashfs
for the overlay. And when would this be the case? Maybe when i mounted it elsewhere. I do not want this but i would
be nice to know when this would occur. So its more or less like usb without the specific flash adjustment. The process is so easy , that i wouldn`t suggest to include it. But maybe i am not the only one , so they could have
a look here.

For the other part:
1 . I mentioned after your suggestion to examine the klibc initram-image , if it could be possibil to
mount another overlay after an overlay which included sshfs fuse and truecrypt by a command. I think i read something like that in your stage scripts maybe larch1 or 2.(Have to find them first , i think they were in usr/share..... I
will have to look at the install package itself. :-) ). I ask this because i see the possibility of doing something like this by myself, the klibc thing would not match with my lack of skills. So i thought to run a script on the first overlay at the init process end which look like this:

sshfs 192.168.1.4 (server) /mnt/overlay2_sqhfs
aufs /mnt/overlay2_sqfs/system.sqfs /mnt/overlay2_root (here i have to look at the aufs docs or maybe you got an hint)
# i didn`t think about var, tmp and home but maybe i will include them all together in the personal truecrypt-image
( I don`t know where to store yet - i will see) which will ask for a password as in contrast to the sshfs-overlay-root which should use a keyfiles for loginless mounting
then
changerootfs to /mnt/overlay2_root
What i don`t know at this point if i get a login prompt after that. Maybe the login executable has to been restarted.
I don`t know.

This all seems easier for me and hopefully doable.


2. I still don`t know if it could be possibible to have the initram-fs look for another sqfs in an directory on
the usb or cd/dvd and if it could be entered with an kernel boot parameter. If i remember right it searches for
the sqfs on sdx and srx . I say this because i change that in the past because it didn`t find my harddisk which
was hdax. If i remember right it takes the first ones it found. There were some incidents when i forget to eject the
cd and wanted to boot to the live-system on the harddisk , because it would use the *.sqhfs on the cd. :-) I don`t
think this is importend for you because other then sdx and srx doesn`t exist in the regular live cd/usb application ,but if you got a hint if it is in larch1 or elsewhere , i would like to look at it and maybe play with it.
And what you thing about multiple *.sqfs in different directories which could be selected with `vmlinux sqfs=/dev/sda1/base1/ ` or something similar. This could provide different systems on one disk. Is this something you had in
mind too and implement this in an other way?



Thank you for your efforts.

Offline

#97 2008-02-25 19:54:14

gradgrind
Member
From: Germany
Registered: 2005-10-06
Posts: 921

Re: larch-4 testing, can also 'livify' existing Arch installation

paraflu wrote:

Hello Gradgrind

Here we go:

Ok what i meant by not a `normal` installer, is that i wanted to have the same structure of the
live system on the harddisk. It`s more or less the same when you install the system to an usb-stick.
i tested this. Here is what`ve done, maybe other wanted this too.
All in qemu
Boot the live cd.
cfdisk /dev/yourhardisk
partition it (700MB whatsoever)
format partition
mkdir /mnt/temp
mount /dev/yourpartition /mnt/temp
cp (or use mc) /.larch/medium/* to /mnt/temp
execute grub
root (hd0,0) (your root partition here)
setup (hd0) (install in MBR)
umount /mnt/temp
reboot

That`s it. Worked for me. So it`s only a copy process and grub install

Yes, that's it, basically. larch has a script for this which does a little bit more (but it may need updating for larch-5): 'liveInstall'.
'larchin' installs the system as a normal Arch Linux system, but I have plans to include an easy 'live system' installation (I believe this is sometimes called a 'frugal' installation) with GUI either in 'larchin' or as part of 'larch'.

paraflu wrote:

Why? small harddisk :-D (i know it`s stupid, but hey maybe it will not harm the harddisk to much, because
of lesser head movement.). I used this for testing stuff with the possibility to write on the medium or mnt another partion on it. i`ve got question here: If i mount another partition in /mnt/ write on it , don`t unmount it at the
shutdown and answer yes for write changes to the medium, is then the mounted partition included in the mksquashfs
for the overlay. And when would this be the case? Maybe when i mounted it elsewhere. I do not want this but i would
be nice to know when this would occur.

That's a good question. All mounts should be excluded, if this is not the case I would consider it a bug.

paraflu wrote:

So its more or less like usb without the specific flash adjustment. The process is so easy , that i wouldn`t suggest to include it. But maybe i am not the only one , so they could have
a look here.

As I said above, it is intended to be supported as standard, I just haven't got around to doing it properly yet. It is a useful option, e.g. for systems running from compact flash/IDE.

paraflu wrote:

For the other part:
1 . I mentioned after your suggestion to examine the klibc initram-image , if it could be possibil to
mount another overlay after an overlay which included sshfs fuse and truecrypt by a command. I think i read something like that in your stage scripts maybe larch1 or 2.(Have to find them first , i think they were in usr/share..... I
will have to look at the install package itself. :-) ). I ask this because i see the possibility of doing something like this by myself, the klibc thing would not match with my lack of skills. So i thought to run a script on the first overlay at the init process end which look like this:

sshfs 192.168.1.4 (server) /mnt/overlay2_sqhfs
aufs /mnt/overlay2_sqfs/system.sqfs /mnt/overlay2_root (here i have to look at the aufs docs or maybe you got an hint)
# i didn`t think about var, tmp and home but maybe i will include them all together in the personal truecrypt-image
( I don`t know where to store yet - i will see) which will ask for a password as in contrast to the sshfs-overlay-root which should use a keyfiles for loginless mounting
then
changerootfs to /mnt/overlay2_root
What i don`t know at this point if i get a login prompt after that. Maybe the login executable has to been restarted.
I don`t know.

This all seems easier for me and hopefully doable.

Yes, of course it would be possible to somehow include the code you need in the initramfs, I don't think you would need aufs at this stage. You could just include it 'straight' (as part of the initramfs system), or mount an archive using squashfs, you could use the standard utilities, or build a smaller set using uclibc/busybox. If you want to use the standard utilities, the way I built the base.sqf archive in larch-4 (in script 'buildlive', using ldd to detect library dependencies) might be of interest.
But if you want to base it on larch, I would recommend using larch-5 as the basis, extending this as necessary. It should provide a reasonably flexible starting point.

paraflu wrote:

2. I still don`t know if it could be possibible to have the initram-fs look for another sqfs in an directory on
the usb or cd/dvd and if it could be entered with an kernel boot parameter. If i remember right it searches for
the sqfs on sdx and srx . I say this because i change that in the past because it didn`t find my harddisk which
was hdax. If i remember right it takes the first ones it found. There were some incidents when i forget to eject the
cd and wanted to boot to the live-system on the harddisk , because it would use the *.sqhfs on the cd. :-) I don`t
think this is importend for you because other then sdx and srx doesn`t exist in the regular live cd/usb application ,but if you got a hint if it is in larch1 or elsewhere , i would like to look at it and maybe play with it.
And what you thing about multiple *.sqfs in different directories which could be selected with `vmlinux sqfs=/dev/sda1/base1/ ` or something similar. This could provide different systems on one disk. Is this something you had in
mind too and implement this in an other way?

Playing around in this way is not very difficult, and I have considered it. larch-5 allows use of the boot parameter 'root=/dev/xxx', which allows you to specify the device to boot (at least it should do, I haven't tested it yet). Other approaches would certainly be possible, too.

Offline

Board footer

Powered by FluxBB