Mailing List Archive

Re: SOLVED planning a flash DOM x86 embedded system
It works now!


It seems that blog shows an old style syntax. Found others, though, like
the following:

http://www.viraj.org/b2evolution/blogs/index.php/2007/05/03/ubuntu_server_and_unionfs


but for nowadays Gentoo systems (at least) the correct syntax is like the
following (which works for me):


/dev/sda3 /.var.rw ext4
noatime,defaults 0 2
union /var unionfs
default_permissions,allow_other,use_ino,nonempty,suid,cow,dirs=/.var.rw
=rw:/.var.ro=ro 0 0
tmpfs /.etc.rw tmpfs
defaults,mode=755 0 0
union /etc unionfs
default_permissions,allow_other,use_ino,nonempty,suid,cow,dirs=/.etc.rw
=rw:/.etc.ro=ro 0 0

Directories /.var.ro and /.etc.ro are already present on the root
file system.

It seems that this was the problem from the beginning, not been able to
correctly mount those partitions at the proper and usual time.

So I did'nt need the changes on "/etc/initramfs.mounts" as I expected.

Thanks
Francisco



2013/10/22 Francisco Ares <frares@gmail.com>

> Found it and gonna try:
>
>
> https://grangerx.wordpress.com/2010/12/31/using-fuse-unionfs-with-centos-5-5-i686/
>
>
> 2013/10/22 Francisco Ares <frares@gmail.com>
>
>> Thanks for the tip, Gareth;
>>
>> As a matter of fact, the unionfs in "/var" is not being mounted - as long
>> as "/etc" also.
>>
>> Finally I got a verbose boot, and it is possible to read, as an error
>> message:
>>
>> !! unable to mount none for /var
>>
>> in my "/etc/fstab", these are the related entries:
>>
>>
>>
>> /dev/sda2 / squashfs
>> noatime,ro 0 1
>> /dev/sda3 /.var.rw ext4
>> noatime,defaults 0 2
>> none /var unionfs
>> nonempty,cow,umask=022,dirs=/.var.rw/=rw:/.var.ro/=ro 0 0
>>
>> Now I'm trying to find out on the manuals how to better tell the mount
>> program there is no device to be mounted for "/var" .
>>
>> Thanks
>> Francisco
>>
>>
>>
>> 2013/10/20 Gareth McClean <disneysw@hotmail.com>
>>
>>> ** **
>>>
>>> Check your /etc/mtab on the failing system to see how the kernel
>>> believes the root partition has been mounted.****
>>>
>>> ** **
>>>
>>> I ended up including a fix-up in at the end of my init script to ensure
>>> /etc/mtab correctly reflected my aufs root file system****
>>>
>>> ** **
>>>
>>> # Insert our new root into the mtab****
>>>
>>> sed -i '1i none / aufs dirs=/rw=rw:/ro=ro' ${NEW_ROOT}/etc/mtab****
>>>
>>> ** **
>>>
>>> this is performed just before performing the “switch_root” process.****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> Also are you sure "/etc/initramfs.mounts" is actually being processed? *
>>> ***
>>>
>>> ** **
>>>
>>> If you are passing the “aufs” option into the init script using grub
>>> then the code to process "/etc/initramfs.mounts" is never called.****
>>>
>>> ** **
>>>
>>> It’s been a few years since I set this up but like you I use genkernel
>>> to create the initramfs (yes I’m lazy). However I replace the default
>>> genkernel init script with a slightly modified version using the
>>> ‘--linuxrc’ option. This replacement script includes my additional aufs
>>> mounts and manages a few additional functions such as performing software
>>> updates which for obvious reasons can’t take place on a fully running
>>> system. ****
>>>
>>> ** **
>>>
>>> I use the ‘loop’, ‘looptype’, ‘ramdisk’ and ‘aufs’ init options which
>>> are passed in via the grub boot manager. These options are normally used
>>> for live CD builds to overlay a small ram disc on top of the CD using aufs. In
>>> essence my change simply maps another physical partition over the top to
>>> allow for permanent data storage.****
>>>
>>> ** **
>>>
>>> Gareth.****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> *From:* Francisco Ares [mailto:frares@gmail.com]
>>> *Sent:* 18 October 2013 18:16
>>> *To:* gentoo-embedded@lists.gentoo.org
>>> *Subject:* Re: [gentoo-embedded] planning a flash DOM x86 embedded
>>> system****
>>>
>>> ** **
>>>
>>> Thanks, Gareth.****
>>>
>>> But it is very interesting that with no special customizations, I am
>>> almost able to have a fully functional system.****
>>>
>>> That new thing about having to use a initramfs when the root filesystem
>>> and the /usr directory are not present in the same physical partition, it
>>> turns out that it helps on having the "genkernel" generated initramfs do
>>> the job of mounting different arrangements for partitions, directories and
>>> unionfs mounts. That is because of the file "/etc/initramfs.mounts" where
>>> the specified mount entries, are extracted from the "/etc/fstab" and
>>> mounted before the initram gives way to the real root environment.****
>>>
>>> For instance, in this system, for now, there is the directory structure
>>> bellow:****
>>>
>>> /.var.rw - here a r/w ext4 partition is to be mounted;****
>>>
>>> /.var.ro - here there are all files and directories expected to be on
>>> a usual /var;****
>>>
>>> /var - here a unionfs mount is to join the ones above****
>>>
>>> The part from fstab for this is ("/.var.ro" is present on the squashfs
>>> root file system):****
>>>
>>> /dev/sda2 / squashfs
>>> noatime,ro 0 1
>>> /dev/sda3 /.var.rw ext4
>>> noatime,defaults 0 2
>>> none /var unionfs
>>> nonempty,cow,umask=022,dirs=/.var.rw/=rw:/.var.ro/=ro 0 0****
>>>
>>> I said it is not yet fully functional because it seems there is
>>> something wrong with permissions, because it ends up with a unknown user
>>> prompt from which I could list the root directories (something similar is
>>> being made to "/etc"):
>>>
>>> total 9,0K
>>> drwxr-xr-x 23 root root 385 Out 18 14:18 ./
>>> drwxr-xr-x 4 root root 4,0K Set 24 09:46 ../
>>> drwxr-xr-x 47 root root 2,6K Out 17 16:03 .etc.ro/
>>> drwxr-xr-x 2 root root 40 Out 18 15:09 .etc.rw/
>>> drwxr-xr-x 11 root root 262 Out 17 16:03 .var.ro/
>>> drwxr-xr-x 6 root root 4,0K Out 18 14:33 .var.rw/
>>> drwxr-xr-x 2 root root 1,4K Out 7 14:46 bin/
>>> drwxr-xr-x 4 root root 1,0K Out 18 14:15 boot/
>>> d????????? 3 root root 2,3K Ago 1 00:17 dev/
>>> drwxr-xr-x 1 root root 2,6K Out 17 16:03 etc/
>>> drwxr-xr-x 3 root root 54 Ago 22 07:55 home/
>>> lrwxrwxrwx 1 root root 5 Out 7 14:05 lib -> lib64/
>>> drwxr-xr-x 12 root root 3,2K Out 17 08:51 lib64/
>>> drwxr-xr-x 2 root root 28 Ago 1 00:16 media/
>>> drwxr-xr-x 2 root root 28 Ago 1 00:16 opt/
>>> drwxr-xr-x 2 root root 3 Jul 31 22:22 proc/
>>> drwxr-xr-x 2 root root 136 Out 18 14:18 root/
>>> drwxr-xr-x 5 root root 120 Ago 30 08:59 run/
>>> drwxr-xr-x 2 root root 2,9K Out 17 08:51 sbin/
>>> drwxr-xr-x 2 root root 28 Ago 1 00:16 sys/
>>> drwxrwxrwt 2 root root 3 Out 18 14:18 tmp/
>>> drwxr-xr-x 13 root root 267 Out 17 11:18 usr/
>>> d????????? 1 root root 262 Out 17 16:03 var/****
>>>
>>> Any hints or suggestions? I will post this to the "gentoo-user" list,
>>> also, I guess it is an interesting thing that might be called a cool side
>>> effect of the recent issues.****
>>>
>>> Thanks
>>> Francisco****
>>>
>>> ** **
>>>
>>> ** **
>>>
>>> 2013/10/17 Gareth McClean <disneysw@hotmail.com>****
>>>
>>> ****
>>>
>>> I do this using a slightly modified init script, aufs3 and a squashfs.**
>>> **
>>>
>>> ****
>>>
>>> Basically the system setups a tmpfs as a RW overlay on top of the
>>> squashfs. Then for permanent storage there is a physical Ext4 partition
>>> overlaid again on top of the /home directory. ****
>>>
>>> ****
>>>
>>> Symbolic links are then used for any configuration files (such as
>>> network configuration) that require persistent storage. These links
>>> obviously reference locations within the /home directory that is stored on
>>> an Ext4 physical partition. ****
>>>
>>> ****
>>>
>>> My init script is slightly more complicated than this since it caters
>>> for both live (squash plus aufs) and development (normal disc access) modes
>>> but basically it boils down to:****
>>>
>>> ****
>>>
>>> ****
>>>
>>> mount -t aufs aufs "${NEW_ROOT}" -o dirs=/rw=rw:/ro=rr****
>>>
>>> ****
>>>
>>> # Mount RW_PERM****
>>>
>>> echo "Mounting RW"****
>>>
>>> mkdir -p /rw-perm****
>>>
>>> mount "UUID=${RW_PERM_UUID}" /rw-perm****
>>>
>>> mount -o bind /ro/home "${NEW_ROOT}/home"****
>>>
>>> mount -t aufs aufs "${NEW_ROOT}/home" -o
>>> dirs=/rw-perm=rw:/ro/home=rr****
>>>
>>> ****
>>>
>>> where ****
>>>
>>> ro = squashfs****
>>>
>>> rw = tmpfs****
>>>
>>> rw-perm = physical Ext4 partition****
>>>
>>> ****
>>>
>>> Note you need the “mount -o bind" command to allow an overlay on top of
>>> an overlay with aufs3 otherwise you will get an error message.****
>>>
>>> ****
>>>
>>> BTW, Unless you have a good reason for doing this I would not recommend
>>> doing this since you have a physical hard drive. The reason I still do this
>>> is mainly for backward compatibility. Of course it is nice to have the
>>> ability to run our system from a liveUSB stick and it minimises software
>>> download size when doing updates but debugging the init script is a very
>>> time consuming process……****
>>>
>>> ****
>>>
>>> ****
>>>
>>> ****
>>>
>>> ****
>>>
>>> *From:* Francisco Ares [mailto:frares@gmail.com]
>>> *Sent:* 16 October 2013 13:49
>>> *To:* gentoo-embedded@lists.gentoo.org
>>> *Subject:* [gentoo-embedded] planning a flash DOM x86 embedded system***
>>> *
>>>
>>> ****
>>>
>>> Hi.****
>>>
>>> I am planning to build a system to be deployed in a SATA flash disk, and
>>> most of the file system will be read-only. There will be a tempfs on /temp
>>> and a read-write partition for /var (perhaps a unionfs with the static part
>>> of /var and that read-write partition)****
>>>
>>> Is there any resources on how to do this using Gentoo?****
>>>
>>> There is already a development system with everything working as
>>> expected on the final system. But when I put it to a squashfs, the system
>>> boots with several errors, like when trying to write to /etc and /var.**
>>> **
>>>
>>> Looking on the new issue regarding /usr and / being on a different
>>> partitions, I have found the file in /etc/initramfs.mounts. I have added
>>> the needed fstab entries to be mounted before the system switches to the
>>> real-root, (as the comments on top of this file claims) but there are
>>> still errors during boot.****
>>>
>>> ****
>>>
>>> Thanks
>>> Francisco****
>>>
>>> ** **
>>>
>>
>>
>
Re: SOLVED planning a flash DOM x86 embedded system [ In reply to ]
On 10/24/13 12:41, Francisco Ares wrote:

> It works now!
> It seems that blog shows an old style syntax. Found others, though,
> like the following:
>
> http://www.viraj.org/b2evolution/blogs/index.php/2007/05/03/ubuntu_server_and_unionfs

>
> but for nowadays Gentoo systems (at least) the correct syntax is like
> the following (which works for me):
>
> /dev/sda3 /.var.rw <http://var.rw> ext4
> noatime,defaults 0 2
> union /var unionfs
> default_permissions,allow_other,use_ino,nonempty,suid,cow,dirs=/.var.rw
> <http://var.rw>=rw:/.var.ro <http://var.ro>=ro 0 0
> tmpfs /.etc.rw <http://etc.rw> tmpfs
> defaults,mode=755 0 0
> union /etc unionfs
> default_permissions,allow_other,use_ino,nonempty,suid,cow,dirs=/.etc.rw
> <http://etc.rw>=rw:/.etc.ro <http://etc.ro>=ro 0 0
>
> Directories /.var.ro <http://var.ro> and /.etc.ro <http://etc.ro>
> are already present on the root file system.
> It seems that this was the problem from the beginning, not been able to
> correctly mount those partitions at the proper and usual time.

This brings up a related issue, I filed a bug about [1].

Documenting how to use UUIDs in the installation handbook. I kept the
bug generic, but I had Arm architectures in mine all along. With the
porting of Grub2 to Arm (Linaro) is seems that soon there will be a
myriad of file systems to run on the newer Arm systems [2] [3]. I
struggle on how to write up the bug, so feel encourage to think about
ways to simply or unify the installation handbooks, related to grub2,
supporting a variety of new file systems, particularly related to arm.
The existing arm handbook [4] is woefully out of date. Granted, the
gentoo-embedded handbook [5] is great, it does not address gentoo-distro
installation on the newer arm (64 bit)chips, akin to the x86 offerings.

So folks are resorting to all sorts of extraneous documentation [6]

Filing bugs (new or edit mine) to make the docs better, enhances
Gentoo's appeal, imho.

James


[1] https://bugs.gentoo.org/show_bug.cgi?id=483654

[2]
http://www.arm.com/products/processors/instruction-set-architectures/armv8-r-architecture.php

[3]
http://www.arm.com/products/processors/instruction-set-architectures/armv8-architecture.php

[4] http://www.gentoo.org/doc/en/handbook/handbook-arm.xml

[5] http://www.gentoo.org/proj/en/base/embedded/handbook/

[6]
http://www.chromebook-linux.com/2011/11/gentoo-is-ready-for-chromebook.html