Ethan,
In general I agree. My only concern is that if we don't integrate
something now zones install with automatic user configuration will
remain broken for another build, as I won't be able to get a fix
together in time for the b18 integration deadline of next Monday June 4th.
Another bug could be logged to address the "proper" fix ,and it would
involve fixing DC and Filesystem, and also could remove the fix for this
bug as it stands if it were to be integrated.
cheers
Matt
On 05/31/12 09:28, Ethan Quach wrote:
Hey Matt,
On 05/24/12 04:09, Matt Keenan wrote:
Hi,
Can I get a pair of eyes on a fix for bug :
Bug;
7171068 booting zones with non-root users in SC config profiles leads
to svc:/filesystem/local in mainteance
http://monaco.us.oracle.com/detail.jsf?cr=7171068
Webrev:
https://cr.opensolaris.org/action/browse/caiman/mattman/7171068/
Bug is caused by fix for 7166325, which attempted to fix where
mountpoints even if specified in Manifest were ignored during zones
creation.
What was not realized during this fix is that Target Discovery will
in 99% of cases always set the mountpoint property of a filesystem
during discovery, regardless of whether it's specified in the
manifest or not.
I talked to Drew about this offline yesterday and at this point we
think we should really try to address this in the
Filesystem::from_xml() method so that it does not populate the
mountpoint value if it wasn't specified in the manifest, and then fix
the places in DC that might have relied on that value being always set
in a Filesystem instance.
Because of this after fix for 7166325, ALL datasets being created in
a zone were now explicit setting their mountpoint. This should not be
the case, in particular rpool/export/home needs to inherit it's
mountpoint from it's parent.
Note that while this issue here is that the mountpoint property for
rpool/export/home inadvertantly becomes a locally set property value,
which then causes the issue seen on first boot, fixing this doesn't
completely fix the entire issue. An AI manifest that actually does
have the mountpoint specified for rpool/export/home (which should
actually be legal) will run into the same symptom on first boot. That
part of the issue is because the first boot method (svc-config-user)
that creates the user account isn't robust enough to handle this
scenario. That has actually been filed as a separate bug, (7172762
<tel:7172762> svc-config-user should be more robust when unmounting
home zfs dataset).
Thanks,
-Ethan
Mountpoint setting should only happen where the mountpoint differs
from the default mountpoint as set by Target Discovery. Target
Discovery sets the mountpoint because DC needs to know this.
- Tested installing zones where users are autoconfigured.
- Also ensured bug 7166325 is fixed with this new revision.
- Ran full suite of unit tests and no regressions found.
regards
Matt
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
