Bug 983330
| Summary: | FSError: mount failed: 32 | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Garrett Cooper <yanegomi> | ||||||||||||||||||||||||||||
| Component: | python-blivet | Assignee: | David Lehman <dlehman> | ||||||||||||||||||||||||||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||||||||||||||||||||||
| Severity: | unspecified | Docs Contact: | |||||||||||||||||||||||||||||
| Priority: | unspecified | ||||||||||||||||||||||||||||||
| Version: | 19 | CC: | anaconda-maint-list, bcl, dlehman, dshea, g.kaviyarasu, jonathan, mkolman, sbueno, stephent98, vanmeeuwen+fedora | ||||||||||||||||||||||||||||
| Target Milestone: | --- | ||||||||||||||||||||||||||||||
| Target Release: | --- | ||||||||||||||||||||||||||||||
| Hardware: | x86_64 | ||||||||||||||||||||||||||||||
| OS: | Unspecified | ||||||||||||||||||||||||||||||
| Whiteboard: | abrt_hash:21292e3d72facc5def40ca6e4beee5d72e733a73d878318c3cc0ec5a90b607f6 | ||||||||||||||||||||||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||||||||||||||||||||||
| Doc Text: | Story Points: | --- | |||||||||||||||||||||||||||||
| Clone Of: | Environment: | ||||||||||||||||||||||||||||||
| Last Closed: | 2013-07-16 01:05:36 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 771938 [details]
File: anaconda-tb
Created attachment 771939 [details]
File: anaconda.log
Created attachment 771940 [details]
File: environ
Created attachment 771941 [details]
File: lsblk_output
Created attachment 771942 [details]
File: messages
Created attachment 771943 [details]
File: nmcli_dev_list
Created attachment 771944 [details]
File: os_info
Created attachment 771945 [details]
File: program.log
Created attachment 771946 [details]
File: storage.log
Created attachment 771947 [details]
File: ifcfg.log
Looks like what happened is that I didn't have it "reclaim space" so it bailed trying to mount things later on. Do you recall how sdb was formatted before installation? lsblk shows sdb and sdb1 have the same UUID. AFAICT, the installer thinks sdb and sdb1 both have an ext4 file system. Snippets from attached anaconda-tb: ... Jul 10 22:06:01 localhost program: Running... dumpe2fs -h /dev/sdb Jul 10 22:06:01 localhost program: dumpe2fs 1.42.7 (21-Jan-2013) Jul 10 22:06:01 localhost program: Journal superblock magic number invalid! ... Jul 10 22:08:16 localhost program: Running... mount -t ext4 -o defaults /dev/sdb /mnt/sysimage/scratch Jul 10 22:08:16 localhost kernel: [ 844.854917] EXT4-fs (sdb): no journal found Jul 10 22:08:16 localhost program: mount: wrong fs type, bad option, bad superblock on /dev/sdb, Jul 10 22:08:16 localhost program: missing codepage or helper program, or other error Jul 10 22:08:16 localhost program: Jul 10 22:08:16 localhost program: In some cases useful info is found in syslog - try Jul 10 22:08:16 localhost program: dmesg | tail or so. Jul 10 22:08:16 localhost blivet: error mounting /dev/sdb on /scratch: mount failed: 32 ... I was trying to reformat and repartition with gparted as well before the install because I ran into issues trying to get things to function the first go-around I did with anaconda (the disks were tainted with bootcode from FreeBSD and getting lost trying to jump to a non-existent GPT partition). Before it looked something like this: sda1: freebsd-boot sda2: swap sda3: freebsd-zfs sdb1: freebsd-zfs Both of the disks were GPT partitioned. After the first attempt installing things it was more or less like: sda1: ext4 sda2: lvm2 sdb1: ext4 but sdb1's boot sector probably still had bootcode installed on it (again, just a guess..). I eventually just nuked the partition table with gparted, left it unformatted, then did mkfs.ext4 with sdb1, and things were copasetic after the 2nd install attempt. Minor correction: After the first attempt installing things it was more or less like: sda1: ext4 sda2: lvm2 sdb1: unformatted After the second attempt installing things it was more or less like: After the first attempt installing things it was more or less like: sda1: ext4 sda2: lvm2 sdb1: ext4 Sorry. Bad copy-paste. I'm a bit tired... Thanks, Garrett. It sounds like sdb could have been in an inconsistent state. Could you post a link to the FreeBSD installer you were using? It might be useful to see what the installer does when it sees ZFS. ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/9.1/FreeBSD-9.1-STABLE-amd64-20130616-r251797-bootonly.iso You'll need to follow instructions similar to these in order to create a zpool as ZFS is still not integrated into the FreeBSD installer -- bsdinstall: http://people.freebsd.org/~swills/gptzfsroot.txt OK. Thanks for the link and the tip. Created attachment 772278 [details] anaconda.storage-zfs-test-1.log (NOT A BUG -- for reference only) The installer handled ZFS fine. I followed the first part of the instructions here, but did not actually install FreeBSD: http://people.freebsd.org/~swills/gptzfsroot.txt Tested with: $ qemu-img create freebsd-test-1.img 12G $ qemu-kvm -m 4096 -hda freebsd-test-1.img -cdrom FreeBSD-9.1-STABLE-amd64-20130616-r251797-bootonly.iso -vga std -boot menu=on $ qemu-kvm -m 4096 -hda freebsd-test-1.img -cdrom ~/xfr/fedora/F19/Fedora-19-x86_64-DVD.iso -vga std -boot menu=on (In reply to Steve Tyler from comment #19) ... > The installer handled ZFS fine. ... My test was to delete everything on the disk from the Manual Partitioning dialog and then auto-create new partitions. A minimal install succeeded and root login was possible. I must have botched up the manual partitioning step somehow. Another important point was that the two disks were in separate zpools, ie sda - sac sdb - sac2 This doesn't appear to be easily reproducible, so I'm tempted just to mark this WORKSFORME, until we have a series of repro steps Thanks for pointing that out. My test was intended to keep it simple. :-) Do you recall running mk2efs on /dev/sdb, not /dev/sdb1, at some point? In a test, it let's me do that, but I can't see how the UUIDs came out the same -- assuming the superblocks would be in different places. Were you explicitly setting the UUID? I would suggest letting the developers weigh in on this ... I did actually ;/... The UUID wasn't being set explicitly BTW Created attachment 772424 [details]
anaconda-tb-QBQczE (captured while installer was stalled)
If sdb is pre-formatted as ext4, the installer stalls at:
Creating ext4 on /dev/sdb.
The pointer is responsive and a root password can be set.
The banner updates.
Procedure:
Initialize two disk images:
$ qemu-img create f19-test-1.img 12G
$ qemu-img create f19-test-2.img 12G
From a previously installed system, format f19-test-2.img as ext4 without any partitions:
$ qemu-kvm -m 4096 -hda f18-test-1.img -hdb f19-test-2.img -vga std -boot menu=on
# mke2fs -t ext4 -L full-disk-ext4-1 /dev/sdb
NB: mke2fs displays a warning: /dev/sdb is entire device, not just one partition!
Start the installer:
$ qemu-kvm -m 4096 -hda f19-test-1.img -hdb f19-test-2.img -cdrom ~/xfr/fedora/F19/Fedora-19-x86_64-DVD.iso -vga std -boot menu=on
Select a minimal install.
Select both disks for Installation Destination.
Select "I want to review/modify ..."
Click to auto-create (NB: This populates sda.)
Select Unknown ext4 on sdb.
Check Reformat.
Enter /scratch for mount point.
Click Update Settings.
Click Done.
Click Accept Changes.
Click Begin Installation.
The installer stalls at:
Creating ext4 on /dev/sdb.
The pointer is responsive and a root password can be set.
The banner updates.
The attached log file was captured from the installer console with:
# pkill -USR2 -o anaconda
Created attachment 772448 [details]
full-disk-ext4-1.txt (terminal session)
Thanks for your help, Garrett.
I was able to create a disk configuration with UUIDs for a primary partition and for the full disk by first creating one ext4 primary partition with gparted and then running mke2fs on the full disk. The UUIDs are different, however:
[root@f18-test-1 ~]# lsblk -f /dev/sdb
NAME FSTYPE LABEL UUID MOUNTPOINT
sdb ext4 full-disk-ext4-1 16962f0d-f1d5-49a4-8425-834e37e627aa
└─sdb1 ext4 a9dcd2d5-3852-4422-a824-f83528f10674
Details are in the attached terminal session.
NB: After rebooting, lsblk no longer shows sdb1.
Tested with:
$ qemu-img create f19-test-2.img 12G
$ qemu-kvm -m 4096 -hda f18-test-1.img -hdb f19-test-2.img -vga std -boot menu=on
F19 doesn't support un-partitioned disks. F20 will. (In reply to Brian C. Lane from comment #27) > F19 doesn't support un-partitioned disks. F20 will. OK, then you should change the resolution to NEXTRELEASE, because hanging is definitely a bug, so NOTABUG is just plain wrong. If you are going to be doing a lot of triage, you might want to look at this: https://bugzilla.redhat.com/page.cgi?id=fields.html#status |
Description of problem: I previously had installed FreeBSD with ZFS on the system, then tried to get things to work with gparted after the fact wiping out the partitions, then finally attempted to create the partitions via the installer with an LVM partition and failed. Version-Release number of selected component: anaconda-19.30.13-1.fc19.x86_64 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/formats/fs.py", line 601, in mount raise FSError("mount failed: %s" % rc) File "/usr/lib/python2.7/site-packages/blivet/formats/fs.py", line 791, in setup return self.mount(**kwargs) File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 2619, in mountFilesystems chroot=rootPath) File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 1642, in mountFilesystems readOnly=readOnly, skipRoot=skipRoot) File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 185, in turnOnFilesystems skipRoot=False) File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 140, in doInstall turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall) File "/usr/lib64/python2.7/threading.py", line 764, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 168, in run threading.Thread.run(self, *args, **kwargs) FSError: mount failed: 32 Additional info: cmdline: /usr/bin/python /sbin/anaconda --liveinst --method=livecd:///dev/mapper/live-osimg-min --lang en_US.UTF-8 cmdline_file: initrd=initrd0.img root=live:CDLABEL=Fedora-Live-LXDE-x86_64-19-1 rootfstype=auto ro rd.live.image quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 BOOT_IMAGE=vmlinuz0 executable: /sbin/anaconda hashmarkername: anaconda kernel: 3.9.5-301.fc19.x86_64 other involved packages: python-blivet-0.17-1.fc19.noarch, python-libs-2.7.5-1.fc19.x86_64 product: Fedora release: Fedora release 19 (Schrödinger’s Cat) type: anaconda version: 19