[Buildroot] Squashfs boot

[Buildroot] Squashfs boot

[Stephen Turner]

Sorry if my previous email went through. Im having some difficulty booting
a squashfs with grub4dos on usb and grub2 from hd. In short im using
bzImage for a kernel and trying to both boot the squashfs in ram and imaged
to a usb drive. I havent found much info on how to use the squashfs from
busybox and what i did find wasnt very helpful. Could someone point me to a
how to for booting a busybox squash? Do i need to make my own initrd Image
or edit some files such as fstab?
I appreciate any and all input.

Thanks
Stephen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130121/4a2c1262/attachment-0001.html>

[Buildroot] Squashfs boot

[Stefan Fröberg]

Hi Stephen
22.1.2013 3:25, Stephen Turner kirjoitti:
>
> Sorry if my previous email went through. Im having some difficulty
> booting a squashfs with grub4dos on usb and grub2 from hd. In short im
> using bzImage for a kernel and trying to both boot the squashfs in ram
> and imaged to a usb drive. I havent found much info on how to use the
> squashfs from busybox and what i did find wasnt very helpful. Could
> someone point me to a how to for booting a busybox squash? Do i need
> to make my own initrd Image or edit some files such as fstab?
> I appreciate any and all input.
>
> Thanks
> Stephen
>
>

What I usually have is squashfs (xz-compressed) image of the whole /usr
(because that's usually the largest).

And everything else is in xz-compressed initramfs. Kernel extract and
loads the initramfs file(s) that you have
specified in grub to  automatically to ram. squashfs image does not need
to loaded to ram but mounted to
loopback devise /dev/loop0. However, when files are accessed in that
image it's contents can be also cached to ram.

The basic idea is that everything that is absolutely needed for booting
and running, the very minimal core of the
system, is located in that initramfs.

Now, in the /etc/inittab file there is usually a line like
null::sysinit:/bin/mount -a

That will instruct that all stuff in /etc/fstab should be mounted.

My /etc/fstab look like this
# /etc/fstab: static file system information.
#
# <file system>         <mount pt>    <type>        <options>       
<dump>     <pass>
/modules.sqfs        /lib/modules    squashfs   
defaults,auto,loop,noatime    0    0
/firmware.sqfs      /lib/firmware    squashfs   
defaults,auto,loop,noatime    0    0
/dev/cdrom            /mnt/cdrom    iso9660        defaults,noatime   
0    0
/mnt/cdrom/usr.sqfs        /mnt/ro        squashfs   
defaults,auto,loop,noatime    0    0
proc                /proc               proc         defaults         
0    0
devpts                /dev/pts           devpts      
defaults,gid=5,mode=620    0    0
tmpfs                   /dev/shm           tmpfs       mode=0777        
    0          0
tmpfs                   /tmp               tmpfs       
defaults              0          0
sysfs                /sys               sysfs        defaults         
0    0

What that does, is:

1 ) mount ./modules.sqfs (xz-compressed squashfs containing kernel
modules) to /lib/modules
2 ) mount ./firmware.sqfs (xz-compressed squashfs containing firmware
stuff) to /lib/firmware
3 ) mount Live-CD (the system itself that is running) to /mnt/cdrom. The
reason for this is
that storing usr.sqfs (xz-compressed squasfhs containing /usr) to
initramfs is waste of memory
while it can be stored into the root (outside of initramfs) of live-cd.
Just like I have done with kernel.
4 ) Mount /mnt/cdrom/usr.sqfs to /mnt/ro.
The reason for this is that later, in  /etc/init.d/rcS
im going to use unionfs to compine read-writeable /mnt/rw (just empty
directory without nothing mounted in)
 and read-only /mnt/ro (the xz-compressed squashfs image from Live-CD
root that just got mounted) to compined
read-write directory in /usr

It's all little compilacted but space and memory saving and stuff can be
written to /usr if need to (for example Xorg
needs at least one location inside/usr to be writable for fonts if I
remember correctly)

If you don't need writable /usr then you can just mount your
usr-squashfs directly to /usr.
If you don't need /usr at all but just want to squashfs your /  then
maybe it's doable but you still have to mount
few places as read-write for tmp files and other stuff.

Like:
mount -t tmpfs tmpfs /tmp

And maybe
mount -t tmpfs tmpfs /var/log

Ofcourse those can be also added to /etc/fstab

What exatcly you have inside that squashfs ? Just busybox and nothing else ?
In that case it's really not worth all the squashfs setup.

Regards
Stefan




>
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130122/4b5e14f3/attachment.html>

[Buildroot] Squashfs boot

[Stefan Fröberg]

It's true that you can use squashfs to compress whole system but even in
that case you have to
make your own init script that will take care of all the magic of mounting.
And because squashfs is read-only filesystem then it get's more trickier
because you have to take care
of yourself of all those /tmp and /var/log etc.. directories that need
to store temporarily stuff.

When you mount that squashfs-file with /dev/loop0 it does use very
little ram.
Like I said only if some files are accessed from it then kernle might
use little ram for caching it so that they are accessed
much faster next time.

So there is no need to separately load it into ram. It's just is there,
mounted throught /dev/loop0
(which is always there, provided that you did not remove loopback device
support from kernel conf)

Actually this is quite interesting because I have newer tried to do that
whole root squashfs myself before
(always just compressed part of the filesystem).

I could try that and report later back if it's worth it.

Stefan


22.1.2013 16:35, Stephen Turner kirjoitti:
> well actually, i just did a standard buildroot with squashfs so
> everything except the kernel bzImage is in the squashfs.  I suppose i
> missunderstood how it worked as i thought having support in the kernel
> allowed the reading of this file and if thats so i didnt expect to
> need a initrd especially since none was generated by the buildroot
> scripts.  I was looking for a solution that worked like that, where i
> could load it to ram or read it from a disk saving ram but in essence
> compress everything except perhaps the kernel. I dont suppose there is
> an option like that is there?
>
> On Tue, Jan 22, 2013 at 7:41 AM, Stefan Fr?berg
> <stefan.froberg@petroprogram.com
> <mailto:stefan.froberg@petroprogram.com>> wrote:
>
>     Hi Stephen
>     22.1.2013 3:25, Stephen Turner kirjoitti:
>>
>>     Sorry if my previous email went through. Im having some
>>     difficulty booting a squashfs with grub4dos on usb and grub2 from
>>     hd. In short im using bzImage for a kernel and trying to both
>>     boot the squashfs in ram and imaged to a usb drive. I havent
>>     found much info on how to use the squashfs from busybox and what
>>     i did find wasnt very helpful. Could someone point me to a how to
>>     for booting a busybox squash? Do i need to make my own initrd
>>     Image or edit some files such as fstab?
>>     I appreciate any and all input.
>>
>>     Thanks
>>     Stephen
>>
>>
>
>     What I usually have is squashfs (xz-compressed) image of the whole
>     /usr (because that's usually the largest).
>
>     And everything else is in xz-compressed initramfs. Kernel extract
>     and loads the initramfs file(s) that you have
>     specified in grub to  automatically to ram. squashfs image does
>     not need to loaded to ram but mounted to
>     loopback devise /dev/loop0. However, when files are accessed in
>     that image it's contents can be also cached to ram.
>
>     The basic idea is that everything that is absolutely needed for
>     booting and running, the very minimal core of the
>     system, is located in that initramfs.
>
>     Now, in the /etc/inittab file there is usually a line like
>     null::sysinit:/bin/mount -a
>
>     That will instruct that all stuff in /etc/fstab should be mounted.
>
>     My /etc/fstab look like this
>     # /etc/fstab: static file system information.
>     #
>     # <file system>         <mount pt>    <type>        <options>   
>         <dump>     <pass>
>     /modules.sqfs        /lib/modules    squashfs   
>     defaults,auto,loop,noatime    0    0
>     /firmware.sqfs      /lib/firmware    squashfs   
>     defaults,auto,loop,noatime    0    0
>     /dev/cdrom            /mnt/cdrom    iso9660       
>     defaults,noatime    0    0
>     /mnt/cdrom/usr.sqfs        /mnt/ro        squashfs   
>     defaults,auto,loop,noatime    0    0
>     proc                /proc               proc         defaults     
>         0    0
>     devpts                /dev/pts           devpts      
>     defaults,gid=5,mode=620    0    0
>     tmpfs                   /dev/shm           tmpfs      
>     mode=0777             0          0
>     tmpfs                   /tmp               tmpfs       
>     defaults              0          0
>     sysfs                /sys               sysfs        defaults     
>         0    0
>
>     What that does, is:
>
>     1 ) mount ./modules.sqfs (xz-compressed squashfs containing kernel
>     modules) to /lib/modules
>     2 ) mount ./firmware.sqfs (xz-compressed squashfs containing
>     firmware stuff) to /lib/firmware
>     3 ) mount Live-CD (the system itself that is running) to
>     /mnt/cdrom. The reason for this is
>     that storing usr.sqfs (xz-compressed squasfhs containing /usr) to
>     initramfs is waste of memory
>     while it can be stored into the root (outside of initramfs) of
>     live-cd. Just like I have done with kernel.
>     4 ) Mount /mnt/cdrom/usr.sqfs to /mnt/ro.
>     The reason for this is that later, in  /etc/init.d/rcS
>     im going to use unionfs to compine read-writeable /mnt/rw (just
>     empty directory without nothing mounted in)
>      and read-only /mnt/ro (the xz-compressed squashfs image from
>     Live-CD root that just got mounted) to compined
>     read-write directory in /usr
>
>     It's all little compilacted but space and memory saving and stuff
>     can be written to /usr if need to (for example Xorg
>     needs at least one location inside/usr to be writable for fonts if
>     I remember correctly)
>
>     If you don't need writable /usr then you can just mount your
>     usr-squashfs directly to /usr.
>     If you don't need /usr at all but just want to squashfs your / 
>     then maybe it's doable but you still have to mount
>     few places as read-write for tmp files and other stuff.
>
>     Like:
>     mount -t tmpfs tmpfs /tmp
>
>     And maybe
>     mount -t tmpfs tmpfs /var/log
>
>     Ofcourse those can be also added to /etc/fstab
>
>     What exatcly you have inside that squashfs ? Just busybox and
>     nothing else ?
>     In that case it's really not worth all the squashfs setup.
>
>     Regards
>     Stefan
>
>
>
>
>>
>>     _______________________________________________
>>     buildroot mailing list
>>     buildroot at busybox.net <mailto:buildroot@busybox.net>
>>     http://lists.busybox.net/mailman/listinfo/buildroot
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130122/bbf1c8b2/attachment.html>

[Buildroot] Squashfs boot

[Stefan Fröberg]

22.1.2013 21:30, Stephen Turner kirjoitti:
> Dont go out of your way to do this but if you do decide to play with
> it i would love to hear back about your experiences.  I suppose my
> concern now is more less that when the buildroot script makes a system
> such as the bzImage+cpio you expect it to boot and in that case it
> does. So why wouldn't the generated bzImage+squashfs boot?  my
> assumption was that i didn't have the correct grub4dos menu.lst
> entries to properly access it but scouring the Internet turned up next
> to nothing except for modifying your fstab to boot partially
> compressed systems.  As it turns out i was able to compress /usr and
> then cpio the remaining system. i now have a 5mb kernel 2mb cpio
> initrd and a 41mb squashfs usr directory which im fairly certain can
> be smaller with the right commands. Im working on getting the system
> to mount the /usr squash system at boot which i have verified there is
> enough of the system available in the initrd to mount it manually so
> im sure it should be able to be done automatically.
>  
> I do appreciate your help. If you have any pointers to the myserious
> buildroot output images not being bootable i would love to hear about
> it but in the mean time you helped me resolve the issue of shrinking
> my system!

My pleasure. Glad that I could help. :-)

Oh, and before I forgot:

When generating that squashfs /usr be sure to use latest version of
mksquashfs (4.2),
at least kernel version of 2.6.38 (that was the version when they added
xz-compression support for squashfs) and give
-comp xz switch when compressing your usr.

Something like this:

mksquashfs usr/ usr.sqfs -comp xz

Stefan

>  
> Thanks,
> Stephen
>
> On Tue, Jan 22, 2013 at 12:49 PM, Stefan Fr?berg
> <stefan.froberg@petroprogram.com
> <mailto:stefan.froberg@petroprogram.com>> wrote:
>
>     It's true that you can use squashfs to compress whole system but
>     even in that case you have to
>     make your own init script that will take care of all the magic of
>     mounting.
>     And because squashfs is read-only filesystem then it get's more
>     trickier because you have to take care
>     of yourself of all those /tmp and /var/log etc.. directories that
>     need to store temporarily stuff.
>
>     When you mount that squashfs-file with /dev/loop0 it does use very
>     little ram.
>     Like I said only if some files are accessed from it then kernle
>     might use little ram for caching it so that they are accessed
>     much faster next time.
>
>     So there is no need to separately load it into ram. It's just is
>     there, mounted throught /dev/loop0
>     (which is always there, provided that you did not remove loopback
>     device support from kernel conf)
>
>     Actually this is quite interesting because I have newer tried to
>     do that whole root squashfs myself before
>     (always just compressed part of the filesystem).
>
>     I could try that and report later back if it's worth it.
>
>     Stefan
>
>
>     22.1.2013 16:35, Stephen Turner kirjoitti:
>>     well actually, i just did a standard buildroot with squashfs so
>>     everything except the kernel bzImage is in the squashfs.  I
>>     suppose i missunderstood how it worked as i thought having
>>     support in the kernel allowed the reading of this file and if
>>     thats so i didnt expect to need a initrd especially since none
>>     was generated by the buildroot scripts.  I was looking for a
>>     solution that worked like that, where i could load it to ram or
>>     read it from a disk saving ram but in essence compress everything
>>     except perhaps the kernel. I dont suppose there is an option like
>>     that is there?
>>
>>     On Tue, Jan 22, 2013 at 7:41 AM, Stefan Fr?berg
>>     <stefan.froberg@petroprogram.com
>>     <mailto:stefan.froberg@petroprogram.com>> wrote:
>>
>>         Hi Stephen
>>         22.1.2013 3:25, Stephen Turner kirjoitti:
>>>
>>>         Sorry if my previous email went through. Im having some
>>>         difficulty booting a squashfs with grub4dos on usb and grub2
>>>         from hd. In short im using bzImage for a kernel and trying
>>>         to both boot the squashfs in ram and imaged to a usb drive.
>>>         I havent found much info on how to use the squashfs from
>>>         busybox and what i did find wasnt very helpful. Could
>>>         someone point me to a how to for booting a busybox squash?
>>>         Do i need to make my own initrd Image or edit some files
>>>         such as fstab?
>>>         I appreciate any and all input.
>>>
>>>         Thanks
>>>         Stephen
>>>
>>>
>>
>>         What I usually have is squashfs (xz-compressed) image of the
>>         whole /usr (because that's usually the largest).
>>
>>         And everything else is in xz-compressed initramfs. Kernel
>>         extract and loads the initramfs file(s) that you have
>>         specified in grub to  automatically to ram. squashfs image
>>         does not need to loaded to ram but mounted to
>>         loopback devise /dev/loop0. However, when files are accessed
>>         in that image it's contents can be also cached to ram.
>>
>>         The basic idea is that everything that is absolutely needed
>>         for booting and running, the very minimal core of the
>>         system, is located in that initramfs.
>>
>>         Now, in the /etc/inittab file there is usually a line like
>>         null::sysinit:/bin/mount -a
>>
>>         That will instruct that all stuff in /etc/fstab should be
>>         mounted.
>>
>>         My /etc/fstab look like this
>>         # /etc/fstab: static file system information.
>>         #
>>         # <file system>         <mount pt>    <type>       
>>         <options>        <dump>     <pass>
>>         /modules.sqfs        /lib/modules    squashfs   
>>         defaults,auto,loop,noatime    0    0
>>         /firmware.sqfs      /lib/firmware    squashfs   
>>         defaults,auto,loop,noatime    0    0
>>         /dev/cdrom            /mnt/cdrom    iso9660       
>>         defaults,noatime    0    0
>>         /mnt/cdrom/usr.sqfs        /mnt/ro        squashfs   
>>         defaults,auto,loop,noatime    0    0
>>         proc                /proc               proc        
>>         defaults          0    0
>>         devpts                /dev/pts           devpts      
>>         defaults,gid=5,mode=620    0    0
>>         tmpfs                   /dev/shm           tmpfs      
>>         mode=0777             0          0
>>         tmpfs                   /tmp               tmpfs       
>>         defaults              0          0
>>         sysfs                /sys               sysfs       
>>         defaults          0    0
>>
>>         What that does, is:
>>
>>         1 ) mount ./modules.sqfs (xz-compressed squashfs containing
>>         kernel modules) to /lib/modules
>>         2 ) mount ./firmware.sqfs (xz-compressed squashfs containing
>>         firmware stuff) to /lib/firmware
>>         3 ) mount Live-CD (the system itself that is running) to
>>         /mnt/cdrom. The reason for this is
>>         that storing usr.sqfs (xz-compressed squasfhs containing
>>         /usr) to initramfs is waste of memory
>>         while it can be stored into the root (outside of initramfs)
>>         of live-cd. Just like I have done with kernel.
>>         4 ) Mount /mnt/cdrom/usr.sqfs to /mnt/ro.
>>         The reason for this is that later, in  /etc/init.d/rcS
>>         im going to use unionfs to compine read-writeable /mnt/rw
>>         (just empty directory without nothing mounted in)
>>          and read-only /mnt/ro (the xz-compressed squashfs image from
>>         Live-CD root that just got mounted) to compined
>>         read-write directory in /usr
>>
>>         It's all little compilacted but space and memory saving and
>>         stuff can be written to /usr if need to (for example Xorg
>>         needs at least one location inside/usr to be writable for
>>         fonts if I remember correctly)
>>
>>         If you don't need writable /usr then you can just mount your
>>         usr-squashfs directly to /usr.
>>         If you don't need /usr at all but just want to squashfs your
>>         /  then maybe it's doable but you still have to mount
>>         few places as read-write for tmp files and other stuff.
>>
>>         Like:
>>         mount -t tmpfs tmpfs /tmp
>>
>>         And maybe
>>         mount -t tmpfs tmpfs /var/log
>>
>>         Ofcourse those can be also added to /etc/fstab
>>
>>         What exatcly you have inside that squashfs ? Just busybox and
>>         nothing else ?
>>         In that case it's really not worth all the squashfs setup.
>>
>>         Regards
>>         Stefan
>>
>>
>>
>>
>>>
>>>         _______________________________________________
>>>         buildroot mailing list
>>>         buildroot at busybox.net <mailto:buildroot@busybox.net>
>>>         http://lists.busybox.net/mailman/listinfo/buildroot
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130122/bd3e765d/attachment.html>

[Buildroot] Squashfs boot

[Peter Korsgaard]

>>>>> "Stefan" == Stefan Fr?berg <stefan.froberg@petroprogram.com> writes:

 Stefan> It's true that you can use squashfs to compress whole system
 Stefan> but even in that case you have to make your own init script
 Stefan> that will take care of all the magic of mounting.  And because
 Stefan> squashfs is read-only filesystem then it get's more trickier
 Stefan> because you have to take care of yourself of all those /tmp and
 Stefan> /var/log etc.. directories that need to store temporarily
 Stefan> stuff.

Read only rootfs (with /tmp and /var/log in tmpfs) should work out of
the box with buildroot, and I've using it for several projects.

-- 
Bye, Peter Korsgaard

[Buildroot] Squashfs boot

[Thomas Petazzoni]

Dear Stefan Fr?berg,

On Tue, 22 Jan 2013 19:49:35 +0200, Stefan Fr?berg wrote:
> It's true that you can use squashfs to compress whole system but even
> in that case you have to
> make your own init script that will take care of all the magic of
> mounting. And because squashfs is read-only filesystem then it get's
> more trickier because you have to take care
> of yourself of all those /tmp and /var/log etc.. directories that need
> to store temporarily stuff.

Huh? Mounting a squashfs filesystem as the root filesystem is very
easy. Just use root=/dev/<whereyourrootfsis> and that's it.

Buildroot already mounts a tmpfs in /tmp and has several symlinks
from /var/<something> to /tmp.

So, with the basic default Buildroot configuration, there is absolutely
nothing complicated in having the entire root filesystem read-only
inside SquashFS. On several projects, I've generated a system with
Buildroot where the entire filesystem is read-only mounted. No problem
at all.

I think your solution is much more complex than just having the entire
root filesystem read-only.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Squashfs boot

[Stefan Fröberg]

23.1.2013 17:57, Thomas Petazzoni kirjoitti:
> Dear Stefan Fr?berg,
>
> On Tue, 22 Jan 2013 19:49:35 +0200, Stefan Fr?berg wrote:
>> It's true that you can use squashfs to compress whole system but even
>> in that case you have to
>> make your own init script that will take care of all the magic of
>> mounting. And because squashfs is read-only filesystem then it get's
>> more trickier because you have to take care
>> of yourself of all those /tmp and /var/log etc.. directories that need
>> to store temporarily stuff.
> Huh? Mounting a squashfs filesystem as the root filesystem is very
> easy. Just use root=/dev/<whereyourrootfsis> and that's it.
>
> Buildroot already mounts a tmpfs in /tmp and has several symlinks
> from /var/<something> to /tmp.
>
> So, with the basic default Buildroot configuration, there is absolutely
> nothing complicated in having the entire root filesystem read-only
> inside SquashFS. On several projects, I've generated a system with
> Buildroot where the entire filesystem is read-only mounted. No problem
> at all.
>
> I think your solution is much more complex than just having the entire
> root filesystem read-only.
>
> Best regards,
>
> Thomas

No.
What I meant was, that if he is going to make it *without* buildroot
(that is, if he can't get buildroot generated squashfs root to boot).
*Then* he has to make his own init stuff to mount those /tmp and /var/log.

And my own solution is overly complex because I want the ability to
write to squashfs, even if just temporarily.
That's why I use initramfs + squashfs + unionfs


Regards
Stefan

[Buildroot] Squashfs boot

[Thomas Petazzoni]

Dear Stefan Fr?berg,

On Wed, 23 Jan 2013 18:05:54 +0200, Stefan Fr?berg wrote:

> No.
> What I meant was, that if he is going to make it *without* buildroot
> (that is, if he can't get buildroot generated squashfs root to boot).
> *Then* he has to make his own init stuff to mount those /tmp
> and /var/log.

Ok. But then if Buildroot has a bug, let's fix the bug instead of
trying to work-around it, no?

> And my own solution is overly complex because I want the ability to
> write to squashfs, even if just temporarily.
> That's why I use initramfs + squashfs + unionfs

Indeed. You could still boot the root filesystem from squashfs, and
then mount a tmpfs and do the unionfs thing. There's no real need to
split usr/ in a squashfs in order to achieve this, I think.

Best regards,

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com

[Buildroot] Squashfs boot

[Stefan Fröberg]

23.1.2013 18:18, Thomas Petazzoni kirjoitti:
> Dear Stefan Fr?berg,
>
> On Wed, 23 Jan 2013 18:05:54 +0200, Stefan Fr?berg wrote:
>
>> No.
>> What I meant was, that if he is going to make it *without* buildroot
>> (that is, if he can't get buildroot generated squashfs root to boot).
>> *Then* he has to make his own init stuff to mount those /tmp
>> and /var/log.
> Ok. But then if Buildroot has a bug, let's fix the bug instead of
> trying to work-around it, no?

Sure. But like I said I haven't (yet) done that whole root squashfs so I
can only guess work
what could be wrong with it. (too old squashfs-utils, wrong kernle
version, maybe missing kernel option?)

>> And my own solution is overly complex because I want the ability to
>> write to squashfs, even if just temporarily.
>> That's why I use initramfs + squashfs + unionfs
> Indeed. You could still boot the root filesystem from squashfs, and
> then mount a tmpfs and do the unionfs thing. There's no real need to
> split usr/ in a squashfs in order to achieve this, I think.
>
> Best regards,
>
> Thomas

Can I write to /usr with buildroot squashfs ?

Stefan

[Buildroot] Squashfs boot

[Arnout Vandecappelle]

On 01/22/13 13:41, Stefan Fr?berg wrote:
[snip]
> My /etc/fstab look like this
> # /etc/fstab: static file system information.
> #
> # <file system> <mount pt> <type> <options> <dump> <pass>
> /modules.sqfs        /lib/modules    squashfs    defaults,auto,loop,noatime    0    0
> /firmware.sqfs      /lib/firmware    squashfs    defaults,auto,loop,noatime    0    0
> /dev/cdrom            /mnt/cdrom    iso9660      defaults,noatime    0    0
> /mnt/cdrom/usr.sqfs        /mnt/ro        squashfs  defaults,auto,loop,noatime    0    0

  Now this is a real use case for being able to split the rootfs into 
several parts.

  However, as Thomas mentioned, it's simpler to just use a complete 
squashfs rootfs and put the unionfs on top of that. How? Somewhere early 
in your init.d you put something like the following (a script I swiped 
from the internet, don't remember where from; I haven't actually tested 
it myself):

#!/bin/sh

CHROOT_PATH="/tmp/unionfs"
UNION_OPT="-o 
allow_other,use_ino,suid,dev,nonempty,chroot=$CHROOT_PATH,max_files=32768"

#mount -t proc proc /proc
#mount -t tmpfs tmpfs /tmp

mkdir -p $CHROOT_PATH/root
mkdir -p $CHROOT_PATH/rw
mkdir -p /tmp/union

# Mount the filesystems
mount --bind / $CHROOT_PATH/root
# $CHROOT_PATH/rw is already on a tmpfs so doesn't need to be mounted

modprobe fuse
$CHROOT_PATH/root/usr/bin/unionfs $UNION_OPT /rw=RW:/root=RO /tmp/union

#mount -t proc proc /tmp/union/proc

cd /tmp/union
mkdir oldroot
pivot_root . oldroot
cd /

# Move existing mounts, if any
#umount /proc
mount --move /oldroot/proc /proc
mount --move /oldroot/dev /dev
mount --move /oldroot/sys /sys
mount --move /oldroot/tmp /tmp
rmdir /tmp/union

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Squashfs boot

[Stephen Turner]

I shouldnt need unionfs as im just loading a basic thinclient and having it
in a ro image would be best to prevent accidental or intentional tampering
when a simple reboot will fix. The rw items can use a temp ramdisk. Only
issue i was running into was figuring out how to read a squashfs at boot
with no initrd or basically  busybox squash output which is only bzImage
and rootfs.squashfs. i have managed to move usr to squash and use the rest
of the os as initrd but if thats what needs to be done then shouldnt the
busybox build script handle that?
On Jan 24, 2013 1:50 PM, "Arnout Vandecappelle" <arnout@mind.be> wrote:

> On 01/22/13 13:41, Stefan Fr?berg wrote:
> [snip]
>
>> My /etc/fstab look like this
>> # /etc/fstab: static file system information.
>> #
>> # <file system> <mount pt> <type> <options> <dump> <pass>
>> /modules.sqfs        /lib/modules    squashfs
>>  defaults,auto,loop,noatime    0    0
>> /firmware.sqfs      /lib/firmware    squashfs
>>  defaults,auto,loop,noatime    0    0
>> /dev/cdrom            /mnt/cdrom    iso9660      defaults,noatime    0
>>  0
>> /mnt/cdrom/usr.sqfs        /mnt/ro        squashfs
>>  defaults,auto,loop,noatime    0    0
>>
>
>  Now this is a real use case for being able to split the rootfs into
> several parts.
>
>  However, as Thomas mentioned, it's simpler to just use a complete
> squashfs rootfs and put the unionfs on top of that. How? Somewhere early in
> your init.d you put something like the following (a script I swiped from
> the internet, don't remember where from; I haven't actually tested it
> myself):
>
> #!/bin/sh
>
> CHROOT_PATH="/tmp/unionfs"
> UNION_OPT="-o allow_other,use_ino,suid,dev,**nonempty,chroot=$CHROOT_PATH,
> **max_files=32768"
>
> #mount -t proc proc /proc
> #mount -t tmpfs tmpfs /tmp
>
> mkdir -p $CHROOT_PATH/root
> mkdir -p $CHROOT_PATH/rw
> mkdir -p /tmp/union
>
> # Mount the filesystems
> mount --bind / $CHROOT_PATH/root
> # $CHROOT_PATH/rw is already on a tmpfs so doesn't need to be mounted
>
> modprobe fuse
> $CHROOT_PATH/root/usr/bin/**unionfs $UNION_OPT /rw=RW:/root=RO /tmp/union
>
> #mount -t proc proc /tmp/union/proc
>
> cd /tmp/union
> mkdir oldroot
> pivot_root . oldroot
> cd /
>
> # Move existing mounts, if any
> #umount /proc
> mount --move /oldroot/proc /proc
> mount --move /oldroot/dev /dev
> mount --move /oldroot/sys /sys
> mount --move /oldroot/tmp /tmp
> rmdir /tmp/union
>
> --
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/**arnoutvandecappelle<http://www.linkedin.com/in/arnoutvandecappelle>
> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130124/d62f19de/attachment.html>

[Buildroot] Squashfs boot

[Stefan Fröberg]

Thin client? Ah, now I beging to understand why you needed to load that
squashfs image into ram.

So your thin client is totally diskless ? No hard drive at all ?
And you plan to load your squashfs image from server or usb stick or
from where ?

Stefan


24.1.2013 21:29, Stephen Turner kirjoitti:
>
> I shouldnt need unionfs as im just loading a basic thinclient and
> having it in a ro image would be best to prevent accidental or
> intentional tampering when a simple reboot will fix. The rw items can
> use a temp ramdisk. Only issue i was running into was figuring out how
> to read a squashfs at boot with no initrd or basically  busybox squash
> output which is only bzImage and rootfs.squashfs. i have managed to
> move usr to squash and use the rest of the os as initrd but if thats
> what needs to be done then shouldnt the busybox build script handle that?
>
> On Jan 24, 2013 1:50 PM, "Arnout Vandecappelle" <arnout@mind.be
> <mailto:arnout@mind.be>> wrote:
>
>     On 01/22/13 13:41, Stefan Fr?berg wrote:
>     [snip]
>
>         My /etc/fstab look like this
>         # /etc/fstab: static file system information.
>         #
>         # <file system> <mount pt> <type> <options> <dump> <pass>
>         /modules.sqfs        /lib/modules    squashfs  
>          defaults,auto,loop,noatime    0    0
>         /firmware.sqfs      /lib/firmware    squashfs  
>          defaults,auto,loop,noatime    0    0
>         /dev/cdrom            /mnt/cdrom    iso9660    
>          defaults,noatime    0    0
>         /mnt/cdrom/usr.sqfs        /mnt/ro        squashfs
>          defaults,auto,loop,noatime    0    0
>
>
>      Now this is a real use case for being able to split the rootfs
>     into several parts.
>
>      However, as Thomas mentioned, it's simpler to just use a complete
>     squashfs rootfs and put the unionfs on top of that. How? Somewhere
>     early in your init.d you put something like the following (a
>     script I swiped from the internet, don't remember where from; I
>     haven't actually tested it myself):
>
>     #!/bin/sh
>
>     CHROOT_PATH="/tmp/unionfs"
>     UNION_OPT="-o
>     allow_other,use_ino,suid,dev,nonempty,chroot=$CHROOT_PATH,max_files=32768"
>
>     #mount -t proc proc /proc
>     #mount -t tmpfs tmpfs /tmp
>
>     mkdir -p $CHROOT_PATH/root
>     mkdir -p $CHROOT_PATH/rw
>     mkdir -p /tmp/union
>
>     # Mount the filesystems
>     mount --bind / $CHROOT_PATH/root
>     # $CHROOT_PATH/rw is already on a tmpfs so doesn't need to be mounted
>
>     modprobe fuse
>     $CHROOT_PATH/root/usr/bin/unionfs $UNION_OPT /rw=RW:/root=RO
>     /tmp/union
>
>     #mount -t proc proc /tmp/union/proc
>
>     cd /tmp/union
>     mkdir oldroot
>     pivot_root . oldroot
>     cd /
>
>     # Move existing mounts, if any
>     #umount /proc
>     mount --move /oldroot/proc /proc
>     mount --move /oldroot/dev /dev
>     mount --move /oldroot/sys /sys
>     mount --move /oldroot/tmp /tmp
>     rmdir /tmp/union
>
>     -- 
>     Arnout Vandecappelle                          arnout at mind be
>     Senior Embedded Software Architect            +32-16-286500
>     <tel:%2B32-16-286500>
>     Essensium/Mind                                http://www.mind.be
>     G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR
>     Leuven
>     LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
>     GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130125/cee45e54/attachment.html>

[Buildroot] Squashfs boot

[Stefan Fröberg]

24.1.2013 19:42, Arnout Vandecappelle kirjoitti:
> On 01/22/13 13:41, Stefan Fr?berg wrote:
> [snip]
>> My /etc/fstab look like this
>> # /etc/fstab: static file system information.
>> #
>> # <file system> <mount pt> <type> <options> <dump> <pass>
>> /modules.sqfs        /lib/modules    squashfs   
>> defaults,auto,loop,noatime    0    0
>> /firmware.sqfs      /lib/firmware    squashfs   
>> defaults,auto,loop,noatime    0    0
>> /dev/cdrom            /mnt/cdrom    iso9660      defaults,noatime   
>> 0    0
>> /mnt/cdrom/usr.sqfs        /mnt/ro        squashfs 
>> defaults,auto,loop,noatime    0    0
>
>  Now this is a real use case for being able to split the rootfs into
> several parts.
>
>  However, as Thomas mentioned, it's simpler to just use a complete
> squashfs rootfs and put the unionfs on top of that. How? Somewhere
> early in your init.d you put something like the following (a script I
> swiped from the internet, don't remember where from; I haven't
> actually tested it myself):
>
> #!/bin/sh
>
> CHROOT_PATH="/tmp/unionfs"
> UNION_OPT="-o
> allow_other,use_ino,suid,dev,nonempty,chroot=$CHROOT_PATH,max_files=32768"
>
> #mount -t proc proc /proc
> #mount -t tmpfs tmpfs /tmp
>
> mkdir -p $CHROOT_PATH/root
> mkdir -p $CHROOT_PATH/rw
> mkdir -p /tmp/union
>
> # Mount the filesystems
> mount --bind / $CHROOT_PATH/root
> # $CHROOT_PATH/rw is already on a tmpfs so doesn't need to be mounted
>
> modprobe fuse
> $CHROOT_PATH/root/usr/bin/unionfs $UNION_OPT /rw=RW:/root=RO /tmp/union
>
> #mount -t proc proc /tmp/union/proc
>
> cd /tmp/union
> mkdir oldroot
> pivot_root . oldroot
> cd /
>
> # Move existing mounts, if any
> #umount /proc
> mount --move /oldroot/proc /proc
> mount --move /oldroot/dev /dev
> mount --move /oldroot/sys /sys
> mount --move /oldroot/tmp /tmp
> rmdir /tmp/union
>

That looks very interesting Arnout.
If that works then I will own you a whiskey bottle :-)

Stefan

[Buildroot] Squashfs boot

[Stefan Fröberg]

Hello Stephen

I made a quick conversion of my LiveCD initramfs stuff to squashfs image
file and then played little bit with it and kernel image
with the help of qemu. (took less time than starting all
reconfiguring/combiling from buildroot)

The good news is that yes, it should be doable to do boot directly from
squashfs root image.

For example I did this to start it (ramdisk_size is in kilobytes):

qemu-system-i386 -kernel bzImage -initrd rootfs.sqfs -append
"ramdisk_size=131072"

It first tries to unpack rootfs as initramfs and then it notices that
it's not initramfs but traditional,
older version of initrd file. (please see root.png).

After that it should print RAMDISK: squashfs filesystem found and start
automatically loading it to ram.
(please see root2.png)

After that it continues normally and starts the normal init process.

And now the bad news:

- Takes a lot of memory. This is old style initrd stuff (time when 2.4
kernel was still hot and new).
- Squashfs is read-only so if you use mdev or udev then expect little
troubles (please see root3.png).

However maybe buildroot init already takes care of those ????


Now, you said you use grub to load ? Then either try givin that
rootfs.sqfs as in a separate line starting with "initrd
/path/to/your/rootfs.sqfs"
in your grub menu.lst (or is it grub.conf now?)
or if that does not work then giving kernel parameter in kernel line
like "initrd rootfs.sqfs" (or maybe "initrd=rootfs.sqfs")

The other way of using squashfs root from image could be maybe done with
initramfs and that script that Arnout posted (without unionfs stuff in
your case).
But maybe it needs some cleaning up first and pivot_root changed to
switch_root ???

Adding maybe this line to init script inside your initramfs to mount
rootfs.sqfs to loopback device just before switching to realroot:

mount -o loop rootfs.sqfs /mnt/realroot
switch_root /mnt/realroot

.... init continues normally here in the real root (squashfs image
mounted to loopback device, usually /dev/loop0) ....


Regards
Stefan

25.1.2013 1:47, Stephen Turner kirjoitti:
>
> Im hoping to use the raspberry pi (may need the special buildroot
> distro for that) but really were building this for soc risc boards in
> general. I am trying to stay away from loading to ram since its
> limited and we will be doing something like a freebsd nanobsd setup
> where scripts update software to 2 partitions one backup other
> booting. That way they have a fall back in the event a update goes
> south. It would be ideal to run the systems from a file instead of dd
> a image to an area. If i cant boot from the squash file then im
> thinking of just squashing the usr and mounting it at boot like i have
> done now as that leaves me with a 2 mb initrd + 40mb squash and 5 mb
> kernel so far on a 586 for a pilot.
>
> On Jan 24, 2013 5:40 PM, "Stefan Fr?berg"
> <stefan.froberg@petroprogram.com
> <mailto:stefan.froberg@petroprogram.com>> wrote:
>
>     Thin client? Ah, now I beging to understand why you needed to load
>     that squashfs image into ram.
>
>     So your thin client is totally diskless ? No hard drive at all ?
>     And you plan to load your squashfs image from server or usb stick
>     or from where ?
>
>     Stefan
>
>
>     24.1.2013 21:29, Stephen Turner kirjoitti:
>>
>>     I shouldnt need unionfs as im just loading a basic thinclient and
>>     having it in a ro image would be best to prevent accidental or
>>     intentional tampering when a simple reboot will fix. The rw items
>>     can use a temp ramdisk. Only issue i was running into was
>>     figuring out how to read a squashfs at boot with no initrd or
>>     basically  busybox squash output which is only bzImage and
>>     rootfs.squashfs. i have managed to move usr to squash and use the
>>     rest of the os as initrd but if thats what needs to be done then
>>     shouldnt the busybox build script handle that?
>>
>>     On Jan 24, 2013 1:50 PM, "Arnout Vandecappelle" <arnout@mind.be
>>     <mailto:arnout@mind.be>> wrote:
>>
>>         On 01/22/13 13:41, Stefan Fr?berg wrote:
>>         [snip]
>>
>>             My /etc/fstab look like this
>>             # /etc/fstab: static file system information.
>>             #
>>             # <file system> <mount pt> <type> <options> <dump> <pass>
>>             /modules.sqfs        /lib/modules    squashfs  
>>              defaults,auto,loop,noatime    0    0
>>             /firmware.sqfs      /lib/firmware    squashfs  
>>              defaults,auto,loop,noatime    0    0
>>             /dev/cdrom            /mnt/cdrom    iso9660    
>>              defaults,noatime    0    0
>>             /mnt/cdrom/usr.sqfs        /mnt/ro        squashfs
>>              defaults,auto,loop,noatime    0    0
>>
>>
>>          Now this is a real use case for being able to split the
>>         rootfs into several parts.
>>
>>          However, as Thomas mentioned, it's simpler to just use a
>>         complete squashfs rootfs and put the unionfs on top of that.
>>         How? Somewhere early in your init.d you put something like
>>         the following (a script I swiped from the internet, don't
>>         remember where from; I haven't actually tested it myself):
>>
>>         #!/bin/sh
>>
>>         CHROOT_PATH="/tmp/unionfs"
>>         UNION_OPT="-o
>>         allow_other,use_ino,suid,dev,nonempty,chroot=$CHROOT_PATH,max_files=32768"
>>
>>         #mount -t proc proc /proc
>>         #mount -t tmpfs tmpfs /tmp
>>
>>         mkdir -p $CHROOT_PATH/root
>>         mkdir -p $CHROOT_PATH/rw
>>         mkdir -p /tmp/union
>>
>>         # Mount the filesystems
>>         mount --bind / $CHROOT_PATH/root
>>         # $CHROOT_PATH/rw is already on a tmpfs so doesn't need to be
>>         mounted
>>
>>         modprobe fuse
>>         $CHROOT_PATH/root/usr/bin/unionfs $UNION_OPT /rw=RW:/root=RO
>>         /tmp/union
>>
>>         #mount -t proc proc /tmp/union/proc
>>
>>         cd /tmp/union
>>         mkdir oldroot
>>         pivot_root . oldroot
>>         cd /
>>
>>         # Move existing mounts, if any
>>         #umount /proc
>>         mount --move /oldroot/proc /proc
>>         mount --move /oldroot/dev /dev
>>         mount --move /oldroot/sys /sys
>>         mount --move /oldroot/tmp /tmp
>>         rmdir /tmp/union
>>
>>         -- 
>>         Arnout Vandecappelle                          arnout at mind be
>>         Senior Embedded Software Architect            +32-16-286500
>>         <tel:%2B32-16-286500>
>>         Essensium/Mind                                http://www.mind.be
>>         G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063
>>         RPR Leuven
>>         LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
>>         GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB
>>         2450 2F1F
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130125/56d3d968/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: root.jpg
Type: image/jpeg
Size: 45905 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130125/56d3d968/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: root2.jpg
Type: image/jpeg
Size: 41946 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130125/56d3d968/attachment-0004.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: root3.jpg
Type: image/jpeg
Size: 45919 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130125/56d3d968/attachment-0005.jpg>

[Buildroot] Squashfs boot

[Arnout Vandecappelle]

On 01/25/13 22:55, Stefan Fr?berg wrote:
> Hello Stephen
>
> I made a quick conversion of my LiveCD initramfs stuff to squashfs image
> file and then played little bit with it and kernel image
> with the help of qemu. (took less time than starting all
> reconfiguring/combiling from buildroot)
>
> The good news is that yes, it should be doable to do boot directly from
> squashfs root image.
>
> For example I did this to start it (ramdisk_size is in kilobytes):
>
> qemu-system-i386 -kernel bzImage -initrd rootfs.sqfs -append
> "ramdisk_size=131072"
>
> It first tries to unpack rootfs as initramfs and then it notices that
> it's not initramfs but traditional,
> older version of initrd file. (please see root.png).
>
> After that it should print RAMDISK: squashfs filesystem found and start
> automatically loading it to ram.
> (please see root2.png)
>
> After that it continues normally and starts the normal init process.
>
> And now the bad news:
>
> - Takes a lot of memory. This is old style initrd stuff (time when 2.4
> kernel was still hot and new).

  Yes, using squashfs as initrd is probably not what you want: it will 
load the entire squashfs into memory (albeit compressed), and then copy 
it (and decompress) when you access it.

  The typical way to use squashfs is as a partition of your disk. So if 
you'd boot from a USB stick, you'd make two partitions: an ext2 for grub 
and the kernel, and a second one for the squashfs. To install it, just do 
"cat output/images/rootfs.sqfs > /dev/sdb2" (assuming your USB key is 
/dev/sdb and squashfs is the second partition). When booting, you append 
the following the kernel command line: "root=/dev/sda2 rootwait" 
(assuming there's no hard disk or anything so the USB key will end up as 
/dev/sda).


> - Squashfs is read-only so if you use mdev or udev then expect little
> troubles (please see root3.png).
>
> However maybe buildroot init already takes care of those ????

  Copy fs/cpio/init to output/target/init and all will be well.


  Regards,
  Arnout

[snip]

-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] Squashfs boot

[Stefan Fröberg]

27.1.2013 0:38, Arnout Vandecappelle kirjoitti:
> On 01/25/13 22:55, Stefan Fr?berg wrote:
>> Hello Stephen
>>
>> I made a quick conversion of my LiveCD initramfs stuff to squashfs image
>> file and then played little bit with it and kernel image
>> with the help of qemu. (took less time than starting all
>> reconfiguring/combiling from buildroot)
>>
>> The good news is that yes, it should be doable to do boot directly from
>> squashfs root image.
>>
>> For example I did this to start it (ramdisk_size is in kilobytes):
>>
>> qemu-system-i386 -kernel bzImage -initrd rootfs.sqfs -append
>> "ramdisk_size=131072"
>>
>> It first tries to unpack rootfs as initramfs and then it notices that
>> it's not initramfs but traditional,
>> older version of initrd file. (please see root.png).
>>
>> After that it should print RAMDISK: squashfs filesystem found and start
>> automatically loading it to ram.
>> (please see root2.png)
>>
>> After that it continues normally and starts the normal init process.
>>
>> And now the bad news:
>>
>> - Takes a lot of memory. This is old style initrd stuff (time when 2.4
>> kernel was still hot and new).
>
>  Yes, using squashfs as initrd is probably not what you want: it will
> load the entire squashfs into memory (albeit compressed), and then
> copy it (and decompress) when you access it.
>
>  The typical way to use squashfs is as a partition of your disk. So if
> you'd boot from a USB stick, you'd make two partitions: an ext2 for
> grub and the kernel, and a second one for the squashfs. To install it,
> just do "cat output/images/rootfs.sqfs > /dev/sdb2" (assuming your USB
> key is /dev/sdb and squashfs is the second partition). When booting,
> you append the following the kernel command line: "root=/dev/sda2
> rootwait" (assuming there's no hard disk or anything so the USB key
> will end up as /dev/sda).
>

But I understanded that he didn't want to use partition to boot but
directly from squashfs image.
At least that's how I understanded this part in his message:  "It would
be ideal to run the systems from a file instead of dd a image to an area"


Regards
Stefan

[Buildroot] Squashfs boot

[Stephen Turner]

Thats what i was hoping to not have to do but i appreciate you sharing that
very much. I will try it that way and see if i like it. Everyone has been
very helpful thanks for all your input.

Stephen
On Jan 26, 2013 5:38 PM, "Arnout Vandecappelle" <arnout@mind.be> wrote:

> On 01/25/13 22:55, Stefan Fr?berg wrote:
>
>> Hello Stephen
>>
>> I made a quick conversion of my LiveCD initramfs stuff to squashfs image
>> file and then played little bit with it and kernel image
>> with the help of qemu. (took less time than starting all
>> reconfiguring/combiling from buildroot)
>>
>> The good news is that yes, it should be doable to do boot directly from
>> squashfs root image.
>>
>> For example I did this to start it (ramdisk_size is in kilobytes):
>>
>> qemu-system-i386 -kernel bzImage -initrd rootfs.sqfs -append
>> "ramdisk_size=131072"
>>
>> It first tries to unpack rootfs as initramfs and then it notices that
>> it's not initramfs but traditional,
>> older version of initrd file. (please see root.png).
>>
>> After that it should print RAMDISK: squashfs filesystem found and start
>> automatically loading it to ram.
>> (please see root2.png)
>>
>> After that it continues normally and starts the normal init process.
>>
>> And now the bad news:
>>
>> - Takes a lot of memory. This is old style initrd stuff (time when 2.4
>> kernel was still hot and new).
>>
>
>  Yes, using squashfs as initrd is probably not what you want: it will load
> the entire squashfs into memory (albeit compressed), and then copy it (and
> decompress) when you access it.
>
>  The typical way to use squashfs is as a partition of your disk. So if
> you'd boot from a USB stick, you'd make two partitions: an ext2 for grub
> and the kernel, and a second one for the squashfs. To install it, just do
> "cat output/images/rootfs.sqfs > /dev/sdb2" (assuming your USB key is
> /dev/sdb and squashfs is the second partition). When booting, you append
> the following the kernel command line: "root=/dev/sda2 rootwait" (assuming
> there's no hard disk or anything so the USB key will end up as /dev/sda).
>
>
>  - Squashfs is read-only so if you use mdev or udev then expect little
>> troubles (please see root3.png).
>>
>> However maybe buildroot init already takes care of those ????
>>
>
>  Copy fs/cpio/init to output/target/init and all will be well.
>
>
>  Regards,
>  Arnout
>
> [snip]
>
> --
> Arnout Vandecappelle                          arnout at mind be
> Senior Embedded Software Architect            +32-16-286500
> Essensium/Mind                                http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/**arnoutvandecappelle<http://www.linkedin.com/in/arnoutvandecappelle>
> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20130127/38c93c85/attachment-0001.html>