8:37 a.m.
With all the latest updates for F10 installed, I tried
to burn yet another dual layer DVD+R today to see if any
progress has been made on:
https://bugzilla.redhat.com/show_bug.cgi?id=440343
Unfortunately, the last comment I added there still
happens: K3B successfully writes the DVD, ejects it,
then never reloads it to try to do the verify.
This time the K3B GUI was frozen up again and I had
to kill it.
On the chance that some part of the KDE environment
is expected to exist, I tried it this time as a new
user running in a KDE session, but same results.
This is with kernel 2.6.27.5-109.fc10.x86_64
and K3B k3b-1.0.5-6.fc10.x86_64
8:51 a.m.
On Sat, 2008-11-15 at 09:37 -0500, Tom Horsley wrote:
With all the latest updates for F10 installed, I tried
to burn yet another dual layer DVD+R today to see if any
progress has been made on:
https://bugzilla.redhat.com/show_bug.cgi?id=440343
Unfortunately, the last comment I added there still
happens: K3B successfully writes the DVD, ejects it,
then never reloads it to try to do the verify.
This time the K3B GUI was frozen up again and I had
to kill it.
On the chance that some part of the KDE environment
is expected to exist, I tried it this time as a new
user running in a KDE session, but same results.
This is with kernel 2.6.27.5-109.fc10.x86_64
and K3B k3b-1.0.5-6.fc10.x86_64
I'm also running F10 updated but I'm seeing a slightly different
phenomenon. After burning a DVD K3B complains that it can't eject it. If
the Verify option is set, it then proceeds to verify anyway. K3B doesn't
freeze (or hasn't so far ...)
I can eject the DVD from the Shell: eject dvd
Kernel 2.6.27.5-109.fc10.x86_64. The drive is an LG GSA-4163B.
poc
9:18 a.m.
On Saturday 15 November 2008 14:37:26 Tom Horsley wrote:
With all the latest updates for F10 installed, I tried
to burn yet another dual layer DVD+R today to see if any
progress has been made on:
https://bugzilla.redhat.com/show_bug.cgi?id=440343
Unfortunately, the last comment I added there still
happens: K3B successfully writes the DVD, ejects it,
then never reloads it to try to do the verify.
This time the K3B GUI was frozen up again and I had
to kill it.
On the chance that some part of the KDE environment
is expected to exist, I tried it this time as a new
user running in a KDE session, but same results.
This is with kernel 2.6.27.5-109.fc10.x86_64
and K3B k3b-1.0.5-6.fc10.x86_64
Surprise, surprise! It looks as though Mandriva have a later version, for
once :-) I have k3b-1.0.5-9mdv2009.0.
Yesterday I burned a disk. It ejected, but couldn't pull the drive back in.
(I understand this is a matter of drive capability, and whether it sends the
correct signals.) When I pushed it back in it proceeded to verify,
completing, and telling me that the tracks were not equivalent. Since this
was an ISO burn it was a simple matter to do a pair of md5sums. They matched,
so I accepted it as a good burn.
Anne
9:56 a.m.
On Sat, 15 Nov 2008 15:18:55 +0000
Anne Wilson <cannewilson(a)googlemail.com> wrote:
When I pushed it back in it proceeded to verify
When I push the drive back in, nothing happens, K3B
still just sits there :-(.
It does write the data correctly. I can compare the
checksums of the originals and the written files
and they match.
9:57 a.m.
On Sat, 15 Nov 2008 15:18:55 +0000, Anne Wilson wrote:
> This is with kernel 2.6.27.5-109.fc10.x86_64
> and K3B k3b-1.0.5-6.fc10.x86_64
Surprise, surprise! It looks as though Mandriva have a later version, for
once :-) I have k3b-1.0.5-9mdv2009.0.
Both are k3b 1.0.5 just with a different RPM package release. Without
examining the package contents (and the applied patches), you cannot
conclude that it is "a later version" of some sort.
Yesterday I burned a disk. It ejected, but couldn't pull the
drive back in.
(I understand this is a matter of drive capability, and whether it sends the
correct signals.) When I pushed it back in it proceeded to verify,
completing, and telling me that the tracks were not equivalent. Since this
was an ISO burn it was a simple matter to do a pair of md5sums. They matched,
so I accepted it as a good burn.
This is still the aging https://bugzilla.redhat.com/440343 problem.
10:06 a.m.
On Saturday 15 November 2008 15:57:25 Michael Schwendt wrote:
On Sat, 15 Nov 2008 15:18:55 +0000, Anne Wilson wrote:
> > This is with kernel 2.6.27.5-109.fc10.x86_64
> > and K3B k3b-1.0.5-6.fc10.x86_64
>
> Surprise, surprise! It looks as though Mandriva have a later version,
> for once :-) I have k3b-1.0.5-9mdv2009.0.
Both are k3b 1.0.5 just with a different RPM package release. Without
examining the package contents (and the applied patches), you cannot
conclude that it is "a later version" of some sort.
> Yesterday I burned a disk. It ejected, but couldn't pull the drive back
> in. (I understand this is a matter of drive capability, and whether it
> sends the correct signals.) When I pushed it back in it proceeded to
> verify, completing, and telling me that the tracks were not equivalent.
> Since this was an ISO burn it was a simple matter to do a pair of
> md5sums. They matched, so I accepted it as a good burn.
This is still the aging https://bugzilla.redhat.com/440343 problem.
On some of my workstations I have to set the drive to not eject, in order for
verify to work. When this one continued to verify after I had manually pushed
the door back in I felt that it was at least a step forward :-)
Anne
12:27 p.m.
2008/11/15 Anne Wilson <cannewilson(a)googlemail.com>
On Saturday 15 November 2008 15:57:25 Michael Schwendt wrote:
> On Sat, 15 Nov 2008 15:18:55 +0000, Anne Wilson wrote:
> > > This is with kernel 2.6.27.5-109.fc10.x86_64
> > > and K3B k3b-1.0.5-6.fc10.x86_64
> >
> > Surprise, surprise! It looks as though Mandriva have a later version,
> > for once :-) I have k3b-1.0.5-9mdv2009.0.
>
> Both are k3b 1.0.5 just with a different RPM package release. Without
> examining the package contents (and the applied patches), you cannot
> conclude that it is "a later version" of some sort.
>
> > Yesterday I burned a disk. It ejected, but couldn't pull the drive
back
> > in. (I understand this is a matter of drive capability, and whether it
> > sends the correct signals.) When I pushed it back in it proceeded to
> > verify, completing, and telling me that the tracks were not equivalent.
> > Since this was an ISO burn it was a simple matter to do a pair of
> > md5sums. They matched, so I accepted it as a good burn.
>
> This is still the aging https://bugzilla.redhat.com/440343 problem.
On some of my workstations I have to set the drive to not eject, in order
for
verify to work. When this one continued to verify after I had manually
pushed
the door back in I felt that it was at least a step forward :-)
as far as i can remember, last stable k3b was on f7 or before. right now, on
same (f9) system, k3b may verify and succeed, verify and fail, eject but
not close the tray to verify, or not eject at all. i've seen this behaviour
with hal support disabled or enabled, on different systems.
Anne
--
fedora-test-list mailing list
fedora-test-list(a)redhat.com
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
--
Linux counter #213090
6:50 a.m.
Michael Schwendt wrote:
This is still the aging https://bugzilla.redhat.com/440343 problem.
Yes, would be wonderfully nice if a kernel hacker or maintainer would ever
at least comment.
-- Rex
3:59 p.m.
On Mon, 17 Nov 2008 06:50:46 -0600
Rex Dieter <rdieter(a)math.unl.edu> wrote:
> This is still the aging https://bugzilla.redhat.com/440343
problem.
Yes, would be wonderfully nice if a kernel hacker or maintainer would ever
at least comment.
I'm not convinced it is the kernel anymore. After all, the F10 preview
can now tell that there is no media in the drive without waiting forever,
so it seems like at least some aspects of the drive status are fixed with
the latest drivers, yet k3b is still not functional, so this may be
entirely a k3b issue at this point (though it would still be nice to
know what the heck is going on).
12:12 p.m.
2008/11/17 Tom Horsley <tom.horsley(a)att.net>
On Mon, 17 Nov 2008 06:50:46 -0600
Rex Dieter <rdieter(a)math.unl.edu> wrote:
> > This is still the aging https://bugzilla.redhat.com/440343 problem.
>
> Yes, would be wonderfully nice if a kernel hacker or maintainer would
ever
> at least comment.
I'm not convinced it is the kernel anymore. After all, the F10 preview
can now tell that there is no media in the drive without waiting forever,
so it seems like at least some aspects of the drive status are fixed with
the latest drivers, yet k3b is still not functional, so this may be
entirely a k3b issue at this point (though it would still be nice to
know what the heck is going on).
maybe hal ....
--
fedora-test-list mailing list
fedora-test-list(a)redhat.com
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
--
Linux counter #213090
12:38 p.m.
cornel panceac wrote:
2008/11/17 Tom Horsley <tom.horsley(a)att.net>
> On Mon, 17 Nov 2008 06:50:46 -0600
> Rex Dieter <rdieter(a)math.unl.edu> wrote:
>
>>> This is still the aging https://bugzilla.redhat.com/440343 problem.
>> Yes, would be wonderfully nice if a kernel hacker or maintainer would
> ever
>> at least comment.
> I'm not convinced it is the kernel anymore. After all, the F10 preview
> can now tell that there is no media in the drive without waiting forever,
> so it seems like at least some aspects of the drive status are fixed with
> the latest drivers, yet k3b is still not functional, so this may be
> entirely a k3b issue at this point (though it would still be nice to
> know what the heck is going on).
maybe hal ....
Have you tried another burning tool such as xcdroast or nautilus-
cd-burner (yes, a Gnome thing) just to isolate it? If those tools
behave the same way, then I'd look deeper in the OS (hal, etc.).
Considering that KDE is still in flux a bit I'd lean towards k3b having
issues rather than the underlying system, but I'm not going to be
pedantic about it since I don't have F10 running anywhere just yet and I
rarely use KDE anyway. Divide and conquer.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer ricks(a)nerd.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- To iterate is human, to recurse, divine. -
----------------------------------------------------------------------
3:12 p.m.
Rick Stevens wrote:
Considering that KDE is still in flux a bit I'd lean towards k3b
having
issues rather than the underlying system,
The k3b application, for the most part, has remained unchanged since f7, so
no real flux in this case. Things "broke" at some point with a *kernel*
update (in f7 time-frame), and has remained in various forms since. You be
the judge.
-- Rex
1:55 a.m.
On Tue, 18 Nov 2008 15:12:44 -0600, Rex Dieter wrote:
Rick Stevens wrote:
> Considering that KDE is still in flux a bit I'd lean towards k3b having
> issues rather than the underlying system,
The k3b application, for the most part, has remained unchanged since f7, so
no real flux in this case. Things "broke" at some point with a *kernel*
update (in f7 time-frame), and has remained in various forms since. You be
the judge.
Still, it could need a work-around in k3b, e.g. making sure the medium is
accessible/readable prior to calculating the written image checksum.
Whether that is done in the k3b code so far is not clear. The symptoms
have changed to "No tracks to verify found", so it doesn't even start to
calculate a checksum. Problems with reloading the open tray could be
separate issues.
I'm not aware of any breakage in f7 time-frame, but f8:
https://bugzilla.redhat.com/show_bug.cgi?id=440343#c4
The k3b upstream ticket is in state "UNCONFIRMED" since February, since
none of the bug reporters has the permission to change the state, and
Sebastian Trüg or another upstream dev has not added a comment yet either.
The problem is not specific to Fedora, but at the same pace new Fedora
kernels are released, I would have to retest CD-RW and DVD-R burning
frequently. Currently I believe that CD-RW no longer suffer from the
problem. DVD-R cannot be verified automatically. Multi-session DVD-R
cannot be mounted automatically by Fedora, i.e. the underlying system
also fails to recognise any written track.
7:05 a.m.
Michael Schwendt wrote:
I'm not aware of any breakage in f7 time-frame, but f8:
https://bugzilla.redhat.com/show_bug.cgi?id=440343#c4
The k3b upstream ticket is in state "UNCONFIRMED" since February, since
none of the bug reporters has the permission to change the state, and
Sebastian Trüg or another upstream dev has not added a comment yet either.
Yeah, upstream hasn't been all that helpful here either (grumble, grumble, I should
have mentioned that previously as well).
-- Rex
9:42 a.m.
On Wed, Nov 19, 2008 at 3:05 PM, Rex Dieter <rdieter(a)math.unl.edu> wrote:
Michael Schwendt wrote:
> I'm not aware of any breakage in f7 time-frame, but f8:
> https://bugzilla.redhat.com/show_bug.cgi?id=440343#c4
>
> The k3b upstream ticket is in state "UNCONFIRMED" since February, since
> none of the bug reporters has the permission to change the state, and
> Sebastian Trüg or another upstream dev has not added a comment yet
either.
Yeah, upstream hasn't been all that helpful here either (grumble, grumble,
I should have mentioned that previously as well).
-- Rex
--
fedora-test-list mailing list
fedora-test-list(a)redhat.com
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
Is it a LG drive by any chance?
--
Aioanei Rares
schaiba(a)fedoraproject.org
"China is a big country, inhabited by many Chinese." --Charles de Gaulle
11:24 a.m.
On Thu, 20 Nov 2008 17:42:16 +0200, Aioanei Rares wrote:
Is it a LG drive by any chance?
Yes, see comments 34-36:
https://bugzilla.redhat.com/show_bug.cgi?id=440343#c34
It works flawlessly with older Linux dists.
9:08 a.m.
On Thu, Nov 20, 2008 at 7:24 PM, Michael Schwendt <
mschwendt.tmp0701.nospam(a)arcor.de> wrote:
On Thu, 20 Nov 2008 17:42:16 +0200, Aioanei Rares wrote:
> > > https://bugzilla.redhat.com/show_bug.cgi?id=440343#c4
> Is it a LG drive by any chance?
Yes, see comments 34-36:
https://bugzilla.redhat.com/show_bug.cgi?id=440343#c34
It works flawlessly with older Linux dists.
--
fedora-test-list mailing list
fedora-test-list(a)redhat.com
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list
I had this problem with a freshly bought LG DVD-RAM with rawhide...it was
definitely a kernel problem, which is now fixed. I think it's not
Fedora-specific, though.
--
Aioanei Rares
schaiba(a)fedoraproject.org
"China is a big country, inhabited by many Chinese." --Charles de Gaulle
10:46 a.m.
2008/11/18 Rick Stevens <ricks(a)nerd.com>
cornel panceac wrote:
> 2008/11/17 Tom Horsley <tom.horsley(a)att.net>
>
> On Mon, 17 Nov 2008 06:50:46 -0600
>> Rex Dieter <rdieter(a)math.unl.edu> wrote:
>>
>> This is still the aging https://bugzilla.redhat.com/440343 problem.
>>>>
>>> Yes, would be wonderfully nice if a kernel hacker or maintainer would
>>>
>> ever
>>
>>> at least comment.
>>>
>> I'm not convinced it is the kernel anymore. After all, the F10 preview
>> can now tell that there is no media in the drive without waiting forever,
>> so it seems like at least some aspects of the drive status are fixed with
>> the latest drivers, yet k3b is still not functional, so this may be
>> entirely a k3b issue at this point (though it would still be nice to
>> know what the heck is going on).
>>
>
>
> maybe hal ....
>
Have you tried another burning tool such as xcdroast or nautilus-
cd-burner (yes, a Gnome thing) just to isolate it? If those tools
behave the same way, then I'd look deeper in the OS (hal, etc.).
brasero ejects the disk and then fails wit: "the media can't be ejected" .
see attached file.
btw, hal is not managing the device because of powertop etc.
we also must not forget that the same system behaves differently in
apparently same conditions, just like when anaconda is unable to select the
same disk as the first disk on the system, on two successive tries.
Considering that KDE is still in flux a bit I'd lean towards k3b having
issues rather than the underlying system, but I'm not going to be
pedantic about it since I don't have F10 running anywhere just yet and I
rarely use KDE anyway. Divide and conquer.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer ricks(a)nerd.com -
- AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 -
- -
- To iterate is human, to recurse, divine. -
----------------------------------------------------------------------
--
fedora-test-list mailing list
fedora-test-list(a)redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
--
Linux counter #213090
5631
days inactive
5638
days old
18 comments
8 participants
participants (8)
-
Anne Wilson -
cornel panceac -
Michael Schwendt -
Patrick O'Callaghan -
Rares Aioanei -
Rex Dieter -
Rick Stevens -
Tom Horsley