libreport version: 2.0.6 executable: /usr/bin/python hashmarkername: anaconda kernel: 3.1.0-7.fc16.i686 product: Fedora reason: FSError: failed to get block size for ext4 filesystem on /dev/md127 time: Sat Nov 12 09:18:56 2011 version: 16 anaconda-tb-ugmCcX: Text file, 338881 bytes description: :The following was filed automatically by anaconda: :anaconda 16.25 exception report :Traceback (most recent call first): : File "/usr/lib/python2.7/site-packages/pyanaconda/storage/formats/fs.py", line 1016, in minSize : "on %s" % (self.mountType, self.device)) : File "/usr/lib/python2.7/site-packages/pyanaconda/storage/formats/fs.py", line 158, in __init__ : foo = self.minSize # force calculation of minimum size : File "/usr/lib/python2.7/site-packages/pyanaconda/storage/formats/__init__.py", line 88, in getFormat : fmt = fmt_class(*args, **kwargs) : File "/usr/lib/python2.7/site-packages/pyanaconda/storage/__init__.py", line 1925, in _parseOneLine : fmt = getFormat(fstype, device=device.path, exists=True) : File "/usr/lib/python2.7/site-packages/pyanaconda/storage/__init__.py", line 2022, in parseFSTab : device = self._parseOneLine((devspec, mountpoint, fstype, options, dump, passno)) : File "/usr/lib/python2.7/site-packages/pyanaconda/storage/__init__.py", line 1588, in mountExistingSystem : fsset.parseFSTab(anaconda=anaconda) : File "/usr/lib/python2.7/site-packages/pyanaconda/upgrade.py", line 171, in upgradeMountFilesystems : mountExistingSystem(anaconda, anaconda.upgradeRoot[0], allowDirty = 0) : File "/usr/lib/python2.7/site-packages/pyanaconda/dispatch.py", line 373, in dispatch : self.dir = self.steps[self.step].target(self.anaconda) : File "/usr/lib/python2.7/site-packages/pyanaconda/gui.py", line 88, in return_false : func(*args, **kwargs) :FSError: failed to get block size for ext4 filesystem on /dev/md127
Created attachment 533235 [details] File: anaconda-tb-ugmCcX
I can't upgrade with preupgrade from F15 to F16 because of this bug. I have a MD RAID 1 with two hard drives. Partitions: 1- /boot (ext4) 2- md raid 1.1 metadata (lukes encrypted ext4) 3- swap Anaconda asks me for the password, which I type correctly. If I ALT+F2 out of Anaconda while the message is displayed, I see that the file system did mount to /mnt/sysimage, so I'm puzzled by the error. I'm guessing it needs to look at /dev/mapper/lukes-$HASH instead of /dev/md127.
md127 is not encrypted. The problem is that we don't ensure the md device is activated before some code deeper down tries to access the device.
AFAICT this will prevent successful upgrade on any system that uses md RAID for a filesystem in /etc/fstab.
(In reply to comment #4) > AFAICT this will prevent successful upgrade on any system that uses md RAID for > a filesystem in /etc/fstab. David, when you get a fix for this could you create a fixed F16 update image? I'd like to use anaconda to upgrade as opposed to yum. Thanks.
Discussed at 2012-03-02 blocker review meeting. Accepted as a blocker per criterion "The installer must be able to successfully complete an upgrade installation from a clean, fully updated default installation (from any official install medium) of the previous stable Fedora release, either via preupgrade or by booting to the installer manually. The upgraded system must meet all release criteria". Depends on the hardware configuration 'have a RAID device', but that's certainly common enough to take this as a blocker. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Try this: updates=http://dlehman.fedorapeople.org/updates/updates-753421-f16.img on the boot command line. Let me know how it goes.
(In reply to comment #7) > Try this: Unfortunately this did not help. Anaconda gave me the same error message. I did see anaconda download your update .img file prior to the error.
(In reply to comment #8) > (In reply to comment #7) > > Try this: > > Unfortunately this did not help. Anaconda gave me the same error message. > > I did see anaconda download your update .img file prior to the error. Please attach the logs from your run with the updates image so I can see what happened: anaconda.log, storage.log, program.log, syslog. Attach them individually, and make sure they are of type text/plain. Thanks.
Created attachment 569518 [details] anaconda.log from updates-753421-f16.img
Created attachment 569519 [details] program.log from updates-753421-f16.img
Created attachment 569520 [details] storage.log from updates-753421-f16.img
Created attachment 569521 [details] syslog from updates-753421-f16.img
(In reply to comment #13) > Created attachment 569521 [details] > syslog from updates-753421-f16.img Please attach your /etc/fstab as well.
Created attachment 569726 [details] fstab from F15
Am I correct in thinking you edited the fstab yourself? Anaconda does not write device UUIDs to /etc/fstab. It only writes filesystem UUIDs, for this very reason: it is ambiguous whether you are specifying the formatting/filesystem with that UUID or the device with that UUID. The easy workaround for you would be to replace the root filesystem's UUID in /etc/fstab to give the UUID of the ext4 filesystem on the encrypted md device instead of the UUID of the encrypted device itself.
(In reply to comment #16) > Am I correct in thinking you edited the fstab yourself? As far as I can remember I have not edited the fstab. I created the RAID using anaconda with the F15 DVD ISO on a flash drive. I have since adjusted the RAID size and added a second swap, but I do not remember having to adjust the root UUID. I guess I would have to install F15/F16/F17 from scratch with the same partition setup to see if I am right or not. > Anaconda does not write device UUIDs to /etc/fstab. It only writes filesystem > UUIDs, for this very reason: it is ambiguous whether you are specifying the > formatting/filesystem with that UUID or the device with that UUID. In that case, Anaconda is choosing the UUID for encrypted RAIDs and if what you say is true then Anaconda needs to be fixed. Not my fstab. > The easy workaround for you would be to replace the root filesystem's UUID in > /etc/fstab to give the UUID of the ext4 filesystem on the encrypted md device > instead of the UUID of the encrypted device itself. So anaconda reads my real /etc/fstab from my encrypted RAID root and it is failing on that? I can try specifying the ext4 FS UUID and try upgrading in about 5 hours.
(In reply to comment #17) > (In reply to comment #16) > > Am I correct in thinking you edited the fstab yourself? > > As far as I can remember I have not edited the fstab. I created the RAID using > anaconda with the F15 DVD ISO on a flash drive. I have since adjusted the RAID > size and added a second swap, but I do not remember having to adjust the root > UUID. I guess I would have to install F15/F16/F17 from scratch with the same > partition setup to see if I am right or not. I just did a test with a fresh F15 install. The UUID written by anaconda to the /etc/fstab was the UUID of the RAID device and not of the ext4 file system. I can provide logs, fstab, or blkid output if it helps.
OK, I take back what I said. I thought I did the partitioning a different way. When I reinstalled the fstab did not have a UUID, it had a /dev/mapper/$UUID line for the root fs. I must have changed it, but I do not know why. I will adjust it to be correct and see if I can upgrade.
Setting my fstab to /dev/mapper/luks-$UUID allowed me to upgrade.
I'm going to drop the 'acceptedblocker', then, so we can re-debate this one on Friday, as our understanding was that this blocked upgrade with a default soft RAID install. As that no longer appears to be the case we need to revisit the blocker status. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Discussed at 2012-03-16 blocker review meeting. Accepted as a blocker bug per criterion "The installed system must be able to download and install updates with yum and the default graphical package manager in all release-blocking desktops" in the context of an IPv6-only connection. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Crap, wrong bug. Sorry. Correct note: Discussed at 2012-03-16 blocker review meeting. Now rejected as a blocker, as we understand it, this bug does not affect upgrade from a default soft-RAID installation configuration. It would be good to verify that an out-of-the-box soft-RAID F16 install upgrades successfully to F17 with Beta TC1 or TC2 when it lands.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.