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
Created an attachment (id=442430) Attached traceback automatically from anaconda.
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
We should definitely not allow mounting-but-not-formatting /.
(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.
*** Bug 525849 has been marked as a duplicate of this bug. ***
Created attachment 461857 [details] Attached traceback automatically from anaconda.
Created attachment 464615 [details] Attached traceback automatically from anaconda.
Created attachment 467344 [details] Attached traceback automatically from anaconda.
Created attachment 468976 [details] Attached traceback automatically from anaconda.
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.
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 :)
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.
I just pushed it to f15-branch, so it'll end up in something like anaconda-15.28-1.
anaconda-15.28-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/anaconda-15.28-1.fc15
anaconda-15.29-1.fc15 has been submitted as an update for Fedora 15. https://admin.fedoraproject.org/updates/anaconda-15.29-1.fc15
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.
*** Bug 701032 has been marked as a duplicate of this bug. ***
*** Bug 702362 has been marked as a duplicate of this bug. ***
*** Bug 675574 has been marked as a duplicate of this bug. ***
(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?
(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?
(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. :)
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..
(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.
(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?
(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..
(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.
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.
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 > ...
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.
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 ...
"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
(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.
*** Bug 730798 has been marked as a duplicate of this bug. ***
*** Bug 1047375 has been marked as a duplicate of this bug. ***
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.
(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.
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.
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.
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.
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.
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.
*** Bug 1072559 has been marked as a duplicate of this bug. ***
(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 ?
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.
(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.
(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."
(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.
Please leave the overblown philosophical argumentation for somewhere else. This is a bug tracking system.
(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.
(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." ?
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.
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.
(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.
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.
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.
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.
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/
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?
"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."
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.
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.
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.
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.
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
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...