path: root/docs/busybox.busybox.narkive.com_PBeyeZOM_custom-initrd-using.txt

   [1]busybox@busybox.net
   Discussion:
   Custom initrd using busybox
   Moot Account
   2006-11-05 16:30:01 UTC
   [2]Permalink
   Hi,
   This is a bloated idea but it's just an exercise. The idea is to use
   the rootfs from buildroot as the initrd (i.e. initrd=/boot/rootfs.gz).
   This initrd should mount the _real_ rootfs using pivot_root. The real
   rootfs is in the second partition (/dev/hda2) and is the _same_ rootfs
   built from buildroot. In other words, rootfs.gz = rootfs in /dev/hda2.
   Inside the initrd (ie rootfs.gz) is /linuxrc which will be read first
   by the kernel after mounting the initrd. Instead of pointing it to
   /bin/busybox, I'm going to create a custom linuxrc.
   My _problem_ starts here. I CAN'T chroot to the rootfs in /dev/hda2
   and execute the /linuxrc, which is still pointed /bin/busybox. I need
   to chroot because /linuxrc will initialize my rootfs and put up the
   login (ie /etc/inittab getty).
   Here are my arguments to the kernel:
   linux /boot/bzImage console=ttyS0,9600
   (since it's a serial console)
   This is the custom linuxrc that does _not_ work:
   #!/bin/sh
   echo "linuxrc execute"
   mount -t proc /proc /proc
   mkdir new_root
   mount -t ext2 /dev/hda2 /new_root
   umount proc
   cd /new_root
   pivot_root . initrd
   mount -t proc proc proc
   mount -t devfs devfs dev
   exec /usr/sbin/chroot . 'exec /linuxrc' \
   <dev/console >dev/console 2>&1
   I'm stuck after the execution pivot_root. It seems that dev/console is
   busy.
   Thanks for any help.
   Luciano Miguel Ferreira Rocha
   2006-11-05 16:52:52 UTC
   [3]Permalink
   [4]Post by Moot Account
   Hi,
   This is a bloated idea but it's just an exercise. The idea is to use
   the rootfs from buildroot as the initrd (i.e. initrd=/boot/rootfs.gz).
   This initrd should mount the _real_ rootfs using pivot_root. The real
   rootfs is in the second partition (/dev/hda2) and is the _same_ rootfs
   built from buildroot. In other words, rootfs.gz = rootfs in /dev/hda2.
   Inside the initrd (ie rootfs.gz) is /linuxrc which will be read first
   by the kernel after mounting the initrd. Instead of pointing it to
   /bin/busybox, I'm going to create a custom linuxrc.
   My _problem_ starts here. I CAN'T chroot to the rootfs in /dev/hda2
   and execute the /linuxrc, which is still pointed /bin/busybox. I need
   to chroot because /linuxrc will initialize my rootfs and put up the
   login (ie /etc/inittab getty).
   linux /boot/bzImage console=ttyS0,9600
   (since it's a serial console)
   #!/bin/sh
   echo "linuxrc execute"
   mount -t proc /proc /proc
   mkdir new_root
   mount -t ext2 /dev/hda2 /new_root
   umount proc
   cd /new_root
   pivot_root . initrd
   mount -t proc proc proc
   mount -t devfs devfs dev
   exec /usr/sbin/chroot . 'exec /linuxrc' \
   <dev/console >dev/console 2>&1
   I'm stuck after the execution pivot_root. It seems that dev/console is
   busy.
   And this stops linuxrc from continuing?
   Try:
   ...
   cd /new_root
   exec < dev/console &> dev/console
   pivot_root . initrd
   ...
   --
   lfr
   0/0
   -------------- next part --------------
   A non-text attachment was scrubbed...
   Name: not available
   Type: application/pgp-signature
   Size: 189 bytes
   Desc: not available
   Url :
   http://busybox.net/lists/busybox/attachments/20061105/78ae3c9d/attachme
   nt.pgp
   Moot Account
   2006-11-05 17:09:43 UTC
   [5]Permalink
   Thanks! I'll try this when I get to the board (Soekris net4801)
   tomorrow.
   But I have another question. How is /sbin/init ( ->busybox ) accessed.
   When I use:
   exec /usr/sbin/chroot . /sbin/init <dev/console >dev/console 2>&1
   the usage of init is printed. This probably means that init is not run
   as PID 1. Also, when I use /linuxrc it seems to be stuck.
   Any ideas?
   Thanks again.
   -Lenmarc
   [6]Post by Luciano Miguel Ferreira Rocha
   [7]Post by Moot Account
   Hi,
   This is a bloated idea but it's just an exercise. The idea is to use
   the rootfs from buildroot as the initrd (i.e. initrd=/boot/rootfs.gz).
   This initrd should mount the _real_ rootfs using pivot_root. The real
   rootfs is in the second partition (/dev/hda2) and is the _same_ rootfs
   built from buildroot. In other words, rootfs.gz = rootfs in /dev/hda2.
   Inside the initrd (ie rootfs.gz) is /linuxrc which will be read first
   by the kernel after mounting the initrd. Instead of pointing it to
   /bin/busybox, I'm going to create a custom linuxrc.
   My _problem_ starts here. I CAN'T chroot to the rootfs in /dev/hda2
   and execute the /linuxrc, which is still pointed /bin/busybox. I need
   to chroot because /linuxrc will initialize my rootfs and put up the
   login (ie /etc/inittab getty).
   linux /boot/bzImage console=ttyS0,9600
   (since it's a serial console)
   #!/bin/sh
   echo "linuxrc execute"
   mount -t proc /proc /proc
   mkdir new_root
   mount -t ext2 /dev/hda2 /new_root
   umount proc
   cd /new_root
   pivot_root . initrd
   mount -t proc proc proc
   mount -t devfs devfs dev
   exec /usr/sbin/chroot . 'exec /linuxrc' \
   <dev/console >dev/console 2>&1
   I'm stuck after the execution pivot_root. It seems that dev/console is
   busy.
   And this stops linuxrc from continuing?
   ...
   cd /new_root
   exec < dev/console &> dev/console
   pivot_root . initrd
   ...
   Luciano Miguel Ferreira Rocha
   2006-11-05 17:20:31 UTC
   [8]Permalink
   [9]Post by Moot Account
   Thanks! I'll try this when I get to the board (Soekris net4801)
   tomorrow.
   But I have another question. How is /sbin/init ( ->busybox ) accessed.
   exec /usr/sbin/chroot . /sbin/init <dev/console >dev/console 2>&1
   the usage of init is printed. This probably means that init is not run
   as PID 1. Also, when I use /linuxrc it seems to be stuck.
   Any ideas?
   Ah, yes. You can't do that using linuxrc. Linuxrc isn't run as init
   (pid
   isn't 1). You're supposed to set the real root device writing to a
   /proc
   file (/proc/sys/kernel/real-root-dev), exit, and the kernel then mounts
   the real root device and executes init.
   You can change that behaviour by booting your kernel with
   "init=/linuxrc
   root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC).
   Other option you could check out would be using initramfs instead of
   old
   initrd:
   1. name your script /init instead of /linuxrc;
   2. call exec switch_root instead of pivot_root (and switch_root isn't
   supposed to return, it calls init by itself);
   3. create the new "initrd" as a new-format cpio file:
   find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img
   More information about initramfs and initrd can be found in a kernel
   source tree:
   - Documentation/initrd.txt
   - Documentation/filesystems/ramfs-rootfs-initramfs.txt
   - Documentation/early-userspace/README
   --
   lfr
   0/0
   -------------- next part --------------
   A non-text attachment was scrubbed...
   Name: not available
   Type: application/pgp-signature
   Size: 189 bytes
   Desc: not available
   Url :
   http://busybox.net/lists/busybox/attachments/20061105/32f2f1f3/attachme
   nt-0001.pgp
   Bernhard Fischer
   2006-11-05 18:07:30 UTC
   [10]Permalink
   [11]Post by Luciano Miguel Ferreira Rocha
   You can change that behaviour by booting your kernel with
   "init=/linuxrc
   root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC).
   resp. root=0100 which wastes less memory ;)
   btw, is there a way to flush all or some of these convenience vars out
   of
   the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i
   admit..
   Jason Schoon
   2006-11-05 18:49:19 UTC
   [12]Permalink
   [13]Post by Luciano Miguel Ferreira Rocha
   You can change that behaviour by booting your kernel with
   "init=/linuxrc
   root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC).
   resp. root00 which wastes less memory ;)
   btw, is there a way to flush all or some of these convenience vars out
   of
   the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i
   admit..
   By convenience vars, do you mean such as /dev/ram0? If so, turning of
   sysfs
   support will get rid of them. In many embedded scenarios sysfs doesn't
   buy
   you much anyway. If you are hotplugging or something similar though,
   the
   space savings are not likely to be worth not having sysfs.
   -------------- next part --------------
   An HTML attachment was scrubbed...
   URL:
   http://busybox.net/lists/busybox/attachments/20061105/8a59f7e3/attachme
   nt.html
   Jason Schoon
   2006-11-05 18:55:15 UTC
   [14]Permalink
   [15]Post by Jason Schoon
   [16]Post by Luciano Miguel Ferreira Rocha
   [17]Post by Luciano Miguel Ferreira Rocha
   You can change that behaviour by booting your kernel with
   "init=/linuxrc
   [18]Post by Luciano Miguel Ferreira Rocha
   root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC).
   resp. root00 which wastes less memory ;)
   btw, is there a way to flush all or some of these convenience vars out
   of
   the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i
   admit..
   By convenience vars, do you mean such as /dev/ram0? If so, turning of
   sysfs support will get rid of them. In many embedded scenarios sysfs
   doesn't buy you much anyway. If you are hotplugging or something
   similar
   though, the space savings are not likely to be worth not having sysfs.
   Nevermind, I figured out what you were really asking. I have never seen
   a
   scenario (CONFIG_EMBEDDED or otherwise) where the full parameters were
   not
   available via /proc/cmdline. I'm guessing that means there isn't
   currently
   a way to get them out of memory.
   If anything, the linux-tiny guys might have a config option to do that.
   -------------- next part --------------
   An HTML attachment was scrubbed...
   URL:
   http://busybox.net/lists/busybox/attachments/20061105/68741ca9/attachme
   nt.htm
   Bernhard Fischer
   2006-11-05 19:11:15 UTC
   [19]Permalink
   [20]Post by Jason Schoon
   [21]Post by Bernhard Fischer
   resp. root=0100 which wastes less memory ;)
   btw, is there a way to flush all or some of these convenience vars out
   of
   the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i
   admit..
   I have never seen a
   scenario (CONFIG_EMBEDDED or otherwise) where the full parameters were
   not
   available via /proc/cmdline. I'm guessing that means there isn't
   currently
   a way to get them out of memory.
   If anything, the linux-tiny guys might have a config option to do that.
   Yeah, thought so too. Sounds like __user_init along with something like
   sysctl (or better, putting it into a /del_usermem fops.flush or the
   like). hm..
   Bernhard Fischer
   2006-11-05 19:11:15 UTC
   [22]Permalink
   [23]Post by Jason Schoon
   [24]Post by Bernhard Fischer
   resp. root=0100 which wastes less memory ;)
   btw, is there a way to flush all or some of these convenience vars out
   of
   the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i
   admit..
   I have never seen a
   scenario (CONFIG_EMBEDDED or otherwise) where the full parameters were
   not
   available via /proc/cmdline. I'm guessing that means there isn't
   currently
   a way to get them out of memory.
   If anything, the linux-tiny guys might have a config option to do that.
   Yeah, thought so too. Sounds like __user_init along with something like
   sysctl (or better, putting it into a /del_usermem fops.flush or the
   like). hm..
   Jason Schoon
   2006-11-05 18:55:15 UTC
   [25]Permalink
   [26]Post by Jason Schoon
   [27]Post by Luciano Miguel Ferreira Rocha
   [28]Post by Luciano Miguel Ferreira Rocha
   You can change that behaviour by booting your kernel with
   "init=/linuxrc
   [29]Post by Luciano Miguel Ferreira Rocha
   root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC).
   resp. root=0100 which wastes less memory ;)
   btw, is there a way to flush all or some of these convenience vars out
   of
   the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i
   admit..
   By convenience vars, do you mean such as /dev/ram0? If so, turning of
   sysfs support will get rid of them. In many embedded scenarios sysfs
   doesn't buy you much anyway. If you are hotplugging or something
   similar
   though, the space savings are not likely to be worth not having sysfs.
   Nevermind, I figured out what you were really asking. I have never seen
   a
   scenario (CONFIG_EMBEDDED or otherwise) where the full parameters were
   not
   available via /proc/cmdline. I'm guessing that means there isn't
   currently
   a way to get them out of memory.
   If anything, the linux-tiny guys might have a config option to do that.
   -------------- next part --------------
   An HTML attachment was scrubbed...
   URL:
   http://lists.busybox.net/pipermail/busybox/attachments/20061105/68741ca
   9/attachment-0001.htm
   Jason Schoon
   2006-11-05 18:49:19 UTC
   [30]Permalink
   [31]Post by Bernhard Fischer
   [32]Post by Luciano Miguel Ferreira Rocha
   You can change that behaviour by booting your kernel with
   "init=/linuxrc
   root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC).
   resp. root=0100 which wastes less memory ;)
   btw, is there a way to flush all or some of these convenience vars out
   of
   the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i
   admit..
   By convenience vars, do you mean such as /dev/ram0? If so, turning of
   sysfs
   support will get rid of them. In many embedded scenarios sysfs doesn't
   buy
   you much anyway. If you are hotplugging or something similar though,
   the
   space savings are not likely to be worth not having sysfs.
   -------------- next part --------------
   An HTML attachment was scrubbed...
   URL:
   http://lists.busybox.net/pipermail/busybox/attachments/20061105/8a59f7e
   3/attachment.htm
   Rob Landley
   2006-11-05 20:19:40 UTC
   [33]Permalink
   [34]Post by Luciano Miguel Ferreira Rocha
   Ah, yes. You can't do that using linuxrc. Linuxrc isn't run as init
   (pid
   isn't 1). You're supposed to set the real root device writing to a
   /proc
   file (/proc/sys/kernel/real-root-dev), exit, and the kernel then mounts
   the real root device and executes init.
   Using initramfs and switch_root is way more straightforward than this.
   And
   doesn't have the magic behind the scenes stuff (like reparenting every
   running process whose ".", "..", or "/" points to the old root, yes
   including
   kernel threads).
   Just sayin'...
   Rob
   [35]Post by Luciano Miguel Ferreira Rocha
   Other option you could check out would be using initramfs instead of
   old
   1. name your script /init instead of /linuxrc;
   Or supply the kernel the "rdinit=/blah" argument to tell it what you
   called
   it.
   [36]Post by Luciano Miguel Ferreira Rocha
   2. call exec switch_root instead of pivot_root (and switch_root isn't
   supposed to return, it calls init by itself);
   Don't forget the "exec". Common mistake. If it's not PID 1, it'll
   abort.
   [37]Post by Luciano Miguel Ferreira Rocha
   find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img
   The kernel can do this for you, if you prefer. And even build it into
   the
   bzImage.
   [38]Post by Luciano Miguel Ferreira Rocha
   - Documentation/filesystems/ramfs-rootfs-initramfs.txt
   I wrote that one. If it's missing something, let me know.
   I also wrote a couple articles for TimeSys, earlier this year. It's a
   little
   long-winded, but might help:
   http://www.timesys.com/timesource/march_06.htm
   http://timesys.com/timesource/initramfs.htm
   Rob
   --
   "Perfection is reached, not when there is no longer anything to add,
   but
   when there is no longer anything to take away." - Antoine de
   Saint-Exupery
   Luciano Miguel Ferreira Rocha
   2006-11-05 23:34:31 UTC
   [39]Permalink
   [40]Post by Rob Landley
   [41]Post by Luciano Miguel Ferreira Rocha
   - Documentation/filesystems/ramfs-rootfs-initramfs.txt
   I wrote that one. If it's missing something, let me know.
   Information about the rdinit parameter would be nice. :)
   It is in kernel-parameters.txt but I never searched for such an option.
   Also, it reads "The program run by the old initrd (which was called
   /initrd, not /init)". Did you mean /linuxrc? I don't recall seeing
   /initrd anywhere else.
   And finally, could you add some bigger warnings about rootfs being
   ramfs, a non-swappable device? The file does say that initramfs is
   extracted to rootfs, an instance of ramfs. But I didn't read the file
   that carefully the first time...
   I made a /init that extracts cpios (gziped and bziped) in / to a tmpfs,
   moves all remaining files to the tmpfs, and executes the new init, if
   anyone is interested.
   Regards,
   Luciano Rocha
   --
   lfr
   0/0
   -------------- next part --------------
   A non-text attachment was scrubbed...
   Name: not available
   Type: application/pgp-signature
   Size: 189 bytes
   Desc: not available
   Url :
   http://busybox.net/lists/busybox/attachments/20061105/6bd4039f/attachme
   nt.pgp
   Rob Landley
   2006-11-05 23:43:52 UTC
   [42]Permalink
   [43]Post by Luciano Miguel Ferreira Rocha
   [44]Post by Rob Landley
   [45]Post by Luciano Miguel Ferreira Rocha
   - Documentation/filesystems/ramfs-rootfs-initramfs.txt
   I wrote that one. If it's missing something, let me know.
   Information about the rdinit parameter would be nice. :)
   I think the current version (2.6.18 and up) mentions it?
   [46]Post by Luciano Miguel Ferreira Rocha
   It is in kernel-parameters.txt but I never searched for such an option.
   Also, it reads "The program run by the old initrd (which was called
   /initrd, not /init)". Did you mean /linuxrc? I don't recall seeing
   /initrd anywhere else.
   Yeah, that's linuxrc.
   [47]Post by Luciano Miguel Ferreira Rocha
   And finally, could you add some bigger warnings about rootfs being
   ramfs, a non-swappable device?
   There are patches floating around to make it tmpfs if you have tmpfs
   built
   into the kernel. I keep thinking they've been integrated. (This is the
   point of tmpfs.)
   [48]Post by Luciano Miguel Ferreira Rocha
   The file does say that initramfs is
   extracted to rootfs, an instance of ramfs. But I didn't read the file
   that carefully the first time...
   It should be possible for this to be tmpfs. When did this last crop
   up...
   http://lkml.org/lkml/2006/7/30/120
   Dunno if it got integrated or not, but there's a start...
   [49]Post by Luciano Miguel Ferreira Rocha
   I made a /init that extracts cpios (gziped and bziped) in / to a tmpfs,
   moves all remaining files to the tmpfs, and executes the new init, if
   anyone is interested.
   The proper thing to do is patch the kernel so initramfs is a tmpfs.
   Rob
   --
   "Perfection is reached, not when there is no longer anything to add,
   but
   when there is no longer anything to take away." - Antoine de
   Saint-Exupery
   Luciano Miguel Ferreira Rocha
   2006-11-06 00:20:07 UTC
   [50]Permalink
   This post might be inappropriate. Click to display it.
   Moot Account
   2006-11-06 20:07:15 UTC
   [51]Permalink
   Hi all,
   Thanks all for the help, it's working now! Apparently, Ive been doing
   the right initrd and initramfs for the past few days. The problem is
   with my real rootfs (the one in /dev/hda2).
   Please pardon a newbie. My question is: what's the _difference_
   between the "buildroot/build_i686/root" folder and rootfs.i686.ext2.gz
   if I enable the gzipped output? I know this is related to buildroot
   but please answer if it's trivial. =)
   The working setup NOW is rootfs.i686.ext2.gz which is my initrd and
   also my real rootfs. The NON-working setup is rootfs.i686.ext2.gz as
   my initrd and "buildroot/build_i686/root" folder as my real rootfs,
   which I copied to /dev/hda2.
   Again, thanks all for the tips!
   -Lenmarc
   Rob Landley
   2006-11-07 21:48:09 UTC
   [52]Permalink
   [53]Post by Moot Account
   Please pardon a newbie. My question is: what's the _difference_
   between the "buildroot/build_i686/root" folder and rootfs.i686.ext2.gz
   The difference is that this is the BusyBox mailing list, and the
   buildroot
   mailing list is buildroot at uclibc.org. Your question is about
   buildroot, not
   busybox.
   Rob
   --
   "Perfection is reached, not when there is no longer anything to add,
   but
   when there is no longer anything to take away." - Antoine de
   Saint-Exupery
   Rob Landley
   2006-11-07 21:48:09 UTC
   [54]Permalink
   [55]Post by Moot Account
   Please pardon a newbie. My question is: what's the _difference_
   between the "buildroot/build_i686/root" folder and rootfs.i686.ext2.gz
   The difference is that this is the BusyBox mailing list, and the
   buildroot
   mailing list is buildroot at uclibc.org. Your question is about
   buildroot, not
   busybox.
   Rob
   --
   "Perfection is reached, not when there is no longer anything to add,
   but
   when there is no longer anything to take away." - Antoine de
   Saint-Exupery
   Moot Account
   2006-11-06 20:07:15 UTC
   [56]Permalink
   Hi all,
   Thanks all for the help, it's working now! Apparently, Ive been doing
   the right initrd and initramfs for the past few days. The problem is
   with my real rootfs (the one in /dev/hda2).
   Please pardon a newbie. My question is: what's the _difference_
   between the "buildroot/build_i686/root" folder and rootfs.i686.ext2.gz
   if I enable the gzipped output? I know this is related to buildroot
   but please answer if it's trivial. =)
   The working setup NOW is rootfs.i686.ext2.gz which is my initrd and
   also my real rootfs. The NON-working setup is rootfs.i686.ext2.gz as
   my initrd and "buildroot/build_i686/root" folder as my real rootfs,
   which I copied to /dev/hda2.
   Again, thanks all for the tips!
   -Lenmarc
   Luciano Miguel Ferreira Rocha
   2006-11-06 00:20:07 UTC
   [57]Permalink
   This post might be inappropriate. Click to display it.
   Rob Landley
   2006-11-05 23:43:52 UTC
   [58]Permalink
   [59]Post by Luciano Miguel Ferreira Rocha
   [60]Post by Rob Landley
   [61]Post by Luciano Miguel Ferreira Rocha
   - Documentation/filesystems/ramfs-rootfs-initramfs.txt
   I wrote that one. If it's missing something, let me know.
   Information about the rdinit parameter would be nice. :)
   I think the current version (2.6.18 and up) mentions it?
   [62]Post by Luciano Miguel Ferreira Rocha
   It is in kernel-parameters.txt but I never searched for such an option.
   Also, it reads "The program run by the old initrd (which was called
   /initrd, not /init)". Did you mean /linuxrc? I don't recall seeing
   /initrd anywhere else.
   Yeah, that's linuxrc.
   [63]Post by Luciano Miguel Ferreira Rocha
   And finally, could you add some bigger warnings about rootfs being
   ramfs, a non-swappable device?
   There are patches floating around to make it tmpfs if you have tmpfs
   built
   into the kernel. I keep thinking they've been integrated. (This is the
   point of tmpfs.)
   [64]Post by Luciano Miguel Ferreira Rocha
   The file does say that initramfs is
   extracted to rootfs, an instance of ramfs. But I didn't read the file
   that carefully the first time...
   It should be possible for this to be tmpfs. When did this last crop
   up...
   http://lkml.org/lkml/2006/7/30/120
   Dunno if it got integrated or not, but there's a start...
   [65]Post by Luciano Miguel Ferreira Rocha
   I made a /init that extracts cpios (gziped and bziped) in / to a tmpfs,
   moves all remaining files to the tmpfs, and executes the new init, if
   anyone is interested.
   The proper thing to do is patch the kernel so initramfs is a tmpfs.
   Rob
   --
   "Perfection is reached, not when there is no longer anything to add,
   but
   when there is no longer anything to take away." - Antoine de
   Saint-Exupery
   Luciano Miguel Ferreira Rocha
   2006-11-05 23:34:31 UTC
   [66]Permalink
   [67]Post by Rob Landley
   [68]Post by Luciano Miguel Ferreira Rocha
   - Documentation/filesystems/ramfs-rootfs-initramfs.txt
   I wrote that one. If it's missing something, let me know.
   Information about the rdinit parameter would be nice. :)
   It is in kernel-parameters.txt but I never searched for such an option.
   Also, it reads "The program run by the old initrd (which was called
   /initrd, not /init)". Did you mean /linuxrc? I don't recall seeing
   /initrd anywhere else.
   And finally, could you add some bigger warnings about rootfs being
   ramfs, a non-swappable device? The file does say that initramfs is
   extracted to rootfs, an instance of ramfs. But I didn't read the file
   that carefully the first time...
   I made a /init that extracts cpios (gziped and bziped) in / to a tmpfs,
   moves all remaining files to the tmpfs, and executes the new init, if
   anyone is interested.
   Regards,
   Luciano Rocha
   --
   lfr
   0/0
   -------------- next part --------------
   A non-text attachment was scrubbed...
   Name: not available
   Type: application/pgp-signature
   Size: 189 bytes
   Desc: not available
   Url :
   http://lists.busybox.net/pipermail/busybox/attachments/20061105/6bd4039
   f/attachment-0002.pgp
   Rob Landley
   2006-11-05 20:26:42 UTC
   [69]Permalink
   [70]Post by Luciano Miguel Ferreira Rocha
   find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img
   Now _that_ is an ugly set of command line options (for cpio). Let's
   see, that
   should equate to:
   cpio -0 -o -H newc
   I'm interested in this because I'm about halfway through writing
   toybox's
   get_optflags(), which doesn't use getopt() so I have to parse all this
   myself. It's not actually that hard, but the tricky case is where some
   of
   your arguments have no dash, ala ps or tar. Then you can wind up with
   stuff
   like:
   tar xjfCv filename.tbz dirname blah
   Which is equivalent to:
   tar -x -j -f filename.tbz -C dirname -v blah
   And _not_ equivalent to:
   tar -x -j -f C -v filename.tbz blah
   Which is what you get with the getopt() in uClibc 0.9.28. (I realize
   this is
   a funky corner case, but it's one that bit me and I want to get it
   _right_
   this time.)
   It looks like the nodash mode and the dash mode of the option parser
   have
   different sequencing requirements. Ok, I can do that...
   Rob
   --
   "Perfection is reached, not when there is no longer anything to add,
   but
   when there is no longer anything to take away." - Antoine de
   Saint-Exupery
   Luciano Miguel Ferreira Rocha
   2006-11-05 23:02:12 UTC
   [71]Permalink
   [72]Post by Rob Landley
   [73]Post by Luciano Miguel Ferreira Rocha
   find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img
   Now _that_ is an ugly set of command line options (for cpio).
   Thank you. :)
   I used to use -0oc. But after wasting a coule of hours trying to make a
   kernel
   recognize a cpio archive, I found that -c doesn't mean exactly the same
   thing everywhere. So now I use -Hnewc everywhere.
   --
   lfr
   0/0
   -------------- next part --------------
   A non-text attachment was scrubbed...
   Name: not available
   Type: application/pgp-signature
   Size: 189 bytes
   Desc: not available
   Url :
   http://busybox.net/lists/busybox/attachments/20061105/fb8660e1/attachme
   nt.pgp
   Luciano Miguel Ferreira Rocha
   2006-11-05 23:02:12 UTC
   [74]Permalink
   [75]Post by Rob Landley
   [76]Post by Luciano Miguel Ferreira Rocha
   find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img
   Now _that_ is an ugly set of command line options (for cpio).
   Thank you. :)
   I used to use -0oc. But after wasting a coule of hours trying to make a
   kernel
   recognize a cpio archive, I found that -c doesn't mean exactly the same
   thing everywhere. So now I use -Hnewc everywhere.
   --
   lfr
   0/0
   -------------- next part --------------
   A non-text attachment was scrubbed...
   Name: not available
   Type: application/pgp-signature
   Size: 189 bytes
   Desc: not available
   Url :
   http://lists.busybox.net/pipermail/busybox/attachments/20061105/fb8660e
   1/attachment-0002.pgp
   Bernhard Fischer
   2006-11-05 18:07:30 UTC
   [77]Permalink
   [78]Post by Luciano Miguel Ferreira Rocha
   You can change that behaviour by booting your kernel with
   "init=/linuxrc
   root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC).
   resp. root=0100 which wastes less memory ;)
   btw, is there a way to flush all or some of these convenience vars out
   of
   the kernel-mem perhaps if CONFIG_EMBEDDED=y ? Didn't look yet, i
   admit..
   Rob Landley
   2006-11-05 20:19:40 UTC
   [79]Permalink
   [80]Post by Luciano Miguel Ferreira Rocha
   Ah, yes. You can't do that using linuxrc. Linuxrc isn't run as init
   (pid
   isn't 1). You're supposed to set the real root device writing to a
   /proc
   file (/proc/sys/kernel/real-root-dev), exit, and the kernel then mounts
   the real root device and executes init.
   Using initramfs and switch_root is way more straightforward than this.
   And
   doesn't have the magic behind the scenes stuff (like reparenting every
   running process whose ".", "..", or "/" points to the old root, yes
   including
   kernel threads).
   Just sayin'...
   Rob
   [81]Post by Luciano Miguel Ferreira Rocha
   Other option you could check out would be using initramfs instead of
   old
   1. name your script /init instead of /linuxrc;
   Or supply the kernel the "rdinit=/blah" argument to tell it what you
   called
   it.
   [82]Post by Luciano Miguel Ferreira Rocha
   2. call exec switch_root instead of pivot_root (and switch_root isn't
   supposed to return, it calls init by itself);
   Don't forget the "exec". Common mistake. If it's not PID 1, it'll
   abort.
   [83]Post by Luciano Miguel Ferreira Rocha
   find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img
   The kernel can do this for you, if you prefer. And even build it into
   the
   bzImage.
   [84]Post by Luciano Miguel Ferreira Rocha
   - Documentation/filesystems/ramfs-rootfs-initramfs.txt
   I wrote that one. If it's missing something, let me know.
   I also wrote a couple articles for TimeSys, earlier this year. It's a
   little
   long-winded, but might help:
   http://www.timesys.com/timesource/march_06.htm
   http://timesys.com/timesource/initramfs.htm
   Rob
   --
   "Perfection is reached, not when there is no longer anything to add,
   but
   when there is no longer anything to take away." - Antoine de
   Saint-Exupery
   Rob Landley
   2006-11-05 20:26:42 UTC
   [85]Permalink
   [86]Post by Luciano Miguel Ferreira Rocha
   find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img
   Now _that_ is an ugly set of command line options (for cpio). Let's
   see, that
   should equate to:
   cpio -0 -o -H newc
   I'm interested in this because I'm about halfway through writing
   toybox's
   get_optflags(), which doesn't use getopt() so I have to parse all this
   myself. It's not actually that hard, but the tricky case is where some
   of
   your arguments have no dash, ala ps or tar. Then you can wind up with
   stuff
   like:
   tar xjfCv filename.tbz dirname blah
   Which is equivalent to:
   tar -x -j -f filename.tbz -C dirname -v blah
   And _not_ equivalent to:
   tar -x -j -f C -v filename.tbz blah
   Which is what you get with the getopt() in uClibc 0.9.28. (I realize
   this is
   a funky corner case, but it's one that bit me and I want to get it
   _right_
   this time.)
   It looks like the nodash mode and the dash mode of the option parser
   have
   different sequencing requirements. Ok, I can do that...
   Rob
   --
   "Perfection is reached, not when there is no longer anything to add,
   but
   when there is no longer anything to take away." - Antoine de
   Saint-Exupery
   Luciano Miguel Ferreira Rocha
   2006-11-05 17:20:31 UTC
   [87]Permalink
   [88]Post by Moot Account
   Thanks! I'll try this when I get to the board (Soekris net4801)
   tomorrow.
   But I have another question. How is /sbin/init ( ->busybox ) accessed.
   exec /usr/sbin/chroot . /sbin/init <dev/console >dev/console 2>&1
   the usage of init is printed. This probably means that init is not run
   as PID 1. Also, when I use /linuxrc it seems to be stuck.
   Any ideas?
   Ah, yes. You can't do that using linuxrc. Linuxrc isn't run as init
   (pid
   isn't 1). You're supposed to set the real root device writing to a
   /proc
   file (/proc/sys/kernel/real-root-dev), exit, and the kernel then mounts
   the real root device and executes init.
   You can change that behaviour by booting your kernel with
   "init=/linuxrc
   root=/dev/ram0", and then the kernel runs linuxrc as init (IIRC).
   Other option you could check out would be using initramfs instead of
   old
   initrd:
   1. name your script /init instead of /linuxrc;
   2. call exec switch_root instead of pivot_root (and switch_root isn't
   supposed to return, it calls init by itself);
   3. create the new "initrd" as a new-format cpio file:
   find . -print0 | cpio -0oHnewc | gzip -9 > ../initrd.img
   More information about initramfs and initrd can be found in a kernel
   source tree:
   - Documentation/initrd.txt
   - Documentation/filesystems/ramfs-rootfs-initramfs.txt
   - Documentation/early-userspace/README
   --
   lfr
   0/0
   -------------- next part --------------
   A non-text attachment was scrubbed...
   Name: not available
   Type: application/pgp-signature
   Size: 189 bytes
   Desc: not available
   Url :
   http://lists.busybox.net/pipermail/busybox/attachments/20061105/32f2f1f
   3/attachment-0002.pgp
   Moot Account
   2006-11-05 17:09:43 UTC
   [89]Permalink
   Thanks! I'll try this when I get to the board (Soekris net4801)
   tomorrow.
   But I have another question. How is /sbin/init ( ->busybox ) accessed.
   When I use:
   exec /usr/sbin/chroot . /sbin/init <dev/console >dev/console 2>&1
   the usage of init is printed. This probably means that init is not run
   as PID 1. Also, when I use /linuxrc it seems to be stuck.
   Any ideas?
   Thanks again.
   -Lenmarc
   [90]Post by Luciano Miguel Ferreira Rocha
   [91]Post by Moot Account
   Hi,
   This is a bloated idea but it's just an exercise. The idea is to use
   the rootfs from buildroot as the initrd (i.e. initrd=/boot/rootfs.gz).
   This initrd should mount the _real_ rootfs using pivot_root. The real
   rootfs is in the second partition (/dev/hda2) and is the _same_ rootfs
   built from buildroot. In other words, rootfs.gz = rootfs in /dev/hda2.
   Inside the initrd (ie rootfs.gz) is /linuxrc which will be read first
   by the kernel after mounting the initrd. Instead of pointing it to
   /bin/busybox, I'm going to create a custom linuxrc.
   My _problem_ starts here. I CAN'T chroot to the rootfs in /dev/hda2
   and execute the /linuxrc, which is still pointed /bin/busybox. I need
   to chroot because /linuxrc will initialize my rootfs and put up the
   login (ie /etc/inittab getty).
   linux /boot/bzImage console=ttyS0,9600
   (since it's a serial console)
   #!/bin/sh
   echo "linuxrc execute"
   mount -t proc /proc /proc
   mkdir new_root
   mount -t ext2 /dev/hda2 /new_root
   umount proc
   cd /new_root
   pivot_root . initrd
   mount -t proc proc proc
   mount -t devfs devfs dev
   exec /usr/sbin/chroot . 'exec /linuxrc' \
   <dev/console >dev/console 2>&1
   I'm stuck after the execution pivot_root. It seems that dev/console is
   busy.
   And this stops linuxrc from continuing?
   ...
   cd /new_root
   exec < dev/console &> dev/console
   pivot_root . initrd
   ...
   Moot Account
   2006-11-05 16:30:01 UTC
   [92]Permalink
   Hi,
   This is a bloated idea but it's just an exercise. The idea is to use
   the rootfs from buildroot as the initrd (i.e. initrd=/boot/rootfs.gz).
   This initrd should mount the _real_ rootfs using pivot_root. The real
   rootfs is in the second partition (/dev/hda2) and is the _same_ rootfs
   built from buildroot. In other words, rootfs.gz = rootfs in /dev/hda2.
   Inside the initrd (ie rootfs.gz) is /linuxrc which will be read first
   by the kernel after mounting the initrd. Instead of pointing it to
   /bin/busybox, I'm going to create a custom linuxrc.
   My _problem_ starts here. I CAN'T chroot to the rootfs in /dev/hda2
   and execute the /linuxrc, which is still pointed /bin/busybox. I need
   to chroot because /linuxrc will initialize my rootfs and put up the
   login (ie /etc/inittab getty).
   Here are my arguments to the kernel:
   linux /boot/bzImage console=ttyS0,9600
   (since it's a serial console)
   This is the custom linuxrc that does _not_ work:
   #!/bin/sh
   echo "linuxrc execute"
   mount -t proc /proc /proc
   mkdir new_root
   mount -t ext2 /dev/hda2 /new_root
   umount proc
   cd /new_root
   pivot_root . initrd
   mount -t proc proc proc
   mount -t devfs devfs dev
   exec /usr/sbin/chroot . 'exec /linuxrc' \
   <dev/console >dev/console 2>&1
   I'm stuck after the execution pivot_root. It seems that dev/console is
   busy.
   Thanks for any help.
   Luciano Miguel Ferreira Rocha
   2006-11-05 16:52:52 UTC
   [93]Permalink
   [94]Post by Moot Account
   Hi,
   This is a bloated idea but it's just an exercise. The idea is to use
   the rootfs from buildroot as the initrd (i.e. initrd=/boot/rootfs.gz).
   This initrd should mount the _real_ rootfs using pivot_root. The real
   rootfs is in the second partition (/dev/hda2) and is the _same_ rootfs
   built from buildroot. In other words, rootfs.gz = rootfs in /dev/hda2.
   Inside the initrd (ie rootfs.gz) is /linuxrc which will be read first
   by the kernel after mounting the initrd. Instead of pointing it to
   /bin/busybox, I'm going to create a custom linuxrc.
   My _problem_ starts here. I CAN'T chroot to the rootfs in /dev/hda2
   and execute the /linuxrc, which is still pointed /bin/busybox. I need
   to chroot because /linuxrc will initialize my rootfs and put up the
   login (ie /etc/inittab getty).
   linux /boot/bzImage console=ttyS0,9600
   (since it's a serial console)
   #!/bin/sh
   echo "linuxrc execute"
   mount -t proc /proc /proc
   mkdir new_root
   mount -t ext2 /dev/hda2 /new_root
   umount proc
   cd /new_root
   pivot_root . initrd
   mount -t proc proc proc
   mount -t devfs devfs dev
   exec /usr/sbin/chroot . 'exec /linuxrc' \
   <dev/console >dev/console 2>&1
   I'm stuck after the execution pivot_root. It seems that dev/console is
   busy.
   And this stops linuxrc from continuing?
   Try:
   ...
   cd /new_root
   exec < dev/console &> dev/console
   pivot_root . initrd
   ...
   --
   lfr
   0/0
   -------------- next part --------------
   A non-text attachment was scrubbed...
   Name: not available
   Type: application/pgp-signature
   Size: 189 bytes
   Desc: not available
   Url :
   http://lists.busybox.net/pipermail/busybox/attachments/20061105/78ae3c9
   d/attachment-0002.pgp
   31 Replies
   147 Views
   [95]Permalink to this page
   [96]Disable enhanced parsing
   Thread Navigation
   Moot Account 2006-11-05 16:30:01 UTC
   Luciano Miguel Ferreira Rocha 2006-11-05 16:52:52 UTC
   Moot Account 2006-11-05 17:09:43 UTC
   Luciano Miguel Ferreira Rocha 2006-11-05 17:20:31 UTC
   Bernhard Fischer 2006-11-05 18:07:30 UTC
   Jason Schoon 2006-11-05 18:49:19 UTC
   Jason Schoon 2006-11-05 18:55:15 UTC
   Bernhard Fischer 2006-11-05 19:11:15 UTC
   Bernhard Fischer 2006-11-05 19:11:15 UTC
   Jason Schoon 2006-11-05 18:55:15 UTC
   Jason Schoon 2006-11-05 18:49:19 UTC
   Rob Landley 2006-11-05 20:19:40 UTC
   Luciano Miguel Ferreira Rocha 2006-11-05 23:34:31 UTC
   Rob Landley 2006-11-05 23:43:52 UTC
   Luciano Miguel Ferreira Rocha 2006-11-06 00:20:07 UTC
   Moot Account 2006-11-06 20:07:15 UTC
   Rob Landley 2006-11-07 21:48:09 UTC
   Rob Landley 2006-11-07 21:48:09 UTC
   Moot Account 2006-11-06 20:07:15 UTC
   Luciano Miguel Ferreira Rocha 2006-11-06 00:20:07 UTC
   Rob Landley 2006-11-05 23:43:52 UTC
   Luciano Miguel Ferreira Rocha 2006-11-05 23:34:31 UTC
   Rob Landley 2006-11-05 20:26:42 UTC
   Luciano Miguel Ferreira Rocha 2006-11-05 23:02:12 UTC
   Luciano Miguel Ferreira Rocha 2006-11-05 23:02:12 UTC
   Bernhard Fischer 2006-11-05 18:07:30 UTC
   Rob Landley 2006-11-05 20:19:40 UTC
   Rob Landley 2006-11-05 20:26:42 UTC
   Luciano Miguel Ferreira Rocha 2006-11-05 17:20:31 UTC
   Moot Account 2006-11-05 17:09:43 UTC
   Moot Account 2006-11-05 16:30:01 UTC
   Luciano Miguel Ferreira Rocha 2006-11-05 16:52:52 UTC

   [97]about - [98]legalese

   Loading...

References

   Visible links:
   1. https://busybox.busybox.narkive.com/
   2. https://narkive.com/PBeyeZOM.1
   3. https://narkive.com/PBeyeZOM.2
   4. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post1
   5. https://narkive.com/PBeyeZOM.3
   6. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post2
   7. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post1
   8. https://narkive.com/PBeyeZOM.4
   9. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post3
  10. https://narkive.com/PBeyeZOM.5
  11. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  12. https://narkive.com/PBeyeZOM.6
  13. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  14. https://narkive.com/PBeyeZOM.7
  15. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post6
  16. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  17. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  18. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  19. https://narkive.com/PBeyeZOM.8
  20. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post7
  21. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post5
  22. https://narkive.com/PBeyeZOM.24
  23. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post7
  24. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post5
  25. https://narkive.com/PBeyeZOM.23
  26. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post6
  27. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  28. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  29. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  30. https://narkive.com/PBeyeZOM.22
  31. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post5
  32. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  33. https://narkive.com/PBeyeZOM.9
  34. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  35. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  36. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  37. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  38. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  39. https://narkive.com/PBeyeZOM.12
  40. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post9
  41. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  42. https://narkive.com/PBeyeZOM.13
  43. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12
  44. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post9
  45. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  46. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12
  47. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12
  48. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12
  49. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12
  50. https://narkive.com/PBeyeZOM.14
  51. https://narkive.com/PBeyeZOM.15
  52. https://narkive.com/PBeyeZOM.16
  53. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post15
  54. https://narkive.com/PBeyeZOM.32
  55. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post15
  56. https://narkive.com/PBeyeZOM.31
  57. https://narkive.com/PBeyeZOM.30
  58. https://narkive.com/PBeyeZOM.29
  59. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12
  60. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post9
  61. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  62. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12
  63. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12
  64. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12
  65. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12
  66. https://narkive.com/PBeyeZOM.28
  67. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post9
  68. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  69. https://narkive.com/PBeyeZOM.10
  70. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  71. https://narkive.com/PBeyeZOM.11
  72. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post10
  73. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  74. https://narkive.com/PBeyeZOM.27
  75. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post10
  76. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  77. https://narkive.com/PBeyeZOM.21
  78. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  79. https://narkive.com/PBeyeZOM.25
  80. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  81. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  82. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  83. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  84. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  85. https://narkive.com/PBeyeZOM.26
  86. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
  87. https://narkive.com/PBeyeZOM.20
  88. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post3
  89. https://narkive.com/PBeyeZOM.19
  90. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post2
  91. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post1
  92. https://narkive.com/PBeyeZOM.17
  93. https://narkive.com/PBeyeZOM.18
  94. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post1
  95. https://narkive.com/PBeyeZOM
  96. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using?parse=disable
  97. https://narkive.com/about
  98. https://narkive.com/legalese

   Hidden links:
 100. https://narkive.com/
 101. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post1
 102. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post2
 103. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post3
 104. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post4
 105. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post5
 106. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post6
 107. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post7
 108. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post8
 109. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post24
 110. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post23
 111. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post22
 112. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post9
 113. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post12
 114. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post13
 115. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post14
 116. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post15
 117. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post16
 118. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post32
 119. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post31
 120. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post30
 121. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post29
 122. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post28
 123. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post10
 124. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post11
 125. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post27
 126. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post21
 127. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post25
 128. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post26
 129. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post20
 130. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post19
 131. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post17
 132. https://busybox.busybox.narkive.com/PBeyeZOM/custom-initrd-using#post18