You are not logged in.
It's been a thought at the back of my mind for sometime but after Mr. Green mentioned it I want to look at using a loopback device to build Archie ISOs without the need for a separate partition.
Now, I'm no expert on these things, but, as I understand it, I can use commands similar to this to make a 1 gig loopback device:
mkdir /root/initrd
dd if=/dev/zero of=initrd.img bs=1k count=1024
mke2fs -i 1024 -b 1024 -m 5 -F -v initrd.img
mount initrd.img /root/initrd -t ext2 -o loop
This loopback device could be used to create the basic Arch install that the ISO require. You would then use that img file as the target partition in the mkliveiso command and mkliveiso could still do it's fancy unionfs mounting with it. You could even be gzip the image and save it for a later build, to save repeating the process.
So, it's basically indentical to using a separate hard-disk partition but can all be done from your home system.
Does that sound correct in theory?
Offline
I'm afraid I haven't been following Archie development, but I do wonder why you need a separate partition at all. You say something to do with unionfs, but doesn't this just work with directories?
larch: http://larch.berlios.de
Offline
You know, if you used a ramfs there's no need for a loopback device ever
Offline
Problem is though, phrak, we need 2Gb ramfs...is that doable?
gradgrind; you may have a point there. Ziggy knows the theory better than me, I'll ask him.
Offline
/me is interested
I assume many are put off building Archie because of the need for a spare partition
ramfs will have to read up on that
Archie needs a device name ie /dev/hda3 so could udev help out here ?
thinking aloud again
EDIT ... Archie creates partition when you run mkliveiso .... & it cannot be mounted emmm
Mr Green
Offline
Archie needs a device name ie /dev/hda3 so could udev help out here ?
Why? As I said, I don't know exactly what you are trying to do that needs a partition (could anyone explain that?), it just sounds a little strange to me because I don't need a separate partition for larch, which I imagine must use a somewhat similar build process to Archie.
larch: http://larch.berlios.de
Offline
this may come out wrong but maybe you could join forces with Archie to create the ultimate LiveCD construction kit
Archie does use a spare partition to build distro framework then crushes it to produce iso
So you have in affect a Arch install on that partition ... what we need is a way to build framework (install) another way
:?
Mr Green
Offline
Archie does use a spare partition to build distro framework then crushes it to produce iso
So you have in affect a Arch install on that partition ...
Yes, I understood that much. What I don't understand is why this is necessary. The mkarch script in larch will install Arch to any directory, it doesn't need to be on a separate partition.
larch: http://larch.berlios.de
Offline
then maybe you/we should talk to Ziggy (where is he hiding!)
Mr Green
Offline
Yes, I understood that much. What I don't understand is why this is necessary. The mkarch script in larch will install Arch to any directory, it doesn't need to be on a separate partition.
I think it is because Archie is also able to create a live-cd from an existing Arch installation. At some point I think that goal got mixed up with the --buildiso functionality and we inherited a separate partition for the --buildiso process - I don't think we need to.
However, I do think that the loopback device, and the possibility to save a "stock" img of the basic Arch install on your local system for repeated Archie builds has a lot of merit, especially given the neatness and compression options. Rather than just bundling the install into the local FS I think the loopback provides the better solution.
As gradgrind says, there is _no_ for a separate partition when using --buildiso; it's something we'll need to fix.
Mr Green: Archie and larch have very different goals. larch does things Archie doesn't want to and Archie does things in a way larch wouldn't dream of. The only thing they have in common is that they build a system using Arch pkgs - the use of pacman is in fact incidental in larch but does ALL the work in Archie As far as I can tell at least.
Phrak is also working on a live-cd which may become the basis for the install disk.
Offline
/me getting confused ....
We have larch Archie mkbootcd & now a secret project phrak which one to use lol
loop device would be cool ... not sure how ramfs works kinda inird ramfs cpio stuff I guess
we talking 2G as minimum ... ?
Mr Green
Offline
However, I do think that the loopback device, and the possibility to save a "stock" img of the basic Arch install on your local system for repeated Archie builds has a lot of merit, especially given the neatness and compression options. Rather than just bundling the install into the local FS I think the loopback provides the better solution.
I've done rather a lot of larch iso builds during its development and I have found it is really quite convenient to have the clean Arch installation in a directory (I have used /home/ArchImage, but of course it could be anywhere) as the only thing I do with it is to compress it with squashfs (any modifications for the live system are done separately in an overlay, so I don't need to change anything in the installation directory, and I could actually throw it away after compression). By keeping the squashed image I can quickly remake isos after changes to the overlay files and build scripts which don't affect the main Arch system.
I'm sure that using a loopback system would be possible if you think this has advantages. I don't see much gain in looking into ramfs, as this is only a temporary filesystem (or did you mean this in some other context?).
larch: http://larch.berlios.de
Offline
Problem is though, phrak, we need 2Gb ramfs...is that doable?
Sure, though that's a bit large... ramfs image are still cpio.gz images
Offline