1 |
Hi, |
2 |
|
3 |
First of all thanks for this valuable mailing list. It pushed us (some |
4 |
colleagues and me) to select gentoo as the target distribution of choice |
5 |
for a set of PC104 embedded systems we use. So far the passive reading |
6 |
and the embedded gentoo handbook leaded to a bootable pc104 system with |
7 |
gentoo on it. Nevertheless my passive reading could not solve some open |
8 |
questions. I collected some ideas and would like to share them here. May |
9 |
be someone can give me a hint or point me to a/some solution(s). I will |
10 |
start with a sketch of the current set up of our embedded environment. |
11 |
|
12 |
The target device is a PC104 with an x86 architecture (a via eden C3 [to |
13 |
be more precise]). The compiling and development machine is a virtual |
14 |
box image with gentoo. This virtual host is also an x86 architecture so |
15 |
that real cross compiling is not necessary. The development host is |
16 |
relying on a virtual machine to allow a deployment of the images across |
17 |
different os host systems (linux, os x ...). So far the installation |
18 |
worked well and the target system is booting without any errors. The |
19 |
installation was quite straight forward. The target disk was attached to |
20 |
the devel pc (with the virtual host) using an IDE2USB adapter. The disk |
21 |
was mounted there to a custom directory /media/target. Through using the |
22 |
portage variables ROOT and PORTAGE_CONFIG set to /media/target it was |
23 |
possible to emerge all base and custom packages to the target hd. Here |
24 |
the (cross) emerge command I used to install the different packages : |
25 |
|
26 |
|
27 |
ROOT=/media/target PORTAGET_CONFIGROOT emerge --ask .. |
28 |
|
29 |
By the way the portage (emerge) related configuration files (like |
30 |
make.conf, make.profiles ....) where adjusted on the target device to |
31 |
fit the needs of the PC104 system. |
32 |
|
33 |
|
34 |
As conclusion it can be noted that this approach worked well, if the |
35 |
target disk is mounted and attached localy to the development gentoo |
36 |
system (the virtual machine). The emerge process and chroot operations |
37 |
worked as presumed. But now. The idea was to mount the target disk from |
38 |
the running target platform (PC104) into the virtual environment. The |
39 |
mount process of choice was in my first try the user space filesystem |
40 |
sshfs. Of course the target device was mounted as root to have |
41 |
sufficient rights. Similar to the above described set up the target disk |
42 |
was mounted to the directory /media/target. But contrary to the local |
43 |
mounting facility (USB2IDE), emerge fails on the filesystem which was |
44 |
mounted from a remote running system. The failure message I get is the |
45 |
following: |
46 |
|
47 |
* checking 14 files for package collisions |
48 |
>>> Merging dev-libs/eventlog-0.2.5 to /media/target/ |
49 |
Traceback (most recent call last): |
50 |
File "/usr/bin/emerge", line 6971, in ? |
51 |
retval = emerge_main() |
52 |
File "/usr/bin/emerge", line 6965, in emerge_main |
53 |
myopts, myaction, myfiles, spinner) |
54 |
File "/usr/bin/emerge", line 6395, in action_build |
55 |
retval = mergetask.merge(pkglist, favorites, mtimedb) |
56 |
File "/usr/bin/emerge", line 3981, in merge |
57 |
return self._merge(mylist, favorites, mtimedb) |
58 |
File "/usr/bin/emerge", line 4259, in _merge |
59 |
prev_mtimes=ldpath_mtimes) |
60 |
File "/usr/lib/portage/pym/portage.py", line 4818, in doebuild |
61 |
vartree=vartree, prev_mtimes=prev_mtimes) |
62 |
File "/usr/lib/portage/pym/portage.py", line 5013, in merge |
63 |
mydbapi=mydbapi, prev_mtimes=prev_mtimes) |
64 |
File "/usr/lib/portage/pym/portage.py", line 9486, in merge |
65 |
mydbapi=mydbapi, prev_mtimes=prev_mtimes) |
66 |
File "/usr/lib/portage/pym/portage.py", line 9494, in _merge |
67 |
cleanup=cleanup, mydbapi=mydbapi, prev_mtimes=prev_mtimes) |
68 |
File "/usr/lib/portage/pym/portage.py", line 9032, in treewalk |
69 |
counter = self.vartree.dbapi.counter_tick(self.myroot, |
70 |
mycpv=self.mycpv) |
71 |
File "/usr/lib/portage/pym/portage.py", line 6555, in counter_tick |
72 |
return self.counter_tick_core(myroot,incrementing=1,mycpv=mycpv) |
73 |
File "/usr/lib/portage/pym/portage.py", line 6631, in |
74 |
counter_tick_core |
75 |
write_atomic(self._counter_path, str(counter)) |
76 |
File "/usr/lib/portage/pym/portage_util.py", line 840, in write_atomic |
77 |
raise OperationNotPermitted(func_call) |
78 |
portage_exception.OperationNotPermitted: |
79 |
write_atomic('/media/target/var/cache/edb/counter') |
80 |
|
81 |
I presume that the failure is due to this write_atomic operation (call). |
82 |
With this in mind I collected some reflections and I would be glad if |
83 |
they could be commented. |
84 |
|
85 |
The mounted remote device can not be accessed in an exclusive way. I |
86 |
presume that this is due to the fact that the target system is running |
87 |
and the target OS will not allow this exclusive usage. This raises two |
88 |
questions. |
89 |
|
90 |
1 - Is this due to the userspace filesystem (I think that this is quite |
91 |
sure, otherwise a simple remote call could block the remote host.) |
92 |
|
93 |
2 - Is there a filesystem or service to mount a filesystem an remotely |
94 |
allow atomic operations on the filesystem. The only filesystem I know to |
95 |
allow locking a remote file is NFS. Even if this somehow not an atomic |
96 |
operation but at least it can lock a file for a defined process. Even if |
97 |
this process is running on a remote machine. (I am not sure about this, |
98 |
but this is some info which I have in an unstructured way in my brain) |
99 |
|
100 |
3 - Should I take a look at the write operation and may be include an |
101 |
option to replace the atomic operation? |
102 |
|
103 |
|
104 |
Any glue? |
105 |
|
106 |
|
107 |
I will continue to dig for a solution. If I find one it will be posted |
108 |
here if there is any interest on this topic. |
109 |
|
110 |
by |
111 |
|
112 |
Marc |
113 |
|
114 |
########################################### |
115 |
|
116 |
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange. |
117 |
For more information, connect to http://www.f-secure.com/ |
118 |
-- |
119 |
gentoo-embedded@l.g.o mailing list |