(cross) emerge to a remote fileystem
Hi,
First of all thanks for this valuable mailing list. It pushed us (some
colleagues and me) to select gentoo as the target distribution of choice
for a set of PC104 embedded systems we use. So far the passive reading
and the embedded gentoo handbook leaded to a bootable pc104 system with
gentoo on it. Nevertheless my passive reading could not solve some open
questions. I collected some ideas and would like to share them here. May
be someone can give me a hint or point me to a/some solution(s). I will
start with a sketch of the current set up of our embedded environment.
The target device is a PC104 with an x86 architecture (a via eden C3 [to
be more precise]). The compiling and development machine is a virtual
box image with gentoo. This virtual host is also an x86 architecture so
that real cross compiling is not necessary. The development host is
relying on a virtual machine to allow a deployment of the images across
different os host systems (linux, os x ...). So far the installation
worked well and the target system is booting without any errors. The
installation was quite straight forward. The target disk was attached to
the devel pc (with the virtual host) using an IDE2USB adapter. The disk
was mounted there to a custom directory /media/target. Through using the
portage variables ROOT and PORTAGE_CONFIG set to /media/target it was
possible to emerge all base and custom packages to the target hd. Here
the (cross) emerge command I used to install the different packages :
ROOT=/media/target PORTAGET_CONFIGROOT emerge --ask ..
By the way the portage (emerge) related configuration files (like
make.conf, make.profiles ....) where adjusted on the target device to
fit the needs of the PC104 system.
As conclusion it can be noted that this approach worked well, if the
target disk is mounted and attached localy to the development gentoo
system (the virtual machine). The emerge process and chroot operations
worked as presumed. But now. The idea was to mount the target disk from
the running target platform (PC104) into the virtual environment. The
mount process of choice was in my first try the user space filesystem
sshfs. Of course the target device was mounted as root to have
sufficient rights. Similar to the above described set up the target disk
was mounted to the directory /media/target. But contrary to the local
mounting facility (USB2IDE), emerge fails on the filesystem which was
mounted from a remote running system. The failure message I get is the
following:
* checking 14 files for package collisions
>>> Merging dev-libs/eventlog-0.2.5 to /media/target/
Traceback (most recent call last):
File "/usr/bin/emerge", line 6971, in ?
retval = emerge_main()
File "/usr/bin/emerge", line 6965, in emerge_main
myopts, myaction, myfiles, spinner)
File "/usr/bin/emerge", line 6395, in action_build
retval = mergetask.merge(pkglist, favorites, mtimedb)
File "/usr/bin/emerge", line 3981, in merge
return self._merge(mylist, favorites, mtimedb)
File "/usr/bin/emerge", line 4259, in _merge
prev_mtimes=ldpath_mtimes)
File "/usr/lib/portage/pym/portage.py", line 4818, in doebuild
vartree=vartree, prev_mtimes=prev_mtimes)
File "/usr/lib/portage/pym/portage.py", line 5013, in merge
mydbapi=mydbapi, prev_mtimes=prev_mtimes)
File "/usr/lib/portage/pym/portage.py", line 9486, in merge
mydbapi=mydbapi, prev_mtimes=prev_mtimes)
File "/usr/lib/portage/pym/portage.py", line 9494, in _merge
cleanup=cleanup, mydbapi=mydbapi, prev_mtimes=prev_mtimes)
File "/usr/lib/portage/pym/portage.py", line 9032, in treewalk
counter = self.vartree.dbapi.counter_tick(self.myroot,
mycpv=self.mycpv)
File "/usr/lib/portage/pym/portage.py", line 6555, in counter_tick
return self.counter_tick_core(myroot,incrementing=1,mycpv=mycpv)
File "/usr/lib/portage/pym/portage.py", line 6631, in
counter_tick_core
write_atomic(self._counter_path, str(counter))
File "/usr/lib/portage/pym/portage_util.py", line 840, in write_atomic
raise OperationNotPermitted(func_call)
portage_exception.OperationNotPermitted:
write_atomic('/media/target/var/cache/edb/counter')
I presume that the failure is due to this write_atomic operation (call).
With this in mind I collected some reflections and I would be glad if
they could be commented.
The mounted remote device can not be accessed in an exclusive way. I
presume that this is due to the fact that the target system is running
and the target OS will not allow this exclusive usage. This raises two
questions.
1 - Is this due to the userspace filesystem (I think that this is quite
sure, otherwise a simple remote call could block the remote host.)
2 - Is there a filesystem or service to mount a filesystem an remotely
allow atomic operations on the filesystem. The only filesystem I know to
allow locking a remote file is NFS. Even if this somehow not an atomic
operation but at least it can lock a file for a defined process. Even if
this process is running on a remote machine. (I am not sure about this,
but this is some info which I have in an unstructured way in my brain)
3 - Should I take a look at the write operation and may be include an
option to replace the atomic operation?
Any glue?
I will continue to dig for a solution. If I find one it will be posted
here if there is any interest on this topic.
by
Marc
###########################################
This message has been scanned by F-Secure Anti-Virus for Microsoft Exchange.
For more information, connect to http://www.f-secure.com/
RSS Feed