Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I really think that the approach "compress everything, unpack at boot" vs "use the flash as if it were a disk" depends on the problem we are trying to solve.
For an embedded system, that performs only one task, the "uncompress to RAM" approach is great, because you can never cause filesystem corruption. Every time you turn on the device, the same data gets loaded into RAM, and it's like you said "newborn"
If you are trying to run some standard application, in a "workstation like" environment, where applications expect that changes to /etc will be kept, files written to ~/.something will be there the next time, etc., you probably want to use the flash as a standard disk.
There are options in between, as you mentioned. For instance, I developed a small distro (10Mb total space occupied) that as two squashfs files mounted loopback onto /bin and /usr/lib, so that all binaries are compressed.
SquashFS compresses much better than cramfs. The only problem is that it is still not in the official kernel, so you have to patch the kernel to get it working.
You can even have the root filesystem read-only from a cramfs (or squashfs) partition and then mount another partition with a standard filesystem (ext3, etc.), and use the mount --bind to have /home, /etc, mapped onto directories inside that partition (so that they share the total available space)
There are a million options. That is what makes Linux great
Do any of you see anything different being needed if you wanted to do the same thing off of a 128 MB USB Thumbdrive? My motherboard will support Thumbdrive booting but I was always trying to make the Thumbdrive a Linux Boot Disk with Syslinux and have the actual drives as additional partitions on the M$ drives. RH9 said it would work but didn't. I always figured it was because the kernel needed USB support built it.
I am running a linux distro from CF. One of the problems I ran into was making the cf bootable. With the CF inside a PCMCIA-CF or a USB - CF adapter neither lilo or grub would install since those don't show up in the systems BIOS as ide drives. My solution was to use an IDE-CF adapter, plug into a MB with a cd-rom on the other ide channel and boot off a slackware cd and install like normal (I had a 128M cf, 16M will be a bit more difficult as you have to leave more out). Next step was to edit the script in the /etc folder and comment out the line where the root partition is remounted as read/write. Then create a ram drive and some scripts to touch some files there and then symlink varios files to those in the ram drive. I have a pretty complete non-gui slack system booting un under 30 seconds from power on with mpg123 working.
A long time ago I tried to do this, but ran into a small problem.
The BIOS loaded LILO, that load the kernel, but the kernel didn't detect the USB drive in time to mount it as the root filesystem. (and complained there was no root device just before the message from the usb core detected the drive)
The solution would be to create a small initrd (maybe using nash) that waits a little until the pen appears and then switch the root filesystem to the pen.
I didn't gave it another try, but I'm pretty sure it would work, it was just not on my extensive todo list
This configuration assumes that the adapter appear as /dev/sda, and the boot partition is already mounted on /mnt/disk, and that on the target system the CF card will appear as the IDE primary master.
Notice the "bios=0x80" line. This tells LILO that, although he can't figure out now where the BIOS thinks the device is, if he tells the BIOS later to load from device 0x80 it will work.
To install a standard distro, if you have enough space on a CF card, the easiest way IMHO would be to use a IDE<->CF adapter and install as usual.
However, if you don't have enough space, you can always try to install to a standard IDE drive, then use that drive as a slave on some other machine, delete what you don't want, compress what you can, and then copy the result onto the flash (maybe tar/untar the result is saffer) and run lilo to make it bootable.
LILO defaults to "/etc/lilo.conf" if no option is provided. However you can have a lot more configuration files to install the bootloader in different setups (I have about 5 files hanging around in my disk).
The man page for LILO describes this much better. I know it is a little extensive, but if you're playing with setting drives for booting somewhere else, it is worth reading
IIRC I think I tried that. I seem to remember trying to point it to /mnt/cf/etc/lilo so maybe with the proper config it would have worked. I got it bootable then plug it back in my laptop and edit/change things from there.
Originally posted by mafiltenborg To get better endurance, one might do a complete copy-to-ramdisk of the entire root-filesystem
Yes, most floppy based mini-Linuxes work this way. I guess it all depends on if you have RAM to spare.
which as far as i can see, can be stored in a compressed state on flash.
This way, flash-size can be significantly reduced (rootfs now stored in a compressed state), leaving room to buy more RAM and thus maintain unit cost.
Yes, but you can also compress root file systems that are only to be mounted "read only" by using things like "cloop" like Lnx-bbc, Knoppix-Linux, and the many distos based on Knoppix does.
Only penalty i can see, is the added time required to unpack the rootfilesystem into RAM.
This usually isn't too bad depending on the power of the processor you are using. Most of these compression schemes are such that they are time consuming to compress but fast to uncompress.
Or am i all wrong when i have this view of things:
Compressed kernel stored at the beginning of CF-memory, unpacking itself (at boottime) to RAM, followed by
Kernel-driven unpacking of compressed rootfilesystem - also into RAM.
No, people do this kind of thing all the time. Learn about "initrd" and Linux ramdisks.
This way, running OS & software may write all they wish, doing no harm to the flash since writing is done to the ramdisk-based rootfilesystem.
Indirect benefit: Everytime the device is powered on, it has no memory of the past. It's like newborn
But the same is true if you mount the root file system Read-only.
Should any NV logging be needed, one may mount part of the flash as a disk and do logging onto that.
And wear out that part of the disk ...
Actually what you might to is have a special "diagnostic" or "debug" mode where you turn logging on only when you are trying to track down a problem.
It is geared towards making a customized boot CD with no frills, and it makes the / file system from a compressed image. If you don't need much, you can bring the whole thing down to < 16MB (the pre-made cd image that's on that page has 13MB).
There's a script that does it all for you if you do a CD; if you have the recipe to make the same for a stick you'll see how to do it.
(I haven't been able to do it because I have no machine that's capable of booting from a stick - if you get it done please let us know how it went).