Bug 5990 - Installing Mageia 1 to Mageia 2, Firefox settings got lost
Summary: Installing Mageia 1 to Mageia 2, Firefox settings got lost
Status: RESOLVED WORKSFORME
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: x86_64 Linux
Priority: Normal normal
Target Milestone: ---
Assignee: Mageia Bug Squad
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on: 6022
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-20 06:46 CEST by Jehan Hysseo
Modified: 2013-08-06 22:03 CEST (History)
4 users (show)

See Also:
Source RPM:
CVE:
Status comment:


Attachments

Description Jehan Hysseo 2012-05-20 06:46:32 CEST
Description of problem
======================

Hello,

I just installed Mageia 2 RC over Mageia 1 on my mother's computer (because she had a broken system, for some reason). Obviously I kept the home folder (successfully except for the problem I'm going to describe. Her data are there after reinstall as expected).

The only problem I encountered is that KDE could not run well: it either "broke" during load, which means it blocked at load screen (no idea why) or would sometimes manage to start but without menu bar (I could still access main functions through right click on the desktop). Anyway I worked this around by renaming .kde4/ so that it would recreate a new one (probably another bug report would be worth it here too. But I understood this is quite a common issue about KDE updates).
Except from this, I did not touch Firefox settings (~/.mozilla/).

But restarting Firefox: brand new profile! Her settings of starting last tabs when exiting, all bookmarks and history, all gone. Only 2 tabs were there: new user to Firefox and Mageia.

NOTE: I saw the bug 3310 about losing various settings (Firefox included) on login screen. No idea if this is related. I made a test of going to the login screen and see if I lose again the brand new profile. Seems not. So looks different, which is why I opened a new bug report. I don't know "exactly when" has the profile actually been lost in the reinstall process.

Version-Release number of selected component
============================================

Not sure if this is a Firefox bug, a package bug, or some other part.
I have no idea what were the versions before. I can tell that now, Firefox package is: 10.0.4 revision 1.mga2 x86_64.
Mageia is RC.

How reproducible
================

I only updated this system once for now. So I have no idea if this is always happening and easily reproduced.
Note also that I did not expect this to happen and did not copy the .mozilla/ folder, nor did I save the whole home partition. I know this is not a "serious" update behavior, but I have been so used for years to reinstall distributions on my own machines without serious (= data lost like here) issue, that I did not expect to have this problem, even with a RC.

Also I'd like to be able to try again for helping in debug, but I unfortunately don't have any spare machine (not daily used) for debug purpose unfortunately.

Steps to Reproduce
==================

1. Having a Mageia 1 (stable KDE) installation.
2. Installing Mageia 2 last RC (KDE version again) over it, keeping only the home and formatting the other partitions.
3. Running Firefox and discovering bookmarks and settings are gone.
Comment 1 Manuel Hiebel 2012-05-20 10:43:36 CEST
>1. Having a Mageia 1 (stable KDE) installation.
>2. Installing Mageia 2 last RC (KDE version again) over it, keeping only the
>home and formatting the other partitions.

How have you make the part 2 ? it it's with the live that will not work since it copy all data from the iso to the harddrive / and /home so if you use the same users you can lost data.
Comment 2 Jehan Hysseo 2012-05-20 12:05:01 CEST
Hi,

I indeed used Mageia 2 RC Live (Europe 1).
I made an installation with custom partitioning and when it asks me what partitions I want to format and keep as is, I obviously kept the home as is.

Are you telling me that even when doing so, it copies/overwrites data to existing users' home directories? Because if so, that's like a huge issue, on a user point of view. User data and customization is like the most important things on a Desktop (and this way of installing a huge historical assets of GNU/Linux distributions), and deleting some of this data â especially when the user knowingly and specifically checked a box asking not to do it â is not very nice.
Comment 3 Manuel Hiebel 2012-05-20 12:07:32 CEST
>Are you telling me that even when doing so, it copies/overwrites data to
>existing users' home directories? Because if so, that's like a huge issue

I guess so if you have the same user name but I'm *really* not sure
Comment 4 Dave Hodgins 2012-05-21 20:25:47 CEST
The Live cds should not be used for upgrade.  They are
designed for clean installations only. See
https://bugs.mageia.org/show_bug.cgi?id=5687#c9

CC: (none) => davidwhodgins

Comment 5 Jehan Hysseo 2012-05-22 03:16:44 CEST
That was a clean installation then. Are you telling me we can't do clean installation while reusing existing home directories?
A new installation necessarily means we want to make only new users (and brand new homes)?

Sometimes we don't have other possibilities too. For instance I happened by the past to change computer. When I did so, I want to keep my home, with all my software configuration and my personal data. And when doing so, I may come from another kind of GNU/Linux (32 bits to 64 for instance, or even a distribution other than Mageia. This was the case for my brand new work laptop where I recently passed from a distribution derived from Ubuntu to Mageia 2 beta). I still expect in this case that my data stays intact. And in our particular case, I expect not to lose my Firefox data for instance!

In the installation described in this report, I don't know if I could have tried an upgrade (actually I did not see the option, there maybe was one), but Mageia 1 was broken (would not even start). It was my mother's computer. I see her every X weeks for only 1 day or 2. I went for the fast track (= I did not want to make an update based from a broken installation) because I want as less bad surprises as possible while I'm gone. Also I had no much time for problem analysis either.

All this to say: I understand your point, and next time I'll try the upgrade. But still there are times when one needs, or even has no choice, and will do a fresh install keeping only home data.
And when doing so, the home is considered sacred, customized, hence should stay untouched. Or if really some nice data processing can be proposed, a warning should occur, with a dialog box asking us if we want it to happen or not.

At least that's my view on upgrade/fresh install altogether.
Comment 6 andré blais 2012-05-22 11:15:39 CEST
According to your step 2, you did a clean install initially.
It shouldn't have affected the /home partition.
If you did a clean install after renaming ~.kde, this is indeed a bug.

You should be able to recover access to an older firefox profile.  (Assuming that it wasn't erased.)
(The file names may have changed since I last installed Firefox.  If so, look for something similar.)
In the ~/.mozilla/firefox/, there is a file called profiles.ini
It has the structure (my comments follow ##) :

--------
[General]
StartWithLastProfile=1   ## if =0, then given choice of profiles on start 

[Profile0]   ## there is always at least one profile
Name=default  ## the profile name could have been changed to something else.
IsRelative=1  ## indicates that "Path" is relative to ~/.mozilla/firefox
Path=xxxxxxxx.default
   ## xxxxxxxx is an alphanumeric sequence generated by firefox
   ## this is the name of the profile directory

[Profile1]   ## if a second profile
Name=somename   ## whatever it is called in the profile manager
IsRelative=1
Path=xxxxxxxx.somename

[Profile2]   ## if a third profile, etc
 ...
--------

If the previous profile hasn't been deleted, you will see more than one profile directory.
To make the previous profile accessible, just add a corresponding section to the profile.ini file.
Note that each profile "Name" MUST be unique.  That is how the profile is selected in the profile manager.  So if not, rename the profile directory before adding the name to profile.ini

Hope this helps :)

CC: (none) => andre999mga

Manuel Hiebel 2012-05-22 16:47:40 CEST

Depends on: (none) => 6022

Comment 7 Dave Hodgins 2012-05-22 21:42:27 CEST
(In reply to comment #5)
> That was a clean installation then. Are you telling me we can't do clean
> installation while reusing existing home directories?
> A new installation necessarily means we want to make only new users (and brand
> new homes)?

The problem is that the live cd installer assumes a completely clean install,
including /home.

When the install is copied to the hard drive, the directory /home/live
is created on disk, with the contents of what were in /home/live, while
running the live cd.

During the finish install, on first boot, the login for the first user is
used to rename /home/live/ to home/user, and the config files edited to
change references to /home/live to /home/user.

The config files, etc, from the /home/live have now overwritten those in
/home/user, since /home/ wasn't clean.

While it's possible to workaround this by using a different loginid for
the first user, or backing up/restoring /home/user, the live cd is not
intended to be used for anything other then a completely clean install.
Comment 8 andré blais 2012-05-23 03:17:31 CEST
If the current live CDs overwrite /home, there should be some warning to protect users.
It would be nice to have at least an option to preserve any existing accounts, if not redesigning to automatically do so.
I would say that if an existing /home is not reformatted on install, that it would be reasonable to assume that the user wished to preserve the contents of home, and thus install accordingly.
Comment 9 Jehan Hysseo 2012-05-23 03:59:28 CEST
Hey all,

not read in details all the messages. I just wanted to clarify something still: the home partition has not been fully overwritten (fortunately! This would have been terrible). When you choose the custom partitioning (not sure what is the exact naming for it during install), it keeps its contents, as expected. So if bug there is, it is not *that* bad (though it is still bad, some people save in their browser information more important than my mother saves).

So when I logged in as this user, I had all the data she had before. Simply when I ran Firefox, I noticed there was no history, no saved passwords and no bookmarks, even though my mother used this browser probably nearly daily.
As far as I see, the only information she lost was the browser profile. I don't know if it erased the .mozilla/ folder, made a new profile, kept the former one but removed information for some reason. I can't check right now unfortunately as I don't have access to this computer for maybe 2 weeks.

I would still propose a warning on the download page to tell people *not to* update a system from live for now, until some bug where data may be lost is further investigated.

This said, is there still this /home/live renamed-to-first-user process during installation, even in the case of custom partitioning?
Comment 10 Dave Hodgins 2012-05-23 04:36:17 CEST
From http://www.mageia.org/en/downloads/ ...

LiveCDs

Use LiveCDs for fresh new installs ONLY. DO NOT use those LiveCDs to upgrade from Mageia 1! Use above DVD or CD and see the upgrade guide.
Comment 11 Dave Hodgins 2012-05-23 04:40:40 CEST
(In reply to comment #9)

> This said, is there still this /home/live renamed-to-first-user process during
> installation, even in the case of custom partitioning?

With the live cds, it doesn't matter how you partition. The
installation procedure is the same.
Comment 12 Dave Hodgins 2012-05-23 04:43:05 CEST
(In reply to comment #8)
> If the current live CDs overwrite /home, there should be some warning to
> protect users.
> It would be nice to have at least an option to preserve any existing accounts,
> if not redesigning to automatically do so.
> I would say that if an existing /home is not reformatted on install, that it
> would be reasonable to assume that the user wished to preserve the contents of
> home, and thus install accordingly.

If you select the option to install from the grub menu, then there won't
be anything in /home/live to overwrite the files in the home directory of
the first user.
Comment 13 Jehan Hysseo 2012-05-23 05:57:18 CEST
I installed from the option in the Grub menu.
Comment 14 Dave Hodgins 2012-05-23 20:04:49 CEST
(In reply to comment #13)
> I installed from the option in the Grub menu.

Looking in the squash compressed distrib file in the live cd, it
does have a /home/live/.mozzila, but it is empty, so I wouldn't
expect that to cause a problem.  I've only checked the i586
gnome and kde4 Europe1-Americas final iso images.  Might be
different in other iso images, depending on the steps followed
when they were created.

I guess the only safe advice where you want to keep only /home
would be to backup it's contents, and restore after the install.
Extreme care would have to be taken, to ensure uid and gid
consistency, especially if more than one id is involved.
Comment 15 Jehan Hysseo 2012-05-24 03:14:36 CEST
Hi,

so if there is an empty .mozilla/ directory, isn't it possible that it just replaces the existing .mozilla/ with this empty directory?
If I could, I'd make a test. But I don't have spare machines. :-/
Comment 16 andré blais 2012-05-24 10:56:57 CEST
Usually when directories are created by a package, they are only created if not present.

Assuming that this is the case, please see comment 6 for reference.

The new profile would be called default, with the corresponding directory yyyyyyyy.default
The old profile also very likely be called default, with the corresponding directory xxxxxxxx.default, 
where yyyyyyyy is highly unlikely to be xxxxxxxx, both random alphanumeric strings generated automatically (by firefox in this case).

The newly created profile.ini contains only one profile [Profile0] called default, referring to the new directory yyyyyyyy.default
Even if the old directory is still there, it would not be visible.

So the workaround would be to rename one of the "default" profiles and the directory, and to add a profile [Profile1], with the appropriately adjusted Name and Path fields.
Or you could simply erase the newer profile, if you are totally sure that it contains no useful information (like added passwords or cookies or address entries), and adjust the path to the older profile.
Comment 17 Marja Van Waes 2012-05-26 13:06:53 CEST
Hi,

This bug was filed against cauldron, but we do not have cauldron at the moment.

Please report whether this bug is still valid for Mageia 2.

Thanks :)

Cheers,
marja

Keywords: (none) => NEEDINFO

Comment 18 andré blais 2012-05-26 14:38:01 CEST
The problem was related to installing live CDs, so it was applying to mga2.
The current advice is to not install live CDs over an existing installation, which was what was done.

However this could be seen as an enhancement request (for mga3 ?), to allow live CDs to be used for clean installs over an existing installation.
Or alternately, to include a warning if attempting to install a live CD.

We are awaiting info to see the extent of the problem.
Sander Lepik 2012-05-26 15:05:46 CEST

Keywords: NEEDINFO => (none)
CC: (none) => sander.lepik

Comment 19 Manuel Hiebel 2012-05-27 17:26:35 CEST
see the blocker bug 6022

Summary: Installing Mageia 1 to Mageia 2 RC, Firefox settings got lost => Installing Mageia 1 to Mageia 2, Firefox settings got lost

Comment 20 Manuel Hiebel 2013-08-06 22:03:20 CEST
not really a bug, and some other are opened to make it more userfriendly

Status: NEW => RESOLVED
Component: Release (media or process) => RPM Packages
Resolution: (none) => WORKSFORME


Note You need to log in before you can comment on or make changes to this bug.