diff options
Diffstat (limited to 'docs/busybox.busybox.narkive.com_PBeyeZOM_custom-initrd-using.txt')
| -rw-r--r-- | docs/busybox.busybox.narkive.com_PBeyeZOM_custom-initrd-using.txt | 1168 |
1 files changed, 1168 insertions, 0 deletions
diff --git a/docs/busybox.busybox.narkive.com_PBeyeZOM_custom-initrd-using.txt b/docs/busybox.busybox.narkive.com_PBeyeZOM_custom-initrd-using.txt new file mode 100644 index 0000000..b9085a5 --- /dev/null +++ b/docs/busybox.busybox.narkive.com_PBeyeZOM_custom-initrd-using.txt @@ -0,0 +1,1168 @@ + [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 |