[lug] The issues of separate /home partitions, or maybe just freedesktop/SuSE problems?
Michael J. Hammel
mjhammel at graphics-muse.org
Fri Mar 20 09:07:23 MDT 2009
On Thu, 2009-03-19 at 15:28 -0600, Chris Riddoch wrote:
> I once heard the advice of using separate partitions for /home in
> order to ease upgrades - the / partition can be wiped and reinstalled
> from scratch, and the personal data on /home is unaffected by a fresh
> install. It seemed like a great idea. I'm wondering, though, if this
> might be responsible for some really broken behavior.
FYI: see http://www.graphics-muse.org/wp/?p=326, The Everyday Guide to
Fedora Upgrades (at least from my point of view).
> The potential disadvantage of using a separate /home partition this
> way is that the newer software installed is expected to appropriately
> handle the presence of older configuration files, either by upgrading
> them automatically or erroring out noisily when there's a problem.
There is a trade off here. If you don't use a /home partition and use a
new install to place the new user-specific config files then you have to
copy out your user data from /home before the upgrade and copy it back
in after the upgrade. I find it easier to deal with the changed config
files than copying 100'sG of data. If you don't have much under /home
then /home on the root partition might be okay. I don't think most
users will want to muck with moving all their data around for each
> It'd be ideal if the software, on detecting unusably old config files,
> would at least suggest that certain files/directories be removed so
> that a fresh, default configuration can be created, as it would be on
> a new install when the program is run for the first time. Alas, it's
> evidently too much to expect from our desktop environments.
That's just bad programming. Changing the format of config files should
require the application to deal with previous versions. And technically
that isn't the desktop environment's fault (GNOME, KDE). It's the
> It seems that some freedesktop.org stuff doesn't handle this
> gracefully. The main application hierarchy menus have been behaving
> very unpredictably - the system upgraded from 11.0 decided not to show
> the 'games' menu at all following the installation of a game. The
> other, previously 10.1-based, lost most menu items altogether. Many
> applications still aren't being presented in the menus on either
> system. Other menu items are multiplying at random.
GNOME or KDE? I use GNOME and haven't lost any menus on upgrades and I
don't spend much time - in fact, no time at all - cleaning up the config
file directories after each upgrade. Some menu items disappear but
that's usually a sign that I haven't installed the related application
yet. Once I install it I get the menu item back, though I have seen
duplicate menu items in cases like that. I just right click and delete
the extra entry.
> Relatedly, the file-type associations for opening things from file
> managers, be it nautilus, konqueror, or dolphin, are frequently
> broken, and unfixable with the 'use this program for this file type'
> option, as many programs we'd want to use aren't in the menus, or are
> with incorrect paths. For example: /usr/X11R6/bin/OOo-writer doesn't
> exist on modern SuSE. It's /usr/bin/owriter now, but you wouldn't
> know it from the menus. Everything relating to menus in /etc was
> deleted and recreated by the installs.
It's been in /usr/bin for sometime now. Maybe SuSE is behind the curve?
More importantly, applications installed with RPMs should be in
directories that are in the normal search path so the use of fully
qualified paths in the menus seems weird. Fedora/GNOME doesn't use
fully qualified paths unless I put them there.
I don't use the file managers much so can't speak on the problems you
mention here, other than to say the few times I do use them they seem to
work fine. I mostly just use them to access files (without respect to
file type) that have spaces in the filenames.
> Separate /home partitions may also be related to another issue: both
> systems are having is problems shutting down properly. First, when
> the shutdown splash screen is about to be displayed, the video is
> corrupted - usually displaying something that had previously been on
> the screen, in wild distortions, on both systems, with completely
> different video hardware.
Despite being different hardware, the problem is the same. The switch
from X video to console video is getting mucked up. I doubt this has
much to do with the /home partition. It's a driver issue, and I would
guess it's a console driver issue since it happens with different X
drivers. I seem to remember this issue from quite some time back with
the console driver. I thought it had been fixed long ago, though.
> With some googling, I found references to other people with similar
> shutdown problems, who *also* have separated /home partitions from /,
> and the problems have been attributed to jexec and JRE, or
> beagle, (both of which we don't have installed) or pulseaudio,
PulseAudio is a good target to apply blame when anything goes wrong.
It's not much of a stretch to blame PulseAudio for ulcer flare-ups. :-)
> or even something having to do with xsession. It sure *looks*
> rather scattershot, and separate /home partitions seem common between
> many of these cases.
No, its doubtful /home on its own partition has anything to do with
switching video modes. Anything is possible, but I'm doubting it.
Wanna test it? Create a new user with a home directory *not* on
the /home partition but rather in the root partition. The login into it
and then shutdown. The video mode switch problem should still be there
if its a driver problem. And honestly, even if it happens to not be
there, I'm still convinced this has nothing to do with a separate /home
> So: what should I blow away from our home directories, with the
> expectation that the desktop environment will start up thinking it's
> new, and just work?
.gnome, .gnome2, .kde to start. Hell, any "$HOME/.*" file. As a test,
I created a new user and looked at what files are there (this is under
Technically, you could remove all those files and the login should still
work, though it's possible that the empty directories for gnome and kde
might need to be there (haven't tried it). If those are the only files
that are there when a new user is created, everything else is
application specific and could be wiped with an upgrade. I don't do
that, but maybe it will help your situation. I keep things
like .evolution so I don't lose my old mail and .mozilla so I keep my
old browser settings, etc. In fact, I keep all the old dot-files
around. Someday I need to go clean some of those out....
Note that I'm not saying you should get rid of those. Only .gnome*
and .kde would probably need to get blown away to pick up the new
configs for the desktop. You might need to copy in their contents
from /etc/skel or whatever /etc/defaults/useradd says to use for the
skeleton setup. Interesting that I just looked at the one on F10 and it
says use /etc/skel, but there is no .kde in there. I wonder where it
> There's so many of them that I don't even know
> what half of these dotfiles/dotdirectories *are*, anymore. Mere
> deleting might not be sufficient, either - in not too-distant memory,
> gconfd would recreate files from its memory cache to defeat tinkering
> users like myself from trying to solve these kinds of problems.
gconfd would have to get these from somewhere and its unlikely it stores
such a cache in a system directory. Chances are good you could blow
away .gconf* and clear that problem.
You menu problems are related to the desktop environment and all of that
is kept under .gnome2 or .kde. Your video problems are driver related
and not related to your /home partition. It just feels like it is. :-)
Michael J. Hammel Principal Software Engineer
mjhammel at graphics-muse.org http://graphics-muse.org
Without software to do something useful with it, hardware's nothing more
than a really complicated space heater.
--- Neil Stephenson
More information about the LUG