Bug 249380

Proposal could of course be rewritten according to your suggestions but this
is certainly something to be decided by project management since it would
mean throwing away current posprosal code and writing new one that can fulfil
your requests. 

- currently nothing about content of partitions is known besides fs type
  Of could we could mount every block device and analyze content but I 
  an already getting complains about slow startup times now. Mounting dozens
  of potentially incosistent filesystems will certainly not make startup 
 faster
- "last mounted on" is not available for reiserfs (no idea about xfs)

Some remarks on things I can change easily:
- When switching to "format" the currently detected fs is default. Which is IMHO
  ok, but you are right that the default should be ext3 if no previous fs
  was detectd. Will fix that.
- Resetting the label when formatting is suggested by proposal code makes sense.
  Will fix that also. Generally resetting the label when formatting is IMHO
  not desirable if someone gives label names like "root", "home", "swap" he
  would probably be pissed if these are destroyed whenever he formats a 
  filesystem.

You other request would mean fundamental changes and I would only change these
if dist team backs up your suggestions and of course is willing to live with 
the considerably increased startup time in some cases.

I just tried to find a case where the partition create/edit dialog does
default to reiserfs and was unsuccessful. It should only default to reiserfs
if reiserfs is the detected filesystem on a partition (which is ok since
of there is a fs detected this should be the default also when format is set
to true).

Please apply the following patch to /usr/share/YaST2/include/partitioning/custom_part_dialogs.ycp, it activates some
more debug output of default fs selection.

BTW: 
Lagrange:~ > ls -l ~sbrabec/var_log_YaST2_utx/
ls: /suse/sbrabec/var_log_YaST2_utx/YaST2: Permission denied

Created attachment 121353 [details]
activate more debug output

To comment #2: This is my case.

I expected ext3 as unconditional default in the expert partitioner, too. Previous system was SuSE Linux 10.0 on reiserfs, which was scheduled to be overwritten. Now I expected ext3 as default for /.

ext3 is only default for three cases:
- when a partition is formatted in a proposal
- when a new partition/LV/MD is created
- when a partition/LV/MD is edited and no filesystem is detected.

Since there are valid reasons to deviate from the default filesystem I do not 
consider it useful to always change the filesystem to ext3 whenever the user
activates format. It worked this way since yast2 partitioner exists and so far
nobody complained.

Meanwhile I changed proposal code to automatically remove labels.
Your other suggestions would mean fundmental changes to current proposal 
functionality and I will only implement such things if dist team approves it.

It was only one part of the bug. Remaining issues:

Trying to install openSUSE 10.2 on my home machine, it offered to format /home partition, which was already ext3 formatted.

This suggestion is invalid on almost 100% of cases - most people with separate
/home want to save its contents after installation.

Logs placed to: ~sbrabec/var_log_YaST2_utx

Proposals to improve:

If /home (and maybe some others) partitions already caries linux-friendly filesystem (ext*, xfs, reiser*), never offer formatting.

While formatting partitions to file system, which supports it, fill "Last
mounted on" entry to properly identify disc structure on next installation.

If more version of SuSE Linux is found in several partitions, the oldest one
should be scheduled to be overwritten.

The bug was resolved as WONTFIX.
Reasons were explianed in my comments.

*** Bug 277582 has been marked as a duplicate of this bug. ***

*** Bug 298861 has been marked as a duplicate of this bug. ***

I still don't see why this is marked as WONTFIX. Proposing to format /home is wrong 99% of the time. That the whole reason of having /home as a separate partition.

I find it outrageous that this serious bug has been declared a 'wontfix'.

I agree. I generally don't want my /home formatted on reinstall.

When the proposal exactly matches the current layout why would you ever want to format /home?  This is something I have to change every time I do an install and in the worst case it would cause complete loss of data for the user.  WONTFIX doesn't make sense to me either.

I had filed this as bug #58733 for NLD9, and got shot down as well.

This is a horrible bug.  Why would you *ever* want to make "format my home" the default?

Reopening.

Since 10.3 development is over now, I will implement code in STABLE (while will
become next openSuSE/SLES release) that look at the fs intended to be used
for /home and suppresses formatting if heuristics indicate it is a valid /home
filesystem. 

I still consider this a bogus feature since it involves mounting a potetially
large filesystem with unknown content and state. If the filesystem happens to
be dirty, the log replay alone may take minutes and there is no save way to
prevent these minutes to be wasted, but in the end it is probably
less time consuming to implement that stuff than to discuss this forever.

Maybe it would be nice to set and use e2fs last-mounted-directory entry to simplify guesses during upgrade:

tune2fs -M /home /dev/hda5

Thank you. I am quite confident that you talented people will manage.
After all, other Linuxes manage, too, (plus importing previous
user-profiles from a pre-existing /home on the fly) without endless waiting-periods.

All distribution use the same filesystem types and more or less the same kernel.
So if a log reply happens during mount the waiting periods are exactly the same 
for all distributions. I would not bother if the added delay would happen during
installations where some minutes more do not matter much, but the (potential)
delay will be added to proposal generation which I consider should be fast.

Ad comment#18:
We are talking about "New Installation", not Update path here.
For update we of course read /etc/fstab and can act accordingly.
For "New installation" there is no such code (and I generally want to rely as
less as possible on any data of the system being valid) since it is expected
for users that want the same disk layout anyway and avoid loss of data to use
"Update" instead of "New Installation".

So, looking at output of tune2fs will be part of the heuristics but AFAIK
there is no equivalent functionality for reiserfs and xfs and actually mounting
the fs cannot be avoided for these. 

(In reply to comment #16 from Thomas Fehr)
> Since 10.3 development is over now, I will implement code in STABLE (while will
> become next openSuSE/SLES release) that look at the fs intended to be used
> for /home and suppresses formatting if heuristics indicate it is a valid /home
> filesystem. 
> 
> I still consider this a bogus feature since it involves mounting a potetially
> large filesystem with unknown content and state. If the filesystem happens to
> be dirty, the log replay alone may take minutes and there is no save way to
> prevent these minutes to be wasted, but in the end it is probably
> less time consuming to implement that stuff than to discuss this forever.
> 

I suggest then making a pop-up dialog when this occurs and let the operator make the decision.   There are already many delays in the installation but one the operator is willing to make is one that saves time in the long run and reconstruction of data structures inadvertently erased or formatted takes longer than remounting a dirty partition and by asking you have alerted the operator and if there is a delay, he also now knows the reason.  If they don't want to save the existing data/structure, proceed as you currently propose to do.

It is not trivial do decide how long a log reply will take without 
actually mounting the filesystem (there may be ways, but they would certainly
be fs specific).

Having a popup with necessary user interaction for during computed disk proposal 
is not desired. So far there is a rule that the first proposal must not do any 
user interactions. 

Thanks for working on this, Thomas!  Every time I do an install I get a cold sweat when I see that my /home may go away :)

As I tried to explain, you should consider selecting the "Update" path instead
of "New Installation". It is simply wrong to use "New installation" and hope that
the generated proposal will exactly match your expectations (the expectation
if the next user might be quite different). If I could write software that is 
able to read the thoughts of the user I would most probably write a online 
poker game, seems much more profitable.

Even after my changes there will be no guarantees whatsoever that the partition 
with /home on it is not select to be removed (this will for example happen when 
project managements decides that a new installation of a new product should be
installed with more space for root filesystem or swap or whatever else might
come up as requirements for new products).

It is quite convenient to do a "safe upgrade" as a new installation to the dedicated partition and keeping the old SuSE instance as the default until all tests and customizations of the new one are complete.

There are already YaST modules for searching the best-fit old instance to read old ssh keys, old /etc/hosts.

It would be very nice, if it would be able to read /etc/fstab as well. I know, that is is not so simple as it sounds, because device might have a different name, one must guess which OS instance is the oldest. (It will also require NFS client configuration behavior change.)


Here are few ideas to improve user experience:


1) Ask user, what should be removed:

If partitioning scheme conforms OpenSUSE needs, then maybe a following question would be good:

There is no free or empty partition nor reserved space on your system. Please choose what to do:
(selected) Overwrite partition with label "SuSE Linux 10.0"
Overwrite partition with SuSE Linux 10.1
Overwrite partition with OpenSUSE 10.2
Overwrite partition with label "Home"
Overwrite partition with label "Swap"

If it does not conform, suggest possible ways to solve:

Your disc partitioning does not conform OpenSUSE 11.0 needs:
- No system partition has enough size
- Swap recommended for your RAM size is too small
...
Please choose what to do:
Backup the whole disc and repartition from scratch
Format previous "Home" as / (Home Warning)
Format previous "SuSE_Linux_10.1" as swap

Implementing this calls back a comment from the previous discussion: Resetting the label when formatting to a really descriptive one (e. g. "OpenSUSE_11.0" for /, "OpenSUSE_11.0_usr" for /usr, "OpenSUSE_11.0_var" for /var, "Swap" for swap, "Home" for /home etc.)


2) Home Warning

A special home warning for formatting of partitions with non empty /home directory and partitions with "Home" string in the name (optionally translated, depends on future default names proposal):

It seems that you are overwriting non-empty home directory! Please confirm deleting of these user data.


3) Safe delete

There is a chance for a "safe formatting" as an addition to Format/Not format: long fsck and rm -rf of everything except selected directories (e. g. /home).

Of course it is already implemented to make expert partitioner search for fstab
on every block device, look into all the read fstab layouts, present them to the
user and select one to be used for an installation. Maybe you should at least have
a short look into what already exits before you demand to throw it away.
Doing this when the user demands it is fine, doing this automatically and unavoidably whenever a proposal is computed is certainly time consuming and
potentially dangerous. The existence of a valid filesystem signature is clearly 
no enough to guarantee a successful mount, I have seen kernel oops when trying
to mount inconsistent filesystem, so I do not want such this to happen in 
default path.
 
Clearly this demands much more than I will implement and it clearly violates
the rules that currently exits for the proposal. Currently there is no user 
interaction during creation of initial proposal allowed. Additionally I do not 
want to mount every block device in the system to determine possible additional
installs during new installation, this may create an acceptable delay on tiny
systems with only a few partitions. As soon as you let this run on a server
with dozens or even hundreds of block devices it will be much too slow.

The idea about using labels for filesystems by default makes much sense and 
could be implemented relatively easy (your naming scheme exceeds max label 
length which is 16 for reiser and ext2/3 and 12 for xfs but this could easily 
be avoided) but this is clearly also something to be decided about by project 
management (since it for example creates non-uniquely labeled filesystems as
soon as you have more than one installation of the same distribution or more
than one swap, curerntly udev is not handling such duplicate label names very
well). 

Please create a feature request and let project management decide about its
implementation. It does not make sense to waste man months because of a 
bugzilla report as long as it is completely unknown what the management wants.

Agreed with that. I think that the root of the problem is twofold: Firstly, the 'upgrade'-option seems to have 'bad reputation' though I don't know whether this is at all based on actual problems; I haven't searched bugzilla for it. So many people prefer a 'clean' install that only keeps /home intact. Now that creating a partition for /home is suggested by default, the logical step is to leave it alone. 'Clean' install doesn't mean the same as before. Perhaps we should look at the 'upgrade'-option, too and see what, if anything, is wrong with it.

As it seems there is indeed reason that users prefer 'new install' over the 'upgrade'-option. I have read several reports now of serious dependency-resolution-problems with 10.2 --> 10.3 upgrades. For example this one: http://education.zdnet.com/?p=1255

These sorts of reports are really meant to scare people away from openSUSE.

If no-one else does I WILL file a feature-request to abolish the current 'upgrade'-option and replace it with an option for a clean install that only leaves the 'home'-partition intact.

Done: Bug #331939

This probably won't get fixed for 10.2; moving to 10.3.

I now added code that checks if the filesystem that the proposal selected
for /home already contains a valid home filesystem. If this is the case the
partition used for /home is not formatted any more. 
This change will be available in with 11.0 Alpha1.

Thanks a bunch, Thomas :)  I'm eagerly awaiting the Alpha1 ISOs to install them on my box.