[Leaf-devel] I'll be away for a week...
I'll be away for a week till January 5th and probably won't have access to my mail during that period. Happy New Year to you all folks ! Jacques ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] initrd confusion
David Douthitt wrote: David, I found this url from the 2.4 initrd.txt quite interesting. You may find it interesting to at least skim through it: [1] Almesberger, Werner; "Booting Linux: The History and the Future" ftp://icaftp.epfl.ch/pub/people/almesber/booting/bootinglinux-current.ps.gz >On 12/28/01 at 10:20 AM, Ewald Wasscher <[EMAIL PROTECTED]> >wrote: > >>David Douthitt wrote: >> > >>>This was the BIG trip up; ROOT= must NOT be /dev/ram or >>>/dev/ram0, but anything else. initrd.txt never says >>>this... in fact, initrd.txt never considers the fact that >>>it might be used for a floppy-based Linux... >>> > >>At least for 2.4 kernels this isn't completely correct. I >>put together a small-as-possible bootloader package and it >>runs with root=/dev/ram0. But, I do specify init=/linuxrc, >>just like Jacques. >> > >>From what I've been reading, what you and Jacques have done is >"cheating" :) > Maybe with respect to running init you are right, though I would call it "making use of new features of the linix kernel".. > >Here is the two methods compared: > >EWALD/JACQUES > >1. initrd.gz is loaded into /dev/ram0 (ROOT=/dev/ram0) >2. The kernel recognizes root is /dev/ram0, and does NOT run /linuxrc >3. The kernel then releases memory and exits the load process >4. The kernel runs init (INIT=/linuxrc) >5. Your linuxrc performs a pivot_root (if necessary) and runs init by >hand. > Agreed. IMHO the advantage of this approach is that it probably will be a bit more future-proof, according to initrd.txt and [1]. The obvious disadvantage is that it doesn't work with 2.2 kernels. > >OXYGEN > >1. initrd.gz is loaded into /dev/ram0 (ROOT=/dev/ram1) >2. The kernel recognizes that root is NOT /dev/ram0, and then DOES run >/linuxrc >3. The kernel then releases memory, performs a pivot_root, and runs >/bin/init > At least 3. is an older mechanism that may be removed in future releases as initrd.txt states. A disadvantage of this approach is that it doesn't work with tmpfs and nfs-root (the latter isn't much of a problem for us). The advantage is that it works with both 2.2 and 2.4 kernels (for the near future at least) > >No unusual kernel parameters required. > >I might suggest too, something that had occured to me: what about an >entry in the inittab that runs /linuxrc? > I agree with Charles here. > >But I digress: I think my way is the most standard way; what do you >all think? > I think that your way is the standard (and only) way with 2.2 kernels. It still works with 2.4 kernels, but may not do so with future releases of 2.4 and later kernels. From the little I have read about initramfs etc.I understand that more of the late booting process (like finding and mounting the root filesystem) will be moved to user space in the future. Considering this it makes sense to do things like pivot_rooting and finding and mounting the root filesystem yourself instead of relying on the kernel to do this. Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: [Leaf-user] Kernel Version
On 12/28/01 at 5:41 PM, Jan Linders <[EMAIL PROTECTED]> wrote: > Is there a way to find out which kernel version I'm running > on my LRP Router ? Try one of these: # uname -r # cat /proc/sys/kernel/osrelease # sysctl kernel.osrelease ...the '#' is your shell prompt; don't type it... -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Re: Question on Oxygen 1.8.0 boot CD
On 12/28/01 at 9:39 AM, Angelacos, Nathan <[EMAIL PROTECTED]> wrote: > I've noticed that the cdrom.cfg, smallnet.cfg, etc. > configuration files on the bootable cd are not in the root > directory of the cdboot.ima image on the CD. > > Instead, they are inside the root.lrp, in > /var/boot/config. > > This is different from the standard floppy boot images, > where the .cfg files are on the root of the boot floppy. > > Is there some specific reason that it has to be this way? Yes. > Is it possible to create .cfg in the root of cdboot.ima > and have them read? No. The disk image is read via BIOS INT13, and the Linux kernel has no support for this. Linux cannot read from this image in anyway; it is syslinux which has read in root.lrp et al, and syslinux supports reading this boot image. This setup also means you can boot from a device that Linux does not support - which could be useful in booting from a hard disk with tight security, for example. -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] initrd confusion
> Here is the two methods compared: > > EWALD/JACQUES > > 1. initrd.gz is loaded into /dev/ram0 (ROOT=/dev/ram0) > 2. The kernel recognizes root is /dev/ram0, and does NOT run /linuxrc > 3. The kernel then releases memory and exits the load process > 4. The kernel runs init (INIT=/linuxrc) > 5. Your linuxrc performs a pivot_root (if necessary) and runs init by > hand. I would generally frown on this...you want the kernel to run linuxrc normally, then mount the real-root-device and run init when linuxrc is finished. > OXYGEN > > 1. initrd.gz is loaded into /dev/ram0 (ROOT=/dev/ram1) > 2. The kernel recognizes that root is NOT /dev/ram0, and then DOES run > /linuxrc > 3. The kernel then releases memory, performs a pivot_root, and runs > /bin/init > > No unusual kernel parameters required. This is the right way to do it, except the 2.5 step of linuxrc building a root filesystem on /dev/ram1 was omitted. > I might suggest too, something that had occured to me: what about an > entry in the inittab that runs /linuxrc? Um...bad idea IMHO. The whole point of using the initrd functionality is to get a tiny environment that can create the root OS, which will then be mounted & run by the kernel. If you do linuxrc things with init, you have to have the root filesystem built beforehand (ie larger initial ramdisk), and if you want to build a different root filesystem, you've got the whole pivot_root problem to deal with again. Just use the initrd stuff the way it's intended and let the kernel deal with mounting the newly created root filesystem and running init like normal... > But I digress: I think my way is the most standard way; what do you > all think? No need to explain the need for INIT=/linuxrc, etc. You've got my vote. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] initrd confusion
> >This was the BIG trip up; ROOT= must NOT be /dev/ram or /dev/ram0, but > >anything else. initrd.txt never says this... in fact, initrd.txt > >never considers the fact that it might be used for a floppy-based > >Linux... > > > At least for 2.4 kernels this isn't completely correct. I put together a > small-as-possible bootloader package and it runs with root=/dev/ram0. > But, I do specify init=/linuxrc, just like Jacques. In this case, linuxrc is NOT running as it would for a 'normal' ramdisk environment, but is instead replacing the init process. This means linuxrc is responsible for mounting the real root device as root, and running init when it finishes (init...or linuxrc in this case...should NEVER exit). Most of this is done automatically by the kernel if you use the initrd functionality the way it was intended. Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
[Leaf-devel] Question on Oxygen 1.8.0 boot CD
Dave, I've noticed that the cdrom.cfg, smallnet.cfg, etc. configuration files on the bootable cd are not in the root directory of the cdboot.ima image on the CD. Instead, they are inside the root.lrp, in /var/boot/config. This is different from the standard floppy boot images, where the .cfg files are on the root of the boot floppy. Is there some specific reason that it has to be this way? Is it possible to create .cfg in the root of cdboot.ima and have them read? Thanks in advance. ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] initrd confusion
On 12/28/01 at 10:20 AM, Ewald Wasscher <[EMAIL PROTECTED]> wrote: > David Douthitt wrote: > >This was the BIG trip up; ROOT= must NOT be /dev/ram or > >/dev/ram0, but anything else. initrd.txt never says > >this... in fact, initrd.txt never considers the fact that > >it might be used for a floppy-based Linux... > At least for 2.4 kernels this isn't completely correct. I > put together a small-as-possible bootloader package and it > runs with root=/dev/ram0. But, I do specify init=/linuxrc, > just like Jacques. >From what I've been reading, what you and Jacques have done is "cheating" :) Here is the two methods compared: EWALD/JACQUES 1. initrd.gz is loaded into /dev/ram0 (ROOT=/dev/ram0) 2. The kernel recognizes root is /dev/ram0, and does NOT run /linuxrc 3. The kernel then releases memory and exits the load process 4. The kernel runs init (INIT=/linuxrc) 5. Your linuxrc performs a pivot_root (if necessary) and runs init by hand. OXYGEN 1. initrd.gz is loaded into /dev/ram0 (ROOT=/dev/ram1) 2. The kernel recognizes that root is NOT /dev/ram0, and then DOES run /linuxrc 3. The kernel then releases memory, performs a pivot_root, and runs /bin/init No unusual kernel parameters required. I might suggest too, something that had occured to me: what about an entry in the inittab that runs /linuxrc? But I digress: I think my way is the most standard way; what do you all think? No need to explain the need for INIT=/linuxrc, etc. -- David Douthitt UNIX Systems Administrator HP-UX, Unixware, Linux [EMAIL PROTECTED] ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] initrd confusion
David Douthitt wrote: >I figured some things out... SOME > >I modified the kernel to answer the questions for me :) > >So now I have Oxygen booting with a standard Linux kernel - very nice. >Too bad that the initrd_archive patch seems to be going away... > But maybe we will have the initramfs someone posted about a while to replace that :-) > >This was the BIG trip up; ROOT= must NOT be /dev/ram or /dev/ram0, but >anything else. initrd.txt never says this... in fact, initrd.txt >never considers the fact that it might be used for a floppy-based >Linux... > At least for 2.4 kernels this isn't completely correct. I put together a small-as-possible bootloader package and it runs with root=/dev/ram0. But, I do specify init=/linuxrc, just like Jacques. > >>2. How does all of this interact with the kernel value returned by >>rdev? >> > Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
Re: [Leaf-devel] initrd confusion
David Douthitt wrote: > >4. Does it matter whether a zImage or bzImage is made? I thought not >- but then initrd.txt implies that it matters, as there is a >"bzImage+initrd" p >atch alluded to... > Usually I just make bzImage, and have never run into any problems. > >5. What is the status of /dev/initrd? Do we need it? What is it for? >initrd.txt says it can be useful; devices.txt says that it will be >obsoleted as of 2.6. > I don't think we will need it. If I understand Documentation/initrd.txt correctly, it can only be used when the initrd is loaded, but _not_ mounted as the initial root fs I don't understand when it might be useful. > >One interesting thing I never thought of - but which was suggested by >initrd: use init=/bin/sh or link /linuxrc to /bin/sh both VERY >interesting ideas... > Ewald Wasscher ___ Leaf-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-devel
