https://bugzilla.novell.com/show_bug.cgi?id=249380#c25
--- Comment #25 from Thomas Fehr 2007-10-02 10:51:00 MST ---
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.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.