Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
I still fail to burn ISO even to blank CDs. The same for SAO or DAO to blank and than burn. I tried to "play" a bit with the few customizable fields in the Brasero plugins, basically two: cdrdao (enable the "--driver generic-mmc-raw" flag) and growisofs (allow the use of DAO), but the problems persist. Gconf is obsolete and now replaced by Dconf, but in fact I don't know where to put my hands. I try to deepen ... m Il 15/11/21 17:11, Thomas Schmitt ha scritto: Hi, i wrote: My only idea which does not need a code change is to employ the wodim plugin of Brasero and to hope that it burns by write type SAO. Mauro Sacchetto wrote: Which way? Good question. I have wodim installed. But last time when i tried, the wodim item was greyed out in the plugin list window which i somehow managed to pop up. Google brings me to https://github.com/lmedinas/brasero which in "Notes on plugins for advanced users" proposes to remove libburn (bleh !) or to use something named Gconf for changing plugin priorities. Wikipedia says: "GConf was a system used by the GNOME desktop". The riddle remains, i fear. Have a nice day :) Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi, i wrote: > > My only idea which does not need a code change is to employ the wodim > > plugin of Brasero and to hope that it burns by write type SAO. Mauro Sacchetto wrote: > Which way? Good question. I have wodim installed. But last time when i tried, the wodim item was greyed out in the plugin list window which i somehow managed to pop up. Google brings me to https://github.com/lmedinas/brasero which in "Notes on plugins for advanced users" proposes to remove libburn (bleh !) or to use something named Gconf for changing plugin priorities. Wikipedia says: "GConf was a system used by the GNOME desktop". The riddle remains, i fear. Have a nice day :) Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Il 15/11/21 14:58, Thomas Schmitt ha scritto: My only idea which does not need a code change is to employ the wodim plugin of Brasero and to hope that it burns by write type SAO. If so, then the drive would not get lost after a successful burn run. Which way? Thanx! m
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi, Mauro Sacchetto wrote: > sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin > After this, the drive is unavailable Well, then we have found: - The immediate cause of the problem: READ CD with LBA -1. - A good suspect in Brasero: Function brasero_medium_track_written_SAO() https://sources.debian.org/src/brasero/3.12.3-1/libbrasero-media/brasero-medium.c/?hl=1565#L1565 - The generally problematic expectation of Brasero that it can determine whether a CD track was written by write type SAO (and not by TAO). - We have not explored yet: - Why does Brasero believe to see 2 tracks on a closed CD-RW with a single TAO track ? BraseroMedia: (at brasero-medium.c:2062) 2 track(s) found This misperception triggers the call to brasero_medium_track_written_SAO(). - Why does brasero_medium_track_get_info() want to distinguish SAO from TAO only if its parameter multisession is set to "true". Its only caller has a strange comment before setting multisession: https://sources.debian.org/src/brasero/3.12.3-1/libbrasero-media/brasero-medium.c/?#L2052 num = (size - sizeof (BraseroScsiFormattedTocData)) / sizeof (BraseroScsiTocDesc); /* remove 1 for leadout */ multisession = !(priv->info & BRASERO_MEDIUM_BLANK) && num > 0; If the leadout is counted as surplus track, then why not "num > 1" ? - So the Brasero "Copy" task of TAO CDs is not possible with the ASUS drive. The code of Brasero would have to be changed for that. We have no workaround yet for the case of burning the netinst ISO by Brasero. I found no way to tell Brasero that its libburn plugin shall ask libburn for SAO. libburn would of course be able to avoid SAO if it is told to do so. It would propose SAO if being asked to find a suitable write type for track input of which the size is known in advance. My only idea which does not need a code change is to employ the wodim plugin of Brasero and to hope that it burns by write type SAO. If so, then the drive would not get lost after a successful burn run. Of course you would have to carefully avoid to show Brasero a TAO CD in the ASUS drive. Best would be to blank any CD-RW before giving it to Brasero. - Have a nice day :) Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Il 14/11/21 14:25, Thomas Schmitt ha scritto: The main question is: Is the drive unusable afterwards ? (I.e. do i have identified the culprit for your drive problem ?) I put the CD into the drive, mount and umount it: all goes. I lauch che command and obtain: == samiel@darkstar:~$ samiel@darkstar:~$ sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin bash: samiel@darkstar:~$: comando non trovato samiel@darkstar:~$ sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin SCSI Status: Check Condition Sense Information: Fixed format, current; Sense key: Illegal Request Additional sense: Unaligned write command == After this, the drive is unavailable: == Impossible to mount debian...iso Error mounting the system-managed device /dev/sr0: no medium fount o /dev/sr0 == m
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi, i made the experiments which i mentioned in the previous mail: - The Pioneer drive does not go mad from READ CD for LBA -1 or from READ CD MSF for sector 00:01:74. - The ASUS drive does not go mad from READ CD MSF for sector 00:01:74. - The TSSTcorp drive tolerates READ CD MSF for sector 00:01:74 without a message in dmesg about USB reset. (It did that reset with READ CD for LBA -1 but showed no lasting problem.) None of the drives reports success with the READ CD MSF command. So with this command the Brasero function brasero_medium_track_written_SAO() would return TRUE, which is wrong with the given CD. The desire to read the Lead-in sector before the start of the payload data simply seems not fulfillable here for the first track of a CD. Brasero will have to abandon this idea or come up with a better read command - which i currently fail to imagine. - The SCSI specs say that LBA -1 is bad: While exploring how to encode the READ CD MFS command for 00:01:74, i found this statement in the MMC-5 specs: "3.2.21 Method 1 Addressing [...] Method 1 logical sector numbering is not defined for sectors outside of the program area." This sector numbering is in effect with command READ CD. The "program area" is the payload part of the CD with a single track. So READ CD with logical block address -1 is not defined. - Experiments with the ASUS drive: (Anybody remembers BCD number encoding ? I can be glad that they did not choose to use Gray codes. BCD is easy to write in hex. :)) The READ CD MSF expects an inclusive start address (here 00:01:74) and an exclusive end address (here 00:02:00). Except the address fields it has the same byte layout as READ CD. So the command as replacement for the bad READ CD command be 00 ff ff ff ff 00 00 01 10 00 00 is b9 00 00 00 01 74 00 02 00 10 00 00 This does not yield a good result in form a of data, but also no bad consequences for the drive or complaints from the transport layer in dmesg. $ sg_raw /dev/sr0 b9 00 00 00 01 74 00 02 00 10 00 00 --request=2352 --outfile=tdb_data.bin SCSI Status: Check Condition Sense Information: Fixed format, current; Sense key: Illegal Request Additional sense: Invalid field in cdb Error 5 occurred, no data received (I meanwhile learned that i need to tell sg_raw to expect a certain number of bytes as reply. My choice 2352 is the size of CD-DA payload. The data CD is supposed to deliver only 2048 bytes of payload. I tried a request size of 2048, but the behavior of sg_raw did not change.) In order to prove that my SCSI command is correctly encoded, i asked for the first valid payload block at 00:02:00 = LBA 0 : $ sg_raw /dev/sr0 b9 00 00 00 02 00 00 02 01 10 00 00 --request=2352 --outfile=tdb_data.bin SCSI Status: Good Writing 2352 bytes of data to tdb_data.bin The file tdb_data.bin shows the MBR data of the Debian netinst ISO. The same result i get with a valid READ CD command for LBA 0: $ sg_raw /dev/sr0 be 00 00 00 00 00 00 00 01 10 00 00 --request=2352 --outfile=tdb_data.bin None of these experiments caused problems like with Brasero. - What does PIONEER BD-RW BDR-S09 say to such commands: $ sg_raw /dev/sr1 b9 00 00 00 01 74 00 02 00 10 00 00 --request=2352 --outfile=tdb_data.bin SCSI Status: Check Condition Sense Information: Fixed format, current; Sense key: Illegal Request Additional sense: Invalid field in cdb Error 5 occurred, no data received The drive is still usable and dmesg shows no new complaints. (Except blkid's graceful failures to read the Run-out blocks.) With CDB b9 00 00 00 02 00 00 02 01 10 00 00 i get the first data block from the CD: the isohybrid MBR, which xorriso inserted when it created the ISO for the debian-cd project. Now for the ugly test: $ sg_raw /dev/sr1 be 00 ff ff ff ff 00 00 01 10 00 00 --request=2352 --outfile=tdb_data.bin SCSI Status: Check Condition Sense Information: Fixed format, current; Sense key: Illegal Request Additional sense: Logical block address out of range Error 22 occurred, no data received It turns out that this drive and its transport layers in the kernel can stand the bad READ CD command. No dmesg complaints to see from this experiment. xorriso still works with the drive. This quite kills the theory that the kernel transport layer gets a hickup without the help of the drive's SATA interface. So the ASUS drive indeed has a stake in the problem. - And the TSSTcorp CDDVDW SH-S223B : $ sg_raw /dev/sr2 b9 00 00 00 01 74 00 02 00 10 00 00 --request=2352 --outfile=tdb_data.bin SCSI Status: Check Condition Sense Information: Fixed format, current; Sense key: Illegal Request Additional sense:
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi, Mauro Sacchetto wrote: > samiel@darkstar:~$ sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 > --outfile=tdb_data.bin > SCSI Status: Check Condition > > Sense Information: > Fixed format, current; Sense key: Illegal Request > Additional sense: Unaligned write command Now we know from where that error came, which is inappropriate for optical drives. (Maybe that the kernel created it, and not the drive.) > Is it my test right and enough? The main question is: Is the drive unusable afterwards ? (I.e. do i have identified the culprit for your drive problem ?) > In fact I am a little surprised (although I don't know how these things are > handled by the Debin team) > that so far there has been no intervention by the packagers of Brasero I understand that there is no upstream developer any more and no community which would continue the GUI part and build it with patch proposals. It looks like i was involved in the second youngest thread on the mailing list, back in 2019: https://mail.gnome.org/archives/brasero-list/2019-January/thread.html The youngest thread is a request for help with building Brasero. It got no answer. Possibly i will post a report about the problem there. Just in case some new developer shows up. Said that, and contrary to my statement in the previous mail, i have not yet used up my ideas for experiments: - Will the Pioneer drive go bad if i send the READ CD 0x command ? It looks like Brasero doesn't do this. - Will READ CD MSF 00:01:74 work better ? Maybe with all three drives without incident and dmesg complaint ? (I have to study the specs, because i never used that command before.) If the Pioneer drive goes bad too, then it might even be a kernel problem with that obviously disliked sector address, and not a problem only with the ASUS drive. This could become obvious if the Additional sense: Unaligned write command from your above experiment changes to my result >>> transport error: Host_status=0x03 [DID_TIME_OUT] if you use kernel 5.10. Have a nice day :) Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Il 14/11/21 12:02, Thomas Schmitt ha scritto: Hi, i now have clear evidence from a run of sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin that the read attempt for sector 0x (= -1) brings the ASUS DRW-24D5MT into the unusable state. @ Mauro Sacchetto: Could you please try to reproduce this finding after installing sg3-utils. I obtain === samiel@darkstar:~$ sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin SCSI Status: Check Condition Sense Information: Fixed format, current; Sense key: Illegal Request Additional sense: Unaligned write command === Is it my test right and enough? - Possible remedies: We would need a Brasero developer to find a workaround, because not only the bad READ CD command needs to be avoided, but also a replacement for the code gesture to distinguish TAO CDs from SAO CDs would have to be developed. Maybe this distinction is not really necessary. It seems not to work properly on the TSSTcorp drive by making a false correction of the track size. But that would be up to a Brasero developer to decide. In fact I am a little surprised (although I don't know how these things are handled by the Debin team) that so far there has been no intervention by the packagers of Brasero
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi,
i now have clear evidence from a run of
sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin
that the read attempt for sector 0x (= -1) brings the
ASUS DRW-24D5MT into the unusable state.
@ Mauro Sacchetto:
Could you please try to reproduce this finding after installing sg3-utils.
The main suspect for emitting SCSI this command is Brasero function
brasero_medium_track_written_SAO()
in libbrasero-media/brasero-medium.c .
Code study of that function and the logs of Brasero "Copy" runs with
the Pioneer and the TSSTcorp show that bad things happen if the function
is called:
- The Pioneer drive does not trigger the log message from
brasero_medium_track_written_SAO()
and leaves no problem report lines in dmesg.
So i conclude that the function was not called.
- The TSSTcorp drive triggers this message:
BraseroMedia: (at brasero-medium.c:1573) Checking for TDBs in track pregap.
and dmesg reports a (successful / harmless ?) USB reset.
-
Possible remedies:
We would need a Brasero developer to find a workaround, because not
only the bad READ CD command needs to be avoided, but also a replacement
for the code gesture to distinguish TAO CDs from SAO CDs would have to
be developed.
Maybe this distinction is not really necessary. It seems not to work
properly on the TSSTcorp drive by making a false correction of the
track size. But that would be up to a Brasero developer to decide.
A cheaper workaround would be to identify the drive model from the
function parameter
BraseroDeviceHandle *handle
and to return before any read attempt if it is an ASUS DRW-24D5MT
and maybe others, which still need to have been found.
Again it would be up to a Brasero developer to decide whether TRUE or
FALSE would be the best reply in this case.
Maybe it would be possible to read that sector by SCSI command
READ CD MSF with address 00:01:74.
(The track begins at 00:02:00. Brasero wants one sector before that
start which to my computation would be 00:01:74.)
-
Experiments made:
I tried the "Copy" task of Brasero with the TSSTcorp drive in its USB box
at /dev/sr2.
Other than with the Pioneer at /dev/sr1, this run reports
BraseroMedia: (at brasero-medium.c:2062) 2 track(s) found
BraseroMedia: (at brasero-medium.c:1645) Retrieving track information for 1
BraseroMedia: (at brasero-medium.c:1715) Data track belongs to first session
of multisession CD. Checking for real size (193686 sectors currently).
BraseroMedia: (at brasero-medium.c:1573) Checking for TDBs in track pregap.
BraseroMedia: (at brasero-medium.c:1742) Correcting track size (now 193688)
which indicates that Brasero thinks this CD was written with write
type SAO.
But i burnt it with xorriso -as cdrecord -tao. libburn's demo program
telltoc reports that blocks 193687 and 193688 are not readable and thus
supposes the CD to be burnt by TAO.
Later the log confrims telltoc's findings:
BraseroBurn: (at burn-process.c:417) BraseroCdrdao stderr: Found L-EC error
at sector 193686 - ignored.
BraseroBurn: (at burn-job.c:1430) BraseroCdrdao called brasero_job_get_action
BraseroBurn: (at burn-process.c:417) BraseroCdrdao stderr: Found L-EC error
at sector 193687 - ignore
("L-EC error" would mean a medium problem. So the drive maybe contributes
to the confusion of Brasero. dmesg reports the same errors, probably from
blkid inspecting the medium for an UDF anchor.)
dmesg reports around the time when Brasero was inspecting the drive:
usb 1-13: reset high-speed USB device number 5 using xhci_hcd
and with another "Copy" task again:
usb 1-13: reset high-speed USB device number 5 using xhci_hcd
Whatever, the drive stays usable and no error of READ CD for sector
0x is reported in dmesg.
Poking manually into that drive:
# apt-get install sg3-utils
$ sg_raw /dev/sr2 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin
>>> transport error: Host_status=0x03 [DID_TIME_OUT]
Driver_status=0x00 [DRIVER_OK]
SCSI Status: Good
and another USB device reset is reported in dmesg
usb 1-13: reset high-speed USB device number 5 using xhci_hcd
Still the drive is usable afterwards.
Now the decisive test with /dev/sr0, the ASUS drive:
No Brasero is running.
After inserting the CD into /dev/sr0, i see in dmesg complaints about
i/o errors with the last two blocks. This time not "L-EC error" but
rather "Illegal Request", as i would expect from the specs.
The drive is usable for xorriso.
So:
$ sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 --outfile=tdb_data.bin
SCSI Status: Check Condition
Sense Information:
Fixed format, current; Sense key: Illegal Request
Additional sense: Unaligned write command
dmesg reports
ata3.00: exception Emask 0x0 SAct
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi, Mauro Sacchetto wrote: > brasero -g --brasero-media-debug > log 2>&1 (After knowing the magic words i find man pages in the web which have it.) In the log from a successful Copy job with the Pioneer drive (sr1) i do not see the message about "TDB". But in the log of an immediate failure with the TAO CD in the ASUS drive, i see: BraseroMedia: (at brasero-drive.c:983) No medium inserted BraseroMedia: (at brasero-medium.c:1738) Following two sectors are readable. BraseroMedia: (at brasero-medium.c:1573) Checking for TDBs in track pregap. A problem with this log seems to be that the messages for both drives are intermixed without an indication which drive is meant. I assume that the "No medium inserted" is for empty sr1. So i cannot really tell from comparing both logs what triggers the TDB check on the ASUS or what prevents it on the Pioneer. But the Debian code search for "Following two sectors are readable" yields a suspect: https://sources.debian.org/src/brasero/3.12.3-1/libbrasero-media/brasero-medium.c/?hl=1738#L1738 The call brasero_medium_track_written_SAO() is made only if /* Test the last block, the before last and the one before before last */ result = brasero_mmc1_read_block (handle, ... yields result == BRASERO_SCSI_OK This seems to be true with the ASUS but not with the Pioneer. The log message immediately before "Following two sectors ..." is to see in both logs and seems to be falsely issued: BraseroMedia: (at brasero-medium.c:1715) Data track belongs to first session of multisession CD. Checking for real size (193536 sectors currently). Both logs have BraseroMedia: (at brasero-medium.c:2062) 2 track(s) found but the CD-RW is closed and has only one session with one track. If not the parameter "multisession" was set with the call of brasero_medium_track_get_info() then we possibly would not have this lengthy bug discussion. Well, i will know for sure only after i hacked libburn to issue such a READ CD command for sector number -1 with exactly the same CDB bytes as reported by dmesg: [20205.014237] ata3.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 5 Volume set (in), Read cd be 00 ff ff ff ff 00 00 01 10 00 00 res 40/00:03:00:00:00/00:00:00:00:00/a0 Emask 0x4 (timeout) If this experiment makes the drive stuck, then we have the culprit. Hmm ... i dimly remember a project to send SCSI commands from the shell. Google brings me to sg_raw of sg3-utils. Looks like we have it. https://manpages.debian.org/testing/sg3-utils/sg_raw.8.en.html Probably: sg_raw /dev/sr0 be 00 ff ff ff ff 00 00 01 10 00 00 \ --outfile=tdb_data.bin I will explore this later this weekend. Have a nice day :) Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
I'm not sure it is what are you searching for, but Brasero produces a log launching from console it by : brasero -g --brasero-media-debug > log 2>&1 Then , I choose "Disk copy" and find ~/log Il 12/11/21 13:25, Thomas Schmitt ha scritto: I was not able to talk Brasero into showing me its session log for the failed "Copy" run. If my new theory is right there should be a log line "Checking for TDBs in track pregap." before nothing works any more.
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi, am i too stupid or is there really no user option to set write type SAO ? Neither clicking around in Brasero's GUI nor searching for BRASERO_BURN_FLAG_DAO in the source brings any insight. I want to burn a blank CD with SAO in order to check whether this avoids the problem with the ASUS drive at the end of burning. (SAO would be set by libburn API call burn_write_opts_auto_write_type() if the struct burn_disc, which will be used for burning, already has its burn_track objects attached and all track sources have a predictable size. The libburn plugin of Brasero would call burn_write_opts_set_write_type() with BURN_WRITE_SAO if flags from brasero_job_get_flags() would have the BRASERO_BURN_FLAG_DAO bit set. https://sources.debian.org/src/brasero/3.12.3-1/plugins/libburnia/burn-libburn.c/?hl=526#L526 ) It looks like the wodim plugin uses SAO by default. But i fail to activate this plugin. Have a nice day :) Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi,
the "Copy" task yields very interesting results:
A closed CD-R and a closed CD-RW which were written by write type SAO
don't spoil the drive.
Inserting a closed TAO CD-RW (burnt by Brasero) spoils the drive.
This spoiling is in effect already when the dialog window of Brasero asks
me to submit a medium or to choose a drive for copying.
dmesg shows:
[ 715.623542] ata3.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
[ 715.623564] ata3.00: cmd a0/00:00:00:00:00/00:00:00:00:00/a0 tag 13
Volume set (in), Read cd be 00 ff ff ff ff 00 00 01 10
00 00res 40/00:02:00:00:02/00:00:00:00:00/00 Emask 0x4 (timeout)
[ 715.623570] ata3.00: status: { DRDY }
[ 715.623577] ata3: hard resetting link
[ 715.938617] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 715.944589] ata3.00: failed to IDENTIFY (device reports invalid type,
err_mask=0x0)
[ 715.944594] ata3.00: revalidation failed (errno=-22)
[ 720.963384] ata3: hard resetting link
[ 721.278510] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 726.339201] ata3.00: qc timeout (cmd 0xa1)
[ 726.339213] ata3.00: failed to IDENTIFY (I/O error, err_mask=0x4)
[ 726.339217] ata3.00: revalidation failed (errno=-5)
[ 726.339223] ata3.00: disabled
[ 726.654802] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 726.654833] ata3: EH complete
[ 726.660786] sr 2:0:0:0: [sr0] tag#16 FAILED Result: hostbyte=DID_BAD_TARGET
driverbyte=DRIVER_OK cmd_age=0s
[ 726.660788] sr 2:0:0:0: [sr0] tag#16 CDB: Test Unit Ready 00 00 00 00 00 00
(As one can see, the kernel's hard resetting the link does not help.)
The line [715.623564] tells that the bad command was BEh READ CD for
sector -1.
This only looks wrong, but isn't by itself, because CDs have a Lead-in
which usually starts at sector -150.
Before that experiment i already learned something new about CDs
from reading brasero source code about media inspection:
The function brasero_medium_track_written_SAO() looks for an indication
that the CD was written with TAO or Packet
https://sources.debian.org/src/brasero/3.12.3-1/libbrasero-media/brasero-medium.c/#L1576
MMC-5 4.2.3.12 "The Track Descriptor Block" specifies this indication
for non-SAO CD to be in each block of the "pre-gap", which preceeds the
payload of the track. I.e. sector -1 is such a Track Descriptor Block.
This is a valuable information for possibly avoiding the readahead bug
with TAO CDs.
I was tempted to explore this trick myself for libburn. But now i think
that it could be the gesture which does not play well with the ASUS
DRW-24D5MT.
Now i will probably need some help by the GNOME community:
How to build Brasero from source ?
ldd /usr/bin/brasero | wc -l
yields a library count of 115. Ewww.
Although i know how to prepare the .deb packages of libburn on salsa and
to test-build them on a virtual Sid, i expect that Brasero is more effort.
In genral i am not trustworthy as operator beyond apt-get "update",
"dist-upgrade", and "install".
My plan for an experiment would be to let function
brasero_medium_track_written_SAO()
immediately and unconditionally return FALSE without any read experiment.
(This might confuse Brasero at the end checkreading. But i know that
the errors from reading the Run-out blocks on the ASUS do not yield a
spoiled drive.)
Some instructions how to achieve such a change in Brasero would be highly
welcome.
Next problem of me unskilled Brasero user:
I was not able to talk Brasero into showing me its session log for the
failed "Copy" run. If my new theory is right there should be a log line
"Checking for TDBs in track pregap."
before nothing works any more.
It would be interesting to see the log of a successful medium inspection
on one of the two other drives whether the "TDBs" got really checked.
But i don't know how to get the log of a successful run.
Best would be to let Brasero log into its start terminal from the
very beginning.
Does somebody have instructions for me how to achieve such a visible log ?
Have a nice day :)
Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Il 11/11/21 22:49, Thomas Schmitt ha scritto: Hi, Mauro Sacchetto wrote: that is (more or less): "Impossible to block unity". "unit", maybe ? The device. Yes, sorry for my bad English. After Brasero fails, it's impossible to erase the CD with K3, Either Brasero did its evil deed before trying to lock the unità or the failure to do so did not prevent further access to the drive. Do i get it right that you ordered Brasero to copy the CD to an image file, not a second CD/DVD/BD drive ? Something in Brasero's own activities for drive and medium inspection must be to blame. I will try the "Copy" task with fvwm tomorrow, just to be sure that it's not about the desktops. Yes: for I have only a drive, fist the Cd is copied in an image on HD, and then the image burned in a new support in the same drive Simon McVittie wrote: My understanding is that udisks does not automatically mount anything on its own If I'm not wrong, the CD is not automaticalli mounted. I see its name in Nemo -- Devices, but it needs a double click to mount it and to inspect its content
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi, Mauro Sacchetto wrote: > that is (more or less): "Impossible to block unity". "unit", maybe ? The device. > After Brasero fails, it's impossible to erase the CD with K3, Either Brasero did its evil deed before trying to lock the unità or the failure to do so did not prevent further access to the drive. Do i get it right that you ordered Brasero to copy the CD to an image file, not a second CD/DVD/BD drive ? Something in Brasero's own activities for drive and medium inspection must be to blame. I will try the "Copy" task with fvwm tomorrow, just to be sure that it's not about the desktops. I wrote: > > (How stupid can Brasero and udisks become ? Is there any limit ?) Simon McVittie wrote: > My understanding is that udisks does not automatically mount anything on > its own Indeed it looks like that. With fvwm instead of XFCE the pop-up windows and the automounting don't happen. My apologies towards udisks. > If you're using a purely XFCE system, thunar-volman is probably the > component responsible for mounting removable media. So curses towards thunar-volman ... and an apology because this is off-topic now that i have seen the problem with fvwm, too. Two of my questions in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=998718#110 are answered: - Would it happen without desktop ? = Yes. - Is the XFCE (?) window involved which offers a file manger even for blank CDs when they get inserted ? = No There are no indications that automats outside of Brasero have a stake in the problem. Have a nice day :) Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
On Mon, 08 Nov 2021 at 17:15:26 +0100, Thomas Schmitt wrote: > I start Brasero and a window pops up which says it cannot mount the CD. > (How stupid can Brasero and udisks become ? Is there any limit ?) My understanding is that udisks does not automatically mount anything on its own (it's designed to be mechanism, not policy), but your desktop environment might contain a component that provides the policy part and asks udisks to mount media. I would expect a desktop environment that does that to have configuration for whether that component is active or not. In GNOME, it's the Removable Media panel in the Settings app (gnome-control-center). If you're using a purely XFCE system, thunar-volman is probably the component responsible for mounting removable media. I don't know how or whether that can be configured. smcv
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
On Testing / Cinnamon it's impossible too "copy a disk"
(another voice of Brasero menu)
The CD-RW seems to be recognized and the burning begins,
but fails with:
Session error : Impossibile bloccare l'unità ((null))
(brasero_burn_record brasero-burn.c:2854)
that is (more or less): "Impossible to block unity".
The same on Stable / KDE with Brasero further installed
(obviously with all its dependencies).
After Brasero fails, it's impossible to erase the CD with K3,
and it's necessary to reboot ("No disk on /dev/sr0")
After reboot, K3B recognize the presence of the CD and blank it.
So, in Xfce, Cinnamon or KDE, the trouble is present
Il 11/11/21 15:12, Thomas Schmitt ha scritto:
Hi,
i managed to start fvwm2 (by Ctrl+Alt+F2 in the XFCE login window and
startx /usr/bin/fvwm2) and tried whether Brasero and ASUS drive have a
better relationship then.
They don't. It's as bad as with XFCE.
The Brasero run was started with a blank CD-RW in the drive and came,
with two pauses of a minute, up the "Checkreading" stage. Then it
complained that the drive was in use and the ASUS drive went unusable
as with the XFCE tests.
After a power cycle i verified that the CD was burned completely and
tried whether readom is to blame:
readom dev=/dev/sr0 f=cdimage.raw
It isn't. The drive stays usable after aborting readom with Ctrl+C because
it was stuck with futile retries to read the two TAO Run-out sectors at
the end of the track. The MD5 of cdimage.raw then matches the ISO image.
The CD does not get automounted with fvwm2. So this aspect of XFCE is
not a suspect any more.
Have a nice day :)
Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi, i managed to start fvwm2 (by Ctrl+Alt+F2 in the XFCE login window and startx /usr/bin/fvwm2) and tried whether Brasero and ASUS drive have a better relationship then. They don't. It's as bad as with XFCE. The Brasero run was started with a blank CD-RW in the drive and came, with two pauses of a minute, up the "Checkreading" stage. Then it complained that the drive was in use and the ASUS drive went unusable as with the XFCE tests. After a power cycle i verified that the CD was burned completely and tried whether readom is to blame: readom dev=/dev/sr0 f=cdimage.raw It isn't. The drive stays usable after aborting readom with Ctrl+C because it was stuck with futile retries to read the two TAO Run-out sectors at the end of the track. The MD5 of cdimage.raw then matches the ISO image. The CD does not get automounted with fvwm2. So this aspect of XFCE is not a suspect any more. Have a nice day :) Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
I again carried out a small experiment (as a simple user as I am) and precise, or rather I correct, what was stated in a previous email. Burning an ISO to a blank CD-RW (after: wodim dev=/dev/sr0 -v blank=fast) won't work either: This is brasero-session.log: Checking session consistency (brasero_burn_check_session_consistency brasero-burn.c:1739) BraseroBurnURI called brasero_job_get_action BraseroBurnURI called brasero_job_get_action BraseroBurnURI called brasero_job_set_output_size_for_current_track BraseroBurnURI stopping BraseroBurnURI called brasero_job_get_action BraseroBurnURI called brasero_job_get_session_output_size BraseroBurnURI output set (IMAGE) image = /tmp/brasero_tmp_OFOIC1.bin toc = none BraseroBurnURI called brasero_job_get_session_output_size BraseroBurnURI called brasero_job_get_action BraseroBurnURI called brasero_job_get_current_track BraseroBurnURI no burn:// URI found BraseroBurnURI stopping BraseroLocalTrack called brasero_job_get_action BraseroLocalTrack called brasero_job_get_action BraseroLocalTrack called brasero_job_set_output_size_for_current_track BraseroLocalTrack stopping BraseroLocalTrack called brasero_job_get_action BraseroLocalTrack called brasero_job_get_session_output_size BraseroLocalTrack output set (IMAGE) image = /tmp/brasero_tmp_JEOIC1.bin toc = none BraseroLocalTrack called brasero_job_get_session_output_size BraseroLocalTrack called brasero_job_get_action BraseroLocalTrack called brasero_job_get_current_track BraseroLocalTrack no remote URIs BraseroLocalTrack stopping BraseroChecksumImage called brasero_job_get_current_track BraseroChecksumImage called brasero_job_get_action BraseroChecksumImage called brasero_job_get_flags BraseroChecksumImage called brasero_job_get_action BraseroChecksumImage called brasero_job_get_action BraseroChecksumImage called brasero_job_get_fd_in BraseroChecksumImage called brasero_job_set_output_size_for_current_track BraseroChecksumImage stopping BraseroChecksumImage called brasero_job_get_current_track BraseroChecksumImage called brasero_job_get_action BraseroChecksumImage called brasero_job_get_flags BraseroChecksumImage called brasero_job_get_action BraseroChecksumImage called brasero_job_get_session_output_size BraseroChecksumImage output set (IMAGE) image = /tmp/brasero_tmp_VVNIC1.bin toc = none BraseroChecksumImage called brasero_job_get_session_output_size BraseroChecksumImage called brasero_job_get_action BraseroChecksumImage called brasero_job_get_action BraseroChecksumImage called brasero_job_get_current_track BraseroChecksumImage called brasero_job_get_input_type BraseroChecksumImage called brasero_job_set_current_action BraseroChecksumImage called brasero_job_get_fd_in BraseroChecksumImage called brasero_job_get_current_track BraseroChecksumImage called brasero_job_get_current_track BraseroChecksumImage Starting checksuming file /home/samiel/debian-11.1.0-amd64-netinst.iso (size = 396361728) BraseroChecksumImage called brasero_job_get_fd_out BraseroChecksumImage called brasero_job_get_current_track BraseroChecksumImage Setting new checksum (type = 2) b710c178eb434d79ce40ce703d30a5f0 ((null) before) BraseroChecksumImage Finished track successfully BraseroChecksumImage stopping BraseroLibburn called brasero_job_get_action BraseroLibburn called brasero_job_get_action BraseroLibburn unsupported operation BraseroLibburn deactivating BraseroLibburn called brasero_job_get_action BraseroLibburn called brasero_job_get_action BraseroLibburn called brasero_job_get_device BraseroLibburn Drive (/dev/sr0) init result = 1 BraseroLibburn called brasero_job_get_flags BraseroLibburn called brasero_job_get_media BraseroLibburn called brasero_job_get_fd_in BraseroLibburn called brasero_job_get_tracks BraseroLibburn Setting multi 0 BraseroLibburn Setting burnproof 1 BraseroLibburn Setting dummy 0 BraseroLibburn called brasero_job_get_session_output_size BraseroLibburn called brasero_job_set_current_action BraseroLibburn burn_drive_convert_fs_adr( /dev/sr0 ) BraseroLibburn Writing BraseroLibburn called brasero_job_set_dangerous BraseroLibburn called brasero_job_set_current_action BraseroLibburn called brasero_job_get_session_output_size BraseroLibburn called brasero_job_set_current_action BraseroLibburn burn_drive_is_enumerable_adr( /dev/sr0 ) is true BraseroLibburn called brasero_job_get_session_output_size BraseroLibburn called brasero_job_set_current_action BraseroLibburn Async START UNIT succeeded after 0.1 seconds BraseroLibburn called brasero_job_get_session_output_size BraseroLibburn called brasero_job_set_current_action BraseroLibburn Allocating buffer via mmap() BraseroLibburn called brasero_job_get_session_output_size BraseroLibburn called brasero_job_set_current_action BraseroLibburn cd Profile= 0Ah , obs= 32768 , obs_pad= 0 BraseroLibburn called brasero_job_get_session_output_size BraseroLibburn called brasero_job_set_current_action
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi, what i believe to have learned so far: - The problem is a co-operation of ASUS DRW-24D5MT and Brasero or some software which Brasero employs. This other software (if involved at all) does not strike with K3B (tested by Mauro Sacchetto) or non-GUI burn programs like wodim or xorriso. - The problem happens only with CD media. This media family is the most complicated among the optical media, because it not only can record data blocks of 2048 bytes per sector but also other sector types like CD-DA with 2352 bytes. - Reading data CD by audio CD commands is supposed to fail on the first read attempt, but the ASUS DRW-24D5MT tolerates this against the SCSI specs. The drive announces the obsolete feature 103h "CD Audio External Play Feature". (PIONEER BDR-S09 does not. TSSTcorp SH-S223B does, but throws the specified error when reading data CD as audio CD.) Weak theory: This tolerance might lure Brasero or other software into sending SCSI commands which are inappropriate with data CD, like the obsolete SCAN command or the obsolete STOP PLAY/SCAN command. These commands were obsoleted in 2006 by MMC-5 together with the PLAY AUDIO and other commands which were specific to standalone playing of audio CD. (All drives still support READ CD which can be used to read audio CD into the computer and let its media players create sound.) - There seems to be involved a difference between Cinnamon of Debian Testing and XFCE of Debian 10. While Mauro Sacchetto does not get an unusable drive with Brasero and a blank CD-RW on Cinnamon, i get to that problem after writing succeeded but before the checksum gets verified by Brasero. (The CD verifies good in another drive by comparing the MD5s of ISO image and CD.) With non-blank CD-RW i experienced sometimes the problem already after inserting it into the ASUS drive while Brasero is running. Mauro Sacchetto did not report such an early problem. Open questions: - Would it happen without desktop ? E.g. with fvwm2 as window manager. - Is udisks involved ? It seems to be very eager to automount as soon as the CD contains data. When i kill its process, they come back quickly. - Is the XFCE (?) window involved which offers a file manger even for blank CDs when they get inserted ? - Is the way of attachment of the drive to the computer involved ? My TSSTcorp drive offers obsolete CD audio commands but is in a USB box, whereas the ASUS is directly at SATA. - Why does only Brasero invite the problem ? Have a nice day :) Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
I smoothly burned the same ISO with Brasero to a DVD + RW, and the media was recognized immediately.On the other hand, the identification of the CD-RW is much slower (apart from the fact that the burn then fails) and this suggests that something else "occupies" the disc already, which is why Brasero does not find it and considers it unsupported. And let's go back to your hypotheses: either there is a perverse interaction between a Brasero component and the ASUS burner, or there is something else that interferes as soon as the media is inserted and before Brasero takes possession of it, which at this point does not manages to do. If there is any other test I can do (difficult, after all the ones you have done), I am always available. And thanks for your work! Il 09/11/21 16:44, Thomas Schmitt ha scritto: Do you have any idea what software might be doing this anomalous attempt, which is to try to read the data CD as if it were audio? Not yet. I normally don't use desktops but rather a window manager and i hate the kind of perky automats which i see on Debian 10 XFCE when i insert a medium or Brasero is done with writing a medium. Actually i use that machine mainly headless via ssh from an older machine which fits me like an old shoe. When i managed to get rid of XFCE i will try whether Brasero alone is able to spoil the drive. (I'd expect so, because the desktop's automats have enough opportunity to grope the medium after a xorriso run, but don't spoil the ASUS DVD burner.)
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi, the spoiled ASUS drive does not seem to be a direct result of an attempt to read audio CD sectors from a data CD. The drive is rather too tolerant in that aspect. The MMC-5 specs say that it should throw error 5,64,00 "ILLEGAL MODE FOR THIS TRACK", but the drive doesn't. It does not go bad either. So my nice theory about READ CD causing the SCSI error about unaligned writing is officially dead. And i have an unexpected casualty to bemoan ... - Experiments made: I removed the security barrier in cdrskin which prevents reading of data CDs as audio CDs and told it to read a CD with data as audio: mkdir audio_test cdrskin -V -v dev=/dev/sr0 extract_audio_to=audio_test \ >audio_test/scsi_log 2>&1 Normally it says: cdrskin: WARNING : Track 01 is not an audio track. cdrskin: SORRY : Medium in drive is not an audio CD. but now it reads to my big surprise the whole track into file audio_test/01.wav . The scsi_log shows READ CD commands which demand CD-DA sectors and get data back without error indication: READ CD be 04 00 00 00 00 00 00 18 10 00 00 841123 us [ 4002657 ] The resulting file is too large, because CD-ROM checksums and other non-data parts of the CD sectors where read together with the CD-ROM payload data. Divided by 2352 the number of read bytes gives the number of sectors of the track as announced by the CD table-of-content. To prove that the specs are normally obeyed, i insert the same CD into the TSSTcorp drive at /dev/sr2 and execute the cdrskin command (without option -V because i need no SCSI log). The drive takes duely offense: cdrskin: Writing audio track file: audio_test/01.wav cdrskin: SORRY : SCSI error on read_cd(0,0): [5 64 00] Illegal request. Illegal mode for this track. cdrskin: SORRY : SCSI error on read_cd(0,0): [5 64 00] Illegal request. Illegal mode for this track. but next the device file vanishes cdrskin: FAILURE : Failure to read audio sectors cdrskin: FATAL : Failed to transfer command to drive cdrskin: ( Most recent system error: 19 'No such device' ) cdrskin: FATAL : --- SG_IO: return= -1 , errno= 19 , host_status= 0x0 , driver_status= 0x0 cdrskin: FATAL : Attempted command: TEST UNIT READY : 00 00 00 00 00 00 cdrskin: FATAL : Lost connection to drive dmesg reports of repeated USB disconnect and connect going on. No power cycle helps. It seems that the USB hub went mad. Unplugging and replugging it into another mainboard USB port does not help. A very unexpected victim of a drive and media experiment. The drive comes back to life after i removed the hub and plugged the drive's USB box cable directly into the mainboard USB port. Violating SCSI specs brings bad luck. I won't ever repeat this test. (I am not superstitious, because superstition brings even more bad luck.) - Have a nice day :) Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi, Mauro Sacchetto wrote: > I actually managed to burn a blank CD-RW with brasero as well. > The problem arises when the CD-RW already has content. Not for me. Blank CDs behave better with the automounter (but not with the prompt window which offers me to start the file manager). But when they are written, Brasero gets stuck after the checkreading stage and the drive is then unusable until power cycle. I think we have different desktop systems: You tested with GNOME or KDE, i tested with XFCE (which i plan to replace by fvwm2 to get rid of the file manager prompt). Normally this should make no difference. But if it is about unwanted disc groping, the desktop is indeed a suspect. > Do you have any idea what software might be doing this anomalous attempt, > which is to try to read the data CD as if it were audio? Not yet. I normally don't use desktops but rather a window manager and i hate the kind of perky automats which i see on Debian 10 XFCE when i insert a medium or Brasero is done with writing a medium. Actually i use that machine mainly headless via ssh from an older machine which fits me like an old shoe. When i managed to get rid of XFCE i will try whether Brasero alone is able to spoil the drive. (I'd expect so, because the desktop's automats have enough opportunity to grope the medium after a xorriso run, but don't spoil the ASUS DVD burner.) > Given their modest cost, ... which might be part of the problem. What costs nothing is nothing. My ASUS was the second attempt to get a new DVD burner after a HL-DT-ST (LG) GH24NSC0 became unrealiable after only 2.5 years. The first new one was a Lite-On which could not read what it had written. I sent it back and got the ASUS as replacement. It works well for me, as long as i don't let Brasero act on CD media. All three burners were at sale for less than 20 dollars. (I pay in EUR.) Half of my burners are from LG. But this is only due to what was offered when i wanted a new drive. I have a very good ASUS BW-16D1HT, a noisy Optiarc BD-5300S (company has vanished), 4 LGs, a Samsung SH-S223B, and a Pioneer BDR-S09. Most of them never had to suffer a Brasero burn run. :)) (The Pioneer grips so hard and rotates so fast that modern Verbatim BD-RE media get cracks at the inner hole after having been read 20 times by it. Old Verbatims and modern Primeon BD-RE survive undamaged. I blame it on engraved letters on the modern Verbatim media which are very near to the inner rim, i.e. the place where the drive grips the medium. The Pioneer does not react on read speed settings but delivers data at maximum speed as long as the reader consumes that fast. I had to enhance libburn so that it can enforce a lower read speed by waiting between READ commands. At 6x BD speed = 27 MB/s the Verbatim BD-RE survive without cracks. This speed makes much fewer noise than the drive's favored 10x.) > Have you encountered any models that offer greater guarantees than the ASUS > in my possession? Normally they are ill only individually. The fact that our two burners of the same model fail in a very similar way is really unusual. It seems that Blu-ray drives are of better quality than drives which can only do CD and DVD. The BD drives cost about four times what DVD drives cost, although BD differs from DVD only by the presence of the third (blue) laser. The mechanics are mostly the same. DVD drives have only two lasers: infrared for CD and red for DVD. Have a nice day :) Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
I actually managed to burn a blank CD-RW with brasero as well. The problem arises when the CD-RW already has content. Do you have any idea what software might be doing this anomalous attempt, which is to try to read the data CD as if it were audio? Given their modest cost, I can of course also buy a more reliable burner. Have you encountered any models that offer greater guarantees than the ASUS in my possession? Thank you Il 09/11/21 14:41, Thomas Schmitt ha scritto: that the culprit is some software which wants to play the CD as audio CD
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi, the drive and Brasero work with DVD+RW, unformatted DVD-RW, and formatted DVD-RW. No bad symptoms to see, except that i get molested by the automounter and that i often have to repeatedly double click the drive field and the "Burn" button before burning begins. These successes give me the idea that the culprit is some software which wants to play the CD as audio CD. This needs a different SCSI command for reading. It's name is READ CD and it can be told to require CD-DA sectors of 2352 bytes rather than the 2048 bytes of data CD sectors. This would somehow explain the SCSI error "unaligned write", which then actually would rather mean "unaligned read". (This imposes the riddle why the TSSTcorp drive in the USB box does not cause such an SCSI error message.) Tests made: First i put the DVD+RW into the ASUS and start Brasero. The DVD gets found and after a few double clicks on the drive field, the Burn button finally works and "Burning" begins. "Finalizing", "SUCCESS", "Checksum", loud reading, "Ejecting medium". No SCSI error. xorriso -toc shows the written session. dd if=/dev/sr0 bs=2048 count=193536 | md5sum yields the correct MD5. (That @#$%^ automounter mounted it without asking me. Some other software pops up the window offering to start the file manager.) Next try: Brasero starts up with empty tray. Then i put in the DVD+RW from which i removed the ISO 9660 superblock by xorriso -blank. All works fine. No SCSI error message. Now with unformatted DVD-RW, fast blanked by xorriso -outdev /dev/sr0 -blank deformat_quickest This yields a medium state that is only suitable for write type DAO, which can only take a single session. The DVD-RW is an old 2x speed type. Full blanking would last about 40 minutes. Starting Brasero while the DVD is in the ASUS drive. All is well. Just half as fast as with the DVD+RW. Now after formatting the DVD-RW by unmounting (g) and this run: xorriso -outdev /dev/sr0 -format as_needed which lasts 40 minutes, i can burn and the drive stays usable. Have a nice day :) Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi, Mauro Sacchetto wrote: > I don't have the option of using more than one burner. I could try with more USB burners. But we already know that it is a problem between Brasero or its helper software on one side and the firmware of ASUS DRW-24D5MT on the other side. There may be other burner firmwares with the same vulnerability. But finding them would not bring more insight. (Of course i will keep this possibility in mind for occasions when other Brasero users report similar problems.) > It is difficult to understand how we can get out of it. I lack of a plausible theory how Brasero or its helpers can spoil the drive when Brasero is up and waiting for a disk to appear in the drive. I meanwhile have ideas for more experiments: - Does it happen only with CD but not with DVD+RW or DVD-RW ? I will probably test this today. - Does it work if i manage to permanently disable udisks ? (I once did this on Debian 8. But memories are dim and udisks quite surely evolved a lot since then.) I will have to find out about udisks configuration. Simply killing its two processes does not help. I tried and they came back. Any hints are welcome. - Does it happen when the ASUS burner is in a USB box ? If no: Does it depend on the maximum speed of the SATA port ? (See below the quote from the Manjaro thread.) This will mean that i have to break out my screw driver and the docs about the mainboard. (Me and a screw driver is a dangerous combination.) Update: The docs say that my mainboard ASUS Pro WS C246-ACE has 4 SATA 6.0 Gb/s ports and no slower SATA ports. So a port change looks not very promising. -- If Brasero had a maintainer and that maintainer has no better idea about the particular cause of this quite catastrophic behavior, then i would propose that Brasero shall try early to identify the drive model name, and refrain from doing anything more with the drive if it is an ASUS DRW-24D5MT (and maybe other types which might be found by users). It should first try to learn the drive model name from udev, so that it does not have to touch the drive by itself. If udev does not tell, then it would have to issue an SCSI INQUIRY command, which will tell the drive type. --- The software side of the problem seems old enough to have left traces in the web. But there are not so many found by Google: I now learn that i participated in a german thread without noticing that Brasero is at the core of the problem: https://forum.ubuntuusers.de/topic/problem-mit-dvd-rw-laufwerk-sata/ The thread starter reports at some stage that he succeeded with Brasero and CD. But we have to take such statements with a grain of salt. In the end he bought another drive and got happy. In https://forum.manjaro.org/t/solved-asus-cd-writer-installation-issues/37659 i see an interesting but riddling success report: "I moved the device on the MB from SATA 5 to SATA 6 and everything run smoothly" I assume the poster means the numbering of the SATA ports on the board. It is fewly plausible that Mauro Sacchetto and i both have bad SATA ports or cables. But what about SATA generations ? Maybe that board has ports for 3 Gbps and for 6 Gbps which makes a difference. --- Have a nice day :) Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
I don't have the option of using more than one burner. I had done a simple experiment by installing Brasero (obviously with all its dependencies) on the partition where I have Stable with KDE. So different kernel and different version of Brasero. The behavior is the same as that found in Testing with Cinnamon. It is difficult to understand how we can get out of it. In any case from the console, both with wodim and with xorriso, it is possible to burn correctly, or by installing K3b, even if on Cinnamon it requires 125 packag
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi, i booted kernel 4.19.0-17 which stems from a Debian 10 upgrade. Same as with 5.10-rc3: I started up brasero with empty tray of all drives. After inserting the CD-RW into the ASUS, brasero does not see it. xorriso shows that the drive is already in the bad state. So i did a power cycle with empty ASUS tray. Before starting Brasero i insert the CD-RW into the ASUS drive. Brasero sees it when starting up. So i can start the burn run. It gets to "Success", throws SCSI error 5,21,04, 1 minute of no action, then "Creating image Checksum", 1 minute of no action, then a new window pops up: "Error while burning. The drive is busy" and the drive is spoiled. So it is quite surely not about the kernel version. (But i meanwhile suspect that the SCSI error 5,21,04 is generated by the kernel and not by the drive. It does not happen with USB, it is outruled by the specs for optical drives, and i cannot imagine what command could be considered unaligned by the drive.) Have a nice day :) Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi i have to correct my previous report: > The obscure SCSI error 5,21,04 "Unaligned write" appears only with the ASUS. It appears with the PIONEER too, but not with the TSSTcorp drive. (And Brasero spoils the ASUS even if the message does not appear.) Nevertheless, i riddle what SCSI command can cause this error. WRITE commands tell block address and block count of their payload. They have no means to address single bytes. CDs can take single blocks as payload of a WRITE command. So i fail to see how such a command can be unaligned. Have a nice day :) Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi, Mauro Sacchetto wrote: > I installed on testing (kernel 5.14...) the kernel 5.10 from stable > (backports), but I received the same error So i fired up my experimental machine which has Debian 10 but kernel 5.10.0-rc3 cloned from git branch "linux-block" and modified to fix a few bugs in modules sr, cdrom and isofs. (linux-scsi is not interested in my patches. Shrug.) Three drives are attached: 0 -dev '/dev/sr0' rwrw-- : 'ASUS' 'DRW-24D5MT' 1 -dev '/dev/sr1' rwrw-- : 'PIONEER ' 'BD-RW BDR-S09' 2 -dev '/dev/sr2' rwrw-- : 'TSSTcorp' 'CDDVDW SH-S223B' sr0 and sr1 are connected via SATA. sr2 is in a USB box. sr0 is the same model as yours. Best chances for reproducing the burn disaster. Brasero and udisks on XFCE seem to be much at odds. Windows pop up which offer mounting and file managering. I decline. - Experiment reports about the ASUS: First run with /dev/sr0, the ASUS: Brasero burns but stalls with its "Success" stage. The SCSI error reply is reported in Brasero's start terminal: Sense key: 0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x40 0xa0 0x03 0x21 0x04 0x00 0x00 0x00 0x00 0x00 but no crash happens. The drive is now unusable but the CD yields the correct MD5 for debian-11.1.0-amd64-netinst.iso when read by /dev/sr2. I power cycle the machine to get my drive back. Next try, still with sr0 ASUS: Brasero says that no supported disk is in the drive. I click "Cancel" and again "Burn image". It finds the CD in sr0 but then immediately crashes with "Segmentation fault". Drive is unusable afterwards. Power cycle and next try with sr0 ASUS: I start Brasero and put the CD into sr0. Immediately the drive becomes unusable. No further action is needed. Power cycle and next try with sr0 ASUS: I blank the CD-RW by xorriso to keep udisks as far away as possible. I start Brasero and a window pops up which says it cannot mount the CD. (How stupid can Brasero and udisks become ? Is there any limit ?) I confirm that i noticed and let Brasero burn. It burns up to "Finalizing" and "Success" but then stalls for about a minute while the drive is blinking. Then comes the SCSI error message and after another minute a window pops up: "Error while burning. The drive is busy." I click "Close" and get the big Brasero window. I quit Brasero and the drive is unusable. Whatever i do, i don't get a new /dev/sr3 with the ASUS drive. --- Experiment reports about PIONEER and TSSTcorp (Samsung): Power cycle and CD into /dev/sr2, the TSSTcorp in a USB box. First i let md5sum compute the MD5 of the previously burnt CD. It matches the ISO's MD5. I blank the CD-RW by xorriso, eject, and start Brasero. CD back into sr2 Complaint about being not mountable. Whatever, Brasero begins to burn, finalizes, says "success", waits a minute while the drive is blinking, shows "Creating image checksum", begins to read at high and noisy speed, and finally ejects the medium. I insert again. Some software lets the drive blink and then complains that it cannot mount. md5sum /dev/sr2 yields the correct MD5. Blanked again by xorriso. I insert the CD into /dev/sr1, the PIONEER at SATA. This run is the smoothest of all: "Burning image to CD", "Finalizing", "Success", SCSI error message in start terminal, "Creating image checksum", "Ejecting medium", "Success". No minute of inactivity to see. Afterwards the drive is still functional with xorriso. md5sum yields the correct checksum. -- Summary: Brasero (maybe by help of udisks) is absolutely ill with the ASUS drive. With the other two drives it is still behaving confused but in the end can burn and does _not_ spoil the connection between drive and kernel. The obscure SCSI error 5,21,04 "Unaligned write" appears only with the ASUS. So the ASUS firmware quite probably has a stake in the problem. But it seems to need some abuse by Brasero (or udisks) to throw the SCSI error and then to become unusable. -- Outlook: I will try later with kernel 4.19.0-17 which is currently the official one for Debian 10 (upgraded in october due to the certificate blooper around "DST Root CA X3"). For now i would bet that the problem with the ASUS drive persists. I assume that it is a cooperation of buggy userland tools and buggy drive firmware. Have a nice day :) Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
I eject the CD-RW, inser it again and try to mount it: root@darkstar:~# mount /home/samiel/debian-11.1.0-amd64-netinst.iso /media/cdrom mount: /media/cdrom0: WARNING: source write-protected, mounted read-only. So the drive itself is still operational after the mishap. Yes, but only as root, not as a simple user In Nemo -- Devices now I see twice the CD-RW, the old one (not inspectable) and the new one (inspectable). Looks like the drive was re-connected by the kernel without completely dropping the old connection. Possibly udev adjusted the symbolic link /dev/cdrom to the newer device file (/dev/sr1 ?). The only plausible theory which i have is that Brasero now hits a new problem in the kernel (5.14 ?) which may or may not involve the drive's firmware but does not show up with older kernels. (I have a kernel 5.10 which works well with 3 drives.) I installed on testing (kernel 5.14...) the kernel 5.10 from stable (backports), but I received the same error Thank you for your job!:)
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi, Mauro Sacchetto wrote: > samiel@darkstar:~$ xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed > $isoimage > [...] > xorriso : UPDATE : 378 of 378 MB written (fifo 0%) [buf 100%] 0.0x. > xorriso : UPDATE : Thank you for being patient. Working since 728 seconds. > Writing to '/dev/sr0' completed successfully. > [...] > Media current: CD-RW > Media status : is written , is closed > Media summary: 1 session, 193686 data blocks, 378m data, 0 free > It's all ok! Phew ! It would have been a hell of a job to debug a broken relationship of libburn and the kernel of Debian Testing, as i'd need it on a real machine. (I have a Sid in a virtual machine, but there the ioctl(SG_IO) takes a different path through the device driver jungle.) > I eject the CD-RW, inser it again and try to mount it: > root@darkstar:~# mount /home/samiel/debian-11.1.0-amd64-netinst.iso > /media/cdrom > mount: /media/cdrom0: WARNING: source write-protected, mounted read-only. So the drive itself is still operational after the mishap. > In Nemo -- Devices now I see twice the CD-RW, the old one (not inspectable) > and the new one (inspectable). Looks like the drive was re-connected by the kernel without completely dropping the old connection. Possibly udev adjusted the symbolic link /dev/cdrom to the newer device file (/dev/sr1 ?). The only plausible theory which i have is that Brasero now hits a new problem in the kernel (5.14 ?) which may or may not involve the drive's firmware but does not show up with older kernels. (I have a kernel 5.10 which works well with 3 drives.) I will ask at debian-user mailing list whether there are users of Testing who have burners and can test them with Brasero. Maybe significant, maybe not: While riddling what Brasero can do to the drive-kernel connection i see: > Sense key: 0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x40 0xa0 0x03 0x21 > 0x04 0x00 0x00 0x00 0x00 0x00 That's an SCSI error reply: Key 5, ASC 21, ASCQ 04. Key 5 means "Illegal Request". https://www.t10.org/lists/asc-num.htm#ASC_21 shows a list of ASC 21 errors up to ASCQ 09. According to that it is 21h/04h DZ UNALIGNED WRITE COMMAND where a missing "R" between "DZ" and "UNALIGNED" indicates that this is not supposed to happen with optical drives. But i fail to imagine what other SCSI device would have been addressed by Brasero directly. The Linux block device layer does not forward such SCSI error codes to user space. A program gets to see them only if it sends SCSI commands via the lower level sg driver. The form of above "Sense key:" indicates that it does not stem from libburn, which works via the sg driver. Debian's code search https://codesearch.debian.net/search?q=package%3Abrasero+Sense+key finds the origin of the message in brasero_sense_data_print() https://sources.debian.org/src/brasero/3.12.3-1/libbrasero-media/scsi-sense-data.c/?hl=93#L93 Another search finds the only caller in brasero_sense_data_unknown() which has more customers. Among them is brasero_sense_data_illegal_request() called by brasero_sense_data_process(), called by brasero_scsi_command_issue_sync(). But then the trace becomes fuzzy. https://codesearch.debian.net/search?q=package%3Abrasero+brasero_scsi_command_issue_sync=0 yields 35 matches. (Brasero surely does too much SCSI on its own.) The source file names seem to tell what SCSI commands shall be performed. No write command among them, and only one setter named brasero_spc1_mode_select(), which is not a good suspect for the "unaligned write command error". It is not clear whether that error is involved in spoiling the relationship between kernel and drive. Have a nice day :) Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
== samiel@darkstar:~$ isoimage=/home/samiel/debian-11.1.0-amd64-netinst.iso samiel@darkstar:~$ xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed $isoimage xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project. xorriso : NOTE : Disc status unsuitable for writing Drive current: -outdev '/dev/sr0' Media current: CD-RW Media status : is written , is closed Media summary: 1 session, 193536 data blocks, 378m data, 0 free Beginning to blank medium in mode 'fast'. xorriso : UPDATE : Blanking ( 1.0% done in 1 seconds ) ... xorriso : UPDATE : Blanking ( 97.8% done in 53 seconds ) Blanking done xorriso : NOTE : Re-assessing -outdev '/dev/sr0' Drive current: -outdev '/dev/sr0' Media current: CD-RW Media status : is blank Media summary: 0 sessions, 0 data blocks, 0 data, 703m free Beginning to write data track. xorriso : UPDATE : Thank you for being patient. Working since 0 seconds. ... xorriso : UPDATE : Thank you for being patient. Working since 43 seconds. xorriso : UPDATE : 0 of 378 MB written (fifo 99%) [buf 100%] 3.8x. ... xorriso : UPDATE : 378 of 378 MB written (fifo 0%) [buf 100%] 0.0x. xorriso : UPDATE : Thank you for being patient. Working since 728 seconds. Writing to '/dev/sr0' completed successfully. xorriso : NOTE : Re-assessing -outdev '/dev/sr0' xorriso : NOTE : Disc status unsuitable for writing Drive current: -outdev '/dev/sr0' Media current: CD-RW Media status : is written , is closed Media summary: 1 session, 193686 data blocks, 378m data, 0 free == It's all ok! Than I try to burn the ISO woth Brasero launching it by console: == samiel@darkstar:~$ brasero ** (brasero:2837): WARNING **: 01:07:35.934: Could not establish a connection to Tracker: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.freedesktop.Tracker3.Miner.Files was not provided by any .service files (brasero:2837): Gtk-WARNING **: 01:08:01.131: Failed to fetch network locations: È stato raggiunto il timeout Sense key: 0x70 0x00 0x05 0x00 0x00 0x00 0x00 0x0a 0x00 0x40 0xa0 0x03 0x21 0x04 0x00 0x00 0x00 0x00 0x00 Segmentazion fault == and Brasero crashes dmesg: == [ 1657.332142] sr 5:0:0:0: [sr0] tag#10 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s [ 1657.332151] sr 5:0:0:0: [sr0] tag#10 CDB: Prevent/Allow Medium Removal 1e 00 00 00 01 00 [ 1657.332231] brasero[2837]: segfault at 2f400 ip 7fc57b9e0231 sp 7ffecc8f6368 error 4 in libc-2.32.so[7fc57b8a7000+149000] [ 1657.332268] Code: 84 00 00 00 00 00 0f 1f 00 31 c0 c5 f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 89 f9 48 89 fa c5 f9 ef c0 83 e1 3f 83 f9 20 77 1f fd 74 0f c5 fd d7 c1 85 c0 0f 85 df 00 00 00 48 83 c7 20 83 e1 == I eject the CD-RW, inser it again and try to mount it: == root@darkstar:~# mount /home/samiel/debian-11.1.0-amd64-netinst.iso /media/cdrom mount: /media/cdrom0: WARNING: source write-protected, mounted read-only. == In Nemo -- Devices now I see twice the CD-RW, the old one (not inspectable) and the new one (inspectable). But If I try to mount it not by console, but from Nemo (when there is only an occurence of the device) I receive: == Impossible to mount debiam-11iso Error mounting /dev/sr0 at /media/samiel7Debian...: no medium found on /dev/sro After this: == samiel@darkstar:~$ isoimage=/home/samiel/debian-11.1.0-amd64-netinst.iso samiel@darkstar:~$ xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed $isoimage xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project. libburn : FAILURE : SCSI command 12h yielded host problem: 0x4 SG_ERR_DID_BAD_TARGET (Bad target, device not responding ?) libburn : FAILURE : Command: INQUIRY : 12 00 00 00 24 00 : dxfer_len= 36 libburn : FATAL : Lost connection to drive xorriso : FAILURE : Cannot acquire drive '/dev/sr0' xorriso : FAILURE : -as cdrecord: Job could not be performed properly. xorriso : aborting : -abort_on 'FAILURE' encountered 'FATAL' == Il 07/11/21 22:34, Thomas Schmitt ha scritto: Did you already try what happens if you eject the CD and insert it again after spoiling the drive state with Brasero and before using the drive for mounting or for xorriso -toc ?
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi,
(No need to Cc: me, i am subscribed to the bug report 998718.
If you are subscribed too and don't want to be Cc:ed, then tell me.)
> thanx for your quick reply
That's because new udevadm said "XORRISO". I found the bug report by my
evening patrol with Google.
---
Diagnosis:
The unusable drive state looks like a bad relationship between drive
and kernel. Regrettably the dmesg log does not tell how Brasero brought
this relationship in its bad shape.
What to do next:
Did you already try what happens if you eject the CD and insert it again
after spoiling the drive state with Brasero and before using the drive
for mounting or for xorriso -toc ?
If not yet, then please do.
> xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project.
I guess this means you are running Debian "testing".
("stable" has version 1.5.2.)
To outrule the possibility that libburn underneath Brasero is to blame,
please use xorriso to burn an image by this drive:
isoimage=...path.to.your.ISO.image.file...
xorriso -as cdrecord -v dev=/dev/sr0 blank=as_needed $isoimage
Then try whether the drive is still usable.
(Crossing fingers now.)
-
Just in case somebody is interested in details of my diagnosis:
Mauro Sacchetto wrote:
> dmesg tell me:
> [23315.697087] sr 5:0:0:0: [sr0] tag#16 FAILED Result:
> hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s
> [23315.697092] sr 5:0:0:0: [sr0] tag#16 CDB: Prevent/Allow Medium Removal 1e
> 00 00 00 01 00
The drive did not respond to a SCSI command from the kernel's SCSI
driver. Brasero obviously tried to lock the drive tray so that pressing
the eject button would have no effect. (At least with motorized trays.)
> [23315.697128] brasero[9154]: segfault at 2f400 ip 7fb6350a5231 sp
> 7fff0e805918 error 4 in libc-2.32.so[7fb634f6c000+149000]
This might be due to a bug in Brasero, which would not react properly
on the failure of the tray locking attempt.
> xorriso tells me only
> TEST UNIT READY
> 00 00 00 00 00 00
> 19 us [ 1091 ]
The drive obviously responded to this SCSI command (indicating that it
is ready for work).
> INQUIRY
> 12 00 00 00 24 00
> From drive: 36b
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 10 us [ 1207 ]
> --- SG_IO: host_status= 0x4 SG_ERR_DID_BAD_TARGET (Bad target, device not
> responding ?)
> --- SG_IO: Gave up connection to drive
Here the drive did not respond to the kernel, which thus reported the
DID_BAD_TARGET to libburn. The Linux SG_IO adapter of libburn then gave
up the connection.
> libburn : FATAL : Lost connection to drive
> xorriso : FAILURE : Cannot acquire drive '/dev/sr0'
> xorriso : aborting : -abort_on 'FAILURE' encountered 'FATAL'
But xorriso at least found a way out without producing a segmentation
fault in libc or elsewhere.
> Better than my previous report:
> xorriso -scsi_log on -outdev /dev/sr0 -toc
> [... longer list of SCSI transactions ...]
> Media current: CD-RW
> [...]
> Media product: 97m26s65f/79m59s74f , CMC Magnetics Corporation
> Media status : is written , is closed
> [...]
> TOC layout : Idx , sbsector , Size , Volume Id
> ISO session : 1 , 0 , 193536s , Debian 11.1.0 amd64 n
> Media summary: 1 session, 193536 data blocks, 378m data, 0 free
All seems well. The drive responds to commands in reasonable time,
the medium is recognized as CD-RW, and the filesystem is recognized
as ISO 9660.
Have a nice day :)
Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
thanx for your quick reply dmesg tell me: = [23315.697087] sr 5:0:0:0: [sr0] tag#16 FAILED Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK cmd_age=0s [23315.697092] sr 5:0:0:0: [sr0] tag#16 CDB: Prevent/Allow Medium Removal 1e 00 00 00 01 00 [23315.697128] brasero[9154]: segfault at 2f400 ip 7fb6350a5231 sp 7fff0e805918 error 4 in libc-2.32.so[7fb634f6c000+149000] [23315.697136] Code: 84 00 00 00 00 00 0f 1f 00 31 c0 c5 f8 77 c3 66 2e 0f 1f 84 00 00 00 00 00 89 f9 48 89 fa c5 f9 ef c0 83 e1 3f 83 f9 20 77 1f fd 74 0f c5 fd d7 c1 85 c0 0f 85 df 00 00 00 48 83 c7 20 83 e1 = xorriso tells me only = root@darkstar:~# xorriso -scsi_log on -outdev /dev/sr0 -toc 2>&1 | tee -i /tmp/xorriso.log xorriso 1.5.4 : RockRidge filesystem manipulator, libburnia project. TEST UNIT READY 00 00 00 00 00 00 19 us [ 1091 ] INQUIRY 12 00 00 00 24 00 From drive: 36b 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 us [ 1207 ] --- SG_IO: host_status= 0x4 SG_ERR_DID_BAD_TARGET (Bad target, device not responding ?) --- SG_IO: Gave up connection to drive libburn : FAILURE : SCSI command 12h yielded host problem: 0x4 SG_ERR_DID_BAD_TARGET (Bad target, device not responding ?) libburn : FAILURE : Command: INQUIRY : 12 00 00 00 24 00 : dxfer_len= 36 libburn : FATAL : Lost connection to drive xorriso : FAILURE : Cannot acquire drive '/dev/sr0' xorriso : aborting : -abort_on 'FAILURE' encountered 'FATAL' = Il 07/11/21 19:37, Thomas Schmitt ha scritto: Hi, i am upstream programmer of libburn, which might be in charge of burning underneath Brasero. Regrettably i cannot interpret Brasero's messages unless they come from libburn or libisofs. So i am not sure whether i can help with fixing Brasero. The statement by other software that no medium is found in /dev/sr0 surprises me. Such a status assessment is usually done by the drive and i am not aware of any regular means to let a drive ignore or deny its loaded medium. Do you see anything in dmesg that occured when Brasero failed and looks related to "sr" or "cdrom" ? Can i talk you into inquring the drive by xorriso and logging its SCSI transactions when the drive has gone mad from Brasero and a medium is still inserted ? xorriso -scsi_log on -outdev /dev/sr0 -toc 2>&1 | tee -i /tmp/xorriso.log This would give insight into what the drive tells about its status without the programs-in-the-middle. The log is quite verbose and will have several hundred lines. Please post /tmp/xorriso.log as attachment or send it to me by private mail. (I wonder why udevadm monitor of Testing is so eager to insert blanks everywhere. But that would be a different bug, if it is not a copy+paste artefact.) Have a nice day :) Thomas -- Prof. Mauro Sacchetto Santa Croce 1332a 30135 Venezia tel.: 041 722938 cell.: 348 9690575 e-mail:mauro.sacche...@gmail.com Linux user no.: 353546 public key athttp://keyserver.linux.it
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Hi, i am upstream programmer of libburn, which might be in charge of burning underneath Brasero. Regrettably i cannot interpret Brasero's messages unless they come from libburn or libisofs. So i am not sure whether i can help with fixing Brasero. The statement by other software that no medium is found in /dev/sr0 surprises me. Such a status assessment is usually done by the drive and i am not aware of any regular means to let a drive ignore or deny its loaded medium. Do you see anything in dmesg that occured when Brasero failed and looks related to "sr" or "cdrom" ? Can i talk you into inquring the drive by xorriso and logging its SCSI transactions when the drive has gone mad from Brasero and a medium is still inserted ? xorriso -scsi_log on -outdev /dev/sr0 -toc 2>&1 | tee -i /tmp/xorriso.log This would give insight into what the drive tells about its status without the programs-in-the-middle. The log is quite verbose and will have several hundred lines. Please post /tmp/xorriso.log as attachment or send it to me by private mail. (I wonder why udevadm monitor of Testing is so eager to insert blanks everywhere. But that would be a different bug, if it is not a copy+paste artefact.) Have a nice day :) Thomas
Bug#998718: Brasero fails (on Testing) burning an ISO image on a CD-RW
Package: Brasero Version: 3.12.3-1 I work on Debian Testing (Bookworm) with Cinnamon, always kept up to date. The problem I point out is related to the burning of ISO to CD-RW using Brasero. I state that from the console using wodim I can both erase CD-RW and burn an ISO. Instead, if I proceed with Brasero with an already burned CD-RW (containing an ISO): a) if I try to erase the disk beforehand with the relative tool in the Tools menu, the disk is found but the operation is not carried out with the warning: === Unable to lock the drive === b) if I try to burn the ISO directly the disc is initially found, but the operation is not carried out with the warning: === Insert a writable CD or DVD. The disk in Asus DRW-24D5MT is not supported === After both types of attempts, the CD-RW (which has not been modified and still contains the paretenza ISO) is no longer found even by Nemo, with the warning: === Unable to mount Error mounting system-managed device / dev / sr0: no medium found on / dev / sr0 === If I reboot the system, the CD-RW is found again, and I can mount it from Nemo and inspect its contents. It seems that Brasero does not identify the CD-RW as such, ie as rewritable. The same operations succeed perfectly from a Stable with KDE, using K3b. I have compared the logs. Testing / Cinnamon gives me: === samiel @ darkstar: ~ $ udevadm monitor --property --udev monitor will print the received events for: UDEV - the event which udev sends out after rule processing UDEV [19048.365742] change /devices/pci:00/:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sr0 (block) ACTION = change DEVPATH = / devices / pci: 00/: 00: 1f.2 / ata6 / host5 / target5: 0: 0/5: 0: 0: 0 / block / sr0 SUBSYSTEM = block DISK_MEDIA_CHANGE = 1 DEVNAME = / dev / sr0 DEVTYPE = disk SEQNUM = 3051 USEC_INITIALIZED = 1848541 ID_CDROM = 1 SYSTEMD_MOUNT_DEVICE_BOUND = 1 ID_CDROM_CD_R = 1 ID_CDROM_CD_RW = 1 ID_CDROM_DVD = 1 ID_CDROM_DVD_R = 1 ID_CDROM_DVD_RAM = 1 ID_CDROM_DVD_R_DL_SEQ = 1 ID_CDROM_DVD_R_DL_JR = 1 ID_CDROM_DVD_PLUS_R_DL = 1 ID_CDROM_DVD_PLUS_R = 1 ID_CDROM_DVD_PLUS_RW = 1 ID_CDROM_DVD_RW_SEQ = 1 ID_CDROM_DVD_RW_RO = 1 ID_CDROM_CD = 1 ID_CDROM_RW_REMOVABLE = 1 ID_CDROM_DVD_RW = 1 ID_CDROM_DVD_R_DL = 1 ID_CDROM_MEDIA = 1 ID_CDROM_MEDIA_CD_RW = 1 ID_CDROM_MEDIA_STATE = complete ID_CDROM_MEDIA_SESSION_COUNT = 1 ID_CDROM_MEDIA_TRACK_COUNT = 1 ID_CDROM_MEDIA_TRACK_COUNT_DATA = 1 ID_ATA = 1 ID_TYPE = cd ID_BUS = ata ID_MODEL = DRW-24D5MT ID_MODEL_ENC = DRW-24D5MT \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 \ x20 ID_REVISION = 2.00 ID_SERIAL = DRW-24D5MT_KLJL1685744 ID_SERIAL_SHORT = KLJL1685744 ID_ATA_SATA = 1 ID_ATA_SATA_SIGNAL_RATE_GEN1 = 1 ID_WWN = 0x50014800 ID_WWN_WITH_EXTENSION = 0x50014800 ID_PATH = pci-: 00: 1f.2-ata-6.0 ID_PATH_TAG = pci-_00_1f_2-ata-6_0 ID_PATH_ATA_COMPAT = pci-: 00: 1f.2-ata-6 ID_FS_DATA_PREPARER_ID = XORRISO-1.5.0 \ x202018.09.15.133001 \ x2c \ x20LIBISOBURN-1.5.0 \ x2c \ x20LIBISOFS-1.5.0 \ x2c \ x20LIBBURN-1.5.0 ID_FS_UUID = 2021-11-03-15-04-45-00 ID_FS_UUID_ENC = 2021-11-03-15-04-45-00 ID_FS_BOOT_SYSTEM_ID = EL \ x20TORITO \ x20SPECIFICATION ID_FS_VERSION = Joliet Extension ID_FS_LABEL = Debian_testing_amd64_n ID_FS_LABEL_ENC = Debian \ x20testing \ x20amd64 \ x20n ID_FS_TYPE = iso9660 ID_FS_USAGE = filesystem ID_PART_TABLE_UUID = 7ed8b2bd ID_PART_TABLE_TYPE = dos ID_FOR_SEAT = block-pci-_00_1f_2-ata-6_0 MAJOR = 11 MINOR = 0 DEVLINKS = / dev / disk / by-id / wwn-0x50014800 / dev / disk / by-id / ata-DRW-24D5MT_KLJL1685744 /dev/disk/by-path/pci-:00:1f.2-ata-6 /dev/disk/by-path/pci-:00:1f.2-ata-6.0 / dev / cdrom / dev / disk / by-label / Debian \ x20testing \ x20amd64 \ x20n / dev / disk / by-uuid / 2021-11-03-15-04-45-00 TAGS =: systemd: uaccess: seat: CURRENT_TAGS =: systemd: uaccess: seat: === Stable / KDE gives to me: === samiel@darkstar:~$ udevadm monitor --property --udev monitor will print the received events for: UDEV - the event which udev sends out after rule processing UDEV [184.968927] change /devices/pci:00/:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sr0 (block) ACTION=change DEVPATH=/devices/pci:00/:00:1f.2/ata6/host5/target5:0:0/5:0:0:0/block/sr0 SUBSYSTEM=block DISK_MEDIA_CHANGE=1 DEVNAME=/dev/sr0
