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 attachment 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.
