Bugzilla Bug 221177

This is related to bug #186173 and friends, but doesn't appear to be a
duplicate.

With k3b-1.0.4 (with the do not eject medium after write process checkbox
checked), and indeed with previous versions, things were hunky dory, everything
worked and verified correctly.

With 1.0.4-r1, I now get an error similar to the errors in the family of bugs
above.  However, despite my having the no-eject checkbox checked, k3b is STILL
ejecting and reloading the disk, where with 1.0.4, IIRC, it did NOT eject the
disk, simply verified it without ejecting.

It appears one of three things is happening:

1) k3b may not be waiting long enough for the eject and remount, perhaps
because I have the don't eject checkbox checked, but for some reason it's
ejecting and reloading anyway.

2) Given that I get the following messages in syslog:

May  9 22:51:57 h2 cdrom: This disc doesn't have any tracks I recognize!
May  9 22:56:59 h2 UDF-fs: Partition marked readonly; forcing readonly mount
May  9 22:56:59 h2 UDF-fs INFO UDF: Mounting volume 'DVD_VIDEO_RECORDER',
timestamp 2004/11/03 18:45 (1e5c)

perhaps k3b is taking that cdrom error and failing, even tho UDF-fs then mounts
it fine.

That's weird, tho, because the corresponding fstab entry is:
/dev/sr0  /m/dvd  udf,iso9660  user,exec,noauto,ro  0 0

Is it really trying CD/ISO before UDF, despite the fstab entry having the
REVERSE order?  And when it does do the UDF, why is it saying it is forcing
read-only , when the fstab entry says to mount it read-only in the first place?
WTF?  Is it trying to ignore my fstab entry?  At least it ends up mounted where
and how it's supposed to mount, /m/dvd, udf read-only, but why the messages
suggesting it's trying something else first, despite the fstab entry telling it
otherwise?

Talking about the fstab entry...

3) I also get an error (dialog, either k3b or perhaps hal/kde/whatever, that
error doesn't appear to show up in syslog and I forgot to copy it before
closing the dialog) about /media/sr0.  However, I have /dev/sr0 set to mount to
/m/dvd in fstab (/mnt is a symlink to /m on my system, /m being shorter...),
and that's where it ultimately does mount.  Maybe hal is trying to mount it on
/media/sr0 and/or k3b is expecting it there, and therefore doesn't see it on
/m/dvd even tho that's in fstab, or maybe there's an error trying to mount it
to /media/* and that's what triggers k3b to fail the verify.

In any case, before the patch trying to "fix" things that went into -r1, it
worked fine.  Now, it fails.  The "fix" appears to have broken a working
system, here.

FWIW, I was able to "md5sum /dev/sr0" and manually compare that to the sum k3b
gave me for the ISO.  It verified correct.  However, it should be verifying on
its own, as it did before the "fix" in -r1 broke things.

emerge --info to be attached.

Created an attachment (id=152721) [details]
emerge --info

emerge --info

I did an emerge --emptytree world recently after upgrading to gcc-4.3.0, use
emerge -NuD world regularly when updating, and regularly do revdep-rebuild and
emerge --depclean afterward as well, thus keeping the system as clean and fully
updated as possible.

I ask the ebuild maintainer to close this bug and ask user to reopen if the
problem reappears. The breakish patch has been removed some time ago, as stated
in the ChangeLog:

*k3b-1.0.5-r1 (13 Jun 2008)

  13 Jun 2008; Carsten Lohrke <carlo@gentoo.org>
  +files/k3b-1.0.5-desktop-entry.diff, +k3b-1.0.5-r1.ebuild:
  Fix .desktop entry stuff properly, get rid of the seemingly improper patch
  for bug #186173, see also bug #221177.