Bug 629311 - install allows use of preexisting root filesystem without reformat
Summary: install allows use of preexisting root filesystem without reformat
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: David Lehman
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: anaconda_trace_hash:0dc5a0f2b7967b84d...
: 525849 675574 701032 702362 730798 1047375 1072559 (view as bug list)
Depends On:
Blocks: F15Blocker, F15FinalBlocker F15Beta-accepted, F15BetaFreezeExcept
TreeView+ depends on / blocked
 
Reported: 2010-09-01 14:57 UTC by Steve Tyler
Modified: 2017-10-25 09:37 UTC (History)
20 users (show)

Fixed In Version: anaconda-15.29-1.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-04-15 18:26:46 UTC


Attachments (Terms of Use)
Attached traceback automatically from anaconda. (594.33 KB, text/plain)
2010-09-01 14:57 UTC, Steve Tyler
no flags Details
Attached traceback automatically from anaconda. (585.57 KB, text/plain)
2010-11-21 19:24 UTC, Robert N. Evans
no flags Details
Attached traceback automatically from anaconda. (318.79 KB, text/plain)
2010-12-03 17:17 UTC, Thomas Lake
no flags Details
Attached traceback automatically from anaconda. (1.04 MB, text/plain)
2010-12-08 02:03 UTC, henola55
no flags Details
Attached traceback automatically from anaconda. (270.59 KB, text/plain)
2010-12-15 21:50 UTC, kentontofte
no flags Details

Description Steve Tyler 2010-09-01 14:57:09 UTC
The following was filed automatically by anaconda:
anaconda 14.15 exception report
Traceback (most recent call first):
  File "/usr/lib/python2.7/site-packages/yum/config.py", line 1004, in _getsysver
    raise Errors.YumBaseError("Error: " + str(e))
  File "/usr/lib/python2.7/site-packages/yum/config.py", line 859, in readStartupConfig
    startupconf.releasever = _getsysver(startupconf.installroot, startupconf.distroverpkg)
  File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 277, in _getConfig
    startupconf = config.readStartupConfig(fn, root)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/yuminstall.py", line 720, in doConfigSetup
    YumSorter._getConfig(self)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/yuminstall.py", line 410, in setup
    self.doConfigSetup(root=self.anaconda.rootPath)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/yuminstall.py", line 1189, in doBackendSetup
    self.ayum.setup()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/backend.py", line 269, in doBackendSetup
    if anaconda.backend.doBackendSetup(anaconda) == DISPATCH_BACK:
  File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 212, in moveStep
    rc = stepFunc(self.anaconda)
  File "/usr/lib64/python2.7/site-packages/pyanaconda/dispatch.py", line 131, in gotoNext
    self.moveStep()
  File "/usr/lib64/python2.7/site-packages/pyanaconda/gui.py", line 1174, in nextClicked
    self.anaconda.dispatch.gotoNext()
YumBaseError: Error: rpmdb open failed

Comment 1 Steve Tyler 2010-09-01 14:57:13 UTC
Created an attachment (id=442430)
Attached traceback automatically from anaconda.

Comment 2 Steve Tyler 2010-09-01 15:22:20 UTC
This happened after restarting an F14-Alpha net install. The earlier attempt failed when anaconda/yum could not download a package (I'm still looking into that problem).

tty1 showed some error messages about the rpmdb signatures not matching (I can be more exact, if they cannot be found in the exception report.)

I *did not format* "/", so there were files left over from the previous failed install attempt. In particular, /mnt/sysimage/var/lib/rpm/ was populated.

After rebooting and mounting the install target file system:

[stephent@walnut rpm]$ ls -F /mnt/cedar_root/var/lib/rpm
Basenames     __db.004     Name            Pubkeys         Triggername
Conflictname  Dirnames     Obsoletename    Requirename
__db.001      Filedigests  Packages        Requireversion
__db.002      Group        Providename     Sha1header
__db.003      Installtid   Provideversion  Sigmd5

Comment 3 Chris Lumens 2010-09-01 15:27:35 UTC
We should definitely not allow mounting-but-not-formatting /.

Comment 4 Steve Tyler 2010-09-01 15:36:49 UTC
(In reply to comment #3)
> We should definitely not allow mounting-but-not-formatting /.

I neglected to mention that I used the custom partitioning option. When I selected my root partition, but did not check the format box, anaconda displayed a warning that gave me the option to not format anyway.

Comment 5 Brian Lane 2010-11-18 19:45:17 UTC
*** Bug 525849 has been marked as a duplicate of this bug. ***

Comment 6 Robert N. Evans 2010-11-21 19:24:55 UTC
Created attachment 461857 [details]
Attached traceback automatically from anaconda.

Comment 7 Thomas Lake 2010-12-03 17:17:15 UTC
Created attachment 464615 [details]
Attached traceback automatically from anaconda.

Comment 8 henola55 2010-12-08 02:03:37 UTC
Created attachment 467344 [details]
Attached traceback automatically from anaconda.

Comment 9 kentontofte 2010-12-15 21:50:55 UTC
Created attachment 468976 [details]
Attached traceback automatically from anaconda.

Comment 10 David Lehman 2011-03-10 18:33:02 UTC
I am committing and pushing a patch that will force all users to create a new filesystem on the root device.

If you are one of the people who wants to pass non-standard options to mkfs, your option is to add a profile to /etc/mke2fs.conf in kickstart %pre and specify your profile via the --fsprofile option available to the partition, logvol, and raid kickstart commands.

Comment 11 Adam Williamson 2011-03-11 17:31:09 UTC
Discussed at 2011-03-11 blocker review meeting. This doesn't actually hit any of our release criteria and we think that's fine, but at the same time, obviously we should fix it if we have a fix. Rejected as a blocker, accepted as NTH, please do push the fix :)

Comment 12 Adam Williamson 2011-04-18 16:15:00 UTC
this has been 'closed rawhide' but as noted above this bug was proposed and accepted as NTH for F15; you can push the fix into F15 if you think it's safe/appropriate. for the sake of tracking the process, can you add a comment whether or not this has been / will be done? thanks.

Comment 13 David Lehman 2011-04-18 19:29:44 UTC
I just pushed it to f15-branch, so it'll end up in something like anaconda-15.28-1.

Comment 14 Fedora Update System 2011-04-21 18:41:28 UTC
anaconda-15.28-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/anaconda-15.28-1.fc15

Comment 15 Fedora Update System 2011-04-26 14:41:18 UTC
anaconda-15.29-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/anaconda-15.29-1.fc15

Comment 16 Fedora Update System 2011-04-28 19:22:01 UTC
anaconda-15.29-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 17 David Lehman 2011-05-02 18:36:40 UTC
*** Bug 701032 has been marked as a duplicate of this bug. ***

Comment 18 Chris Lumens 2011-05-05 13:13:05 UTC
*** Bug 702362 has been marked as a duplicate of this bug. ***

Comment 19 Adam Williamson 2011-05-12 15:57:33 UTC
*** Bug 675574 has been marked as a duplicate of this bug. ***

Comment 20 Adam Williamson 2011-05-12 16:22:57 UTC
*** Bug 675574 has been marked as a duplicate of this bug. ***

Comment 21 Mukund Sivaraman 2011-05-26 13:40:18 UTC
(In reply to comment #3)
> We should definitely not allow mounting-but-not-formatting /.

For years, I have upgraded to new releases of Red Hat Linux and Fedora on my computers by moving stuff out of the way on the existing root filesystem and installing the new release over it. It saves me time by not having to copy data out of the root filesystem (which includes /home), and copy it back.

The fix committed for this bug has shown up in Anaconda in Fedora 15, and I can no longer do this, except in the case that I use repo=hd:/dev/<root-device> where the device is not allowed to be formatted as it's got the ISO image.

Is there no other way you could've worked around it by providing a way to move existing data out of the way? Please can you at least provide a force cmdline argument that allows it for future releases?

Comment 22 Steve Tyler 2011-05-26 14:09:12 UTC
(In reply to comment #21)
> (In reply to comment #3)
> > We should definitely not allow mounting-but-not-formatting /.
...
> ... the root filesystem (which includes /home) ...
...

Have you considered putting /home into its own partition or logical volume?

Comment 23 Mukund Sivaraman 2011-05-26 14:20:30 UTC
(In reply to comment #22)
> (In reply to comment #21)
> > (In reply to comment #3)
> > > We should definitely not allow mounting-but-not-formatting /.
> ...
> > ... the root filesystem (which includes /home) ...
> ...
> 
> Have you considered putting /home into its own partition or logical volume?

I am thinking of it today. :)

Comment 24 Mehmet Avcioglu 2011-05-26 14:31:46 UTC
Aside from /home, consider below scenario..

Boot installer (not live cd), change to shell
mount /dev/sd1 /tmp/boot
mkdir /tmp/boot/F14
mv /tmp/boot/* /tmp/boot/F14/
umount /tmp/boot
mount /dev/sda3 /tmp/root
mkdir /tmp/root/F14
mv /tmp/root/* /tmp/root/F14/
umount /tmp/root

Uncheck format, install F15, and boot. If I don't like it; 

boot rescue, mount, move, umount, boot

So above method no longer works?

Bugs marked as duplicate of this 525849 (livecd), 701032 (livecd), 702362 (low
space), 675574 (livecd) are actually not really duplicates of this and people
who opened those were not necessarily interested in this solution (myself
included). Yes this solution definitely fixes those but what is the point of
this solution I am not really sure, help people who don't know what they are
doing, who select custom partition and uncheck format? A simple "Are you sure
you know what you are doing?" pop up should have been fine..

Comment 25 David Lehman 2011-05-26 14:59:17 UTC
(In reply to comment #24)
> this solution I am not really sure, help people who don't know what they are
> doing, who select custom partition and uncheck format? A simple "Are you sure
> you know what you are doing?" pop up should have been fine..

The problem with this is that people who don't know what they're doing are often unaware of that fact.

There are a million things that people could do that may or may not be wise. We are not striving to support them all.

Comment 26 Steve Tyler 2011-05-26 15:09:59 UTC
(In reply to comment #24)
> Aside from /home, consider below scenario..
> 
> Boot installer (not live cd), change to shell
> mount /dev/sd1 /tmp/boot
> mkdir /tmp/boot/F14
> mv /tmp/boot/* /tmp/boot/F14/
> umount /tmp/boot
> mount /dev/sda3 /tmp/root
> mkdir /tmp/root/F14
> mv /tmp/root/* /tmp/root/F14/
> umount /tmp/root
> 
> Uncheck format, install F15, and boot. If I don't like it; 
> 
> boot rescue, mount, move, umount, boot
> 
> So above method no longer works?
...

IIUC, this method basically backs up the F14 installation on the target partitions themselves. Wouldn't it be just as easy (and much safer) to back them up onto some other partitions?

Comment 27 Mehmet Avcioglu 2011-05-26 15:30:34 UTC
(In reply to comment #25)
> The problem with this is that people who don't know what they're doing are
> often unaware of that fact.
> 
> There are a million things that people could do that may or may not be wise. We
> are not striving to support them all.

Yes agreed. But this solutions tries to do just that, fix one of those million things that people do, not format their root partition and keep their old /var. (who can only get there after making a number of non-default, hey expert only beware, selections) And it does that by breaking something people have been taking for granted past 14 versions. After this fix there is no way to do a fast install and keep your old data. Looking more and more like a Windows installer.:)

(In reply to comment #26)
> IIUC, this method basically backs up the F14 installation on the target
> partitions themselves. Wouldn't it be just as easy (and much safer) to back
> them up onto some other partitions?

Yes of course and the wise course of action would be to do that. But is that something the installer needs to make sure, force? We can come up with a number of different scenarios were the old method would have saved time and effort. Here is a far fetched (maybe not) one.:) Machine with 100GB of data on root partition, sitting on a remote facility with a slow data link and ip kvm. You do have backups, rsync what changed during the day at nights. You ship your shiny new F15 install DVD to there and ask a secretary to pop it in. Bugger..

Comment 28 Mukund Sivaraman 2011-05-26 15:36:15 UTC
(In reply to comment #26)
> IIUC, this method basically backs up the F14 installation on the target
> partitions themselves. Wouldn't it be just as easy (and much safer) to back
> them up onto some other partitions?

Steve, the reason I've been using this method is that it's much faster to move files than copy them to another filesystem, and apart from that I don't have such spare space on every machine to do a copy. In my current case, it's a datacenter server (in another country) which I attempted to reinstall through Anaconda's VNC facility.

Realistically the only way this requirement of cleaning up the root filesystem will not be bothersome over time is if /home is on a separate filesystem. I had not been doing that so far, because it's nice to have all available space for use everywhere in the filesystem tree. One can't expect a user to move all data on a machine every 6 months.

If the Anaconda developers agree, it'd be nice to have an option to move existing data out of the way into a randomly named directory, or a cmdline option for the old behavior (where we do the moving and Anaconda simply installs over). The rename would not take a lot of time to perform.

Comment 29 David Lehman 2011-05-26 15:55:42 UTC
It is *strongly* recommended that if you plan to upgrade or reinstall a system you do create separate devices for user data (/home) and any other non-system data you expect to want to preserve.

One of the things this change does is strongly encourage better system administration practices. We will not be adding any option to override the new behavior.

Comment 30 Steve Tyler 2011-05-26 16:27:03 UTC
Backing up Dave, here ... :-)

(In reply to comment #28)
> ... I don't have such spare space on every machine to do a copy. ...

It sounds like the servers need more resources to support pre-upgrade backups.

> ... it's nice to have all available space for
> use everywhere in the filesystem tree. ...

The logical volume manager supports resizing of logical volumes and the corresponding file systems. Other features include live snapshots and mirroring. The documentation is excellent:
1. http://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/ch-lvm.html
2. man pages

> ...

Comment 31 Mehmet Avcioglu 2011-05-26 18:45:25 UTC
I agree with most of the above comments. But the fact of the matter is this bugfix does not fix a bug, instead breaks a feature. If the point is to _force_ better system administration practices, the installer should _force_ putting /opt /var /home /usr/local in separate partitions. In my opinion the default options of the installer already _encourages_ better system administration practices. What is being discussed here is removal of an advanced option. If anything the discussion should have went towards an expert mode of some sorts, or additional warnings or along the lines of what Mukund suggested on comment #28. But amazingly (to me) went towards removal of a feature because somebody installed a new system on top of an already installed filesystem, again after making a number of incorrect decisions (select custom layout, select disks and partitions, select not to format).

(In reply to comment #29)
> It is *strongly* recommended that if you plan to upgrade or reinstall a system
> you do create separate devices for user data (/home) and any other non-system
> data you expect to want to preserve.

Realise that it is no longer a *strong* recommendation but a force majeure. 

> One of the things this change does is strongly encourage better system
> administration practices. We will not be adding any option to override the new
> behavior.

Understood. Unfortunate. Hope this doesn't make its way to RedHat installer.

I disagree wholeheartedly but respect the decisions of the maintainers and will not make further comments.

Comment 32 Steve Tyler 2011-05-26 19:03:33 UTC
The default installer partitioning could include a separate /home (on a logical volume), but then there would be the question of how much space it should be allocated vs. the other root directories ...

Comment 33 Adam Williamson 2011-05-26 19:35:26 UTC
"The default installer partitioning could include a separate /home (on a logical
volume), but then there would be the question of how much space it should be
allocated vs. the other root directories ..."

It already does, if the disk is large enough; I think the cutoff is 50GB. Above that, you get a separate /home partition by default, below it, you don't. There's a heuristic for sizing the partitions too, I forget what that is.



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 34 Steve Tyler 2011-05-26 20:50:48 UTC
(In reply to comment #33)
> "The default installer partitioning could include a separate /home (on a
> logical
> volume), but then there would be the question of how much space it should be
> allocated vs. the other root directories ..."
> 
> It already does, if the disk is large enough; I think the cutoff is 50GB. Above
> that, you get a separate /home partition by default, below it, you don't.
> There's a heuristic for sizing the partitions too, I forget what that is.

OK, thanks. My test installs are usually onto <12GB, so I never noticed that. With a mock install onto a 500GB disk, the installer creates /home, /root, and swap as LVs. Excellent.

Comment 35 Chris Lumens 2011-08-16 14:09:22 UTC
*** Bug 730798 has been marked as a duplicate of this bug. ***

Comment 36 Chris Lumens 2014-01-16 20:56:53 UTC
*** Bug 1047375 has been marked as a duplicate of this bug. ***

Comment 37 Jan Kratochvil 2014-01-17 10:16:41 UTC
Separate partitions are just a workaround of this bug.  They are not technically needed.  mkdir /old; mv /* /old/ worked for me for 20 years until new Anaconda.

Comment 38 David Lehman 2014-01-17 17:06:40 UTC
(In reply to Jan Kratochvil from comment #37)
> Separate partitions are just a workaround of this bug.  They are not
> technically needed.  mkdir /old; mv /* /old/ worked for me for 20 years
> until new Anaconda.

This is not a bug. It is intentional behavior based on real-life consequences of trying to use preexisting filesystem for the root filesystem of a new OS installation. I do not care how long you have done it. We have made a concerted effort to prevent it for many years now. We have done so for a reason. If it is too much for you to either a) make a backup or b) create one extra block device to facilitate reinstalling the OS I still cannot imagine how you would think it's reasonable to ask us to write and maintain hundreds of lines of code to try to accommodate your laziness.

Comment 39 Jan Kratochvil 2014-01-17 18:29:44 UTC
Fedora/RHEL is not the only distro out there.  IMO this way Fedora/RHEL is losing its users.  One cannot force users to anything in Free software.

Comment 40 David Lehman 2014-01-17 18:38:18 UTC
There is a difference between me not bending over backwards to accommodate every whim of every potential fedora user and me forcing anyone to do anything. Nobody has a gun to your head.

Comment 41 Adam Williamson 2014-01-17 23:08:06 UTC
Jan: http://www.islinuxaboutchoice.com/

as I've opined elsewhere, I find it a fairly useful mental approach, in fact, to conceive of the entire *function* of a Linux distribution as being 'to take choices away from the user', in other words, to 'force (anything) to the user'. That's what a distribution does: it makes a bunch of choices to provide the user with a working operating system. In fact, this is really what all software is doing. You get ultimate 'choice' at the software level by writing all your own code. From scratch. In assembly. If you do anything else, you are letting things make choices for you, in order to make your life more convenient. It's probably unlikely that every single choice that is made for you at any level by any component is precisely the choice you would have made yourself, but that's the trade-off for not having to do all the work yourself.

Comment 42 Radu Rendec 2014-01-18 16:28:51 UTC
I totally agree with Mukund (comment #28), Mehmet (comment #31) and Jan (comment #37). Leaving *all* users without a choice is not a good solution to prevent inexperienced users from doing something wrong.

Making a backup of the old rootfs or installing to a different block device (especially when you don't have it and need to move/resize partitions) is far more complicated and time consuming than just moving everything to a directory and installing to the same device without formatting it. And then, if something goes wrong and you want to revert to the old installation, you need to move data around again.

While many users are inexperienced and don't know/care about this, keep in mind that there are users out there who *do* know what they are doing.

David, I really don't understand why you have to "write and maintain hundreds of lines of code" to just bypass a certain check. You could simply provide an "advanced mode" option that just lets you use an existing filesystem for the rootfs without formatting it. You wouldn't have to do additional checks or implement sophisticated algorithms to cope with existing data. Users who choose to go this way are probably educated enough to take care of themselves.

Comment 43 Mehmet Avcioglu 2014-01-18 16:43:34 UTC
I keep getting notifications about this ticket from 2.5 years ago. Just realized that was the last time I used Fedora having commented on this ticket after the live cd method destroyed all my data without giving a glimpse of what it was doing or any verification. I think there were better ways to spend the time that was spent to change what has been working for decades but never mind.

Comment 44 Chris Lumens 2014-03-05 16:11:34 UTC
*** Bug 1072559 has been marked as a duplicate of this bug. ***

Comment 45 Joergen Thomsen 2014-03-06 21:14:46 UTC
(In reply to David Lehman from comment #38)
> 
>  accommodate your laziness.

I beg your pardon, sir. This is not a way to speak to your users.

The real world is far more complex, than any developer can imagine (being a developer myself). Artificial restrictions which may only fit into a narrow view of the world is not the right way to go. 

Actually, as I see it, the only thing to do in the current code is lifting the restriction of requiring '/' to be reformatted. 

I think that this change would help immensely on this:

diff  pyanaconda/ui/gui/spokes/custom.py custom.py
1254,1255d1253
<         elif mountpoint == "/" and device.format.exists and not reformat:
<             error = _("You must create a new filesystem on the root device.")


May I suggest implementing this in the next release ?

Comment 46 Adam Williamson 2014-03-06 21:16:37 UTC
Joergen: please read the thread. This is a design question, it is not a technical question. As the restriction is artificial, of course removing it is *technically* simple. That doesn't mean it is the right thing to do. This is not a deployment method we support or want to support, therefore we prevent it from being used.

Comment 47 Joergen Thomsen 2014-03-06 21:30:15 UTC
(In reply to Adam Williamson from comment #46)
> Joergen: please read the thread. This is a design question

To me it is a bug to be fixed.

>This is not a deployment method we support 

Ok, you know better than I, how I should make a deployment ? 
I strongly disagree.

Comment 48 David Lehman 2014-03-06 21:44:51 UTC
(In reply to Joergen Thomsen from comment #47)
> Ok, you know better than I, how I should make a deployment ? 
> I strongly disagree.

Perhaps you would like to make a (concise, focused) case for allowing reuse of an existing root filesystem beyond "because I want to."

Comment 49 Joergen Thomsen 2014-03-06 21:58:43 UTC
(In reply to Adam Williamson from comment #41)
> 'to take choices away from the user', in other words, to 'force (anything)
> to the user'. 

What is the anaconda developers precise definition of 'user' ?
It is not possible to develop without having a precise definition.

As I see it, the recent releases have been focused on simple naive users only, leaving the more experienced users out in the dark as second class users. 

Both groups of users should be supported.

The issue in this thread is only one of more issues with the anaconda limiting design decisions making recent Fedora releases a very unpleasant experience.

Comment 50 Adam Williamson 2014-03-06 22:02:28 UTC
Please leave the overblown philosophical argumentation for somewhere else. This is a bug tracking system.

Comment 51 Joergen Thomsen 2014-03-06 22:04:19 UTC
(In reply to Adam Williamson from comment #50)
> Please leave the overblown philosophical argumentation for somewhere else.
> This is a bug tracking system.

Please, read your own comment #41 before issuing such statements.

Comment 52 Joergen Thomsen 2014-03-06 22:07:52 UTC
(In reply to David Lehman from comment #48)
> (In reply to Joergen Thomsen from comment #47)
> > Ok, you know better than I, how I should make a deployment ? 
> > I strongly disagree.
> 
> Perhaps you would like to make a (concise, focused) case for allowing reuse
> of an existing root filesystem beyond "because I want to."

Perhaps you would like to make a (concise, focused) case for NOT allowing reuse of an existing root filesystem, when "I want to." ?

Comment 53 Adam Williamson 2014-03-06 22:09:32 UTC
No, that's not how development works. If you want something in a product changed, convince the person who builds it to change it. You can't just say "ah, but you can't convince me it's right, so you have to change it!"

Well, you CAN say that, but it is not going to get you very far.

Comment 54 Mehmet Avcioglu 2014-03-07 07:27:18 UTC
For almost three years people here have been making pretty damn convincing arguments (imo) against this change which breaks a previous functionality and nobody is able to come up with a reason other than saving idiots who don't read what they see on a screen or select an option that they don't understand from overwriting existing data and forcing them to format that data instead and we are still talking about convincing developers. Well, they are not convinced, they don't give a damn, they want to make an installer as close to Windows as possible.

Comment 55 Jan Kratochvil 2014-03-07 08:24:00 UTC
(In reply to David Lehman from comment #48)
> Perhaps you would like to make a (concise, focused) case for allowing reuse
> of an existing root filesystem beyond "because I want to."

So that I can upgrade my Fedora system. (dot)

in detail:

Without moving 1.5 TB of data back and forth which put my server 2 days out of service.  And I had a luck I still had enough free disk space to keep my data two times there.

I was always using Comment 37 'mv' solution which no longer works.  How should I upgrade my system otherwise? Regular upgrade did not boot due to some yet another systemd breakage - so I needed new installation of rpm configs with no leftover old configs (*).

(*) I could make a script moving out all files not in 'rpm -qf' or which do not pass 'rpm -V' etc. to simulate a new installation but that is too complicated.

Comment 56 Radu Rendec 2014-03-07 08:25:20 UTC
Not all users are noobs or morons. There are users out there who really know what they're doing. For the latter, you should provide a way to let them reuse the existing rootfs without formatting it - instead of forcing them to use a separate partition/device and spend twice more time to achieve the same result. If you want my technical arguments, please read comment #42.

As for the "This is not a deployment method we support or want to support, therefore we prevent it from being used" statement, with all do respect, I believe it's wrong. If computer manufacturers thought the same, they would have made a special bios that prevented users from booting/installing linux, just because they (the manufacturers) don't support or want to support linux. Wouldn't you be "a little" frustrated if you bought a new laptop and found out you couldn't install linux on it just because the manufacturer *decided* for you that linux is wrong and they don't want to support it?

As a side note, I know there's been a lot of work in the new anaconda, but IMO it's still lacking a lot of functionality and flexibility that the old version had.

Comment 57 David Lehman 2014-03-07 16:20:00 UTC
Every argument in this bug report boils down to "I want to do this because it is faster/easier." This is not convincing.

Having said that, I am willing to entertain the possibility of moving all data into an installer-created subdirectory in order to reuse an existing filesystem for the root filesystem as described in comment 28. If any of you wants to submit a patch that accomplishes this I will be happy to review it and, if it passes a review of peers as well, apply it.

Comment 58 Radu Rendec 2014-03-07 16:29:48 UTC
David, I believe this is a very elegant solution to supporting both what we all argued for and the "clean" way of installing the system, at the same time.

I can't help with the patch since my python knowledge is very limited, but I would be more than happy to help out with testing as soon as somebody submits a patch and it is accepted.

Comment 59 Adam Williamson 2014-03-07 18:26:54 UTC
radu: your comparison is not valid. It's not the computer vendor's job to support the operating system. It's certainly the operating system vendor's job. We're building an operating system: it's entirely our right to determine the parameters within which we want it to operate.

Aside from that, I'll just leave this here:

https://xkcd.com/1172/

Comment 60 Nicolae Crefelean 2014-06-06 08:54:27 UTC
Hello!

I'm fully aware that most of the people have no clue how to install an operating system, or that there are people who make mistakes or poor decisions when installing. In fact, there's a very small minority or people who know (exactly/very well) what they're doing. But this minority is still comprised of tens of thousands of people world-wide, maybe more, most of them being responsible with deploying IT infrastructure all over the places.

I can certainly understand sane defaults, but the lack of such an option makes a sysadmin's life really annoying. When you have to deliver a new IT ecosystem in a reasonable amount of time, you will most likely look for the best solution. And when you have to deal with plenty of PCs you have two options:

1. Blindly copy everything the users have in a safe place so you can restore whatever needs to be restored after you install the new OS;
2. Talk to the users and maybe their managers so you find out exactly what you have to save, so you can only copy what they actually need.

Both options take time: (1) after install and (2) before the install. However, you would rather offer them the new OS in the least amount of time, so they can get back to work as soon as possible. But copying everything is a pain and it also requires free space, plus the backup and restore operation takes quite some time.

Now multiply this pain with only 5 PCs and it's enough to be reluctant in choosing an operating system which doesn't allow you to take shortcuts. That's option 3, which allows you to move everything in a directory, then install the OS and move anything required back in its place. This is really a time saver.

Dumbing down the world because the majority can't handle it... isn't that awful? Even if it's a hidden option it should still be there for people who know what they're doing.

I'm pretty much sure the people at RedHat are clever enough to know that the real-life IT is not at all perfect and there's more than one reason to need the option not to format a partition. Not every IT environment setup can be automated/scripted, and more obviously, only few sysadmins care enough or have the time to write and follow bug reports. Some really don't care enough and they would rather make the hard choice and choose another distro but at least deliver the new IT infrastructure considerably quicker and less painful to everyone involved.

So why isn't this option allowed back in the installer?

Comment 61 Adam Williamson 2014-06-06 15:52:41 UTC
"So why isn't this option allowed back in the installer?"

For all the reasons already cited in the earlier discussion. I point you in particular to comment #25: "There are a million things that people could do that may or may not be wise. We are not striving to support them all." and comment #29: "One of the things this change does is strongly encourage better system administration practices."

Comment 62 Nicolae Crefelean 2014-06-10 02:04:49 UTC
To be short: "Even if it's a hidden option it should still be there for people who know what they're doing."

Because the difference (in the installer code) between formatting and not formatting is way too small to simply dismiss it, especially when you actually had it coded.

I do believe better practices should be promoted everywhere as default choices, but I also believe some people simply don't care enough about the advanced users. It's a pity this is one of those places as well.

Comment 63 Jan Kratochvil 2014-06-10 08:07:24 UTC
There is no longer a need to argue whether to allow it or not.

Comment 57 made IMO a good enough patch variant acceptance offer.  Just someone has to code it.

Comment 64 Nicolae Crefelean 2014-06-11 07:37:49 UTC
I know I'm beating a dead horse here but as I said, the code is already written. If there was a real interest in helping the advanced users, someone would merge it back in the installer.

Comment 65 Adam Williamson 2014-06-11 07:45:29 UTC
re-read c#57. it is not about re-introducing the functionality exactly as requested in the report. it is more along the lines of a compromise proposal.

Comment 66 Tru Huynh 2017-03-13 11:21:18 UTC
RHEL 7.3/CentOS-7.3 get this feature activated (was not there of the previous point release).

How can I do this 7.2 ks.cfg features which was ok:
...
part /boot --fstype=ext4 --grow --size=1 --ondisk=sda
part /          --onpart=sdb --noformat
...
%pre
# /boot only
parted -s /dev/sda  mklabel msdos
# / ext4
parted -s /dev/sdb  mklabel msdos
mkfs.ext4 -F /dev/sdb
%end


AFAIK, mke2f.conf cant use the '-F -F' flags so I can not do:

part /     --fstype=ext4 --fsprofile=sdb  --onpart=sdb 

%pre
cat >> /etc/mke2fs.conf <<EXT4
        sdb = {
                options= "-F -F"
        }
EXT

mke2fs interactively fails with "/dev/sdb is entire device, not just one partition, Proceed anyway (y,n)"

How can I pass the  '-F -F' flags now?

Thanks

Tru

Comment 67 David Sundqvist 2017-10-25 09:37:20 UTC
This effectively prevents creating an XFS root fs with an external journal on a logical volume (-l logdev=/dev/vgx/lvx) as the logical volumes seem to get selectively activated for the mkfs and there's no logic that will activate the extra needed lv to proceed with the format.

Ah, well, moving the mkfs commands in the %pre script and replacing them with a wrapper script that will do the logic will do the trick.

I guess that can be used if someone wants to not format the root fs as well...


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