-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

der Mouse wrote:
>>> Can you maybe mount the USB key elsewhere and see what the ownership
>>> and mode bits on the root and mount point (and everything leading to
>>> the mount point, if it's not directly under /) are?
>> It actually boots a memory disk with a file system image from the USB
>> memory stick,
> 
> So this is a kernel-with-embedded-image a la the INSTALL kernels, only
> with your stuff rather than the install stuff in the image?  (Just
> checking that I have the right picture in mind.)

   Exactly; it's a very minimal system, which is only used to boot, and
then switch over control to my cgd0 (on wd0).

>> so the real root is RAM at all times, once the kernel has been
>> loaded.
> 
> It's actually in RAM, perhaps, but it's not in RAM in the sense of
> (say) inodes being in the inode cache; stuff in a ramdisk is as
> inaccessible to everything but the ramdisk driver as stuff on a real
> disk is.

   Yes, of course. I just wanted to point out that I'm freely able to
plug my USB memory stick in some other computer and analyze it, if
needed. :)

[---]
> Me too.  I was actually thinking about this myself.  What port is this
> on?  Your PR says amd64; is that what you're using still?

   Yes.

>>>> Does login in via ssh and exiting cause the same changes? 
>>> No.
> 
> Strong clue.  I now think Thor's speculation about device node aliasing
> and the ramdisk's root's /dev is likely to be on target.  I've been
> thinking "...revoke()..." ever since I saw you say that logging *out*
> was what "fixed" things, but until Thor said that I was baffled as to
> what revoke() could be touching that would be relevant.

   Hmm.. Where (source code-wise) are chroots initialized?

>>> This kind of problem is why I've never been comfortable having init
>>> do the chroot for this sort of system configuration, FWIW.
>> Let's for a moment assume that I didn't know it was a bad idea to use
>> init.root, and let's also assume that I'm kind of stuck with it now.
>> Is there any hope of fixing it?
> 
> I would hope so; if not, we might as well get rid of init.root - if
> this sort of problem arises whenever it's used, I'd call it unusable.

   Well.. I'm actually typing this on this very machine. Sure, it feels
stable like plutonium, but it works as long as I keep logging out from
time to time. :)

   But you are right; it's seriously broken as it's currently behaving
on my system.

> Perhaps it'd be a good idea for me to push a bit harder on my
> root-on-cgd project, though, in case this turns out to be Really Hard
> to fix.

   What's the difference between what I'm doing now, and the system
you're working on?

> (It might, for example, require a complete redesign of device
> node aliasing or some such.)

   Someone should put that in the man page for sysctl's init.root. :)

- --
Kind regards,
Jan Danielsson

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (NetBSD)

iD8DBQFG8o7MuPlHKFfKXTYRCn0MAJ4/T5p1gh0MZ9wZ7hGOugWxqA8dNgCfS7i4
7qwmUXzuL1ecQaNOP+w/R98=
=dRht
-----END PGP SIGNATURE-----