I haven't used RW disks for ages, but since I wanted to experiment a bit, it seemed sensible. I put a CD-RW into k3b (FC4) and it erased it happily, but I can't get it to burn to the disk at all. I'm just getting messages like
Error trying to open /dev/hdd exclusively ... retrying in 1 second. /usr/bin/cdrecord: Device or resource busy. Cannot open '/dev/hdd'. Cannot open SCSI driver.
I did the same batch of files onto a CD-R without any problem at all.
Is this a known problem?
Anne
On Wed, 2006-03-15 at 15:11 +0000, Anne Wilson wrote:
I haven't used RW disks for ages, but since I wanted to experiment a bit, it seemed sensible. I put a CD-RW into k3b (FC4) and it erased it happily, but I can't get it to burn to the disk at all. I'm just getting messages like
Error trying to open /dev/hdd exclusively ... retrying in 1 second. /usr/bin/cdrecord: Device or resource busy. Cannot open '/dev/hdd'. Cannot open SCSI driver.
I did the same batch of files onto a CD-R without any problem at all.
Is this a known problem?
Sounds like something has the device mounted already. Check the mount table: df -vh
and make sure the device is not mounted. Then try k3b again.
On Wednesday 15 March 2006 15:16, Scot L. Harris wrote:
On Wed, 2006-03-15 at 15:11 +0000, Anne Wilson wrote:
I haven't used RW disks for ages, but since I wanted to experiment a bit, it seemed sensible. I put a CD-RW into k3b (FC4) and it erased it happily, but I can't get it to burn to the disk at all. I'm just getting messages like
Error trying to open /dev/hdd exclusively ... retrying in 1 second. /usr/bin/cdrecord: Device or resource busy. Cannot open '/dev/hdd'. Cannot open SCSI driver.
I did the same batch of files onto a CD-R without any problem at all.
Is this a known problem?
Sounds like something has the device mounted already. Check the mount table: df -vh
and make sure the device is not mounted. Then try k3b again.
That was the first thing I checked. And, as I said, k3b wrote to a CD-R immediately afterwards.
Anne
On Wed, 2006-03-15 at 15:33 +0000, Anne Wilson wrote:
That was the first thing I checked. And, as I said, k3b wrote to a CD-R immediately afterwards.
Does your drive support RW disks?
Anne
fedora-list mailing list fedora-list@redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
On Wednesday 15 March 2006 15:36, Tony Heaton wrote:
On Wed, 2006-03-15 at 15:33 +0000, Anne Wilson wrote:
That was the first thing I checked. And, as I said, k3b wrote to a CD-R immediately afterwards.
Does your drive support RW disks?
It's supposed to. Considering how long it is since I used a RW, though, it's possible that something is not as it was.
No - it's not the drive. I've just tried it in another drive - and with a different CD-RW.
Something very odd is happening with these disks. I get errors, as I said, if I ask it to simulate. I tried doing a burn without a simulation, and it went through the whole process, but then said it couldn't read the ISO9660 file system. Attemptint to mount the disk says that it doesn't exist.
It could be the disks, of course. I'll have to dig around and see if I can find a new one.
Anne
On Wednesday 15 March 2006 16:12, Anne Wilson wrote:
different CD-RW.
Something very odd is happening with these disks. I get errors, as I said, if I ask it to simulate. I tried doing a burn without a simulation, and it went through the whole process, but then said it couldn't read the ISO9660 file system. Attemptint to mount the disk says that it doesn't exist.
It could be the disks, of course. I'll have to dig around and see if I can find a new one.
I couldn't find a new CD-RW, so I tried a DVD-RW. They don't write either.
growisofs ----------------------- Executing 'builtin_dd if=/dev/fd/0 of=/dev/hdd obs=32k seek=0' /dev/hdd: "Current Write Speed" is 2.0x1385KBps. :-[ WRITE@LBA=0h failed with SK=5h/ASC=64h/ACQ=00h]: Input/output error :-( write failed: Input/output error
growisofs command: ----------------------- /usr/bin/growisofs -Z /dev/hdd=/dev/fd/0 -use-the-force-luke=notray -use-the-force-luke=tty -use-the-force-luke=tracksize:256694 -dvd-compat -speed=2
mkisofs ----------------------- 256694 INFO: UTF-8 character encoding detected by locale settings. Assuming UTF-8 encoded filenames on source filesystem, use -input-charset to override. Using 100_4044000.JPG;1 for Photos/Garden/100_4044.JPG (100_4044.jpg) Using 100_4039000.JPG;1 for Photos/Garden/100_4039.jpg (100_4039.JPG) Using 100_4036000.JPG;1 for Photos/Garden/100_4036.jpg (100_4036.JPG) /usr/bin/mkisofs: Connection reset by peer. cannot fwrite 2048*1
I can live without re-writeables, if there really is a problem, but if it's my system that has a problem it needs sorting.
Anne
Anne Wilson wrote:
:-[ WRITE@LBA=0h failed with SK=5h/ASC=64h/ACQ=00h]: Input/output error :-( write failed: Input/output error
I can live without re-writeables, if there really is a problem, but if it's my system that has a problem it needs sorting.
Anything wandering around in /var/log/messages about that IO Error?
-Andy
Andy Green wrote:
Anne Wilson wrote:
:-[ WRITE@LBA=0h failed with SK=5h/ASC=64h/ACQ=00h]: Input/output error :-( write failed: Input/output error
I can live without re-writeables, if there really is a problem, but if it's my system that has a problem it needs sorting.
Anything wandering around in /var/log/messages about that IO Error?
Hm also did you erase these CDRWs first?
-Andy
On Wednesday 15 March 2006 16:54, Andy Green wrote:
Anne Wilson wrote:
:-[ WRITE@LBA=0h failed with SK=5h/ASC=64h/ACQ=00h]: Input/output error :-( write failed: Input/output error
I can live without re-writeables, if there really is a problem, but if it's my system that has a problem it needs sorting.
Anything wandering around in /var/log/messages about that IO Error?
Lots -
Mar 15 16:33:04 david kernel: ide: failed opcode was: unknown Mar 15 16:33:04 david kernel: end_request: I/O error, dev hdd, sector 168 Mar 15 16:33:04 david kernel: hdd: media error (bad sector): status=0x51 { DriveReady SeekComplete Error } Mar 15 16:33:04 david kernel: hdd: media error (bad sector): error=0x30 { LastFailedSense=0x03 } Mar 15 16:33:04 david kernel: ide: failed opcode was: unknown Mar 15 16:33:04 david kernel: end_request: I/O error, dev hdd, sector 176 Mar 15 16:33:04 david kernel: hdd: media error (bad sector): status=0x51 { DriveReady SeekComplete Error } Mar 15 16:33:04 david kernel: hdd: media error (bad sector): error=0x30 { LastFailedSense=0x03 } Mar 15 16:33:04 david kernel: ide: failed opcode was: unknown Mar 15 16:33:04 david kernel: end_request: I/O error, dev hdd, sector 184 Mar 15 16:33:04 david kernel: hdd: media error (bad sector): status=0x51 { DriveReady SeekComplete Error } Mar 15 16:33:04 david kernel: hdd: media error (bad sector): error=0x30 { LastFailedSense=0x03 } Mar 15 16:33:04 david kernel: ide: failed opcode was: unknown Mar 15 16:33:04 david kernel: end_request: I/O error, dev hdd, sector 192
and lots more like it.
Hm also did you erase these CDRWs first?
I did - using k3b.
I've just found a brand-new cd-rw and again k3b appeared to do the burn, but when it came to the verify it said it couldn't read the ISO9660 file system. I cannot mount the disk - konqueror says it doesn't know the file system. This time there were no errors in messages when it failed to read the file system.
Either there is a big problem with k3b or my drive, I think. And I'm worried that both drives I have tried have the same problem.
Anne
On Wed, 2006-03-15 at 17:49 +0000, Anne Wilson wrote:
On Wednesday 15 March 2006 16:54, Andy Green wrote:
Anne Wilson wrote:
:-[ WRITE@LBA=0h failed with SK=5h/ASC=64h/ACQ=00h]: Input/output error :-( write failed: Input/output error
I can live without re-writeables, if there really is a problem, but if it's my system that has a problem it needs sorting.
Anything wandering around in /var/log/messages about that IO Error?
Lots -
Mar 15 16:33:04 david kernel: ide: failed opcode was: unknown Mar 15 16:33:04 david kernel: end_request: I/O error, dev hdd, sector 168 Mar 15 16:33:04 david kernel: hdd: media error (bad sector): status=0x51 { DriveReady SeekComplete Error } Mar 15 16:33:04 david kernel: hdd: media error (bad sector): error=0x30 { LastFailedSense=0x03 } Mar 15 16:33:04 david kernel: ide: failed opcode was: unknown Mar 15 16:33:04 david kernel: end_request: I/O error, dev hdd, sector 176 Mar 15 16:33:04 david kernel: hdd: media error (bad sector): status=0x51 { DriveReady SeekComplete Error } Mar 15 16:33:04 david kernel: hdd: media error (bad sector): error=0x30 { LastFailedSense=0x03 } Mar 15 16:33:04 david kernel: ide: failed opcode was: unknown Mar 15 16:33:04 david kernel: end_request: I/O error, dev hdd, sector 184 Mar 15 16:33:04 david kernel: hdd: media error (bad sector): status=0x51 { DriveReady SeekComplete Error } Mar 15 16:33:04 david kernel: hdd: media error (bad sector): error=0x30 { LastFailedSense=0x03 } Mar 15 16:33:04 david kernel: ide: failed opcode was: unknown Mar 15 16:33:04 david kernel: end_request: I/O error, dev hdd, sector 192
and lots more like it.
Hm also did you erase these CDRWs first?
I did - using k3b.
I've just found a brand-new cd-rw and again k3b appeared to do the burn, but when it came to the verify it said it couldn't read the ISO9660 file system. I cannot mount the disk - konqueror says it doesn't know the file system. This time there were no errors in messages when it failed to read the file system.
Either there is a big problem with k3b or my drive, I think. And I'm worried that both drives I have tried have the same problem.
Anne
Anne,
Cabling? I would have expected DMA messages, nevertheless are you using 80-pin cabling?
After the long thread about which end is which: The blue end to the motherboard, single drive (or master) at the other end of the cable.
Bob...
On Wednesday 15 March 2006 18:27, Bob Chiodini wrote:
Cabling? I would have expected DMA messages, nevertheless are you using 80-pin cabling?
After the long thread about which end is which: The blue end to the motherboard, single drive (or master) at the other end of the cable.
I'd have to pull out the furniture to check, but as far as I can remember the dvd-rom and dvd-rw drives are on ide2 and using 40-wire cable. It's worked in the past, though as I mentioned earlier, the problem appears to be related to rw disks, which I don't normally use.
Anne
On Wed, 2006-03-15 at 16:12 +0000, Anne Wilson wrote:
Something very odd is happening with these disks. I get errors, as I said, if I ask it to simulate. I tried doing a burn without a simulation, and it went through the whole process, but then said it couldn't read the ISO9660 file system. Attemptint to mount the disk says that it doesn't exist.
I just talked about this very subject on the fedora beta list. It seems if I burn a new cd-rw disk, it seems to work fine. But if I try to reburn it, it wouldn't do it. I think someone mentioned that they unmounted it and it still had problems.
On Wednesday 15 March 2006 20:40, Mike Chambers wrote:
On Wed, 2006-03-15 at 16:12 +0000, Anne Wilson wrote:
Something very odd is happening with these disks. I get errors, as I said, if I ask it to simulate. I tried doing a burn without a simulation, and it went through the whole process, but then said it couldn't read the ISO9660 file system. Attemptint to mount the disk says that it doesn't exist.
I just talked about this very subject on the fedora beta list. It seems if I burn a new cd-rw disk, it seems to work fine. But if I try to reburn it, it wouldn't do it. I think someone mentioned that they unmounted it and it still had problems.
I'm fairly sure that I've tracked it down, Mike.
Someone told me off-list to try to burn a short iso using cdrecord in a terminal. The command I used was
cdrecord dev=/dev/hdd -vvvvvvvv -blank=disc /home/anne/test.iso
and it failed. I googled on 'faio_wait_on_buffer for writer timed out' and found that others were complaining of the same problem. Then someone reported that if you split the command into two, it works perfectly, so I did
cdrecord -vv dev=/dev/hdd blank=all cdrecord -vv dev=/dev/hdd /home/anne/test.iso
and it wrote perfectly - this to a disk that k3b had been totally unable to deal with.
It looks as though there is actually a bug in cdrecord, which is causing k3b to fail.
Anne
Anne Wilson wrote:
On Wednesday 15 March 2006 20:40, Mike Chambers wrote:
On Wed, 2006-03-15 at 16:12 +0000, Anne Wilson wrote:
Something very odd is happening with these disks. I get errors, as I said, if I ask it to simulate. I tried doing a burn without a simulation, and it went through the whole process, but then said it couldn't read the ISO9660 file system. Attemptint to mount the disk says that it doesn't exist.
I just talked about this very subject on the fedora beta list. It seems if I burn a new cd-rw disk, it seems to work fine. But if I try to reburn it, it wouldn't do it. I think someone mentioned that they unmounted it and it still had problems.
I'm fairly sure that I've tracked it down, Mike.
Someone told me off-list to try to burn a short iso using cdrecord in a terminal. The command I used was
cdrecord dev=/dev/hdd -vvvvvvvv -blank=disc /home/anne/test.iso
and it failed. I googled on 'faio_wait_on_buffer for writer timed out' and found that others were complaining of the same problem. Then someone reported that if you split the command into two, it works perfectly, so I did
cdrecord -vv dev=/dev/hdd blank=all cdrecord -vv dev=/dev/hdd /home/anne/test.iso
and it wrote perfectly - this to a disk that k3b had been totally unable to deal with.
It looks as though there is actually a bug in cdrecord, which is causing k3b to fail.
Anne
Nice catch!
Which versions of cdrecord and k3b are you using?
Thanks,
John
On Wednesday 15 March 2006 22:56, John Wendel wrote:
Nice catch!
Which versions of cdrecord and k3b are you using?
k3b 0.12.10 (Using KDE 3.5.1-0.1.fc4 Red Hat)
Cdrecord-Clone 2.01-dvd
Also, in LogWatch today -
--------------------- Kernel Begin ------------------------
WARNING: Kernel Errors Present Buffer I/O error on device hdc, l...: 47 Time(s) end_request: I/O error, dev hdc, sector...: 1363 Time(s) hdc: command error: error=0x54 { Ab...: 1358 Time(s) hdc: command error: status=0x51 { D...: 1358 Time(s)
---------------------- Kernel End -------------------------
Which presumably refers to my attempts to burn.
Anne
Anne Wilson wrote: [that she had problems erasing CDROMs RW]
How did this ever come out?
Mike
On Tuesday 21 March 2006 06:26, Mike McCarty wrote:
Anne Wilson wrote: [that she had problems erasing CDROMs RW]
How did this ever come out?
Not sure what you are asking, Mike. Did you not see my answer to Mike Chambers?
k3b seems to be unhappy about writing to CD-RW, at least on my system. Come to think of it, it has been so for a very long time - a couple of years or more, which is why I had stopped using them. I can burn them from the CLI, but not from k3b. I haven't tested in xcdroast since I corrected the character-set problem. I'll try to do that today. Feel free to contact me off-list if you want to ask questions that would bore other readers ;-)
Anne
On Tuesday 21 March 2006 09:28, Anne Wilson wrote:
I haven't tested in xcdroast since I corrected the character-set problem. I'll try to do that today.
Data set 1 - 300MB if mp3s
CD-RW - xcdroast - fast blank, couldn't calculate size with Joliet set, but burned when Joliet option removed.
CD-RW - k3b - fast blank. With Joliet set, complained about file names containing illegal characters, but burned them anyway once Joliet was removed!
Data set 2 - 1.5 GB mp3s
DVD-RW - k3b - blank attempted to said to be unnecessary, overwrite accepted. With Joliet set, said it couldn't calculate burn size (NB not the same error message as when burning the CD-RW). With Joliet removed, burn completed and verified.
Conclusions? Clearly no Joliet, but apart from that the error messages may be misleading. Maybe the fact that I couldn't get them to burn at all after my problems a few days ago stem from something that was cached? I don't know. Even the 'illegal characters' caused no problems this time.
Anne
Anne Wilson wrote:
I haven't used RW disks for ages, but since I wanted to experiment a bit, it seemed sensible. I put a CD-RW into k3b (FC4) and it erased it happily, but I can't get it to burn to the disk at all.
There is a new version of k3b for both FC4 and FC5 in updates-testing. Harold Hoyer has asked on fedora-test-list that people please test it. If you are still having problems with k3b, you might want to try it.
You will have to temporarily enable updates-testing to install this: try something like yum --enablerepo=updates-testing update k3b If you find any bugs in the new updates-testing, please check they aren't in bugzilla, and if they aren't, add them.
The usual disclaimer applies: this is a test release of the k3b package (based on a new upstream version). It may have fixed some bugs and introduced others, and there's no guarantee what those bugs might do...
I don't have k3b installed on my system, so I obviously don't have anything that depends on it. If this is true for you, and you want to revert k3b, the easiest way will be to uninstall and reinstall from stable repos.
James.
On Thursday 23 March 2006 13:01, James Wilkinson wrote:
There is a new version of k3b for both FC4 and FC5 in updates-testing. Harold Hoyer has asked on fedora-test-list that people please test it. If you are still having problems with k3b, you might want to try it.
I saw that, and did wonder about trying it. However, my problems seem to have been resolved, so from that point of view I would not be able to say whether there was any improvement or not.
If, on the other hand, there would still be a benefit to the community in installing and testing it, I may be able to do that tomorrow. Otherwise it would have to wait until after the weekend.
Anne
On 3/23/06, James Wilkinson fedora@westexe.demon.co.uk wrote:
Anne Wilson wrote:
I haven't used RW disks for ages, but since I wanted to experiment a bit, it seemed sensible. I put a CD-RW into k3b (FC4) and it erased it happily, but I can't get it to burn to the disk at all.
There is a new version of k3b for both FC4 and FC5 in updates-testing. Harold Hoyer has asked on fedora-test-list that people please test it. If you are still having problems with k3b, you might want to try it.
Hello everyone,
I am getting the same error as Anne did - not only with k3b but also with Gnomebaker. The problem occurs whenever I try to erase a CD/RW disc.
Any help would be appreciated.
Below is the error log from k3b:
System ----------------------- K3b Version: 0.12.14
KDE Version: 3.5.1-2.3 Red Hat QT Version: 3.3.5 Kernel: 2.6.16-1.2080_FC5 Devices ----------------------- HL-DT-ST RW/DVD GCC-4521B 1.05 (/dev/hdd, ) at [CD-R; CD-RW; CD-ROM; DVD-ROM] [DVD-ROM; CD-ROM; CD-R; CD-RW] [SAO; TAO; RAW; SAO/R96P; SAO/R96R; RAW/R16; RAW/R96P; RAW/R96R]
Used versions ----------------------- cdrecord: 2.1.1a03
cdrecord command: ----------------------- /usr/bin/cdrecord -v gracetime=2 dev=/dev/hdd speed=6320481 -tao driveropts=burnfree -eject blank=fast -force
cdrecord ----------------------- /usr/bin/cdrecord: Cannot allocate memory. WARNING: Cannot do mlockall(2).
/usr/bin/cdrecord: WARNING: This causes a high risk for buffer underruns. /usr/bin/cdrecord: Operation not permitted. WARNING: Cannot set RR-scheduler /usr/bin/cdrecord: Permission denied. WARNING: Cannot set priority using setpriority(). /usr/bin/cdrecord: WARNING: This causes a high risk for buffer underruns. scsidev: '/dev/hdd' devname: '/dev/hdd' scsibus: -2 target: -2 lun: -2 Error trying to open /dev/hdd exclusively ... retrying in 1 second. Error trying to open /dev/hdd exclusively ... retrying in 1 second. Error trying to open /dev/hdd exclusively ... retrying in 1 second. Error trying to open /dev/hdd exclusively ... retrying in 1 second. Error trying to open /dev/hdd exclusively ... retrying in 1 second. Error trying to open /dev/hdd exclusively ... retrying in 1 second. Error trying to open /dev/hdd exclusively ... retrying in 1 second. Error trying to open /dev/hdd exclusively ... retrying in 1 second. Error trying to open /dev/hdd exclusively ... retrying in 1 second. Error trying to open /dev/hdd exclusively ... retrying in 1 second. /usr/bin/cdrecord: Device or resource busy. Cannot open '/dev/hdd'. Cannot open SCSI driver. /usr/bin/cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are root. /usr/bin/cdrecord: For possible transport specifiers try 'cdrecord dev=help'. Cdrecord-Clone 2.01.01a03-dvd (i686-pc-linux-gnu) Copyright (C) 1995-2005 Jörg Schilling NOTE: This version contains the OSS DVD extensions for cdrtools and thus may have bugs related to DVD issues that are not present in the original cdrtools. Please send bug reports or support requests to http://bugzilla.redhat.com/bugzilla The original cdrtools author should not be bothered with problems in this version. TOC Type: 1 = CD-ROM
-- Stand before it and there is no beginning. Follow it and there is no end. Stay with the ancient Tao, Move with the present.
On Tuesday 04 April 2006 18:54, Matt Arnilo S. Baluyos (Mailing Lists) wrote:
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
There may be other problems, but this one suggests that something, probably automount, is grabbing the device. Make sure you have closed any file manager windows, and if a device icon has come onto the desktop, use it to umount the device.
Anne
On Tue, 4 Apr 2006, Anne Wilson wrote:
On Tuesday 04 April 2006 18:54, Matt Arnilo S. Baluyos (Mailing Lists) wrote:
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
There may be other problems, but this one suggests that something, probably automount, is grabbing the device. Make sure you have closed any file manager windows, and if a device icon has come onto the desktop, use it to umount the device.
Run lsof and see what has that device open/mounted.
On 4/5/06, Anne Wilson cannewilson@tiscali.co.uk wrote:
On Tuesday 04 April 2006 18:54, Matt Arnilo S. Baluyos (Mailing Lists) wrote:
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
There may be other problems, but this one suggests that something, probably automount, is grabbing the device. Make sure you have closed any file manager windows, and if a device icon has come onto the desktop, use it to umount the device.
Thanks Anne, doing a umount on /dev/hdd solved the problem.
This is weird though - shouldn't Fedora automagically do this thing for us? I
I don't recall ever having to do a manual umount on my burner device whenever I had to to erase rewriteable media on a RHEL-clone like CentOS.
-- Stand before it and there is no beginning. Follow it and there is no end. Stay with the ancient Tao, Move with the present.
On Tuesday 04 April 2006 20:48, Matt Arnilo S. Baluyos (Mailing Lists) wrote:
On 4/5/06, Anne Wilson cannewilson@tiscali.co.uk wrote:
On Tuesday 04 April 2006 18:54, Matt Arnilo S. Baluyos (Mailing Lists)
wrote:
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
There may be other problems, but this one suggests that something, probably automount, is grabbing the device. Make sure you have closed any file manager windows, and if a device icon has come onto the desktop, use it to umount the device.
Thanks Anne, doing a umount on /dev/hdd solved the problem.
This is weird though - shouldn't Fedora automagically do this thing for us? I
I don't recall ever having to do a manual umount on my burner device whenever I had to to erase rewriteable media on a RHEL-clone like CentOS.
I'm not exactly sure of the cause, but I have met this from time to time over the last couple of years. I suspect that the fast-changing scene of auto-mounting is responsible. ISTR that it happened at some stages in Mandriva, then disappeared at others.
Anne
Anne Wilson wrote:
On Tuesday 04 April 2006 20:48, Matt Arnilo S. Baluyos (Mailing Lists) wrote:
On 4/5/06, Anne Wilson cannewilson@tiscali.co.uk wrote:
On Tuesday 04 April 2006 18:54, Matt Arnilo S. Baluyos (Mailing Lists)
wrote:
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
There may be other problems, but this one suggests that something, probably automount, is grabbing the device. Make sure you have closed any file manager windows, and if a device icon has come onto the desktop, use it to umount the device.
Thanks Anne, doing a umount on /dev/hdd solved the problem.
This is weird though - shouldn't Fedora automagically do this thing for us? I
I don't recall ever having to do a manual umount on my burner device whenever I had to to erase rewriteable media on a RHEL-clone like CentOS.
I'm not exactly sure of the cause, but I have met this from time to time over the last couple of years. I suspect that the fast-changing scene of auto-mounting is responsible. ISTR that it happened at some stages in Mandriva, then disappeared at others.
It's the way my machine works, and umount is what I've had to do. I use FC2.
Mike
On Tue, 2006-04-04 at 16:59 -0500, Mike McCarty wrote:
Anne Wilson wrote:
On Tuesday 04 April 2006 20:48, Matt Arnilo S. Baluyos (Mailing Lists) wrote:
On 4/5/06, Anne Wilson cannewilson@tiscali.co.uk wrote:
On Tuesday 04 April 2006 18:54, Matt Arnilo S. Baluyos (Mailing Lists)
wrote:
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
There may be other problems, but this one suggests that something, probably automount, is grabbing the device. Make sure you have closed any file manager windows, and if a device icon has come onto the desktop, use it to umount the device.
Thanks Anne, doing a umount on /dev/hdd solved the problem.
This is weird though - shouldn't Fedora automagically do this thing for us? I
I don't recall ever having to do a manual umount on my burner device whenever I had to to erase rewriteable media on a RHEL-clone like CentOS.
I'm not exactly sure of the cause, but I have met this from time to time over the last couple of years. I suspect that the fast-changing scene of auto-mounting is responsible. ISTR that it happened at some stages in Mandriva, then disappeared at others.
It's the way my machine works, and umount is what I've had to do. I use FC2.
---- this may come as a shock to you but user space mounting of devices, udev and the dropping of udevfs has substantially changed since FC-2.
Craig
Anne Wilson wrote:
On Tuesday 04 April 2006 18:54, Matt Arnilo S. Baluyos (Mailing Lists) wrote:
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
There may be other problems, but this one suggests that something, probably automount, is grabbing the device. Make sure you have closed any file manager windows, and if a device icon has come onto the desktop, use it to umount the device.
Erm, not on my machine. I have to use umount from a CLI. Using the desktop icon results in the disc being ejected.
Mike
On Tue, 2006-04-04 at 16:58 -0500, Mike McCarty wrote:
Anne Wilson wrote:
On Tuesday 04 April 2006 18:54, Matt Arnilo S. Baluyos (Mailing Lists) wrote:
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
There may be other problems, but this one suggests that something, probably automount, is grabbing the device. Make sure you have closed any file manager windows, and if a device icon has come onto the desktop, use it to umount the device.
Erm, not on my machine. I have to use umount from a CLI. Using the desktop icon results in the disc being ejected.
---- which would probably work because a program such as K3b would call for it to be inserted and not mount such a disk but rather perform whatever is needed to erase and start writing.
Craig
Craig White wrote:
On Tue, 2006-04-04 at 16:58 -0500, Mike McCarty wrote:
Anne Wilson wrote:
On Tuesday 04 April 2006 18:54, Matt Arnilo S. Baluyos (Mailing Lists) wrote:
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
There may be other problems, but this one suggests that something, probably automount, is grabbing the device. Make sure you have closed any file manager windows, and if a device icon has come onto the desktop, use it to umount the device.
Erm, not on my machine. I have to use umount from a CLI. Using the desktop icon results in the disc being ejected.
which would probably work because a program such as K3b would call for it to be inserted and not mount such a disk but rather perform whatever is needed to erase and start writing.
Now who's speaking out of ignorance? :-)
No, because when K3b calls for the door to close, the automounter finds it and mounts it. And if it's blank, using this technique causes the "CD Maker" to start up, preventing K3b from working right.
The only thing that works on my machine is
(1) Insert the disc (2) If it was blank, wait for the CD Maker to start, then kill it (3) If it was not blank, wait for it to mount, start a CLI, and umount it (4) Start or continue with K3b.
I never have approved of auto mouting like this. IMO, MicroSoft products handle removable media better than UNIX like OSs, especially floppies.
Mike
On Tue, 2006-04-04 at 17:44 -0500, Mike McCarty wrote:
Craig White wrote:
On Tue, 2006-04-04 at 16:58 -0500, Mike McCarty wrote:
Anne Wilson wrote:
On Tuesday 04 April 2006 18:54, Matt Arnilo S. Baluyos (Mailing Lists) wrote:
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
There may be other problems, but this one suggests that something, probably automount, is grabbing the device. Make sure you have closed any file manager windows, and if a device icon has come onto the desktop, use it to umount the device.
Erm, not on my machine. I have to use umount from a CLI. Using the desktop icon results in the disc being ejected.
which would probably work because a program such as K3b would call for it to be inserted and not mount such a disk but rather perform whatever is needed to erase and start writing.
Now who's speaking out of ignorance? :-)
---- clearly I am since I haven't used FC-2 in quite a while and have never purchased an 'R/W' disc and have never used one. I did qualify my comment as 'probably' because I don't have first hand knowledge so yes, I am speaking out of ignorance. ;-) ----
No, because when K3b calls for the door to close, the automounter finds it and mounts it. And if it's blank, using this technique causes the "CD Maker" to start up, preventing K3b from working right.
The only thing that works on my machine is
(1) Insert the disc (2) If it was blank, wait for the CD Maker to start, then kill it (3) If it was not blank, wait for it to mount, start a CLI, and umount it (4) Start or continue with K3b.
---- but to be accurate...this is on FC-2 and things have changed a bit since then. ----
I never have approved of auto mouting like this. IMO, MicroSoft products handle removable media better than UNIX like OSs, especially floppies.
---- I'm not sure what you mean - Windows will automount a CD, Linux will automount a CD. I know that EZ-CD Creator will prevent automounting a CD that is inserted if EZ-CD is foreground application - but I do recall CD's automounting when inserted even when K3b is foreground application. So perhaps, this still might not be a suitable method.
As for floppies...I dunno - Windows is pretty non-responsive to other stuff when formatting/writing to a floppy, whereas Linux just buffers it...but that does mean that to flush the buffers, it is necessary to unmount it first. It would seem that both approaches have their benefits/drawbacks.
Craig
Craig White wrote:
On Tue, 2006-04-04 at 17:44 -0500, Mike McCarty wrote:
[snip]
The only thing that works on my machine is
(1) Insert the disc (2) If it was blank, wait for the CD Maker to start, then kill it (3) If it was not blank, wait for it to mount, start a CLI, and umount it (4) Start or continue with K3b.
but to be accurate...this is on FC-2 and things have changed a bit since then.
I don't know whether this particular thing has changed, but I doubt it. Certainly some things have changed.
I never have approved of auto mouting like this. IMO, MicroSoft products handle removable media better than UNIX like OSs, especially floppies.
I'm not sure what you mean - Windows will automount a CD, Linux will automount a CD. I know that EZ-CD Creator will prevent automounting a CD
My MSDOS machine does not automount anything. I also dislike the way Windows automounts CDROMS. Windows does not automount floppies.
that is inserted if EZ-CD is foreground application - but I do recall CD's automounting when inserted even when K3b is foreground application. So perhaps, this still might not be a suitable method.
I'm not Windows-aware enough to know about that, but it would make sense not to automount when something else is already trying to use the device. OTOH, there would need to be a way of registering that, either as a system call [flock()?] or in a configuration file.
As for floppies...I dunno - Windows is pretty non-responsive to other stuff when formatting/writing to a floppy, whereas Linux just buffers it...but that does mean that to flush the buffers, it is necessary to unmount it first. It would seem that both approaches have their benefits/drawbacks.
Well, nearly every decision I've made in my life, with very few exceptions, was some sort of compromise. Formatting a floppy should not make the machine slow. That sounds like a non-interrupt polling method for handling the disc. I'm also not savvy enough about the floppy disc I/F to know whether it *can* interrupt, though I did at one time write a program which could format a 360K floppy (before IOCTL() took over the job from the BIOS), and could display/mark/unmark bad sectors on them, as well as map them (looking for scratches).
IINM, sync will also flush pending writes to a floppy with Linux.
Mike
On Tuesday 04 April 2006 23:44, Mike McCarty wrote:
No, because when K3b calls for the door to close, the automounter finds it and mounts it. And if it's blank, using this technique causes the "CD Maker" to start up, preventing K3b from working right.
The only thing that works on my machine is
(1) Insert the disc (2) If it was blank, wait for the CD Maker to start, then kill it (3) If it was not blank, wait for it to mount, start a CLI, and umount it (4) Start or continue with K3b.
Much the same can happen in FC4. ISTR that I do have to do the umounting after k3b gets going. There's more than one cause, too, I think. Speaking from memory, there is k3b attempting to automount it. Then there is the removable media attempt to automount it. I just start k3b, then minimise it, wait until everything has had its say, then close or use the umount option, simply making sure that at the end nothing is holding on to it.
OK - memory is not the most reliable, but that's the general approach I use.
Anne
On Tuesday 04 April 2006 22:58, Mike McCarty wrote:
Anne Wilson wrote:
On Tuesday 04 April 2006 18:54, Matt Arnilo S. Baluyos (Mailing Lists)
wrote:
Error trying to open /dev/hdd exclusively ... retrying in 1 second.
There may be other problems, but this one suggests that something, probably automount, is grabbing the device. Make sure you have closed any file manager windows, and if a device icon has come onto the desktop, use it to umount the device.
Erm, not on my machine. I have to use umount from a CLI. Using the desktop icon results in the disc being ejected.
Strange - here (FC4) I have the options of both umount and eject. Could it be a kde/gnome difference? Of course the issue is to make sure that it's umounted, so it doesn't matter what method is used.
Anne
Mike McCarty:
Erm, not on my machine. I have to use umount from a CLI. Using the desktop icon results in the disc being ejected.
Anne Wilson:
Strange - here (FC4) I have the options of both umount and eject. Could it be a kde/gnome difference? Of course the issue is to make sure that it's umounted, so it doesn't matter what method is used.
Yes it does.
Scenario 1: 1. Insert blank RW. 2. Auto system decides to do something with disc that upsets your preferred burning software. 3. Unmount disc. 4. Use your burning software as you see fit.
Scenario 2: 1. Insert blank RW. 2. Auso system does what it does... 3. Eject disc. 4. Go back to step 1 and never get to burn your disc.
On Friday 07 April 2006 17:01, Tim wrote:
Mike McCarty:
Erm, not on my machine. I have to use umount from a CLI. Using the desktop icon results in the disc being ejected.
Anne Wilson:
Strange - here (FC4) I have the options of both umount and eject. Could it be a kde/gnome difference? Of course the issue is to make sure that it's umounted, so it doesn't matter what method is used.
Yes it does.
Scenario 1:
- Insert blank RW.
- Auto system decides to do something with disc that upsets your preferred burning software.
- Unmount disc.
- Use your burning software as you see fit.
Scenario 2:
- Insert blank RW.
- Auso system does what it does...
- Eject disc.
- Go back to step 1 and never get to burn your disc.
Tim, you're being obtuse. It does not matter in the least which method you use to umount, as long as you umount. I never suggested that ejecting was a solution. Mike had referred to umounting from the CLI, as you will see above.
Anne
On Fri, 2006-04-07 at 18:59 +0100, Anne Wilson wrote:
Tim, you're being obtuse. It does not matter in the least which method you use to umount, as long as you umount. I never suggested that ejecting was a solution. Mike had referred to umounting from the CLI, as you will see above.
Looking further back in the thread, it looks like the prior poster is trying to do something with the disc. i.e. They need the disc in the drive, *and* for it not to be in use. The messages that both you and Matt Arnilo S. Baluyos reported this little bit in: "Error trying to open /dev/hdd exclusively ... retrying in 1 second."
If it weren't for that (wanting to do something with the disc), then it wouldn't particularly matter how you freed the drive. But if you're only going to have to put the disc back in again, and go through all of this to burn a disc (or do something else with it), the little problem I mentioned still stands (you want it just to be unmounted, not ejected).
On Friday 07 April 2006 20:35, Tim wrote:
On Fri, 2006-04-07 at 18:59 +0100, Anne Wilson wrote:
Tim, you're being obtuse. It does not matter in the least which method you use to umount, as long as you umount. I never suggested that ejecting was a solution. Mike had referred to umounting from the CLI, as you will see above.
Looking further back in the thread, it looks like the prior poster is trying to do something with the disc. i.e. They need the disc in the drive, *and* for it not to be in use. The messages that both you and Matt Arnilo S. Baluyos reported this little bit in: "Error trying to open /dev/hdd exclusively ... retrying in 1 second."
If it weren't for that (wanting to do something with the disc), then it wouldn't particularly matter how you freed the drive. But if you're only going to have to put the disc back in again, and go through all of this to burn a disc (or do something else with it), the little problem I mentioned still stands (you want it just to be unmounted, not ejected).
What are you talking about? The thread has discussed several ways in which you can umount it. Only you keep going on about ejecting.
Anne
Matt Arnilo S. Baluyos (Mailing Lists) wrote:
/usr/bin/cdrecord: Cannot allocate memory. WARNING: Cannot do mlockall(2). /usr/bin/cdrecord: WARNING: This causes a high risk for buffer underruns.
You might want to look into this ... https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=187275#c3