* [Buildroot] Squashfs boot [not found] <CAN_xxrWTp21-a-jD7x11yJa6ghM=C=ON2h_bx_is1iFhEkE0bQ@mail.gmail.com> @ 2013-01-22 1:25 ` Stephen Turner 2013-01-22 12:41 ` Stefan Fröberg 0 siblings, 1 reply; 17+ messages in thread From: Stephen Turner @ 2013-01-22 1:25 UTC (permalink / raw) To: buildroot 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> ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] Squashfs boot 2013-01-22 1:25 ` [Buildroot] Squashfs boot Stephen Turner @ 2013-01-22 12:41 ` Stefan Fröberg [not found] ` <CAN_xxrVD=Tq=ekME-jdHKRzyUwXk0PMocQX9mrxxcgjZQ8SYqA@mail.gmail.com> 2013-01-24 17:42 ` Arnout Vandecappelle 0 siblings, 2 replies; 17+ messages in thread From: Stefan Fröberg @ 2013-01-22 12:41 UTC (permalink / raw) To: buildroot 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> ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <CAN_xxrVD=Tq=ekME-jdHKRzyUwXk0PMocQX9mrxxcgjZQ8SYqA@mail.gmail.com>]
* [Buildroot] Squashfs boot [not found] ` <CAN_xxrVD=Tq=ekME-jdHKRzyUwXk0PMocQX9mrxxcgjZQ8SYqA@mail.gmail.com> @ 2013-01-22 17:49 ` Stefan Fröberg [not found] ` <CAN_xxrXZWmhECAH1JfgvHk+U_wksdZ0ZyxpcaSea8KsEYy04mw@mail.gmail.com> ` (2 more replies) 0 siblings, 3 replies; 17+ messages in thread From: Stefan Fröberg @ 2013-01-22 17:49 UTC (permalink / raw) To: buildroot 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> ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <CAN_xxrXZWmhECAH1JfgvHk+U_wksdZ0ZyxpcaSea8KsEYy04mw@mail.gmail.com>]
* [Buildroot] Squashfs boot [not found] ` <CAN_xxrXZWmhECAH1JfgvHk+U_wksdZ0ZyxpcaSea8KsEYy04mw@mail.gmail.com> @ 2013-01-22 19:39 ` Stefan Fröberg 0 siblings, 0 replies; 17+ messages in thread From: Stefan Fröberg @ 2013-01-22 19:39 UTC (permalink / raw) To: buildroot 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> ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] Squashfs boot 2013-01-22 17:49 ` Stefan Fröberg [not found] ` <CAN_xxrXZWmhECAH1JfgvHk+U_wksdZ0ZyxpcaSea8KsEYy04mw@mail.gmail.com> @ 2013-01-22 20:20 ` Peter Korsgaard 2013-01-23 15:57 ` Thomas Petazzoni 2 siblings, 0 replies; 17+ messages in thread From: Peter Korsgaard @ 2013-01-22 20:20 UTC (permalink / raw) To: buildroot >>>>> "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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] Squashfs boot 2013-01-22 17:49 ` Stefan Fröberg [not found] ` <CAN_xxrXZWmhECAH1JfgvHk+U_wksdZ0ZyxpcaSea8KsEYy04mw@mail.gmail.com> 2013-01-22 20:20 ` Peter Korsgaard @ 2013-01-23 15:57 ` Thomas Petazzoni 2013-01-23 16:05 ` Stefan Fröberg 2 siblings, 1 reply; 17+ messages in thread From: Thomas Petazzoni @ 2013-01-23 15:57 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] Squashfs boot 2013-01-23 15:57 ` Thomas Petazzoni @ 2013-01-23 16:05 ` Stefan Fröberg 2013-01-23 16:18 ` Thomas Petazzoni 0 siblings, 1 reply; 17+ messages in thread From: Stefan Fröberg @ 2013-01-23 16:05 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] Squashfs boot 2013-01-23 16:05 ` Stefan Fröberg @ 2013-01-23 16:18 ` Thomas Petazzoni 2013-01-23 16:31 ` Stefan Fröberg 0 siblings, 1 reply; 17+ messages in thread From: Thomas Petazzoni @ 2013-01-23 16:18 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] Squashfs boot 2013-01-23 16:18 ` Thomas Petazzoni @ 2013-01-23 16:31 ` Stefan Fröberg 0 siblings, 0 replies; 17+ messages in thread From: Stefan Fröberg @ 2013-01-23 16:31 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] Squashfs boot 2013-01-22 12:41 ` Stefan Fröberg [not found] ` <CAN_xxrVD=Tq=ekME-jdHKRzyUwXk0PMocQX9mrxxcgjZQ8SYqA@mail.gmail.com> @ 2013-01-24 17:42 ` Arnout Vandecappelle 2013-01-24 19:29 ` Stephen Turner 2013-01-24 22:42 ` Stefan Fröberg 1 sibling, 2 replies; 17+ messages in thread From: Arnout Vandecappelle @ 2013-01-24 17:42 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] Squashfs boot 2013-01-24 17:42 ` Arnout Vandecappelle @ 2013-01-24 19:29 ` Stephen Turner 2013-01-24 22:40 ` Stefan Fröberg 2013-01-24 22:42 ` Stefan Fröberg 1 sibling, 1 reply; 17+ messages in thread From: Stephen Turner @ 2013-01-24 19:29 UTC (permalink / raw) To: buildroot 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> ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] Squashfs boot 2013-01-24 19:29 ` Stephen Turner @ 2013-01-24 22:40 ` Stefan Fröberg [not found] ` <CAN_xxrXsvvupyo61cqZhCR4JyLwtCsm1NRAh9JCy_uVHRqGO4A@mail.gmail.com> 0 siblings, 1 reply; 17+ messages in thread From: Stefan Fröberg @ 2013-01-24 22:40 UTC (permalink / raw) To: buildroot 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> ^ permalink raw reply [flat|nested] 17+ messages in thread
[parent not found: <CAN_xxrXsvvupyo61cqZhCR4JyLwtCsm1NRAh9JCy_uVHRqGO4A@mail.gmail.com>]
* [Buildroot] Squashfs boot [not found] ` <CAN_xxrXsvvupyo61cqZhCR4JyLwtCsm1NRAh9JCy_uVHRqGO4A@mail.gmail.com> @ 2013-01-25 21:55 ` Stefan Fröberg 2013-01-26 22:38 ` Arnout Vandecappelle 0 siblings, 1 reply; 17+ messages in thread From: Stefan Fröberg @ 2013-01-25 21:55 UTC (permalink / raw) To: buildroot 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> ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] Squashfs boot 2013-01-25 21:55 ` Stefan Fröberg @ 2013-01-26 22:38 ` Arnout Vandecappelle 2013-01-26 23:04 ` Stefan Fröberg 2013-01-27 7:13 ` Stephen Turner 0 siblings, 2 replies; 17+ messages in thread From: Arnout Vandecappelle @ 2013-01-26 22:38 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] Squashfs boot 2013-01-26 22:38 ` Arnout Vandecappelle @ 2013-01-26 23:04 ` Stefan Fröberg 2013-01-27 7:13 ` Stephen Turner 1 sibling, 0 replies; 17+ messages in thread From: Stefan Fröberg @ 2013-01-26 23:04 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] Squashfs boot 2013-01-26 22:38 ` Arnout Vandecappelle 2013-01-26 23:04 ` Stefan Fröberg @ 2013-01-27 7:13 ` Stephen Turner 1 sibling, 0 replies; 17+ messages in thread From: Stephen Turner @ 2013-01-27 7:13 UTC (permalink / raw) To: buildroot 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> ^ permalink raw reply [flat|nested] 17+ messages in thread
* [Buildroot] Squashfs boot 2013-01-24 17:42 ` Arnout Vandecappelle 2013-01-24 19:29 ` Stephen Turner @ 2013-01-24 22:42 ` Stefan Fröberg 1 sibling, 0 replies; 17+ messages in thread From: Stefan Fröberg @ 2013-01-24 22:42 UTC (permalink / raw) To: buildroot 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 ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2013-01-27 7:13 UTC | newest] Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAN_xxrWTp21-a-jD7x11yJa6ghM=C=ON2h_bx_is1iFhEkE0bQ@mail.gmail.com> 2013-01-22 1:25 ` [Buildroot] Squashfs boot Stephen Turner 2013-01-22 12:41 ` Stefan Fröberg [not found] ` <CAN_xxrVD=Tq=ekME-jdHKRzyUwXk0PMocQX9mrxxcgjZQ8SYqA@mail.gmail.com> 2013-01-22 17:49 ` Stefan Fröberg [not found] ` <CAN_xxrXZWmhECAH1JfgvHk+U_wksdZ0ZyxpcaSea8KsEYy04mw@mail.gmail.com> 2013-01-22 19:39 ` Stefan Fröberg 2013-01-22 20:20 ` Peter Korsgaard 2013-01-23 15:57 ` Thomas Petazzoni 2013-01-23 16:05 ` Stefan Fröberg 2013-01-23 16:18 ` Thomas Petazzoni 2013-01-23 16:31 ` Stefan Fröberg 2013-01-24 17:42 ` Arnout Vandecappelle 2013-01-24 19:29 ` Stephen Turner 2013-01-24 22:40 ` Stefan Fröberg [not found] ` <CAN_xxrXsvvupyo61cqZhCR4JyLwtCsm1NRAh9JCy_uVHRqGO4A@mail.gmail.com> 2013-01-25 21:55 ` Stefan Fröberg 2013-01-26 22:38 ` Arnout Vandecappelle 2013-01-26 23:04 ` Stefan Fröberg 2013-01-27 7:13 ` Stephen Turner 2013-01-24 22:42 ` Stefan Fröberg
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.