How can I recreate ArchLinux's installation ramdisk?

V01D · 2006-08-17 22:44:20

Hi,
I'm on a project where I developed my own custom ramdisk so I can automate the installation procedure for Arch. Currently, I have a script that takes Arch's initrd.img, and adds stuff to it (my scripts).

Now, I would like to be able to create the ramdisk from scratch (not requiring Arch's image as a base). Therefore, I would like to get the script(s) (if any) that ArchLinux devs use to create Arch's installation ramdisk. There are some things I want to change (some busybox options and stuff) so I really need this.

On cvs I can see a nice laid build system for creating an installation image using the new cpio method. But I can't find anything related to the old initrd system (even when using the RELEASE_0_7_2 CVS tag).

Also, I'm interested in the initcpio system since it seems way more simple to create Arch's installation image. Even more, I already saw the archboot package that would allow me to recreate the initcpio that will be used for installing the upcoming Arch release. I'm going to play with this, but I'm going to stay with the old initrd system until Arch's next release.

And regarding the cpio system, I have a doubt. How does the ramdisk environment change when using cpio over old initrd? I noticed that busybox is no longer used. Is using busybox an option? Would it make sense?

Thanks

phrakture · 2006-08-17 23:06:36

V01D wrote:

Also, I'm interested in the initcpio system since it seems way more simple to create Arch's installation image. Even more, I already saw the archboot package that would allow me to recreate the initcpio that will be used for installing the upcoming Arch release. I'm going to play with this, but I'm going to stay with the old initrd system until Arch's next release.

On a personal level, I'm not a fan of archboot. It keeps the system running within the dash shell that is part of the klibc utilities. There is a problem with this, as klibc doesn't necessarilly free memory properly all the time (it's not designed to run for long periods of time, so memory reclaimation was actually _just_ added 2 days ago). One should leave early-userspace as soon as possible. archboot does not do this.

Personally, I feel the initcpio image for a boot CD should load a real arch system. This can be made pretty minimal, and adding squashfs/unionfs into the mix you can get a decent bootable CD at around 100 megs (with full bash and a handful of diagnosis tools).

I have scripts for this throw together... they're not production quality, but I can stick them into svn so you can play with it if you want.

V01D wrote:

And regarding the cpio system, I have a doubt. How does the ramdisk environment change when using cpio over old initrd? I noticed that busybox is no longer used. Is using busybox an option? Would it make sense?

Not much changes. For the record, initrd was obsoleted in kernel 2.5 for initramfs (which is used here). For some reason people still keep using initrd.
Adding busybox isn't a big deal, but, assuming you use the mechanism I have put in place with mkinitcpio, you'd want to actually write a copy of the base hook with your custom changes. For those who asked, this is why 'base' is not just defaultly installed, but is in the HOOKS setting.
Basically, to use busybox, you'd want to either link it against klibc (might be tough) or link it statically. I can't guarantee that dropping klibc for uClibc isn't going to have an impact on the mkinitcpio scripts (and if you do this and it does cause breakage, please let me know).

Feel free to ask any questions you'd like.

V01D · 2006-08-17 23:27:20

phrakture wrote:

V01D wrote:
Also, I'm interested in the initcpio system since it seems way more simple to create Arch's installation image. Even more, I already saw the archboot package that would allow me to recreate the initcpio that will be used for installing the upcoming Arch release. I'm going to play with this, but I'm going to stay with the old initrd system until Arch's next release.
On a personal level, I'm not a fan of archboot. It keeps the system running within the dash shell that is part of the klibc utilities. There is a problem with this, as klibc doesn't necessarilly free memory properly all the time (it's not designed to run for long periods of time, so memory reclaimation was actually _just_ added 2 days ago). One should leave early-userspace as soon as possible. archboot does not do this.
Personally, I feel the initcpio image for a boot CD should load a real arch system. This can be made pretty minimal, and adding squashfs/unionfs into the mix you can get a decent bootable CD at around 100 megs (with full bash and a handful of diagnosis tools).
I have scripts for this throw together... they're not production quality, but I can stick them into svn so you can play with it if you want.
V01D wrote:
And regarding the cpio system, I have a doubt. How does the ramdisk environment change when using cpio over old initrd? I noticed that busybox is no longer used. Is using busybox an option? Would it make sense?
Not much changes. For the record, initrd was obsoleted in kernel 2.5 for initramfs (which is used here). For some reason people still keep using initrd.
Adding busybox isn't a big deal, but, assuming you use the mechanism I have put in place with mkinitcpio, you'd want to actually write a copy of the base hook with your custom changes. For those who asked, this is why 'base' is not just defaultly installed, but is in the HOOKS setting.
Basically, to use busybox, you'd want to either link it against klibc (might be tough) or link it statically. I can't guarantee that dropping klibc for uClibc isn't going to have an impact on the mkinitcpio scripts (and if you do this and it does cause breakage, please let me know).
Feel free to ask any questions you'd like.

Ok, now I'm getting things a little better. I think that my best option is to use busybox using initcpio (don't you know how I can ask about the scripts you use for the old initrd? even if I don't use that initrd, I would like to see how the filesystem inside the initrd is created; there are programs like dhcpcd that I don't know from where to take (my own system?)).

I have some more questions now =]
a) You say I should use static busybox or with klibc. Can't I just use uClibc? (NOTE: I get a little confused about what uClibc is... I see libc6 on the ramdisk, is that uClibc?)
b) is the new cpio system just a new way of handling file and a RAM based filesystem? or is it a deeper change compared to initrd? the whole thing about kinit confuses me a little... And I can't find much documentation about this. I mean, I saw an option on busybox's config regarding something about init and initramfs, but I don't get much about it.
In other words, how much would I have to change If I'd create a cpio with all files that are present on the initrd?
c) regarding any extra program I want to add (think of the BINARY='' option of mkinitcpio), how would this be handled if I use busybox? will it see that I use uClibc? Or will it try to add klibc?
d) Can I add any program to the ramdisk and expect it to work (assuming it doesn't depends on any other library but libc)? I mean, does a program have to be compiled specially to be used with uClibc or klibc?

Well, thanks a lot for the help in advance.
Matt.

phrakture · 2006-08-18 01:23:34

V01D wrote:

Ok, now I'm getting things a little better. I think that my best option is to use busybox using initcpio (don't you know how I can ask about the scripts you use for the old initrd? even if I don't use that initrd, I would like to see how the filesystem inside the initrd is created; there are programs like dhcpcd that I don't know from where to take (my own system?)).

Well, the scripts would/should work with either system. Problem is that the initrd scripts are a bit lacking. The mkinitcpio scripts are included in /lib/initcpio/* - check under the "hooks" directory. You don't need dhcpcd. This is already accounted for with the 'net' hook, which is part of mkinitcpio.

mkinitcpio -H net

for help with the net hook, and how to use it.

V01D wrote:

You say I should use static busybox or with klibc. Can't I just use uClibc? (NOTE: I get a little confused about what uClibc is... I see libc6 on the ramdisk, is that uClibc?)

Both uClibc and klibc have similar goals. Both are mini C libraries, meant to be used for small systems. The difference is that uClibc is meant for embedded systems, and klibc is meant specifically for early-userspace. You *can* use a pure uClibc system, but you will lose all the tools that klibc provides (ls /usr/lib/klibc/bin/*). Admittedly, some of these are replaced by busybox, but others (which are important) may not be. However, they should all compile under uClibc.

V01D wrote:

is the new cpio system just a new way of handling file and a RAM based filesystem? or is it a deeper change compared to initrd? the whole thing about kinit confuses me a little... And I can't find much documentation about this. I mean, I saw an option on busybox's config regarding something about init and initramfs, but I don't get much about it.
In other words, how much would I have to change If I'd create a cpio with all files that are present on the initrd?

The difference between initrd and initramfs, from a consumer's persepctive, is minimal. Instead of /linuxrc, you want to use /init as the script name. If you were to convert the existing initrd, you would just have to rename that.
I need to stress, though, that the linuxrc for the old initrd is very very limited. Reusing that is going to cause alot of headaches and cost you development time. The init script and hooks that are part of mkinitcpio are much more generalized, and the system, as a whole, is hugely open to "add ins". Maybe it would help if you explained exactly what you want to do, and I can tell you how much work it would take to do it both ways?

V01D wrote:

regarding any extra program I want to add (think of the BINARY='' option of mkinitcpio), how would this be handled if I use busybox? will it see that I use uClibc? Or will it try to add klibc?

klibc is added by the 'base' hook, which is why I stated earlier that you can rewrite your own custom base hook to take care of that, or even removed base altogether. There are only a few minor issues there.

V01D wrote:

Can I add any program to the ramdisk and expect it to work (assuming it doesn't depends on any other library but libc)? I mean, does a program have to be compiled specially to be used with uClibc or klibc?

No, copying random programs to the ramdisk will fail. You need to recompile them against klibc or uClibc, or link them statically. You can not interchange C libraries.

I really think it would help if you describe what you're trying to do. It sounds like you want busybox simply for convienance, and are going to cause yourself a mess of trouble just to add it.

V01D · 2006-08-18 01:53:39

Well, regarding on "what I want to do": an automated installation like RedHat's kickstart system. Most specifically, I've created (it's already working, but not released) a system (contained in a single arch package) by which you can use ArchLinux in cluster environments (something like a replacement for RockCluster distribution). The project is thoroughly explained on http://www.archcluster.com.ar

In short, what I need (and currently do) is:
create a minimal set of scripts that only try to get the NIC detected and then run DHCP on it. Later, by looking at the DHCP lease information (/etc/dhcpc/dhcpcd-eth0.info) I take the DHCP server's address and do a GET to the web server installed there, passing the NIC's MAC as a parameter to the CGI script. This script, has a set of configuration files defining how the node should be installed. The web scripts create a tarball with the remaining scripts and handles it to the node being installed. The node now runs the main script in the package and starts partitioning, formatting, retrieving packages, configuring the node and then, reboots.

So, I need:
a) dhcp (I'm deciding if I can actually use the net hook or not, depends on the degree of integration with my current scripts, it just would be easier to have udhcp integrated into busybox and not change my scripts at all)
b) all possible modules that come with the kernel (this would allow an user to put a custom kernel without having to learn about the hooks system). I mean, I would create a hook that just copies most of the modules useful during installation.

And regarding the limitations of linuxrc... I'm currently using the initrd, so using that again but over the cpio system would probably be easier for me since I wouldn't have to change my script a lot (and what I wan't from the cpio system is the possibility to create this installation image without root privilieges, since it is just like a tar file). Now, I would have to create my own 'base' hook for busybox and uClibc, but that doesn't seem so hard.

I think I just don't need all the power of the klibc system (at least, from my not-so-informed point of view).

If you are curious about the scripts I've developed, you can check the subversion repository where I'm storing my code. The scripts under scripts/ are the ones that get copied to the initrd. Under www/script/ you'll find the rest of the scripts, which are retrieved after getting the kickstart tarball.

BTW, I've tried to build uClibc using the PKGBUILD I've found on CVS (under arch/) but It ends up showing me the menuconfig... is the .config missing?

V01D · 2006-08-18 04:22:05

After finding more documentation I'm getting this a even a little more....
I see now that busybox can be either linked dynically against uclibc (this seems to be the case for arch's installation image) or statically (in which case, no library is required).

Also, it seems I can get all the needed functionality from busybox: dhcp client, wget. So, what I'm going to try now is to build busybox statically and forget about uclibc (specially since it seems to be a _really_ intrtincated procedure to get busybox to compile against uclibc, since it seems to need a special environment for this). Besides... having everything in busybox satisfies my KISS urges =]

But, after getting this tested, I'll put this custom busybox in a cpio archive. And now that I think about it, I could use mkinitcpio (but only with my own hooks, since I wouldn't use any of arch's... or at least I would have to see how to include modules... since I think that the best would be to just copy every module that may be useful while autoinstalling (drivers and such).

gradgrind · 2006-08-18 10:18:56

I don't know if it would help you, but you may like to look at my - hopefully well documented - larch scripts. These use an initramfs (i.e. same as initcpio) presently based on busybox statically linked against uclibc. I haven't (yet) changed to something based on the Arch mkinitcpio because that seems quite a bit more complicated - overkill for my purposes (live CD). My documentation includes some details about compiling uclibc and busybox.

See http://four.fsphost.com/gradgrind/

There is also a fairly simple Arch installer written in python/bash.

phrakture · 2006-08-18 14:49:36

V01D wrote:

But, after getting this tested, I'll put this custom busybox in a cpio archive. And now that I think about it, I could use mkinitcpio (but only with my own hooks, since I wouldn't use any of arch's... or at least I would have to see how to include modules... since I think that the best would be to just copy every module that may be useful while autoinstalling (drivers and such).

For dhcp, you can pass: "ip=:::::eth0:dhcp" to the kernel, and it will load eth0 with dhcp (requires the 'net' hook). As for wget, I'm sure curl would probably compile against klibc, as curl is fairly small. Even smaller may be netcat, but I'm not sure....

The reason I bring this up is that, the smaller an image is, the faster it boots (and the less problems it has on lower-spec'd machines). Statically linking busybox may bloat the image a decent amount (random guess, about 500K).

V01D · 2006-08-18 16:21:20

gradgrind wrote:

I don't know if it would help you, but you may like to look at my - hopefully well documented - larch scripts. These use an initramfs (i.e. same as initcpio) presently based on busybox statically linked against uclibc. I haven't (yet) changed to something based on the Arch mkinitcpio because that seems quite a bit more complicated - overkill for my purposes (live CD). My documentation includes some details about compiling uclibc and busybox.
See http://four.fsphost.com/gradgrind/
There is also a fairly simple Arch installer written in python/bash.

I managed to compile busybox statically against glibc, is that a problem?
I got some warnings about some functions needing the library at runtime when linking busybox.

I'd compile uClibc if I had the .config that Arch uses. I could create my own configuration but I don't know much about how should it be configured.

I'll check your documentation and see If I can make something out of there.

edit I've saw your docs and now I'm trying to use buildroot, but I can't get the base .config you said you took from the prebuilt rootfs. Where can I get it?[/b]

V01D · 2006-08-18 16:32:37

phrakture wrote:

V01D wrote:
But, after getting this tested, I'll put this custom busybox in a cpio archive. And now that I think about it, I could use mkinitcpio (but only with my own hooks, since I wouldn't use any of arch's... or at least I would have to see how to include modules... since I think that the best would be to just copy every module that may be useful while autoinstalling (drivers and such).
For dhcp, you can pass: "ip=:::::eth0:dhcp" to the kernel, and it will load eth0 with dhcp (requires the 'net' hook). As for wget, I'm sure curl would probably compile against klibc, as curl is fairly small. Even smaller may be netcat, but I'm not sure....
The reason I bring this up is that, the smaller an image is, the faster it boots (and the less problems it has on lower-spec'd machines). Statically linking busybox may bloat the image a decent amount (random guess, about 500K).

But, I'm not using klibc for now... I don't know how hard could it get to compile busybox against it. At most, I would like to use uClibc. I don't see the need for curl if I have wget nor the net hook (which includes) dhcpcd into the image, if I have udhcpc.

Also, I'm not targetting really low end machines. I (and other people, if any) would be using ArchCluster on HPC environments, and there aren't very crappy machines there =b

phrakture · 2006-08-18 16:44:53

V01D wrote:

But, I'm not using klibc for now... I don't know how hard could it get to compile busybox against it. At most, I would like to use uClibc. I don't see the need for curl if I have wget nor the net hook (which includes) dhcpcd into the image, if I have udhcpc.

I'm trying to suggest ways to do this with klibc. curl is much smaller and quicker than wget, thus it reduces image size. Also, the nethook does _NOT_ include dhcpcd into the image. It does it using mostly the same code the kernel does for NFS loading.

tpowa · 2006-08-18 16:54:31

phrakture, archboot does leave dash and launches init with bash and such stuff so i don't see a problem here.

V01D · 2006-08-18 17:01:06

phrakture wrote:

V01D wrote:
But, I'm not using klibc for now... I don't know how hard could it get to compile busybox against it. At most, I would like to use uClibc. I don't see the need for curl if I have wget nor the net hook (which includes) dhcpcd into the image, if I have udhcpc.
I'm trying to suggest ways to do this with klibc. curl is much smaller and quicker than wget, thus it reduces image size. Also, the nethook does _NOT_ include dhcpcd into the image. It does it using mostly the same code the kernel does for NFS loading.

I understand klibc sounds like the better approach seems it is new, it is smaller, and it is what it is going to be used in the near future. But, right now, I really don't know how to manage myself with the kinit and klibc stuff. I just don't know how to start. I'm guessing I would have to hack some mkinitcpio hooks and make others of my own. Then modify my existing installation scripts... It's just more work right now. Besides, busybox is already working for me, so I know I won't have to start debugging a lot after I manage to create the cpio archive with busybox and uclibc in it.

One thing I don't get, is where all the binaries that busybox provides are when I'm using just the klibc system. I mean, I see the hooks adding files from my own system (on arch-net I see BINARIES with a whole bunch of programs). I mean, wouldn't this add the glibc as a dependency? Or do they use klibc automatically?

Also, regarding the net hook. I was looking at arch-net (from archboot) and not 'net' (from mkinitcpio), which confused me.

I understand that the kernel can already bring an interface up but I currently use some of the information I get from the dhcp for other purposes (I need the ip of the dhcp server, and dhcpcd did this... udhcpc also makes this possible). I don't know how the kernel manages the information it retrieves, I'll look into it. For now, there's no problem in using udhcpc.

gradgrind · 2006-08-18 19:57:28

I managed to compile busybox statically against glibc, is that a problem?

I should think that's ok, but I have never done it - it will probably be quite big, though.

I got some warnings about some functions needing the library at runtime when linking busybox.

Sorry, no idea. Try the busybox site?

I've saw your docs and now I'm trying to use buildroot, but I can't get the base .config you said you took from the prebuilt rootfs. Where can I get it?

Errrm, that's a good question. I'm afraid I'm not sure where I got it from, I probably searched through the prebuilt version and dug it out somewhere. The version I finally used is available in the larch tar-ball:
larch_all/larch-x.y.z/docs/buildroot_my_config

I think that's the same one I put in the wiki:
http://wiki.archlinux.org/index.php/Set … ent_system

V01D · 2006-08-18 21:14:58

I've finally managed to configure everything on my own =b
I'm compiling buildroot for the 6th time now =S
But, at least, now it is really customized...

BTW, in current buildroot at least, it is not necessary to compile busybox manually. buildroot can be configured in its menuconfig to get busybox and it willl compile it on its own. In other words, one just have to download buildroot, and configure buildroot. Afterwards, you can put your own .config files for busybox and uClibc. When you hit 'make' it will download everything it needs and compile automatically.

Pretty neat.

Arch Linux

#1 2006-08-17 22:44:20

How can I recreate ArchLinux's installation ramdisk?

#2 2006-08-17 23:06:36

Re: How can I recreate ArchLinux's installation ramdisk?

#3 2006-08-17 23:27:20

Re: How can I recreate ArchLinux's installation ramdisk?

#4 2006-08-18 01:23:34

Re: How can I recreate ArchLinux's installation ramdisk?

#5 2006-08-18 01:53:39

Re: How can I recreate ArchLinux's installation ramdisk?

#6 2006-08-18 04:22:05

Re: How can I recreate ArchLinux's installation ramdisk?

#7 2006-08-18 10:18:56

Re: How can I recreate ArchLinux's installation ramdisk?

#8 2006-08-18 14:49:36

Re: How can I recreate ArchLinux's installation ramdisk?

#9 2006-08-18 16:21:20

Re: How can I recreate ArchLinux's installation ramdisk?

#10 2006-08-18 16:32:37

Re: How can I recreate ArchLinux's installation ramdisk?

#11 2006-08-18 16:44:53

Re: How can I recreate ArchLinux's installation ramdisk?

#12 2006-08-18 16:54:31

Re: How can I recreate ArchLinux's installation ramdisk?

#13 2006-08-18 17:01:06

Re: How can I recreate ArchLinux's installation ramdisk?

#14 2006-08-18 19:57:28

Re: How can I recreate ArchLinux's installation ramdisk?

#15 2006-08-18 21:14:58

Re: How can I recreate ArchLinux's installation ramdisk?

Board footer