cant burn a cd iso

[Daniel Leal]

Hi !

I am trying to burn a iso in my laptop with freebsd 7.2

Installed cdrtools and then kldload atapicam.

Then I looked for the cdrom:
#cdrecord -scanbus

Cdrecord-Clone 2.01 (i386-unknown-freebsd7.2) Copyright (C) 1995-2004
J?rg Schilling
Using libscg version 'schily-0.8'.
scsibus2:
2,0,0 200) 'PIONEER ' 'DVD-RW DVR-K17A' '1.51' Removable CD-ROM
2,1,0 201) *
2,2,0 202) *
2,3,0 203) *
2,4,0 204) *
2,5,0 205) *
2,6,0 206) *
2,7,0 207) *

So I try to burn the iso with the comand:
# cdrecord -v dev=2,0,0 myfile.iso

It seams to start correctly, but in the midle gave me the input/output
error:
Can someone help me please?

Thanks

Here is all what I could get from the -v option:cdrecord: No write mode
specified.

cdrecord: Asuming -tao mode.
cdrecord: Future versions of cdrecord may have different drive dependent
defaults.
cdrecord: Continuing in 5 seconds...
Cdrecord-Clone 2.01 (i386-unknown-freebsd7.2) Copyright (C) 1995-2004
Jrg Schilling
TOC Type: 1 = CD-ROM
scsidev: '2,0,0'
scsibus: 2 target: 0 lun: 0
Using libscg version 'schily-0.8'.
SCSI buffer size: 64512
atapi: 0
Device type : Removable CD-ROM
Version : 0
Response Format: 2
Capabilities :
Vendor_info : 'PIONEER '
Identifikation : 'DVD-RW DVR-K17A'
Revision : '1.51'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Current: 0x0009
Profile: 0x002B
Profile: 0x001B
Profile: 0x001A
Profile: 0x0015
Profile: 0x0014
Profile: 0x0013
Profile: 0x0012
Profile: 0x0002
Profile: 0x0011
Profile: 0x0010
Profile: 0x000A
Profile: 0x0009 (current)
Profile: 0x0008
cdrecord: This version of cdrecord does not include DVD-R/DVD-RW support
code.
cdrecord: If you need DVD-R/DVD-RW support, ask the Author for
cdrecord-ProDVD.
cdrecord: Free test versions and free keys for personal use are at
ftp://ftp.berlios.de/pub/cdrecord/ProDVD/

Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
Driver flags : MMC-3 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
Drive buf size : 1267712 = 1238 KB
FIFO size : 4194304 = 4096 KB
Track 01: data 616 MB
Total size: 708 MB (70:12.05) = 315904 sectors
Lout start: 708 MB (70:14/04) = 315904 sectors
Current Secsize: 2048
ATIP info from disk:
Indicated writing power: 5
Is not unrestricted
Is not erasable
Disk sub type: Medium Type B, low Beta category (B-) (4)
ATIP start of lead in: -11834 (97:24/16)
ATIP start of lead out: 359849 (79:59/74)
Disk type: Short strategy type (Phthalocyanine or similar)
Manuf. index: 24
Manufacturer: SONY Corporation
Blocks total: 359849 Blocks current: 359849 Blocks remaining: 43945
Starting to write CD/DVD at speed 24 in real TAO mode for single session.
Last chance to quit, starting real write 0 seconds. Operation starts.
Waiting for reader process to fill input buffer ... input buffer ready.
BURN-Free is OFF.
Performing OPC...
Starting new track at sector: 0
Track 01: 499 of 616 MB written (fifo 100%) [buf 79%]
20.6x.cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error
CDB: 2A 00 00 03 E6 A9 00 00 1F 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 71 00 03 00 56 42 66 0E 00 00 00 00 0C 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
Sense Key: 0x3 Medium Error, deferred error, Segment 0
Sense Code: 0x0C Qual 0x00 (write error) Fru 0x0
Sense flags: Blk 5653094 (not valid)
cmd finished after 0.001s timeout 40s
write track data: error after 523585536 bytes
cdrecord: A write error occured.
cdrecord: Please properly read the error message above.
Writing time: 287.920s
Average write speed 15.0x.
Min drive buffer fill was 42%
Fixating...
cdrecord: Input/output error. close track/session: scsi sendcmd:
retryable error
CDB: 5B 00 02 00 00 00 00 00 00 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 70 00 05 00 00 00 00 0E 00 00 00 00 72 03 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
Sense Key: 0x5 Illegal Request, Segment 0
Sense Code: 0x72 Qual 0x03 (session fixation error - incomplete track in
session) Fru 0x0
Sense flags: Blk 0 (not valid)
cmd finished after 1.353s timeout 480s
cmd finished after 1.353s timeout 480s
cdrecord: Cannot fixate disk.
Fixating time: 1.467s
cdrecord: fifo had 8311 puts and 8248 gets.
cdrecord: fifo was 0 times empty and 2899 times full, min fill was 85%.

[Juergen Lock]

Post by Daniel Leal
Hi !
I am trying to burn a iso in my laptop with freebsd 7.2
Installed cdrtools and then kldload atapicam.
#cdrecord -scanbus
Cdrecord-Clone 2.01 (i386-unknown-freebsd7.2) Copyright (C) 1995-2004
J?rg Schilling
Using libscg version 'schily-0.8'.
2,0,0 200) 'PIONEER ' 'DVD-RW DVR-K17A' '1.51' Removable CD-ROM
2,1,0 201) *
2,2,0 202) *
2,3,0 203) *
2,4,0 204) *
2,5,0 205) *
2,6,0 206) *
2,7,0 207) *
# cdrecord -v dev=2,0,0 myfile.iso
It seams to start correctly, but in the midle gave me the input/output
Can someone help me please?
Thanks
Here is all what I could get from the -v option:cdrecord: No write mode
specified.
cdrecord: Asuming -tao mode.
cdrecord: Future versions of cdrecord may have different drive dependent
defaults.
cdrecord: Continuing in 5 seconds...
Cdrecord-Clone 2.01 (i386-unknown-freebsd7.2) Copyright (C) 1995-2004
Jrg Schilling
TOC Type: 1 = CD-ROM
scsidev: '2,0,0'
scsibus: 2 target: 0 lun: 0
Using libscg version 'schily-0.8'.
SCSI buffer size: 64512
atapi: 0
Device type : Removable CD-ROM
Version : 0
Response Format: 2
Vendor_info : 'PIONEER '
Identifikation : 'DVD-RW DVR-K17A'
Revision : '1.51'
Device seems to be: Generic mmc2 DVD-R/DVD-RW.
Current: 0x0009
Profile: 0x002B
Profile: 0x001B
Profile: 0x001A
Profile: 0x0015
Profile: 0x0014
Profile: 0x0013
Profile: 0x0012
Profile: 0x0002
Profile: 0x0011
Profile: 0x0010
Profile: 0x000A
Profile: 0x0009 (current)
Profile: 0x0008
cdrecord: This version of cdrecord does not include DVD-R/DVD-RW support
code.
cdrecord: If you need DVD-R/DVD-RW support, ask the Author for
cdrecord-ProDVD.
cdrecord: Free test versions and free keys for personal use are at
ftp://ftp.berlios.de/pub/cdrecord/ProDVD/
Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr).
Driver flags : MMC-3 SWABAUDIO BURNFREE
Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R16 RAW/R96P RAW/R96R
Drive buf size : 1267712 = 1238 KB
FIFO size : 4194304 = 4096 KB
Track 01: data 616 MB
Total size: 708 MB (70:12.05) = 315904 sectors
Lout start: 708 MB (70:14/04) = 315904 sectors
Current Secsize: 2048
Indicated writing power: 5
Is not unrestricted
Is not erasable
Disk sub type: Medium Type B, low Beta category (B-) (4)
ATIP start of lead in: -11834 (97:24/16)
ATIP start of lead out: 359849 (79:59/74)
Disk type: Short strategy type (Phthalocyanine or similar)
Manuf. index: 24
Manufacturer: SONY Corporation
Blocks total: 359849 Blocks current: 359849 Blocks remaining: 43945
Starting to write CD/DVD at speed 24 in real TAO mode for single session.
Last chance to quit, starting real write 0 seconds. Operation starts.
Waiting for reader process to fill input buffer ... input buffer ready.
BURN-Free is OFF.
Performing OPC...
Starting new track at sector: 0
Track 01: 499 of 616 MB written (fifo 100%) [buf 79%]
20.6x.cdrecord: Input/output error. write_g1: scsi sendcmd: retryable error
CDB: 2A 00 00 03 E6 A9 00 00 1F 00
status: 0x2 (CHECK CONDITION)
Sense Bytes: 71 00 03 00 56 42 66 0E 00 00 00 00 0C 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00
Sense Key: 0x3 Medium Error, deferred error, Segment 0

^^^^^^^^^^^^

Post by Daniel Leal
[...]

Try another blank (also from a different make/batch, or possibly a cdrw
first?) When I got something like this once the blank had a media defect
that was even visible to the naked eye...

Of course the drive could be dieing too, apparently today's drives don't
last for as many writes anymore as in the past. (Chinese mfgrs cutting
corners everywhere I guess...)

HTH,
Juergen

[Julian H. Stacey]

Post by Daniel Leal
# cdrecord -v dev=2,0,0 myfile.iso

I've happily used cdrecord many years on FreeBSD, admittedly only up to 7.1
on my burn host. I didnt notice anthing odd in your posting (OK
didnt look Real hard). Maybe you were just unlucky & really did
have bad media.

Might your current working directory for myfile.iso be nsf mounted
on a slow net & cant keep up supply of data ?
(do ftp test to other host if in doubt, Ive had cases in past where
a bad electrolytic capacitor in power supply dried out, voltage dropped,
connection remained, but rate slowed)

Could it be that SCSI interrupts of writer are getting priority
over hard disc reading the source .iso ? (though OK I see
nothing else on your bus 2), not sure how priority works with mutiple busses
... anyway maybe data is from ATA not scsi disc.

If you have RW media (so it wont burn a small hole in your pocket)
Do a number of writes.

If you dont have RW media at least try a nymber of writes with -dummy

Is your machine heavily loaded or intermittently so ?

Is your processor too hot ? ..etc .. :-)

PS this posting topic would be more normal on hackers@ rather than
this multimedia@

Good luck,
Julian

[Joerg Schilling]

Hi,

what is the reason for using a 5 year old cdrtools version?

Are there no updates on FreeBSD?

BTW: the other problem may be a result of using media that is unsupported by
the drive.

Jörg

[Aryeh M. Friedman]

Post by Joerg Schilling
Hi,
what is the reason for using a 5 year old cdrtools version?
Are there no updates on FreeBSD?
BTW: the other problem may be a result of using media that is unsupported by
the drive.
Jörg

Use burncd(1)

[Joerg Schilling]

I am confused - in none of your postings I found what is the latest version of
cdrtools and where it can obtained.
Could you please help us with this?
http://cdrecord.berlios.de/private/cdrecord.html

If you lookd at the web site....

ftp://ftp.berlios.de/pub/cdrecord/
and it seems that version 2.01 from 2004 is still the greatest one (in the
version-comparison sense).

....you should know that the latest version is 2.01.01a60

What is the reason for following the "Old/Stable" link?

2.01 is completely outdated and should be avoided because of many bugs (e.g. in
mkisofs).

Jörg

[Andriy Gapon]

Post by Joerg Schilling

I am confused - in none of your postings I found what is the latest version of
cdrtools and where it can obtained.
Could you please help us with this?
http://cdrecord.berlios.de/private/cdrecord.html

If you lookd at the web site....

ftp://ftp.berlios.de/pub/cdrecord/
and it seems that version 2.01 from 2004 is still the greatest one (in the
version-comparison sense).

....you should know that the latest version is 2.01.01a60
What is the reason for following the "Old/Stable" link?
2.01 is completely outdated and should be avoided because of many bugs (e.g. in
mkisofs).

Sorry if sounded like a smart-ass, I didn't intend that.
I had suspicions about "Old" part of the link, but I was looking for "Stable".
Maybe we just see different things behind words like "alpha", "beta" and "stable".
But FreeBSD ports typically track stable releases of third-party programs, only in
exceptional cases we create "-devel" versions of the ports that track betas or
other kind of WIP.
I realize that there is a new trend of "permanently beta" software (GOOG), but I
think that it would be beneficial to the community of users of your software if
you'd split Old and Stable categories and declared some recent version of cdrtools
to be a Stable Release.

[Joerg Schilling]

Post by Andriy Gapon

Post by Joerg Schilling
What is the reason for following the "Old/Stable" link?
2.01 is completely outdated and should be avoided because of many bugs (e.g. in
mkisofs).

Sorry if sounded like a smart-ass, I didn't intend that.
I had suspicions about "Old" part of the link, but I was looking for "Stable".

"stable" means dead and "will not change".

Post by Andriy Gapon
Maybe we just see different things behind words like "alpha", "beta" and "stable".
But FreeBSD ports typically track stable releases of third-party programs, only in
exceptional cases we create "-devel" versions of the ports that track betas or
other kind of WIP.

There is "pre-alpha" which may happen under special conditions, e.g. after a
bigger change was introduced. There is no real difference between alpha and
beta. "stable" as alias for "dead" was already mentioned.

Decent software development always tries to be 100% bug free.

In a decent software development, interface changes (if needed at all) are
announced many years before they are implemented. For this reason, people only
should get into problems if they ignore announced changed for more than 3-5
years.

Post by Andriy Gapon
I realize that there is a new trend of "permanently beta" software (GOOG), but I
think that it would be beneficial to the community of users of your software if
you'd split Old and Stable categories and declared some recent version of cdrtools
to be a Stable Release.

There seems to be a general trend towards longer so called "development cycles".
Sun did e.g. publish Solaris 10 in February 2005 and there is still no
Solaris 11.

The OpenSource development is a smoothly moving target and you cannot
synchronize different projects anyway.

If you follow the rule to always publish bug-free versions if possible, people
can live with this paradigm.

[Rick C. Petty]

Post by Joerg Schilling

I am confused - in none of your postings I found what is the latest version of
cdrtools and where it can obtained.
Could you please help us with this?
http://cdrecord.berlios.de/private/cdrecord.html

If you lookd at the web site....

He did look at the website.

Post by Joerg Schilling

ftp://ftp.berlios.de/pub/cdrecord/
and it seems that version 2.01 from 2004 is still the greatest one (in the
version-comparison sense).

....you should know that the latest version is 2.01.01a60

The port available in sysutils/cdrtools-devel is 2.01.01a59, so what's the
big deal?

Post by Joerg Schilling
What is the reason for following the "Old/Stable" link?

Probably he was following the "stable" part. This implies that the newer
versions are not stable, which is why there's a cdrtools-devel port.

Post by Joerg Schilling
2.01 is completely outdated and should be avoided because of many bugs (e.g. in
mkisofs).

It's not always the case that newer versions are more stable and have fewer
bugs. In fact, cdrtools in particular has been that way in the past, where
mkisofs(1) created ISOs which were buggy (in that they were not even
mountable, or sometimes were mountable but some of the file pointers went
past the end of the ISO). In those times, I've had to drop back a version
or two to get a decent ISO. Maybe this is no longer the case since 2.01.
Maybe you should provide a short summary of the known issues in 2.01 that
are fixed in 2.01.01a60 and some assurances that the latter produces broken
images left often than the former.

Also it would probably help if you were more civil about it. Andriy asked
a reasonable question and made a reasonable assumption about the term
"stable".

-- Rick C. Petty

[Joerg Schilling]

Post by Rick C. Petty

Post by Joerg Schilling

Post by Daniel Leal
ftp://ftp.berlios.de/pub/cdrecord/
and it seems that version 2.01 from 2004 is still the greatest one (in the
version-comparison sense).

....you should know that the latest version is 2.01.01a60

The port available in sysutils/cdrtools-devel is 2.01.01a59, so what's the
big deal?

It is not a big deal if this version is installed by default ;-)

Post by Rick C. Petty

Post by Joerg Schilling
What is the reason for following the "Old/Stable" link?

Probably he was following the "stable" part. This implies that the newer
versions are not stable, which is why there's a cdrtools-devel port.

As I mentioned before: stable means dead -> no longer taken care of.

Post by Rick C. Petty

Post by Joerg Schilling
2.01 is completely outdated and should be avoided because of many bugs (e.g. in
mkisofs).

It's not always the case that newer versions are more stable and have fewer
bugs. In fact, cdrtools in particular has been that way in the past, where
mkisofs(1) created ISOs which were buggy (in that they were not even
mountable, or sometimes were mountable but some of the file pointers went
past the end of the ISO). In those times, I've had to drop back a version

During the past 5 years, I fixed dozens of bugs in mkisofs from the early days
of mkisofs. A bug that matches your description did never exist.

Post by Rick C. Petty
or two to get a decent ISO. Maybe this is no longer the case since 2.01.
Maybe you should provide a short summary of the known issues in 2.01 that
are fixed in 2.01.01a60 and some assurances that the latter produces broken
images left often than the former.

As mentioned above, such a problem did never exist.

If you did observe such problems, you did not use mkisofs but something else.
Did you use the defective fork from Debian? Did someone else modified your
local version?

Post by Rick C. Petty
Also it would probably help if you were more civil about it. Andriy asked
a reasonable question and made a reasonable assumption about the term
"stable".

I was and I am still very friendly and explained the meaning of the word
"stable". What is your problem?


Jörg

[Rick C. Petty]

Post by Joerg Schilling

Post by Rick C. Petty
The port available in sysutils/cdrtools-devel is 2.01.01a59, so what's the
big deal?

It is not a big deal if this version is installed by default ;-)

What do you mean "by default"? sysutils/cdrtools is not part of the base
installation of FreeBSD, that's why it's a port. At some point down the
line you installed sysutils/cdrtools. I'm just suggesting that you should
have installed sysutils/cdrtools-devel instead.

Post by Joerg Schilling

Post by Rick C. Petty

Post by Joerg Schilling
What is the reason for following the "Old/Stable" link?

Probably he was following the "stable" part. This implies that the newer
versions are not stable, which is why there's a cdrtools-devel port.

As I mentioned before: stable means dead -> no longer taken care of.

Yes, we all know your interpretation of the world "stable", which is not the
expected meaning that FreeBSD folks generally intend when they use that
term. I certainly would not call RELENG_7 "dead". When someone sees one
link that says "stable" (not one stating "dead"), they assume that the
opposite means "unstable". I suspect the port maintainer for cdrtools made
this assumption and choose "stability" over "possibly not tested as much".

Post by Joerg Schilling

Post by Rick C. Petty

Post by Joerg Schilling
2.01 is completely outdated and should be avoided because of many bugs (e.g. in
mkisofs).

It's not always the case that newer versions are more stable and have fewer
bugs. In fact, cdrtools in particular has been that way in the past, where
mkisofs(1) created ISOs which were buggy (in that they were not even
mountable, or sometimes were mountable but some of the file pointers went
past the end of the ISO). In those times, I've had to drop back a version

During the past 5 years, I fixed dozens of bugs in mkisofs from the early days
of mkisofs. A bug that matches your description did never exist.

That's a pretty far-fetched statement. I will assume that you mean that
this was not a bug that you fixed or that you did an exhaustive search
through the reported bugs and did not find such a report. I can assure you
that such a bug did exist around the FreeBSD 5.0 or 5.1 timeframe (six
years ago). I had two vanilla machines building release images and one
machine's ISOs sometimes failed. The two boxes had slightly different
cdrtools versions installed. I downgraded the one and things worked
correctly. I'm not 100% positive, but looking at my distfiles archive from
around that time, I believe the working version was 2.00.3 and the broken
version was 2.01a31. I can't be too sure because I lost a number of
distfiles in my archive.

My test case to prove the cause of the issue was something like:

# mkisofs -v -pad -r -hide-rr-moved -o test.iso /5.1/R/cdrom/disc1/
# mdconfig -au0 -f test.iso
# mount -t cd9660 /dev/md0 /cdrom
# find /cdrom -type f -exec dd if='{}' of=/dev/null bs=1m \;

When it worked, the find generated no output. When it was broken, I would
see I/O errors IIRC.

Post by Joerg Schilling

Post by Rick C. Petty
or two to get a decent ISO. Maybe this is no longer the case since 2.01.
Maybe you should provide a short summary of the known issues in 2.01 that
are fixed in 2.01.01a60 and some assurances that the latter produces broken
images left often than the former.

As mentioned above, such a problem did never exist.
If you did observe such problems, you did not use mkisofs but something else.
Did you use the defective fork from Debian? Did someone else modified your
local version?

Nope, just a vanilla FreeBSD install and some ports needed to build a
release, including cdrtools.

Note that my statements were not intended to criticize cdrtools, just that
I sympathize with port maintainers' desire to keep a more "stablized"
version around for things that are essential, such as ports used for
building a release. Pardon the pun, but when you've been *burned* once,
you're more careful to avoid any repeats. And I burned a lot of coasters
that day before I downgraded my cdrtools installation.

Post by Joerg Schilling

Post by Rick C. Petty
Also it would probably help if you were more civil about it. Andriy asked
a reasonable question and made a reasonable assumption about the term
"stable".

I was and I am still very friendly and explained the meaning of the word
"stable". What is your problem?

It seemed like you were being demanding from people who are volunteering
their time. Certainly your previous email seemed to me that you were being
somewhat arrogant as well. However I will give you the benefit of the
doubt that you are attempting to be civil and I fully retract my statement.

Cheers,

-- Rick C. Petty

[Joerg Schilling]

Post by Rick C. Petty

Post by Joerg Schilling
It is not a big deal if this version is installed by default ;-)

What do you mean "by default"? sysutils/cdrtools is not part of the base
installation of FreeBSD, that's why it's a port. At some point down the
line you installed sysutils/cdrtools. I'm just suggesting that you should
have installed sysutils/cdrtools-devel instead.

If pepole who try to install cdrtools are guided to the outdated versions, this
is not a good idea.

Post by Rick C. Petty

Post by Joerg Schilling
As I mentioned before: stable means dead -> no longer taken care of.

Yes, we all know your interpretation of the world "stable", which is not the
expected meaning that FreeBSD folks generally intend when they use that
term. I certainly would not call RELENG_7 "dead". When someone sees one
link that says "stable" (not one stating "dead"), they assume that the
opposite means "unstable". I suspect the port maintainer for cdrtools made
this assumption and choose "stability" over "possibly not tested as much".

I did not talk about FreeBSD but about cdrtools. You are confusing unrelated
information.

Post by Rick C. Petty

Post by Joerg Schilling
During the past 5 years, I fixed dozens of bugs in mkisofs from the early days
of mkisofs. A bug that matches your description did never exist.

That's a pretty far-fetched statement. I will assume that you mean that

No, this is a statement that is aligned with reality. Your claim however is
far-fetched.... You tell me that there was a problem but such a problem
has never been reported nor fixed.

Post by Rick C. Petty
this was not a bug that you fixed or that you did an exhaustive search
through the reported bugs and did not find such a report. I can assure you
that such a bug did exist around the FreeBSD 5.0 or 5.1 timeframe (six

So may it be a bug in FreeBSD 5.0 or 5.1?

Post by Rick C. Petty
years ago). I had two vanilla machines building release images and one
machine's ISOs sometimes failed. The two boxes had slightly different
cdrtools versions installed. I downgraded the one and things worked
correctly. I'm not 100% positive, but looking at my distfiles archive from
around that time, I believe the working version was 2.00.3 and the broken
version was 2.01a31. I can't be too sure because I lost a number of
distfiles in my archive.

As I mentioned already, such a problem has never been reported nor fixed.
If you were right, the problem still must be in mkisofs. Do you have a command
chain to repeat the problem?

Post by Rick C. Petty
# mkisofs -v -pad -r -hide-rr-moved -o test.iso /5.1/R/cdrom/disc1/
# mdconfig -au0 -f test.iso
# mount -t cd9660 /dev/md0 /cdrom
# find /cdrom -type f -exec dd if='{}' of=/dev/null bs=1m \;
When it worked, the find generated no output. When it was broken, I would
see I/O errors IIRC.

If there really was a problem, why didn't sou send a bug report?

Your problems could have many causes:

- a general bug in FreeBSD

- a buf in the "md" driver

- a bug introduced by other peoople in your local copy of mkisofs.

If you give me the chance to repeat it on Solaris, I am willing to believe that
there is a problem and I will fix it as soon as possible. For now: I did never
see any related problem, so I tend to believe that such a problem did never
exist.

Post by Rick C. Petty

Post by Joerg Schilling
If you did observe such problems, you did not use mkisofs but something else.
Did you use the defective fork from Debian? Did someone else modified your
local version?

Nope, just a vanilla FreeBSD install and some ports needed to build a
release, including cdrtools.

??? You don't need "some ports" to build cdrtools. Cdrtools come with a
makefile system that allows it to compile out of the box on aprox. 30 platforms
without any manual help by just typing "make" (better "smake").

Did you use an unmodified original cdrtools source?

Post by Rick C. Petty
Note that my statements were not intended to criticize cdrtools, just that
I sympathize with port maintainers' desire to keep a more "stablized"
version around for things that are essential, such as ports used for
building a release. Pardon the pun, but when you've been *burned* once,
you're more careful to avoid any repeats. And I burned a lot of coasters
that day before I downgraded my cdrtools installation.

So try to find the real reason for your problem.....

The way cdrtools is developed gives you the grant that you get constantly
evolving and less buggy bug still compatible version if you upgrade to the
latest source in:

ftp://ftp.berlios.de/pub/cdrecord/alpha/

There are a few exceptions, and in such a case, there is a marker in the
announcement file. The last time this happened was between 2.01.01a12 and
2.01.01a27 when the buggy GNU getopt_long() was replaced by the more mature
getargs() and thousands of lines of code have been changed.

The general rule for creating a new cdrtools release is to either only fix bugs
or to add new features without adding bugs to previously working parts. This
allows you to upgrade to the latest source, _anytime_ there is not a warning
message in the AN* files.

Post by Rick C. Petty

Post by Joerg Schilling
I was and I am still very friendly and explained the meaning of the word
"stable". What is your problem?

It seemed like you were being demanding from people who are volunteering
their time. Certainly your previous email seemed to me that you were being
somewhat arrogant as well. However I will give you the benefit of the
doubt that you are attempting to be civil and I fully retract my statement.

If you call a person "arrogant" just because he knows what he is talking about,
you need to fix your view on the world. If you did not notice this fact: the
oldest source parts in cdrtools that I wrote are more than 25 years old. I am
not an OSS newbie...

BTW: I am contributing _my_ time for you and I thus expect that people who use
my software are collaborative with reporting bugs and discussions in general.

Jörg

[Andriy Gapon]

Post by Joerg Schilling
Hi,
what is the reason for using a 5 year old cdrtools version?
Are there no updates on FreeBSD?
BTW: the other problem may be a result of using media that is unsupported by
the drive.

Jörg,

I am confused - in none of your postings I found what is the latest version of
cdrtools and where it can obtained.
Could you please help us with this?

I looked here:
http://cdrecord.berlios.de/private/cdrecord.html
followed "Old/Stable" link:
ftp://ftp.berlios.de/pub/cdrecord/
and it seems that version 2.01 from 2004 is still the greatest one (in the
version-comparison sense).

[Julian H. Stacey]

Hi ***@FreeBSD.org
cc freebsd-***@freebsd.org
Current ports/sysutils/cdrtools/Makefile lists you as maintainer:
PORTVERSION?= 2.01
MAINTAINER= ***@FreeBSD.org
Forwarded below from author of cdrecord:
--------

Post by Joerg Schilling
Hi,
what is the reason for using a 5 year old cdrtools version?
Are there no updates on FreeBSD?
BTW: the other problem may be a result of using media that is unsupported by
the drive.
Jörg
--
URL: http://cdrecord.berlios.de/private/ ftp://ftp.berlios.de/pub/schily
_______________________________________________
http://lists.freebsd.org/mailman/listinfo/freebsd-multimedia

Cheers,
Julian

[Marius Strobl]

Post by Julian H. Stacey
PORTVERSION?= 2.01
--------

Post by Joerg Schilling
Hi,
what is the reason for using a 5 year old cdrtools version?
Are there no updates on FreeBSD?

The main reason for still defaulting to cdrtools 2.01 is
to provider a known-good mkisofs for release engineering,
especially since we've already been bitten by IIRC a
third-party archiver in the past. My experience was that
the 2.01.01 alpha series mkisofs didn't always seem
suitable for this purpose, actually even the cdrtools
release notes discouraged its use from time to time.
The other reason is that for over a year now the 2.01.01
alpha release notes indicate a non-alpha release being
imminent, i.e. it didn't look like we'd use 2.01 for
yet another year:
<...>
NEW features of cdrtools-2.01.01a41:

*******
NOTE: cdrtools is currently in a state just before a new major release.
<...>

Note that up to 2.01.01a27 the release notes also sounded
like 2.01.01 would only be a minor update to 2.01 released
"soon". Anyway, those requiring the latest alpha version
always can install the cdrtools-devel port instead.

Marius

[Joerg Schilling]

Post by Marius Strobl

Post by Joerg Schilling
Are there no updates on FreeBSD?

The main reason for still defaulting to cdrtools 2.01 is
to provider a known-good mkisofs for release engineering,
especially since we've already been bitten by IIRC a
third-party archiver in the past. My experience was that

Then I cannot understand why FreeBSD still stays with the old version of
mkisofs.

Stying with the old version means staying with old bugs.

Post by Marius Strobl
the 2.01.01 alpha series mkisofs didn't always seem
suitable for this purpose, actually even the cdrtools
release notes discouraged its use from time to time.

There was a period of less than 6 months starting from August 2006
where I replaced the buggy GNU getopt_long() with my mature getargs()
that resulted in replacing 3000 old lines by 1000 new lines and introduced
a few temporary incompatibilities.

Post by Marius Strobl
The other reason is that for over a year now the 2.01.01
alpha release notes indicate a non-alpha release being
imminent, i.e. it didn't look like we'd use 2.01 for
<...>

I don't understand - sorry.

2.01 is dead since more than 5 years, I don't recommend to use it anymore since
more than 2 years.

Jörg

[Joerg Schilling]

Just a note:

burncd is FreeBSD specific and does only implement a few features.
Cdrecord implements many features and contains many workarounds for
bad firmware in various drives. You should expect more problems from
using burncd than from using burncd.

AFAIR, burncd is a program written by someone who did ask people from the
freebsd mailing lists to use burncd while he at the same time did sell
support for a atapicam based cdrecord solution.


Jörg

[Julian H. Stacey]

Post by Julian H. Stacey
PORTVERSION?= 2.01
--------

Post by Joerg Schilling
Hi,
what is the reason for using a 5 year old cdrtools version?
Are there no updates on FreeBSD?
BTW: the other problem may be a result of using media that is unsupported by
the drive.
Jörg

cd /pub/FreeBSD/branches/-current/ports/sysutils/
grep MAINTAINER cdrtools*/Makefile
cdrtools-devel/Makefile:MAINTAINER= ***@FreeBSD.org
cdrtools/Makefile:MAINTAINER= ***@FreeBSD.org
cdrtools/distinfo: cdrtools-2.01.tar.bz2
cdrtools-cjk/distinfo: cdrtools-2.01.tar.bz2
cdrtools-devel/distinfo: cdrtools-2.01.01a60.tar.bz2

cdrtools-cjk/pkg-descr:
http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/cdrecord.html
Proxy Error

Joerg, may I suggest send-pr to update to eg your
http://cdrecord.berlios.de/private/cdrecord.html

Cheers,
Julian

[Joerg Schilling]

Post by Julian H. Stacey

Post by Joerg Schilling
what is the reason for using a 5 year old cdrtools version?
Are there no updates on FreeBSD?
BTW: the other problem may be a result of using media that is unsupported by
the drive.
Jörg

cd /pub/FreeBSD/branches/-current/ports/sysutils/
grep MAINTAINER cdrtools*/Makefile
cdrtools/distinfo: cdrtools-2.01.tar.bz2
cdrtools-cjk/distinfo: cdrtools-2.01.tar.bz2
cdrtools-devel/distinfo: cdrtools-2.01.01a60.tar.bz2
http://www.fokus.gmd.de/research/cc/glone/employees/joerg.schilling/private/cdrecord.html
Proxy Error
Joerg, may I suggest send-pr to update to eg your
http://cdrecord.berlios.de/private/cdrecord.html

Hi,

could you please explain me what "send-pr" is?

Jörg

[Julian H. Stacey]

Post by Joerg Schilling
Hi,
could you please explain me what "send-pr" is?
Jörg

Hi Joerg,
Sorry, I recall your prime development *IX not FreeBSD, so:
Summary:
man send-pr - send problem report (PR) to a central support site
/usr/src/gnu/usr.bin/send-pr
A script that collects a few environment variables,
& a few categories & mails off a report.
FreeBSD project uses it for submitting patch request, bug reports etc
(It will probably soon be replaced by something being written
under contract, paid for by FreeBSD foundation)
I will send you an off list copy of send-pr source
& will file a send-pr & CC you, you can then just mail same address
with any follow up (even if you may not be mailing from a BSD platform).

Cheers,
Julian

[Julian H. Stacey]

Hi Rick
Best re-read the thread from the beginning to avoid possible confusion.

Post by Rick C. Petty
What do you mean "by default"? sysutils/cdrtools is not part of the base
installation of FreeBSD, that's why it's a port. At some point down the
line you installed sysutils/cdrtools. I'm just suggesting that you should
have installed sysutils/cdrtools-devel instead.

Original poster (installer) was Daniel, not Joerg.
Joerg is author of architecture neutral cdrtools sources.

Post by Rick C. Petty
Yes, we all know your interpretation of the world "stable", which is not the
expected meaning that FreeBSD folks generally intend when they use that
term.

Agreed. Joerg has an unusual use of the word stable, but
then when he started using that usage of stable, he didnt need to
conform to FreeBSD usage of word stable as:
He was I think, a mostly Linux based developer of a cross platform
source that also runs on *BSD.

Even in FreeBSD, Stable only later came to mean the common English
meaning of reliable, I remember several times people asserting all
Stable meant was that the API (libs etc) avoided sudden changes like
in current, didn't back then mean make world wouldnt break etc.

Post by Rick C. Petty
I suspect the port maintainer for cdrtools made
this assumption and choose "stability" over "possibly not tested as much".

Marius is MAINTAINER= of 2/3 ports wrappers, & he wrote:
Mon, 29 Jun 2009 20:21:01 +0200
Message-id: <***@alchemy.franken.de>

The main reason for still defaulting to cdrtools 2.01 is ....

Post by Rick C. Petty
It seemed like you were being demanding from people who are volunteering
their time.

Joerg & Marius contributed time respectively writing cdrtools & wrappers.
Thanks

Julian

[Joerg Schilling]

Post by Julian H. Stacey

Post by Rick C. Petty
Yes, we all know your interpretation of the world "stable", which is not the
expected meaning that FreeBSD folks generally intend when they use that
term.

Agreed. Joerg has an unusual use of the word stable, but
then when he started using that usage of stable, he didnt need to
He was I think, a mostly Linux based developer of a cross platform
source that also runs on *BSD.

Linux is one of many supported platforms and it causes more workload than
others.

Since February 1985 (when the first Sun arrived in Europe), I am working on
SunOS. Before, I was working on UNOS - a UNIX clone.

The main development is still on Solaris and frequent compilations are also
done on HP-UX and Mac OS X. Less frequent compilations are done on Linux and
FreeBSD, as well as on Haiku.

I would be interested to again get access to AIX and IRIX (I know IRIX is dead
but it has the best warnings in the C-compiler ;-).

Post by Julian H. Stacey
Even in FreeBSD, Stable only later came to mean the common English
meaning of reliable, I remember several times people asserting all
Stable meant was that the API (libs etc) avoided sudden changes like
in current, didn't back then mean make world wouldnt break etc.

The last interface change im mkisofs (disallow -H/-L/-P for future POSIX.1-2001
usage with these optiions) was implemented in December 2006. It was announced
in October 2002.

Jörg