Re: F8 k3b problem or just random glitch?
On Wednesday 18 June 2008 22:44:39 Gene Heskett wrote: Anne suggested setting it so it doesn't eject, but then the drive generally has no clue about how to access the disk, so that fails also. Your problem may be different from mine, then. All I know is that I burned just one DVD after I changed the setting and it verified. There is a 'depending on', but I may be burning again this afternoon. If so, I'll report back. Anne -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: F8 k3b problem or just random glitch?
On Wed, 18 Jun 2008 17:44:39 -0400, Gene Heskett wrote: The drive itself must read the equ of LSN0 from the disk, deduce the file system and configure itself, all the while poking at the disk to see what it really is. This process, on any drive I've ever owned, can take upwards of 75 seconds, and rarely less that 55. 55 seconds? Wow! No drive I know (multiple vendors) has ever before taken so much time to load and recognise an inserted CD/DVD. Unless it was cheap media burnt with a somewhat incompatible different writer, resulting in many problems to read it. It wouldn't keep trying for a full minute, though, but give up long before that. Generally, if during the time that the drive led is still on after the disk has been pulled back in, then k3b, or anything else that wants to read it can sit by silently, or take a dump and abort the operation. k3b, or whatever util is doing this latter, and really does need to learn to wait. And why does it work with kernel 2.6.23.15-137.fc8? Why is the drive ready to read with that kernel, but not with the newer ones? I think, I once read that k3b waits for the tray to be closed. Maybe that really is not enough, but the author(s) should know better as this must be documented in the specs somewhere. -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.11 1.21 0.94 -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: F8 k3b problem or just random glitch?
On Wed, 18 Jun 2008 19:19:28 -0400, Tom Horsley wrote: On Wed, 18 Jun 2008 18:23:28 -0400 Gene Heskett [EMAIL PROTECTED] wrote: I personally am not inclined to blame it on the kernel unless some error message was changed and whatever k3b uses to keep track of that stuff is now getting an answer it doesn't like or doesn't know how to translate. It sure *seems* like some recent update, if not the kernel itself. I'm running the same fedora 8 system with the same hardware in which k3b previously had no problems at least trying to verify, but with the latest kernel I got the no tracks message. Plus the redhat bugzilla pointed at earlier in this thread says the bug disappears if an earlier kernel is booted with all else the same, and that really makes it seem like a kernel issue. The bz ticket 440343 also quotes the difference in k3b log output between the non-working and working kernel. In either case, the newer kernels change something, which k3b can't cope with. Perhaps k3b is at fault and can be corrected. If it has different means to wait for a drive to become ready, it ought to implement them. The s/n ratio in the bz ticket gets worse, unfortunately, as more and more users are hit by this bug also in F9. -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.02 1.05 0.98 -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: F8 k3b problem or just random glitch?
On Thursday 19 June 2008, Michael Schwendt wrote: On Wed, 18 Jun 2008 17:44:39 -0400, Gene Heskett wrote: The drive itself must read the equ of LSN0 from the disk, deduce the file system and configure itself, all the while poking at the disk to see what it really is. This process, on any drive I've ever owned, can take upwards of 75 seconds, and rarely less that 55. 55 seconds? Wow! No drive I know (multiple vendors) has ever before taken so much time to load and recognise an inserted CD/DVD. Unless it was cheap media burnt with a somewhat incompatible different writer, resulting in many problems to read it. It wouldn't keep trying for a full minute, though, but give up long before that. I must have been thinking of the last dvd I burnt. I just inserted a ubuntu-8.04 LTS cd I burnt in that drive, and it was about 14 seconds till the led went out the last time and a what do we do with this new disk requester had popped up. That brought up good old konqui, in the single tree view mode. That brings up another question. I hear folks praising konquerer for its file manager abilities, but to me a file manager is a 2 pane operation ala mc. I always fall back to mc cuz it Just Works(TM), it can do lots of things krusader can't even think about doing. What the heck good is konquerer when an attempt to change directories in the left window throws away the right window? I fail to see how that can possibly be useful. I have not found a config option to make it a true, 2 pane file manager. So why do they call it that? unmounting that cd, and inserting an F7 install dvd, the recognition phase took about 20-21 seconds, but whatever pops up the what shall I do with this selector still hasn't 2 minutes later, so I mounted it by hand, and that took circa 10 seconds. So if, before k3b can verify the disk, it has to wait for that about 30 seconds to gain access to the file structure, or 20 seconds just for dd to be able to access the unmounted disk. The error/failure pops up about 2, maybe 3 seconds after it has pulled the disk back in, apparently unwilling to wait until the drive has accepted this 'new' media. All this BTW with kernel 2.6.26-rc6 doing the chores. Despite all the reports otherwise, I haven't been able to tie this non-working situation to a given kernel release. The last time I tried one of the fedora kernels to test something that someone was fussing about, I could not duplicate their problem. Normally, when yum installs a new kernel, it also does a very poor job of editing my grub.conf, over-writing my default choice, and messing with the numbering system I use there. So when I see yum put in a new kernel, the first thing I do is go fix my grub.conf again. Sort of a fetish I guess. :) Generally, if during the time that the drive led is still on after the disk has been pulled back in, then k3b, or anything else that wants to read it can sit by silently, or take a dump and abort the operation. k3b, or whatever util is doing this latter, and really does need to learn to wait. And why does it work with kernel 2.6.23.15-137.fc8? No idea as I don't have a kernel that old on this system. My historical kernels start with 2.6.24.4, and the oldest fedora is vmlinuz-2.6.24.5-85.fc8. If that 2.6.23.15-137.fc8 is the kernel you are running, that would have to date to the original spin of the F8 release, and to not have upgraded since just to stay ahead of security concerns alone seems very careless to me. Why is the drive ready to read with that kernel, but not with the newer ones? I think, I once read that k3b waits for the tray to be closed. Maybe that really is not enough, but the author(s) should know better as this must be documented in the specs somewhere. These things are mechanical servo's, and there will be variations. As for specs, I don't have the money to purchase a copy of either the red book or the orange book. If it works, fine, if it doesn't, well I needed to go to town anyway didn't I? -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.11 1.21 0.94 -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) In order to dial out, it is necessary to broaden one's dimension. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: F8 k3b problem or just random glitch?
On Thursday 19 June 2008 12:17:20 Gene Heskett wrote: That brings up another question. I hear folks praising konquerer for its file manager abilities, but to me a file manager is a 2 pane operation ala mc. I always fall back to mc cuz it Just Works(TM), it can do lots of things krusader can't even think about doing. What the heck good is konquerer when an attempt to change directories in the left window throws away the right window? I fail to see how that can possibly be useful. I have not found a config option to make it a true, 2 pane file manager. So why do they call it that? What's wrong with 'split window'? I sometimes have more than two panes open at once in konqueror if I'm doing some sorting. Anne -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: F8 k3b problem or just random glitch?
On Thursday 19 June 2008, Anne Wilson wrote: On Thursday 19 June 2008 12:17:20 Gene Heskett wrote: That brings up another question. I hear folks praising konquerer for its file manager abilities, but to me a file manager is a 2 pane operation ala mc. I always fall back to mc cuz it Just Works(TM), it can do lots of things krusader can't even think about doing. What the heck good is konquerer when an attempt to change directories in the left window throws away the right window? I fail to see how that can possibly be useful. I have not found a config option to make it a true, 2 pane file manager. So why do they call it that? What's wrong with 'split window'? I sometimes have more than two panes open at once in konqueror if I'm doing some sorting. Anne It won't do it here, never has, and after bitching about it, I ran it to see if there was a config option that would force it, but its stuck in web browse mode forever here. Midnight Commander, aka mc, is the real swiss army knife, and its always nice and sharp, so while I may rail about konquerer, at the end of the day its a shrug cuz I already have a tool that does what I want. People are too darned enamored with eye candy, and that is another animal entirely from usefulness. Krusader is 'purty' I'll give it that, but where is the usefulness? 90% is missing. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The end of the human race will be that it will eventually die of civilization. -- Ralph Waldo Emerson -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: F8 k3b problem or just random glitch?
On Thursday 19 June 2008 12:49:27 Gene Heskett wrote: On Thursday 19 June 2008, Anne Wilson wrote: On Thursday 19 June 2008 12:17:20 Gene Heskett wrote: That brings up another question. I hear folks praising konquerer for its file manager abilities, but to me a file manager is a 2 pane operation ala mc. I always fall back to mc cuz it Just Works(TM), it can do lots of things krusader can't even think about doing. What the heck good is konquerer when an attempt to change directories in the left window throws away the right window? I fail to see how that can possibly be useful. I have not found a config option to make it a true, 2 pane file manager. So why do they call it that? What's wrong with 'split window'? I sometimes have more than two panes open at once in konqueror if I'm doing some sorting. Anne It won't do it here, never has, and after bitching about it, I ran it to see if there was a config option that would force it, but its stuck in web browse mode forever here. Midnight Commander, aka mc, is the real swiss army knife, and its always nice and sharp, so while I may rail about konquerer, at the end of the day its a shrug cuz I already have a tool that does what I want. People are too darned enamored with eye candy, and that is another animal entirely from usefulness. Krusader is 'purty' I'll give it that, but where is the usefulness? 90% is missing. Gene, I sometimes wonder just what you do to your systems :-) Why is it that things that work fine for everyone else just won't perform for you? It must be personal :-) Anne -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: F8 k3b problem or just random glitch?
On Wed, 18 Jun 2008 10:13:03 -0400, Tom Horsley wrote: I left a DVD-R being written by K3B, and when I came back later, it said the verify failed because there were no tracks to verify. However, when I mounted the dvd and did a sha1sum of the files I'd backed up, they matched perfectly the files on the DVD. Can I attribute this to random cosmic rays or something? Or has the new kernel screwed up something k3b depends on? Or has some new helpful security feature made k3b fail? (I guess I'll see what happens the next time I have a chunk of files to backup :-). I have certainly done a backup with verify via k3b many times before under F8 with no problems, but this may be the first time since fedora 8 got a 2.6.25 kernel. https://bugzilla.redhat.com/440343 As a work-around, downgrade to the older kernel mentioned in my sig. You can fetch it from koji, for example. -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.77 1.77 1.56 -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: F8 k3b problem or just random glitch?
On Wednesday 18 June 2008 15:13:03 Tom Horsley wrote: I left a DVD-R being written by K3B, and when I came back later, it said the verify failed because there were no tracks to verify. However, when I mounted the dvd and did a sha1sum of the files I'd backed up, they matched perfectly the files on the DVD. Can I attribute this to random cosmic rays or something? Or has the new kernel screwed up something k3b depends on? Or has some new helpful security feature made k3b fail? (I guess I'll see what happens the next time I have a chunk of files to backup :-). I have certainly done a backup with verify via k3b many times before under F8 with no problems, but this may be the first time since fedora 8 got a 2.6.25 kernel. Some versions of k3b fail to pull the disc back in for the verify, and that's the error message you get. At that point md5sum or sha1sum is, as you realised, the best bet for verifying. FWIW, I believe that I set my drive not to eject on completion, and I think that cured it. Anne -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: F8 k3b problem or just random glitch?
On Wed, 18 Jun 2008 11:07:45 -0400, Gene Heskett wrote: That is because the verify phase of k3b will not wait till the drive has recognized the disk after the eject cycle, so it errors out. I have squawked about that on the k3b bz, to no avail. Unfortunately, there are multiple issues. One is related to ejecting and closing the tray prior to verification. That breaks differently. In k3b bz I suspect there are multiple problem reports and duplicates, too. The ticket I've linked within Red Hat bz (440343 - 444344) is: http://bugs.kde.org/show_bug.cgi?id=157186 -- Fedora release 8 (Werewolf) - Linux 2.6.23.15-137.fc8 loadavg: 1.44 1.25 1.28 -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: F8 k3b problem or just random glitch?
On Wednesday 18 June 2008, Michael Schwendt wrote: On Wed, 18 Jun 2008 11:07:45 -0400, Gene Heskett wrote: That is because the verify phase of k3b will not wait till the drive has recognized the disk after the eject cycle, so it errors out. I have squawked about that on the k3b bz, to no avail. Unfortunately, there are multiple issues. One is related to ejecting and closing the tray prior to verification. That breaks differently. In k3b bz I suspect there are multiple problem reports and duplicates, too. The ticket I've linked within Red Hat bz (440343 - 444344) is: http://bugs.kde.org/show_bug.cgi?id=157186 And that one doesn't quite waddle like this duck, particularly when you put that spin on it. Mine opens and closes the drawer just fine, but only waits about 3 or 4 seconds before giving up. Anne suggested setting it so it doesn't eject, but then the drive generally has no clue about how to access the disk, so that fails also. The drive itself must read the equ of LSN0 from the disk, deduce the file system and configure itself, all the while poking at the disk to see what it really is. This process, on any drive I've ever owned, can take upwards of 75 seconds, and rarely less that 55. Generally, if during the time that the drive led is still on after the disk has been pulled back in, then k3b, or anything else that wants to read it can sit by silently, or take a dump and abort the operation. k3b, or whatever util is doing this latter, and really does need to learn to wait. -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) There are no great men, only great challenges that ordinary men are forced by circumstances to meet. -- Admiral William Halsey -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: F8 k3b problem or just random glitch?
On Wednesday 18 June 2008, Rex Dieter wrote: Gene Heskett wrote: On Wednesday 18 June 2008, Tom Horsley wrote: I left a DVD-R being written by K3B, and when I came back later, it said the verify failed because there were no tracks to verify. That is because the verify phase of k3b will not wait till the drive has recognized the disk after the eject cycle, so it errors out. I have squawked about that on the k3b bz, to no avail. I wasn't aware of that, if a wait is all that is required, that may be something we can patch easy enough. What's the bz you're referring to here? -- Rex You ask the damnedest questions, Rex. But I did search back through my corpus of email, and it didn't get bz'd I guess, but I did have a lengthy conversation with Sebastian Trueg about it without coming to any real solution that I can recall. The last disk I burnt was someplace in the 2.6.26-rc5-ish range for a kernel, and it still failed. The disk was fine by my own checks. Ubuntu-8.04's install TBE. I personally am not inclined to blame it on the kernel unless some error message was changed and whatever k3b uses to keep track of that stuff is now getting an answer it doesn't like or doesn't know how to translate. If it is a kernel problem, that's sure the area I'd have a tail on the ChangeLog for. :) -- Cheers, Gene There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) The lymbic system in my brain is so electrically active, it qualifies as a third brain. Normal humans have two brains, left and right. - Jeff Merkey -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
Re: F8 k3b problem or just random glitch?
On Wed, 18 Jun 2008 18:23:28 -0400 Gene Heskett [EMAIL PROTECTED] wrote: I personally am not inclined to blame it on the kernel unless some error message was changed and whatever k3b uses to keep track of that stuff is now getting an answer it doesn't like or doesn't know how to translate. It sure *seems* like some recent update, if not the kernel itself. I'm running the same fedora 8 system with the same hardware in which k3b previously had no problems at least trying to verify, but with the latest kernel I got the no tracks message. Plus the redhat bugzilla pointed at earlier in this thread says the bug disappears if an earlier kernel is booted with all else the same, and that really makes it seem like a kernel issue. -- fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
