[oi-dev] Updating Hipster and GUI log-in breakage with mounted ZFS datasets

[Jim Klimov]

18 февраля 2015 г. 7:53:49 CET, Nikola M <minikola at gmail.com> пишет:
>There is updating Hipster and GUI log-in breakage with mounted ZFS
>datasets.
>
>Updating Hipster is broken for me since before last 2014.1 update. 
>(Updating from August 2014.1 Hipster)
>I have /opt in separate dataset and it worked fine before, but when 
>updating to last 2014.1 (20141010) with pkg update -v ,  gdm and many 
>services do not start and X with it.
>Seems like some packages during update, insist in putting files inside 
>/opt exclusively on system dataset and it breaks booting rest of the OS
>
>right.
>It reports that /opt is non-empty and insists on it even if it is
>empty, 
>untill also dirs made for mounting sub-datasets are removed. After 
>booting with datasets and subdatasets mounted in /opt it sort of works 
>(boot to gdm) but it is unable to do so after regular update - that is
>a 
>bug.
>
>I tried emptying /opt and then mounting dataset to /opt (and child 
>datasets under /opt) and 20141010 booted and I was able to log in with 
>one administrator account through gdm, but logging with another account
>
>(one that I regularly used in August 2014 Hipster) completely locks 
>machine (X, VTs, everything)..
>This kind of behavior (not able to log in as one user or locking system
>
>on logging in) is what I experienced also one time before in Hipster 
>(Begining of 2014 I think) and I ended up re-making new account and 
>copying only needed data to it .
>
>My suspicion goes to the fact that at my setup, both /opt and
>/home/user 
>datasets have child datasets under it (snapshotting /opt and separate 
>snapshots for application data directories) and that is what I suspect 
>breaks both updating Hipster and locking system on logging in.
>
>Behavior with broken update (and gdm not starting and other services, 
>complaining that /opt is non-empty) is same with /hipster-2015 (I used 
>nwamadm from command line (ouch!) and pkg update to update)
>
>Conclusion is that people that are regularly updating Hipster to 
>ever-updating rolling releases and using separate datasets and 
>sub-datasets end up not being able to start system services, gdm nor X 
>and end up in CLI-only OI , not able to test new X.
>
>I suggest updating Hipster be fixed inside 2014.1 publisher first , to 
>ensure people having Hipster can update to it right, so they can move
>to 
>hipster-2015.
>If not they currently end up with largely unusable system (without 
>educated interventions), not able to follow Hipster updates anymore.  
>(And that breaks Hipster ever updating idea)
>
>
>_______________________________________________
>oi-dev mailing list
>oi-dev at openindiana.org
>http://openindiana.org/mailman/listinfo/oi-dev

Ooh, a victim for my split-root incantations! ;)
You did read my articles on advanced non-stanrard setups, incliding one on maintaining "split-root" installations - which for me means versioned (per-BE) sub-datasets under an rpool/ROOT/$BENAME rootfs dataset (an 'opt' bshould be in this category), as well as datasets shared between BEs like /var/mail or /var/crash and stored elsewhere (under rpool/SHARED for me).

There are many big and small tricks to make it work and to clone and update such BEs
--
Typos courtesy of K-9 Mail on my Samsung Android