Bug 808109

Not sure whether I have explained it correctly in my original request. Some more here.

After the above said update there are no links /dev/cdrom /dev/dvd pointing to /dev/sr0 anymore.

When I issue eject (just eject from the command line) I get an error 

eject: unable to find or open device for: `cdrom' 

(as there is no cdrom link); but if I issue /dev/sr0 it works.

There are links /dev/dvd2 and /dev/dvdrw2 pointing to /dev/sr0.

The nautilus file manager mounts without any problem when a dvd is inserted.

What is the standard way to mount cd/dvd/bd in Fedora(in my case F16 64 bit) with Gnome (in my case Gnome 3)? Should I change my script always to use /dev/sr0 instead of /dev/dvd (or /dev/cdrom)? Will /dev/sr0 not change?

After all there was no problem until the above said software update. But I also can agree that it may be something different from the software update.

Thanks

Please try the procedure detailed in bug #747114 comment #7.

*** This bug has been marked as a duplicate of bug 747114 ***

This seems to be different than the original cause of bug #747114 as it pre-dates the cups "PrivateTmp" change.  Marking this as not a duplicate.

*** Bug 806909 has been marked as a duplicate of this bug. ***

*** Bug 808121 has been marked as a duplicate of this bug. ***

Well, now there is a development in this issue; actually more trouble. After a write operation to the disc, I keep seeing the following in the /var/log/messages: 

Apr  2 09:30:29 hostname kernel: [340798.622317] VFS: busy inodes on changed media or resized disk sr0
Apr  2 09:30:32 hostname kernel: [340801.845138] VFS: busy inodes on changed media or resized disk sr0
Apr  2 09:31:52 hostname kernel: [340881.552248] VFS: busy inodes on changed media or resized disk sr0

and if I try to write to another disc with growisofs I see the following error:

:-( unable to O_EXCL /dev/sr0: someone was in time to remount?

To get the disc writing (at least once) I have to reboot the machine (I dont know which service that I should restart - I just reboot the machine).

Is this related to the original issue?

Cheers

What does 'rpm -q cups' say?

cups-1.5.2-6.fc16.x86_64

Could you please try with the test update cups-1.5.2-8.1.fc16?  See bug #807672 comment #12.

I have installed the package. It did not fix the problem Tim.

Thanks. (Did you try rebooting? Expect so...)

Now could you please try downgrading CUPS to this version?: 1.5.2-1.fc16
Packages are here:
http://koji.fedoraproject.org/koji/buildinfo?buildID=297555

Just download the relevant packages for your architecture and then run:

yum downgrade ./cups-*1.5.2-1.fc16.*.rpm

After rebooting, does the problem persist?

Hi Tim,

The commands 

yum downgrade ./cups-*1.5.2-1.fc16.*.rpm
yum downgrade cups-*1.5.2-1.fc16.*.rpm

failed with 

Loaded plugins: langpacks, presto, refresh-packagekit
No package ./cups-*1.5.2-1.fc16.*.rpm available.
Error: Nothing to do

Any other suggestions?

Thanks

'yum downgrade cups*.rpm' works for me

guna_pmk: you downloaded the packages?

My apologies Tim. I tried it before finishing the work and completely missed your download instructions. I have downloaded and downgraded cups successfully and tried again; the problem seems to be there still.

I think I have mentioned all the following previously; just to recap:

1. After a reboot, a dvd write works without a problem
2. Once a dvd is written ( I use growisofs for writing), the next one fails most of the time. It works sometime. But it is very inconsistent. All the times it fails to write, there is these lines in the /var/log/messages
    VFS: busy inodes on changed media or resized disk sr0
3. All this happens since my software update on 2012-03-29.
4. Since the a software update, I also have no links (/dev/dvd, /dev/dvdrw or /dev/cdrom) created pointing to /dev/sr0 (or whatever the dvd device is); but there are /dev/dvd2, /dev/dvdrw2, /dev/cdrom2 and /dev/cdrw2 links pointing to /dev/sr0.

Additionally, following is the contents of my /etc/udev/rules.d/70-persistent-cd.rules:
=====================================================================================================================
# This file was automatically generated by the /lib/udev/write_cd_rules
# program, run by the cd-aliases-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and set the $GENERATED variable.

# ATAPI_iHBS212_2 (pci-0000:00:1f.2-scsi-1:0:0:0)
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="cdrom", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="cdrw", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="dvd", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-1:0:0:0", SYMLINK+="dvdrw", ENV{GENERATED}="1"

# CD-ROM (pci-0000:00:1d.0-usb-0:1.6:1.0-scsi-0:0:0:1)
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_SERIAL}=="SEMC_CD-ROM_42583930324251573159-0:1", SYMLINK+="cdrom1", ENV{GENERATED}="1"

# ATAPI_iHBS212_2 (pci-0000:00:1f.2-scsi-0:0:0:0)
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="cdrom2", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="cdrw2", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="dvd2", ENV{GENERATED}="1"
SUBSYSTEM=="block", ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:1f.2-scsi-0:0:0:0", SYMLINK+="dvdrw2", ENV{GENERATED}="1"
=====================================================================================================================

Does the above ring any bell?

Please let me know if you need more information in this regard.

Thanks

Hi Tim,

More problems here. Not sure whether the latest downgrade caused the problem. But I have not encountered this problem earlier. I have a UDF image file which I mount to store and remove files. 

Now even after umounting, the loop device is not detached. But if I stop cups, the loop device is detached. But the previously stuck devices can not be retrieved. This is exactly the same as issue #758159.

I mount the image as follows:

mount -o loop /path/to/image.iso /mnt/image

to unmount:

umount /mnt/image

Cheers

Your most recent comment refers to bug #758159, which is an unresolved kernel bug.  However, in comment #15 you referred to a problem (after writing a DVD) which goes away when cups is not running.

When you tried cups-1.5.2-8.1.fc16, did you reboot before trying the DVD?  Please humour me, and try again: the 1.5.2-8.1 package is now a stable update and should be available either now or in the next couple of days.

Once you have cups-1.5.2-8.1.fc16 installed, reboot the machine and try your test again.

If you are still seeing "busy inodes" messages, could you please run "mount" to see if the disc is mounted?  If so, could you please run "fuser -mv /mnt/..." on the mount-point and find out which processes are keeping the file system mounted?

Hi Tim,

Sorry for the delay. I was away for some time.

To answer your questions,

"However, in comment #15 you referred to a problem (after writing a DVD)
which goes away when cups is not running." - I could not see any mention about cups in comment #15 Tim. I don't get the point here.

"When you tried cups-1.5.2-8.1.fc16, did you reboot before trying the DVD? " - Yes I did Tim.


I now have the latest cups (I have performed a complete system update). My new kernel is 3.3.1-5.fc16.x86_64. But it is still incosistent.

"If you are still seeing "busy inodes" messages, could you please run "mount" to
see if the disc is mounted?  If so, could you please run "fuser -mv /mnt/..."
on the mount-point and find out which processes are keeping the file system
mounted?" - That was the first thing I did when I saw the error messages. I even tried 

ls -l /proc/*/cwd | grep -i "cd\|dvd\|sr?"

The dvd device was not in use by any process.

Besides, testing this issue takes all my time; all I do now is reboot the machine once the disc is written. It is very disappointing :(.

We also have not found out the issue with the udev rules :(.

Cheers

OK.  Sorry, I must have mis-read the comment.

So I don't think cups is related to this problem any more.

Changing component to kernel.

I also upgraded a kernel and suddenly /dev/dvd disappeared but /dev/dvd2 pointed to sr0.  Looks something caused a different scsi address to be used for the same hardware...

< # ATAPI_iHBS212_2 (pci-0000:00:1f.2-scsi-1:0:0:0)
> # ATAPI_iHBS212_2 (pci-0000:00:1f.2-scsi-0:0:0:0)

< # HL-DT-STDVD+-RW_GSA-H31N (pci-0000:00:1f.2-scsi-4:0:0:0)
> # HL-DT-STDVD+-RW_GSA-H31N (pci-0000:00:1f.2-scsi-0:0:0:0)

I removed both sets of rules from /etc/udev/70-persistent-cd.rules and ran:
service udev restart

Now 70-persistent-cd.rules has just one set of rules for the DVD drive and /dev/dvd is back.

# Mass update to all open bugs.

Kernel 3.6.2-1.fc16 has just been pushed to updates.
This update is a significant rebase from the previous version.

Please retest with this kernel, and let us know if your problem has been fixed.

In the event that you have upgraded to a newer release and the bug you reported
is still present, please change the version field to the newest release you have
encountered the issue with.  Before doing so, please ensure you are testing the
latest kernel update in that release and attach any new and relevant information
you may have gathered.

If you are not the original bug reporter and you still experience this bug,
please file a new report, as it is possible that you may be seeing a
different problem. 
(Please don't clone this bug, a fresh bug referencing this bug in the comment is sufficient).

Isn't this the systemd namespace issue?

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.