Bug 995892
| Summary: | DeviceError: ('Cannot destroy non-leaf device', 'VolGroup00-LV_var') | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | David Allen <dallen> | ||||||||||||||||||||||||||||
| Component: | anaconda | Assignee: | Anaconda Maintenance Team <anaconda-maint-list> | ||||||||||||||||||||||||||||
| Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||||||
| Priority: | unspecified | ||||||||||||||||||||||||||||||
| Version: | 19 | CC: | anaconda-maint-list, dshea, g.kaviyarasu, jonathan, mkolman, sbueno, stephent98, vanmeeuwen+fedora | ||||||||||||||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||||||||||||||
| Hardware: | i686 | ||||||||||||||||||||||||||||||
| OS: | Unspecified | ||||||||||||||||||||||||||||||
| Whiteboard: | abrt_hash:fc56e149e3b61118352b91e9ea38149908fffa43b5c443e93fe2674f2dce31d2 | ||||||||||||||||||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||||||||||||||||
| Last Closed: | 2014-12-10 15:55:07 UTC | Type: | --- | ||||||||||||||||||||||||||||
| Regression: | --- | Mount Type: | --- | ||||||||||||||||||||||||||||
| Documentation: | --- | CRM: | |||||||||||||||||||||||||||||
| Verified Versions: | Category: | --- | |||||||||||||||||||||||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||||||||||||||||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||||||||||||||||||||||
| Embargoed: | |||||||||||||||||||||||||||||||
| Attachments: |
|
||||||||||||||||||||||||||||||
Created attachment 785476 [details]
File: anaconda.log
Created attachment 785477 [details]
File: environ
Created attachment 785478 [details]
File: lsblk_output
Created attachment 785479 [details]
File: nmcli_dev_list
Created attachment 785480 [details]
File: os_info
Created attachment 785481 [details]
File: program.log
Created attachment 785482 [details]
File: storage.log
Created attachment 785483 [details]
File: syslog
Created attachment 785484 [details]
File: ifcfg.log
Created attachment 785485 [details]
File: packaging.log
Created attachment 785486 [details]
File: anaconda-tb
Upon rebooting the locked up system, I have found that the installer left Grub in an incomplete state such that the existing configuration (Fedora 9 and Windows XP) are no longer available without recovering/reconfiguring Grub. Nice work guys. Thanks for your report. I'm not sure what went wrong, but I believe you can get a working system by reinstalling. You can remove partitions in the Manual Partitioning dialog by selecting each partition to be removed and clicking the "-" button near the left bottom of the dialog. The partitioning requirements have changed quite a bit since F9. In particular, the default size for /boot is 500 MB, so sda2 at 70 MB is far too small. Also, /tmp is now a tmpfs, not a physical device, by default. Which partitions do you want to preserve? Before the install failure, the installer had already run wipefs on sda2, sda3, sda5, and all four logical volumes, so there would have been no file systems accessible to grub2 upon rebooting. Snippet from attached anaconda.log: ... 13:34:21,663 DEBUG anaconda: populate_right_side: existing 70MB partition sda2 (2) with non-existent ext4 filesystem mounted at /boot ... 13:35:52,408 WARN anaconda: Your /boot partition is less than 75 megabytes which is lower than recommended for a normal Fedora install. ... Snippet from attached program.log: $ grep wipefs program.log 14:00:34,424 INFO program: Running... wipefs -f -a /dev/mapper/VolGroup00-LV_home 14:00:34,811 INFO program: Running... wipefs -f -a /dev/sda2 14:00:35,068 INFO program: Running... wipefs -f -a /dev/sda3 14:00:35,626 INFO program: Running... wipefs -f -a /dev/mapper/VolGroup00-LV_tmp 14:00:36,439 INFO program: Running... wipefs -f -a /dev/mapper/VolGroup00-LV_usrlocal 14:00:36,953 INFO program: Running... wipefs -f -a /dev/sda5 14:00:37,514 INFO program: Running... wipefs -f -a /dev/mapper/VolGroup00-LV_var I managed to get a successful install by first deleting all partitions other than the XP NTFS partition, and then letting Anaconda auto-partition the drive. Since the auto-partition scheme is similar to what I was going to do on the laptop anyway, I am satisfied with the default scheme: swap, /, and /home. Although I prefer a separate /var partition. However, I should have been told /prior/ to my even being able to partition my drive that my current configuration and layout was incompatible with this installer. I should also have been given the option of installing Grub1 or another bootloader, with built-in options to do that. And I don't mean some hidden option buried in off-screen documentation about some magic parameters to be given in console: lazy programming. And for godssakes, could someone finally learn how include a means of actually gracefully backing out of the install and rebooting! By rebooting, I mean forcing a cold restart. Having to cycle power or push a reset button is so 1995. Could you possibly make the font size any smaller or the color choice and contrast any harder to read? Do you even know what "grayed out" is supposed to look like compared to a valid option? Can't tell from your design. Along with others, I consider the new installer to be a regression and of very poor design. My opinion is that it's based on lazy programmers with an apparent compulsion to make something cool and iPhone-ish looking. Too much wasted white space, too little information, dialogs and documentation written by and for people who already know what /not/ to do, and certainly reduced functionality vs. the previous Fedora (pre-F18) installers (which weren't perfect but at least usable). I understand that this installer works as intended and by design. Well, if your intentions were to lock out older hardware and OS's, reduce flexibility, functionality (I'm not allowed rename an LVM LV?) and usability, at the risk of alienating users (new ones especially - I've been using Redhat since version 3 and /I/ was confused), or worse causing loss of data, then your design has fulfilled that intention. Never mind that this opinion is irrelevant on a bug-reporting system and more suited to a forum. This is a bug report. Your whole redesign of Anaconda is a bug in itself. Hopefully you either change to something a typical Linux user expects, and if the current maintainer can't do that, get someone who can. Or risk Fedora continuing its down-slide towards being considered a minor, less than useful distribution. Thanks for your followup report, David. You did exactly what I was going to recommend -- delete all unneeded partitions and use autopart to create a new storage configuration. Once you have that, you can fine-tune it to suit your needs -- for example, you can shrink /home to make room for /var. NB: The installer will allocate all available space for a new storage device if you specify a Desired Capacity in the Add a Mount Point dialog that is larger than the remaining available space. You can also leave the Desired Capacity blank and get the same effect. Both methods are documented in the "Tips and hints" section of the Manual Partitioning help page. Created attachment 785919 [details] screenshot showing renamed volume group and logical volume (In reply to David Allen from comment #14) ... > (I'm not allowed rename an LVM LV?) ... Where were you not allowed to rename an LVM LV? In a test with a newly created volume group, both the volume group name and the logical volume name could be changed. Tested with: $ qemu-kvm -m 4096 -hda f19-test-2.img -cdrom ~/xfr/fedora/F19/Fedora-19-x86_64-DVD.iso -vga std -boot menu=on (In reply to David Allen from comment #14) ... > to be given in console: lazy programming. And for godssakes, could someone > finally learn how include a means of actually gracefully backing out of the > install and rebooting! By rebooting, I mean forcing a cold restart. Having > to cycle power or push a reset button is so 1995. ... There is a Quit button in the lower left corner of the Installation Summary. Does clicking the Quit button do what you want? NB: You can test that without making any changes to your installed system. Created attachment 785947 [details] screenshot showing "Warning checking storage configuration" in Installation Summary (In reply to David Allen from comment #14) ... > However, I should have been told /prior/ to my even being able to partition > my drive that my current configuration and layout was incompatible with this > installer. ... Using gparted, I pre-partitioned a VM disc image with a 70 MB partition. After configuring it as the /boot partition in Manual Partitioning, the installer displays this unobtrusive warning in the Installation Summary: Warning checking storage configuration The GUI gives no indication whatsoever that the user should click on the Installation Destination link to read the warning. The tooltip simply repeats the same vague warning. (In reply to David Allen from comment #14) ... > My opinion is that it's based on lazy programmers with an > apparent compulsion to make something cool and iPhone-ish looking. ... You can follow what the anaconda developers do all day starting here: The anaconda-patches Archives https://lists.fedorahosted.org/pipermail/anaconda-patches/ Here are a bunch of links concerning the GUI design: This concerns a pre-F18 design, but the Partitioning Personas are brilliant: What’s your partitioning persona? And, the partitioning UI thus far. http://blog.linuxgrrl.com/2011/12/14/whats-your-partitioning-persona-and-the-partitioning-ui-thus-far/ This shows the anaconda GUI design that was first implemented in F18: More Anaconda Custom Partitioning http://blog.linuxgrrl.com/category/fedora/anaconda/ A very nice GUI design analysis and mockup, pre-F18: Anaconda Storage UI Design https://fedoraproject.org/wiki/Design/AnacondaStorageUI http://mairin.wordpress.com/category/fedora/anaconda/ (In reply to Steve Tyler from comment #18) > Created attachment 785947 [details] > screenshot showing "Warning checking storage configuration" in Installation > Summary ... > Using gparted, I pre-partitioned a VM disc image with a 70 MB partition. > After configuring it as the /boot partition in Manual Partitioning, the > installer displays this unobtrusive warning in the Installation Summary: > > Warning checking storage configuration > > The GUI gives no indication whatsoever that the user should click on the > Installation Destination link to read the warning. The tooltip simply > repeats the same vague warning. See Bug 969684, Comment 50. (In reply to Steve Tyler from comment #20) ... > See Bug 969684, Comment 50. Bug 996509 - bootloader install failure after installer accepts 70 MiB /boot partition This probably explains the bootloader install failure you reported in: Bug 969684, Comment 47. *** This bug has been marked as a duplicate of bug 1027682 *** |
Description of problem: This is in an attempt to replace the existing Fedora 9 with F19. Followed installation dialogs. Installer would not accept root password entry - keyboard locked up. After a few minutes it seems the installer did not like the way I selected my disk partitioning scheme. Then the installation failed and now I'm here. BTW, your disk management system in F19 sucks. Versions previous to F18 were just fine. Leave well enough alone. New layout is confusing and less functional. No doubt that is why I have this problem: I wanted to remove some existing partitions, and recover that space. How to do this is unclear to me although no doubt ver clear to the dev of this POS. Version-Release number of selected component: anaconda-19.30.13-1 The following was filed automatically by anaconda: anaconda 19.30.13-1 exception report Traceback (most recent call first): File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 809, in _preDestroy raise DeviceError("Cannot destroy non-leaf device", self.name) File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 2660, in _preDestroy StorageDevice._preDestroy(self) File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 2679, in resize self._preDestroy() File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 403, in execute self.device.resize() File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 237, in processActions action.execute() File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 310, in doIt self.devicetree.processActions() File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 169, in turnOnFilesystems storage.doIt() File "/usr/lib/python2.7/site-packages/pyanaconda/install.py", line 140, in doInstall turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall) File "/usr/lib/python2.7/threading.py", line 764, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib/python2.7/site-packages/pyanaconda/threads.py", line 168, in run threading.Thread.run(self, *args, **kwargs) DeviceError: ('Cannot destroy non-leaf device', 'VolGroup00-LV_var') Additional info: cmdline: /usr/bin/python /sbin/anaconda cmdline_file: initrd=initrd.img inst.stage2=hd:LABEL=Fedora\x2019\x20i386 quiet BOOT_IMAGE=vmlinuz executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.9.5-301.fc19.i686 product: Fedora release: Cannot get release name. type: anaconda version: 19