On Apr 20, 2012, at 10:29 AM, ext tuxor1...@web.de wrote:
>> Anyway, .54 seems to run most (if not all?) postinstall steps, but I
>> get some failures to the log. I'm not sure if those are fatal or
>> not, and don't have more time for debugging today, sorry.
>
> I'm trying to sum up, what's still missing for the
> second-stage of debootstrap.
>
> ###########
>
> There are mainly two critical errors:
>
> 1. libuuid1 and other packages can't be configured because useradd and
> groupadd commands are corrupt. They report "failure while writing
> changes to /etc/passwd" and "[...] /etc/group" respectively.
>
> 2. The following problem is with "sysvinit":
> rm: cannot remove `/dev/initctl': Permission denied
>
> ###########
>
> For the first error there is an obvious workaround:
>
> echo "libuuid:*:101:" >> etc/group
> echo "libuuid:*:101:101:libuuid:/var/lib/libuuid:/bin/sh" >> etc/passwd
>
> For now it's only a workaround. In the long term we will need an
> improved behaviour of the groupadd and useradd commands.
useradd seems to work for me, I have libuuid in /etc/passwd of the
debootstrapped thing and I'm also able to run useradd manually.
How does it fail for you?
> The second error is more problematic. Looks like we need a new
> scratchbox2 mapping rule for this.
Well, I didn't have /dev/initctl in the first place, so it didn't fail for me
(I tested that debootstrapping problem on debian wheezy, where the sysvinit
installation is already compatible and the postinstall script doesn't have to
do the cleanup step, which currently isn't working for you in the "emulate"
mode).
I wouldn't create any initctl-specific mapping rules. Instead I'd like to have
a generic solution; in the long run it is clearly possible that someone invents
more postinstall scripts etc. which will try to do similar actions.
So "rm /dev/xyzzy" should at least pretend to be usable when SB2 is simulating
root privileges. There are several ways how that can be faked/simulated.
One is that SB2 could make unlink(), remove(), etc. override EPERM and return
success status when root simulation is active (e.g. SB2's geteuid()==0, but
real geteuid()!=0).
The second way would be otherwise similar, but limited to specific file system
locations. In practise that would mean that the /dev mapping rules would have
an additional flag indicating that unlink() etc shall never return EPERM from
there.
The third option would be a more comprehensive /dev simulation subsystem.
At least options one and two would be easy to implement. But I'm not yet sure
which is the right way to go, all of these solutions have pros and cons => must
think a bit more about it.
>
> ###########
>
> There is a kind of "warning", when "initscripts" tries to link /run/ to
> /var/run. I'm not entirely sure how to fix this though:
>
> guest environment detected: Linking /run to /var/run
> rmdir: failed to remove `/run': Directory not empty
> Can't symlink /run to /var/run; please fix manually.
>
> This seems to be non-critical though.
/var/run was initially redirected to a session-specific location, because we
wanted to have several parallel sessions for one target. That way it is
possible to run e.g. several dbus instances in parallel.
Now when someone has decided to replace /var/run, and the same things must go
to /run, maybe SB2 should do the same thing for /run? (i.e. to create
session-specific copy of /run, too?)
Lauri
_______________________________________________
Scratchbox-users mailing list
Scratchbox-users@lists.scratchbox.org
http://lists.scratchbox.org/cgi-bin/mailman/listinfo/scratchbox-users
