Latest updates - mount issues?

[glennzo]

Updated my Fedora 17 box this morning:
[root@phenom17 glenn>$ yum history info 31
Loaded plugins: fastestmirror, langpacks, local, presto, refresh-packagekit
Transaction ID : 31
Begin time : Sat Apr 14 04:24:49 2012
Begin rpmdb : 1449:6eb7f78c78e7fffd1082855c0ae41f6bf3fc079f
End time : 04:25:07 2012 (18 seconds)
End rpmdb : 1449:ca3a271d9872c715db9313e159889b398a82997c
User : Glenn Johnson <glenn>
Return-Code : Success
Command Line : update
Transaction performed with:
Installed rpm-4.9.1.3-1.fc17.x86_64 @updates-testing
Installed yum-3.4.3-23.fc17.noarch @updates-testing
Installed yum-metadata-parser-1.1.4-6.fc17.x86_64 @anaconda-0
Installed yum-plugin-fastestmirror-1.1.31-4.fc17.noarch @fedora
Installed yum-presto-0.7.3-1.fc17.noarch @updates-testing
Packages Altered:
Updated gvfs-1.12.0-1.fc17.x86_64 @updates-testing
Update 1.12.0-2.fc17.x86_64 @updates-testing
Updated gvfs-afc-1.12.0-1.fc17.x86_64 @updates-testing
Update 1.12.0-2.fc17.x86_64 @updates-testing
Updated gvfs-archive-1.12.0-1.fc17.x86_64 @updates-testing
Update 1.12.0-2.fc17.x86_64 @updates-testing
Updated gvfs-fuse-1.12.0-1.fc17.x86_64 @updates-testing
Update 1.12.0-2.fc17.x86_64 @_local
Updated gvfs-gphoto2-1.12.0-1.fc17.x86_64 @updates-testing
Update 1.12.0-2.fc17.x86_64 @updates-testing
Updated gvfs-obexftp-1.12.0-1.fc17.x86_64 @updates-testing
Update 1.12.0-2.fc17.x86_64 @updates-testing
Updated gvfs-smb-1.12.0-1.fc17.x86_64 @updates-testing
Update 1.12.0-2.fc17.x86_64 @updates-testing
Updated libgpod-0.8.2-2.fc17.x86_64 @anaconda-0
Update 0.8.2-4.fc17.x86_64 @updates-testing
Updated libimobiledevice-1.1.1-5.fc17.x86_64 @anaconda-0
Update 1.1.4-1.fc17.x86_64 @updates-testing
Updated rhythmbox-2.96-1.fc17.x86_64 @updates-testing
Update 2.96-2.fc17.x86_64 @updates-testing
Updated upower-0.9.15-2.fc17.x86_64 @anaconda-0
Update 0.9.15-3.fc17.x86_64 @updates-testing
Updated usbmuxd-1.0.7-3.fc17.x86_64 @anaconda-0
Update 1.0.8-1.fc17.x86_64 @updates-testing
history info

Now, when I run grub2-mkconfig ....... it hangs and never completes.
[root@phenom17 glenn>$ grub2-mkconfig -o /boot/grub2/grub.cfg
Generating grub.cfg ...
Found background: /home/glenn/Pictures/fedora_wall6.jpg
Found linux image: /boot/vmlinuz-3.3.1-5.fc17.x86_64
Found initrd image: /boot/initramfs-3.3.1-5.fc17.x86_64.img
Found linux image: /boot/vmlinuz-3.3.1-3.fc17.x86_64
Found initrd image: /boot/initramfs-3.3.1-3.fc17.x86_64.img
Found linux image: /boot/vmlinuz-3.3.0-1.fc17.x86_64
Found initrd image: /boot/initramfs-3.3.0-1.fc17.x86_64.img

It should, and has in the past, find Windows 7 on /dev/sda1 and Fedora 16 on /dev/sda2, but it doesn't.

My goal here is to update the boot menu to reflect the newest Fedora 16 kernel version.

Along with the "mkconfig" failure there are now issues with a USB/NTFS desktop drive. That too used to work religiously. Now I seem to be able to mount it but it shows no content.

If I run grub2-mkconfig ....., wait a bit and then hit CTRL-C (because it isn't making any progress) grub2 quits. That seems to leave something going on it the background because if I now try to manually mount /dev/sda1 (NTFS) I get errors.
[root@phenom17 glenn>$ mount -t ntfs-3g /dev/sda1 /mnt/windows/
Failed to write lock '/dev/sda1': Resource temporarily unavailable
Error opening '/dev/sda1': Resource temporarily unavailable
Failed to mount '/dev/sda1': Resource temporarily unavailable


So, I ask, is the update for gvfs a likely candidate for my grub2 issues? <-- Apparently nothing to do with file systems so pretend I didn't ask.

And now that I have more time, the error message I received.

[glennzo]

There is definitely an issue mounting NTFS partitions and it has reared its ugly head just in the last 1-2 days. I can't mount the partition manually and I'm still having issues running grub2-mkconfig. I can mount Linux partitions without issue. Therefore, I believe that if I didn't have Windows installed there would be no problem running grub2-mkconfig and life would go on.

I've been working with the following kernels and getting the same result:
3.3.1-5.fc17.x86_64
3.3.1-3.fc17.x86_64

Don't know if the following is really relevant but just the same.
[root@phenom17 glenn>$ fdisk -l /dev/sda

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000001

Device Boot Start End Blocks Id System
/dev/sda1 * 2048 104859647 52428800 7 HPFS/NTFS/exFAT
/dev/sda2 104859648 209717247 52428800 83 Linux
/dev/sda3 209717248 314574847 52428800 83 Linux
/dev/sda4 314574848 1953523711 819474432 5 Extended
/dev/sda5 314576896 419434495 52428800 83 Linux
/dev/sda6 419436544 524294143 52428800 83 Linux
/dev/sda7 524296192 629153791 52428800 83 Linux
/dev/sda8 629155840 734013439 52428800 83 Linux
/dev/sda9 734015488 838873087 52428800 83 Linux
/dev/sda10 838875136 847263743 4194304 82 Linux swap / Solaris


Fedora 17 is on /dev/sda3, 16 is on /dev/sda2.

Anyone else experiencing this behavior?

[Dan]

Crud! No way to test it here ... no ntfs partitions to play with.

[glennzo]

Same thing on the laptop. Windows 7 is installed so there's an NTFS partition. I can't run grub2-mkconfig on that Fedora 17 box either. I'd report a bug but I have no idea what to report against. :confused:

[Apostate]

I don't have Windows but F17 currently cannot mount my NTFS data partition

[glennzo]

It's the little things that annoy me, but it is, after all, a pre-release OS. :(

[DBelton]

Same here.

I noticed there is another update to gvfs sitting out in updates-testing, but I can't install it due to dependency problems. :(

Which brings up another issue. Has anyone noticed that this past month, there have been major problems with dependency problems in the F17 updates? More problems than in past releases? I have had 4 different packages (on a 64 bit install) try to install and bring in hundreds of 32 bit packages just in the past month.

[glennzo]

Same here.

I noticed there is another update to gvfs sitting out in updates-testing, but I can't install it due to dependency problems. :(

Which brings up another issue. Has anyone noticed that this past month, there have been major problems with dependency problems in the F17 updates? More problems than in past releases? I have had 4 different packages (on a 64 bit install) try to install and bring in hundreds of 32 bit packages just in the past month.

I'm not nearly as observant as you appear to be but yes, a lot of delendency issues on both of my Fedora 17 installs. Most of them solved by simply removing (with care) the offending package, provided its not something I need/want or something that is system critical.

[DBelton]

I just exclude it on the update of a standard --skip-broken doesn't work (like on the packages that try to bring in the 32 bit libs)

ImageMagick was the latest offender in that category, just this past week. A --skip-broken wouldn't work so I used a exclude=ImageMagick* so that I could get my other updates installed.

[glennzo]

I just exclude it on the update of a standard --skip-broken doesn't work (like on the packages that try to bring in the 32 bit libs)

ImageMagick was the latest offender in that category, just this past week. A --skip-broken wouldn't work so I used a exclude=ImageMagick* so that I could get my other updates installed.
I use that method also. Thankfully, --skip-broken seems to work a heck of a lot better than it used to.

What's the freakin' deal with the inability to mount these NTFS partitions though? Jeesh! As stated above, since I have an NTFS partition I can't even update grub. This is a problem for more than one reason. A new kernel for Fedora 17 will not be added to the boot menu. Likewise, if my Fedora 16 install gets a new kernel I won't be able to add that to the F17 boot menu either. I saw one other similar post but apparently no one else has run into the potential bug?

[DBelton]

That scenario would probably only hit people running multiple linux installs on the same machine with a Windows install where they pretty much have to run grub2-mkconfig to add new kernels from one install to the boot menu for another install.

Standard Win/1 Fedora install dual boot systems would be able to update the kernel since the kernel update uses grubby and not grub2-mkconfig.

But I am having the same bug here trying to access a NTFS disk on my Windows install when I boot linux. Anytime I try to browse my /mnt folder with nautilus, it hangs since there is one NTFS filesystem mounted in there, and it can't access it.

gvfs still hasn't been fixed in the repo so that I can update it, either :(

[glennzo]

I guess we're both stuck waiting for the next round of updates. In your opinion is GVFS the culprit or is it more likely something else?

[Dan]

Just got a FUSE utils and libs update. That may fix it. I've got no way to test.

[glennzo]

Figures. I got annoyed and decided to play with Winders for a while. Time to reboot.


Now back to Fedora 17 ...
No love, but a different error message in /var/log/messages.
Apr 15 19:39:16 b-satellite17 udevd[300]: specified user 'usbmux' unknown
Apr 15 19:42:06 b-satellite17 udevd[300]: specified user 'usbmux' unknown
Apr 15 19:42:39 b-satellite17 chronyd[561]: Selected source 216.240.130.137

Other than that, things are much the same here.

[DBelton]

there is also an update to usbmuxd sitting out there that I can't install due to dependency problems as well. Perhaps it fixes the error you got above.

[hadrons123]

@glennzo
did you file a bug report?
I 'm holding off this gvfs update for my f17. I have NTFS partition too.
But until now no new gvfs build is available.

[Apostate]

Just got a FUSE utils and libs update. That may fix it. I've got no way to test.

The FUSE update does not solve this

[glennzo]

@glennzo
did you file a bug report?
I 'm holding off this gvfs update for my f17. I have NTFS partition too.
But until now no new gvfs build is available.

I haven't filed yet. Wasn't sure what to file against because I see dbus errors also. Be my guest if you wish and go ahead an file a report.

[torsch]

I also had the problem mounting the ntfs partitions in F17. But after disabling selinux they were mounted again on reboot.

[glennzo]

But after disabling selinux they were mounted again on reboot.

Well I'll be dipped and rolled! I *thought* I had already tried that. Works a charm!

And, grub2-mkconfig works again!

Welcome to Fedora Forum torsch :blink:

[dd_wizard]

If you don't like running with selinux disabled, and don't want to wait for the fix to get pushed, do this:

$ sudo yum list installed selinux-policy*
...
Installed Packages
selinux-policy.noarch 3.10.0-114.fc17 @updates-testing
selinux-policy-devel.noarch 3.10.0-114.fc17 @updates-testing
selinux-policy-doc.noarch 3.10.0-114.fc17 @updates-testing
selinux-policy-targeted.noarch 3.10.0-114.fc17 @updates-testing

You should see selinux-policy and selinux-policy-targeted on a default install. Grab the packages listed by the command shown above from this (http://koji.fedoraproject.org/koji/buildinfo?buildID=313548) koji package and install them from disk.

sudo yum update selinux-policy*

BTW, has anybody else noticed you no longer need --nogpgcheck for local updates and installs? I've been wondering if that's a feature or a bug.

dd_wizard

P.S. Here's the pertinent bug 812798 (https://bugzilla.redhat.com/show_bug.cgi?id=812798).

[glennzo]

You rock too DD :)

[vallimar]

BTW, has anybody else noticed you no longer need --nogpgcheck for local updates and installs?
I've been wondering if that's a feature or a bug.

That was added awhile back. You can re-enable it if you want by adding/setting
the 'localpkg_gpgcheck' option to '1' in /etc/yum.conf.