[arch-general] initramfs: execute own script
Hi there. I'm newbie in Archlinux's boot process. I need to run my own script in early userspace (initramfs). It must be after mounting root file system, but before switch root. I've opened default initramfs (kernel26.img) and reviewed it's content. So, Archlinux uses some kind of tool called 'kinit'. And it seems, that this tool mounts root and then switch. How to run my own script in kinit? Where can be found documentation of kinit? Thanks for patience. -- )\._.,--....,'``. /, _.. \ _\ (`._ ,. `._.-(,_..'--(,_..'`-.;.'
On Fri, Jan 22, 2010 at 10:39 AM, AlannY <m@alanny.ru> wrote:
Hi there. I'm newbie in Archlinux's boot process.
I need to run my own script in early userspace (initramfs). It must be after mounting root file system, but before switch root.
I've opened default initramfs (kernel26.img) and reviewed it's content. So, Archlinux uses some kind of tool called 'kinit'. And it seems, that this tool mounts root and then switch.
How to run my own script in kinit? Where can be found documentation of kinit?
It sounds like you should be able to put your script in /lib/initcpio/hooks and maybe a detection script for it in /lib/initcpio/install. Then add it to HOOKS in /etc/mkinitcpio.conf and rebuild the initramfs with "mkinitcpio -p kernel26". This is provided by the mkinitcpio package. I've never actually done this myself, so hopefully someone more knowledgeable will come by.
On Fri, Jan 22, 2010 at 06:39:58PM +0300, AlannY wrote:
Hi there. I'm newbie in Archlinux's boot process.
I need to run my own script in early userspace (initramfs). It must be after mounting root file system, but before switch root.
I've opened default initramfs (kernel26.img) and reviewed it's content. So, Archlinux uses some kind of tool called 'kinit'. And it seems, that this tool mounts root and then switch.
How to run my own script in kinit? Where can be found documentation of kinit?
Thanks for patience.
The best way I found to do this was to read the source for the /lib/initcpio/{init,init_functions} look at some of the pairs /lib/initcpio/{hooks,install}/foo for different foo. However, you have to realize that you only have a restricted set of binaries and shell commands available then. Also, Arch is in the process of moving to a different initcpio system. It's not in any of the repos yet, but is in the pipeline. I haven't fully understood what the changes will be. I think they're getting rid of the use of klibc. I expect others who do know better will chime in. -- Jim Pryor profjim@jimpryor.net
On Fri, Jan 22, 2010 at 10:06 AM, Jim Pryor <lists+arch-general@jimpryor.net> wrote:
Also, Arch is in the process of moving to a different initcpio system. It's not in any of the repos yet, but is in the pipeline. I haven't fully understood what the changes will be. I think they're getting rid of the use of klibc.
Yeah, we're killing off klibc, as it's largely unmaintained. We're switching to actually using glibc and busybox. This comes at a size cost, but adds convenience and won't be too noticeable in terms of speed. We'll also gain improved filesystem detection and a better rescue shell. mkinitcpio, including the hooks/install pairs will remain as is, so the instructions provided in this thread will still work fine.
On 01/22/2010 05:21 PM, Aaron Griffin wrote:
On Fri, Jan 22, 2010 at 10:06 AM, Jim Pryor <lists+arch-general@jimpryor.net> wrote:
Also, Arch is in the process of moving to a different initcpio system. It's not in any of the repos yet, but is in the pipeline. I haven't fully understood what the changes will be. I think they're getting rid of the use of klibc.
Yeah, we're killing off klibc, as it's largely unmaintained. We're switching to actually using glibc and busybox. This comes at a size cost, but adds convenience and won't be too noticeable in terms of speed.
We'll also gain improved filesystem detection and a better rescue shell.
mkinitcpio, including the hooks/install pairs will remain as is, so the instructions provided in this thread will still work fine.
Wow... That rocks! Any supposed date? -- Enrico Carlesso<ecarlesso@ecarlesso.org> http://www.ecarlesso.org carlessoenrico @ skype enricocarlesso@gmail.com @ gtalk& msn
On Fri, Jan 22, 2010 at 10:57 AM, Marco <domanov@gmail.com> wrote:
Yeah, we're killing off klibc, as it's largely unmaintained. We're switching to actually using glibc and busybox.
Did you mean ulibc?
No, not uClibc either. We're actually using glibc itself. Other distros do this as well, as it DOES add a lot of flexibility
On Fri, 22 Jan 2010 12:25:16 -0600 Aaron Griffin <aaronmgriffin@gmail.com> wrote:
Did you mean ulibc? No, not uClibc either. We're actually using glibc itself. Other distros do this as well, as it DOES add a lot of flexibility
Just out of curiosity. Was eglibc considered? Why? Why not? I can see, that maintaing just another libc only for minor space benefits in a short-lived initrd doesn't make a lot of sense, but Debian seems to think, that it could even be an all-out replacement for glibc in general. Jinks
On 23/01/10 20:39, Alexander Duscheleit wrote:
On Fri, 22 Jan 2010 12:25:16 -0600 Aaron Griffin<aaronmgriffin@gmail.com> wrote:
Did you mean ulibc? No, not uClibc either. We're actually using glibc itself. Other distros do this as well, as it DOES add a lot of flexibility
Just out of curiosity. Was eglibc considered? Why? Why not?
I can see, that maintaing just another libc only for minor space benefits in a short-lived initrd doesn't make a lot of sense, but Debian seems to think, that it could even be an all-out replacement for glibc in general.
There is really no advantage to using eglibc if you are on x86 or x86_64 systems. Debian will find eglibc appealing because they support all sorts of platforms that are not particularly well supported by glibc. Allan
On 01/23/2010 08:01 AM, Allan McRae wrote:
On 23/01/10 20:39, Alexander Duscheleit wrote:
On Fri, 22 Jan 2010 12:25:16 -0600 Aaron Griffin<aaronmgriffin@gmail.com> wrote:
Did you mean ulibc? No, not uClibc either. We're actually using glibc itself. Other distros do this as well, as it DOES add a lot of flexibility
Just out of curiosity. Was eglibc considered? Why? Why not?
I can see, that maintaing just another libc only for minor space benefits in a short-lived initrd doesn't make a lot of sense, but Debian seems to think, that it could even be an all-out replacement for glibc in general.
There is really no advantage to using eglibc if you are on x86 or x86_64 systems. Debian will find eglibc appealing because they support all sorts of platforms that are not particularly well supported by glibc.
Allan
There is at least one advantage. The build system allows to select groups of functions to compile or not, for example network, ipv6, charsets, locales, maths, wide-chars, regex, nis, and others. But maybe not necessary for initramfs. -- Gerardo Exequiel Pozzi ( djgera ) http://www.djgera.com.ar KeyID: 0x1B8C330D Key fingerprint = 0CAA D5D4 CD85 4434 A219 76ED 39AB 221B 1B8C 330D
On Sat, Jan 23, 2010 at 8:33 AM, Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> wrote:
On 01/23/2010 08:01 AM, Allan McRae wrote:
On 23/01/10 20:39, Alexander Duscheleit wrote:
On Fri, 22 Jan 2010 12:25:16 -0600 Aaron Griffin<aaronmgriffin@gmail.com> wrote:
Did you mean ulibc?
No, not uClibc either. We're actually using glibc itself. Other distros do this as well, as it DOES add a lot of flexibility
Just out of curiosity. Was eglibc considered? Why? Why not?
I can see, that maintaing just another libc only for minor space benefits in a short-lived initrd doesn't make a lot of sense, but Debian seems to think, that it could even be an all-out replacement for glibc in general.
There is really no advantage to using eglibc if you are on x86 or x86_64 systems. Debian will find eglibc appealing because they support all sorts of platforms that are not particularly well supported by glibc.
Allan
There is at least one advantage. The build system allows to select groups of functions to compile or not, for example network, ipv6, charsets, locales, maths, wide-chars, regex, nis, and others. But maybe not necessary for initramfs.
Well, I think the current train of thought is that klibc was such a restricted subset and was difficult to work with and compile things against, using a glibc we already ship and test loses VERY little, so there's no real point in using yet-another restricted subset. I'll be the first person to question the speed reduction due to the size changes, but Thomas has benchmarked it. The simple fact is that while there may be some slowdown, udev detecting modules is still the largest bottleneck.
On Fri, Jan 22, 2010 at 11:06:08AM -0500, Jim Pryor wrote:
The best way I found to do this was to read the source for the /lib/initcpio/{init,init_functions} look at some of the pairs /lib/initcpio/{hooks,install}/foo for different foo. However, you have to realize that you only have a restricted set of binaries and shell commands available then.
Also, Arch is in the process of moving to a different initcpio system. It's not in any of the repos yet, but is in the pipeline. I haven't fully understood what the changes will be. I think they're getting rid of the use of klibc.
I expect others who do know better will chime in.
It not helps at all. "Your" hooks runs before mounting root device. I need to run my script after mount root, but before switch_root. At the end of /lib/initcpio/init, there are call to kinit and it seems kinit mount root partition and do switch_root. Is it possible to write "hook" for kinit? P.S. Why does Arch uses kinit, raw is not trusted? -- )\._.,--....,'``. /, _.. \ _\ (`._ ,. `._.-(,_..'--(,_..'`-.;.'
I guess you'll need to replace kinit, or else include the mount command in your own script and skip the normal mount command. Looking at how something like this is handled in the hooks in archiso or larch might help you.
On Fri, Jan 22, 2010 at 11:11 AM, AlannY <m@alanny.ru> wrote:
On Fri, Jan 22, 2010 at 11:06:08AM -0500, Jim Pryor wrote:
The best way I found to do this was to read the source for the /lib/initcpio/{init,init_functions} look at some of the pairs /lib/initcpio/{hooks,install}/foo for different foo. However, you have to realize that you only have a restricted set of binaries and shell commands available then.
Also, Arch is in the process of moving to a different initcpio system. It's not in any of the repos yet, but is in the pipeline. I haven't fully understood what the changes will be. I think they're getting rid of the use of klibc.
I expect others who do know better will chime in.
It not helps at all. "Your" hooks runs before mounting root device. I need to run my script after mount root, but before switch_root.
At the end of /lib/initcpio/init, there are call to kinit and it seems kinit mount root partition and do switch_root.
Is it possible to write "hook" for kinit?
As Michael said, look at what archiso or larch do. In effect, the use a custom hook script that does the mounting and kinit step themselves, basically abandoning the rest of the init script.
P.S. Why does Arch uses kinit, raw is not trusted?
I have no idea what you're asking here. We use kinit because, when this was created, it was a quick and robust way to do this that didn't require major overhauls or any packages.
participants (10)
-
Aaron Griffin
-
AlannY
-
Alexander Duscheleit
-
Allan McRae
-
Enrico Carlesso
-
Gerardo Exequiel Pozzi
-
Jim Pryor
-
Marco
-
Michael Towers
-
Ray Kohler