Bug 983330 - FSError: mount failed: 32
FSError: mount failed: 32
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: python-blivet (Show other bugs)
19
x86_64 Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: David Lehman
Fedora Extras Quality Assurance
abrt_hash:21292e3d72facc5def40ca6e4be...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-10 22:12 EDT by Garrett Cooper
Modified: 2013-07-15 21:33 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-07-15 21:05:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
File: anaconda-tb (542.84 KB, text/plain)
2013-07-10 22:12 EDT, Garrett Cooper
no flags Details
File: anaconda.log (31.30 KB, text/plain)
2013-07-10 22:13 EDT, Garrett Cooper
no flags Details
File: environ (549 bytes, text/plain)
2013-07-10 22:13 EDT, Garrett Cooper
no flags Details
File: lsblk_output (3.18 KB, text/plain)
2013-07-10 22:13 EDT, Garrett Cooper
no flags Details
File: messages (240.88 KB, text/plain)
2013-07-10 22:13 EDT, Garrett Cooper
no flags Details
File: nmcli_dev_list (9.31 KB, text/plain)
2013-07-10 22:13 EDT, Garrett Cooper
no flags Details
File: os_info (179 bytes, text/plain)
2013-07-10 22:13 EDT, Garrett Cooper
no flags Details
File: program.log (58.25 KB, text/plain)
2013-07-10 22:13 EDT, Garrett Cooper
no flags Details
File: storage.log (191.88 KB, text/plain)
2013-07-10 22:13 EDT, Garrett Cooper
no flags Details
File: ifcfg.log (2.20 KB, text/plain)
2013-07-10 22:13 EDT, Garrett Cooper
no flags Details
anaconda.storage-zfs-test-1.log (NOT A BUG -- for reference only) (111.84 KB, text/plain)
2013-07-11 11:18 EDT, Steve Tyler
no flags Details
anaconda-tb-QBQczE (captured while installer was stalled) (474.56 KB, text/plain)
2013-07-11 16:48 EDT, Steve Tyler
no flags Details
full-disk-ext4-1.txt (terminal session) (1.61 KB, text/plain)
2013-07-11 17:24 EDT, Steve Tyler
no flags Details

  None (edit)
Description Garrett Cooper 2013-07-10 22:12:55 EDT
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
Comment 1 Garrett Cooper 2013-07-10 22:12:59 EDT
Created attachment 771938 [details]
File: anaconda-tb
Comment 2 Garrett Cooper 2013-07-10 22:13:03 EDT
Created attachment 771939 [details]
File: anaconda.log
Comment 3 Garrett Cooper 2013-07-10 22:13:06 EDT
Created attachment 771940 [details]
File: environ
Comment 4 Garrett Cooper 2013-07-10 22:13:10 EDT
Created attachment 771941 [details]
File: lsblk_output
Comment 5 Garrett Cooper 2013-07-10 22:13:14 EDT
Created attachment 771942 [details]
File: messages
Comment 6 Garrett Cooper 2013-07-10 22:13:20 EDT
Created attachment 771943 [details]
File: nmcli_dev_list
Comment 7 Garrett Cooper 2013-07-10 22:13:24 EDT
Created attachment 771944 [details]
File: os_info
Comment 8 Garrett Cooper 2013-07-10 22:13:28 EDT
Created attachment 771945 [details]
File: program.log
Comment 9 Garrett Cooper 2013-07-10 22:13:32 EDT
Created attachment 771946 [details]
File: storage.log
Comment 10 Garrett Cooper 2013-07-10 22:13:36 EDT
Created attachment 771947 [details]
File: ifcfg.log
Comment 11 Garrett Cooper 2013-07-10 22:19:05 EDT
Looks like what happened is that I didn't have it "reclaim space" so it bailed trying to mount things later on.
Comment 12 Steve Tyler 2013-07-11 01:38:49 EDT
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
...
Comment 13 Garrett Cooper 2013-07-11 01:44:55 EDT
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.
Comment 14 Garrett Cooper 2013-07-11 01:46:33 EDT
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
Comment 15 Garrett Cooper 2013-07-11 01:47:19 EDT
Sorry. Bad copy-paste. I'm a bit tired...
Comment 16 Steve Tyler 2013-07-11 02:06:50 EDT
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.
Comment 17 Garrett Cooper 2013-07-11 02:09:27 EDT
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
Comment 18 Steve Tyler 2013-07-11 02:26:35 EDT
OK. Thanks for the link and the tip.
Comment 19 Steve Tyler 2013-07-11 11:18:11 EDT
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
Comment 20 Steve Tyler 2013-07-11 11:31:02 EDT
(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.
Comment 21 Garrett Cooper 2013-07-11 13:29:22 EDT
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
Comment 22 Steve Tyler 2013-07-11 13:49:01 EDT
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 ...
Comment 23 Garrett Cooper 2013-07-11 14:07:04 EDT
I did actually ;/...
Comment 24 Garrett Cooper 2013-07-11 14:07:55 EDT
The UUID wasn't being set explicitly BTW
Comment 25 Steve Tyler 2013-07-11 16:48:43 EDT
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
Comment 26 Steve Tyler 2013-07-11 17:24:50 EDT
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
Comment 27 Brian Lane 2013-07-15 21:05:36 EDT
F19 doesn't support un-partitioned disks. F20 will.
Comment 28 Steve Tyler 2013-07-15 21:33:17 EDT
(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

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