[ELDK] [RFSB] cpio fails Permission denied

[Martin Krause]

Hi Wolfgang,

Wolfgang Denk wrote on Friday, May 21, 2010 3:41 PM:
> Dear Martin,
> 
> In message
> <47F3F98010FF784EBEE6526EAAB078D10635E6F3 at tq-mailsrv.tq-net.de> you
> wrote:  
>> 
>>> i try to build a rootf with the rfsb as a normal user.
>>> Now, when i choose the httpd application or the linux-utils
>>> i get an permission denied from cpio because the files the command
>>> try to copy are owned by root.
>>> These are all files that were changed at the installation of the
>>> ELDK42 by the FIXOWNER Script cause the suid bits are set.
>>> 
>>> I can change the owner of the Files and solve this Problem. But is
>>> this the right way? ELDK_FIXOWNER changes this before with the
>>> reason which is described in the DULG.
>> 
>> I experienced the same problem with the
>> crosstool-targetcomponents-armVFP_trg-0.43-3 package. And I'm also
>> wondering what will be the best way to solve this (I suppose there
>> are many other packages which are concerned by this).
> 
> Well, the problem is simple and straightforward: ELDK_FIXOWNER sets
> ownerships and permissions as needed to export the ELDK installation
> as root file system over NFS.  This includes making some files owned
> by root and set with permissions that prevent reading them as an
> ordinary user.
> 
> So when you want to read these files there are exactly two options:
> 
> 1) Do not run the commands that need to read these files as ordinary
>    user; this would mean to run the "make" or at least thge "cpio"
>    with root permissions (say, under control of "sudo").
> 
>    If you ask for my opinion: I do not consider this a good idea.
> 
> 2) Make sure to set ownership and permissions of these files such that
>    they can be read by you; this would mean that they are not suitable
>    any more for exporting as a root file system, i. e. you need _two_
>    installations of the ELDK: one for use as a root file system (here
>    you need to run the ELDK_MAKEDEV and ELDK_FIXOWNER scripts), and
>    another one as base for building file system images (here you do
>    not need to and actually must not run these scripts).
> 
> Agreed, such a duplicated installation is not really elegant, but disk
> space is cheap these days, and having a separate, clearly controlled
> environment for software production purpores clearly has some benefits
> as well.
> 
> My recommendation is to go with b).

I tried b) and it works very well! 

However, I had to create the "dev" directory in the ELDK target root 
file system directory manually (in my case 
./eldk4.2_arm_rfsb/armVFP/dev). Otherwise Linux does not recognise 
the created squashfs root file system during boot-up. 

Without the "dev" directory I got the following error message:
...
[    2.580000] No filesystem could mount root, tried:  squashfs
[    2.590000] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(31,5)
...

With an image created with the (empty) "dev" directory in the ELDK 
target root file system everything works fine:

...
[   2.560000] VFS: Mounted root (squashfs filesystem) readonly on device 31:5.
...

Normally the "dev" directory is implizitely created by the 
ELDK_MAKEDEV script, when it creates the device nodes. When this
script is not called, then the directory has to be created manually,
it seems (at least for squasfs root file system images).

Side node:

I tried to mount the none-booting squasfs file system (which was
created without the "dev" directory) on the target after I bootet
via NFS. This works without problems, and also the /dev directory 
does exist and contains all device nodes (as specified in the 
rootfs_devices.tab file). I also mounted the "good" squashfs image
and did a file based diff of both file systems. There where no 
differences (except for the file /etc/build-date).

Thanks for the tip!

Regards,
Martin