Announcement

Collapse
No announcement yet.

/dev/ram / kernel experts--question

Collapse
This topic is closed.
X
X
Collapse
 
  • Page of 2
  • Filter
  • Time
  • Show
Clear All
new posts
Previous 1 2 template Next
    #1

    /dev/ram / kernel experts--question

    In building a live persistent Kubuntu flash drive, one method calls for this boot stanza entry:

    title Kubuntu 8.10 LIVE Persistent
    root (hd0,0)
    kernel /casper/vmlinuz boot=casper ramdisk_size=1048576 root=/dev/ram rw quiet splash persistent
    initrd /casper/initrd.gz

    If you google, you'll find that the above kernel statement is widely used in all sorts of live USB applications.

    My main question is about the root = /dev/ram. Obviously, /dev/ram does not correspond to the standard 16 ram*'s under the normal OS /dev nodes. And, I'm guessing that in this use of it, /dev/ram is not meant to correspond to anything in a normal hard disk installed Kubuntu OS, that the designation /dev is only conventional.
    But, anyway, how does this work? Do the newer kernels recognize this generic designation /dev/ram in the kernel (option) statement as something special to be setup in RAM and set it up thusly (with max size specified by ramdisk_size), into which is then loaded the kernel & OS?


    Incidental Q: I assume that the ramdisk_size set to 1 GB here is simply an upper limit within which the kernel and OS are loaded to run for the live session. Not sure why 1048576 was picked (= * 1024 = 1GB), but it is also a popular number popping up in every google but not explained anywhere that I can find.


    Anyone able to explain this in general, layman, conversational terms?

    And/or, have a link that's readable (I've spent 3 hours googling, and came close, but fell shy of an answer to either of the above.)


    An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski
    Tags: None
    • Top
    • Bottom
    #2
    Re: /dev/ram / kernel experts--question

    "Not sure why 1048576 was picked (= * 1024 = 1GB)..." (etc.)

    and btw I do realize the min for live Kubutnu CD is something like 350 MB RAM, so maybe the 1 GB is just a safe upper limit of max possible?
    An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski
    • Top
    • Bottom

    Comment

      #3
      Re: /dev/ram / kernel experts--question

      The sidux manual provides an example that uses a 1G loop file size for persistence:

      http://manual.sidux.com/en/hd-instal...en.htm#fromiso

      But it doesn't say that is a required size or a limit. I dunno -- I was also looking around for some limitation on this, and I can't find one. Perhaps the improvement in media sizes has outstripped the publication of specs and instructions.

      As I mentioned yesterday I managed, more by bravado than intelligence, to make a 7+G persistence area on my 8G USB stick, when I set up Elive on it. Of course, it may break at any time -- I wouldn't claim it is fully functional unless I can safely fill it up with files, and then delete them back off. Heyyyyyyy, now there's a fun idea ......

      • Top
      • Bottom

      Comment

        #4
        Re: /dev/ram / kernel experts--question

        The kernel statement:
        kernel /casper/vmlinuz boot=casper ramdisk_size=1048576 root=/dev/ram rw quiet splash persistent

        @dibl: now, that has nothing to do with persistent partition size, right? (just the persistent on-off switch at the end);
        the ramdisk is where the kernel is loaded to run, correct? "root=" tells the OS where to play; different from the GRUB root device (in general, possibly);
        An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski
        • Top
        • Bottom

        Comment

          #5
          Re: /dev/ram / kernel experts--question

          The only thing I noticed is that the boot stanza is for a read only medium (hence casper).

          And
          ramdisk = ram behaves like a disk (although I am sure you knew that anyway)
          1048576 = 256 * 4096 (ditto)
          Once your problem is solved please mark the topic of the first post as SOLVED so others know and can benefit from your experience! / FAQ
          • Top
          • Bottom

          Comment

            #6
            Re: /dev/ram / kernel experts--question

            Originally posted by Qqmike

            @dibl: now, that has nothing to do with persistent partition size, right? (just the persistent on-off switch at the end);
            the ramdisk is where the kernel is loaded to run, correct? "root=" tells the OS where to play; different from the GRUB root device (in general, possibly);
            Yep, in my rush to put the thing together, I mis-apprehended the purpose of that boot option. It's a memory reservation -- doesn't relate to the size of the casper-rw partition. All the more amazing that it works anyway, the way I did it!
            • Top
            • Bottom

            Comment

              #7
              Re: /dev/ram / kernel experts--question

              @dibl, I think it works because the ramdisk_size specifies an upper limit, a reserve, a max, which is dynamically allocated.

              @toad,
              The ramdisk must be rw for writes/reads, and maybe for some of the casper stuff--buffering I don't know.

              @toad: "1048576 = 256 * 4096 (ditto)"
              Yes => 256 blocks of the basic minimum ram size of 4096.
              Also, of course, and obviously, 1048576 = 2**20;
              and the unit size is 2**10 = 1024.
              So 1048576 means that many units => 1048576*1024 = 1 GB = ramdisk_size

              The part that has me foxed is this generic option:
              root=/dev/ram
              as opposed to one of the standard sixteen ramn, n =0, ..., 15.

              Apparently, the kernel (since it IS a kernel boot option) must be programmed to recognize the string "ram" as a trigger to create a ramdisk for the live session (in RAM).
              Nothing at all to do with ramn. In the live session, one can still see the sixteen ramdisks /dev/ramn. I just have not found a guide ("Complete Kernel Option List") that mentions the magic statement root=/dev/ram. Interesting how Linux works: EVERYONE in every google is using that kernel statement! --
              kernel /casper/vmlinuz boot=casper ramdisk_size=1048576 root=/dev/ram rw quiet splash persistent
              ... and yet, I can't find the original source!

              It's them danged penguins messing around again ...

              An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski
              • Top
              • Bottom

              Comment

                #8
                Re: /dev/ram / kernel experts--question

                root=/dev/ram afaik is for the initram only! Once the kernel has gone through that, the real system is mounted. This would make sense since the stanza is for a read only media (i.e. knicked from a live CD)
                Once your problem is solved please mark the topic of the first post as SOLVED so others know and can benefit from your experience! / FAQ
                • Top
                • Bottom

                Comment

                  #9
                  Re: /dev/ram / kernel experts--question

                  Okay, found a link:

                  http://penguinppc.org/embedded/howto...ilesystem.html

                  under 13.2
                  Once your problem is solved please mark the topic of the first post as SOLVED so others know and can benefit from your experience! / FAQ
                  • Top
                  • Bottom

                  Comment

                    #10
                    Re: /dev/ram / kernel experts--question

                    @toad, Thanks. (any comments on the below would be appreciated, too...)

                    howtogeek also has similar (on a kernel build).
                    Yeah, I get it, as much as one can without actually doing some hands-on kernel/initrd work (which, at my age/stage is not an option ).
                    >> Anyone else wanting to get an overview (in words) of the kernel-boot-initrd process, put these two together for a pretty good start:
                    End-User Implementation section of this article:
                    http://en.wikipedia.org/wiki/Initrd
                    and, maybe this article:
                    http://linux.die.net/man/7/boot
                    boot(7) - Linux man page


                    BUT, I do still have some details caught up ...

                    In particular (Wikipedia article):
                    If the image is a (optionally gzip-compressed) file system image, then it will be made available as a special block device (/dev/ram), which is then mounted as the initial root file system ... [and later on] read only...”

                    So that does sort of settle the /dev/ram block device issue. It looks like the /dev/ram is setup and set aside not only for the initrd but also as the final location for the (final) root LIVE Kubuntu filesystem to run in. ( - ? - ) -- in our application here with the live flash drive.

                    Then for the rw boot option in that kernel statement: The 'rw' option tells the kernel to mount the root filesystem read/write. That appears in every Live USB how-to I've seen. (Usually, as you know, ro is used so filesystem checks can be made on a quiet system, but maybe for the live persistent stuff, the rw is needed?)

                    And, finally, this business: ramdisk_size=1048576t.
                    Are you reading this as applying to the (final) set-aside area of RAM where the Live Kubuntu OS is to run? That's how I see it. You sure don't need that much room for initrd, initial ramdisk (at boot)..



                    *****************EDIT added****************
                    The older, original references seem to refer to root=/dev/ram0.
                    http://lxr.linux.no/linux/Documentation/initrd.txt
                    (and a good boot ref, too, btw:
                    361[1] Almesberger, Werner; "Booting Linux: The History and the Future"
                    362 http://www.almesberger.net/cv/papers/ols2k-9.ps.gz
                    An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski
                    • Top
                    • Bottom

                    Comment

                      #11
                      Re: /dev/ram / kernel experts--question

                      It looks like the /dev/ram is setup and set aside not only for the initrd but also as the final location for the (final) root LIVE Kubuntu filesystem to run in.
                      Wow, you got me searching now 'cos the above cannot be true. And here is what an extract of a wikipedia article says:

                      * If the image is a (optionally gzip-compressed) file system image, then it will be made available as a special block device (/dev/ram), which is then mounted as the initial root file system. The driver for that file system must be compiled statically into the kernel. Many distributions originally used compressed ext2 file systems as initrd images. Others (including Debian 3.1) used cramfs in order to boot on memory-limited systems, since the cramfs image can be mounted in-place without requiring extra space for decompression.

                      Once the initial root file system is up, the kernel executes "/linuxrc" (linux run command) as its first process. When it exits, the kernel assumes that "/linuxrc" has mounted the real root file system and executes "/sbin/init" to begin the normal user-space boot process.
                      Taken from here (incidentally the site you provided the link for just now ). The second para is of import. Now I know that canonical has messed around with the start up process quite a lot, run levels having been scrapped and what not. But I do not believe the above has been affected.

                      As for the rw statement - yeah, first they use the read only casper mode and then they've got to work around it, so your assumption makes sense to me.

                      Re ramdisk_size - this surely relates to /dev/ram and is scrapped/freed once linuxrc (or Ubuntu equivalent) is run.
                      Once your problem is solved please mark the topic of the first post as SOLVED so others know and can benefit from your experience! / FAQ
                      • Top
                      • Bottom

                      Comment

                        #12
                        Re: /dev/ram / kernel experts--question

                        so ...

                        But we also know that the live CD Kubuntu (or USB) runs only in RAM. So that RAM-show must not be visible/controllable to the user; that is, the live CD files must require something like a ram disk to run in RAM, but that's taken care of behind the scenes somehow.
                        An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski
                        • Top
                        • Bottom

                        Comment

                          #13
                          Re: /dev/ram / kernel experts--question

                          here's another way to look at this "questioning" of mine;
                          this kernel line in the Live USB:
                          kernel /casper/vmlinuz boot=casper ramdisk_size=1048576 root=/dev/ram rw quiet splash persistent

                          you sure don't see anything like that in a regular hard disk installed Kubuntu.
                          An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski
                          • Top
                          • Bottom

                          Comment

                            #14
                            Re: /dev/ram / kernel experts--question

                            I think I may get your point. But instead of waxing on about something I don't know enough about how about trying a much smaller ramdisk_size during boot? That way the system should get significantly slower if the ramdisk is not scrapped/freed but is used to run the system in. And if it does not get slower then the ramdisk is only for the init process.

                            You agree with the procedure and assumptions?

                            Fancy giving it a whirl ?
                            Once your problem is solved please mark the topic of the first post as SOLVED so others know and can benefit from your experience! / FAQ
                            • Top
                            • Bottom

                            Comment

                              #15
                              Re: /dev/ram / kernel experts--question

                              Yeah, I'll give that a go--experiment with it.
                              But first I have to rebuild that flash drive (that way, manually) -- I overwrite it with the usb-creator experiment! I just ordered and rec'd 4 new flash drives from Amazon (3x4GB and one 8 GB), so now there's more available for playing around

                              An intellectual says a simple thing in a hard way. An artist says a hard thing in a simple way. Charles Bukowski
                              • Top
                              • Bottom

                              Comment

                              Previous 1 2 template Next
                              Working...
                              X