Hi,
Samuel Thibault:
The test that fails is in isVDSetTerminator: Reserved field must be
0.. On d-i images, there is some data starting from offset 24, I guess
for the hybrid nature of d-i CDs.
I googled for isVDSetTerminator and found
Hi,
newly uploaded is
http://www.gnu.org/software/xorriso/xorriso-1.0.1.tar.gz
Steve, if you want to patch your copy of xorriso-0.6.7:
I only added the memset() call to the following function in
libisofs/ecma119.c :
static
int write_vol_desc_terminator(Ecma119Image *target)
{
int res;
Hi,
$ ls install* isolinux
install:
install.386:
isolinux:
I am quite clueless about this.
$ bsdtar xf debian-sq-di-rc1-i386-businesscard.iso
As learned from Bug#610781, i examine:
http://cdimage.debian.org/cdimage/squeeze_di_rc2/i386/iso-cd/debian-squeeze-di-rc2-i386-businesscard.iso
Hi,
Samuel Thibault:
Mmm, actually there is nothing in _all_ the directories...
This makes it somewhat less puzzling. I was wondering what could
be the decisive difference between /install.386 and others.
Do i get it right that only empty top level directories get
extracted ? I.e. /dists
Hi,
i booted the Debian installation of the project test machine
Linux debian 2.6.26-2-amd64 #1 SMP Tue Jan 12 22:12:20 UTC 2010 x86_64
(Yeah, luxury. A dedicated modern test machine. Donated.)
Now i would need instructions for dummies how to create a debuggable
bsdtar resp. one that gives me
Hi,
it seems the immediate reason is in
libarchive/archive_read_support_format_iso9660.c:read_entries()
which iterates over
next_entry(iso9660)
until a NULL or a non-directory appears.
With an image created by
mount -o loop /reiser/p/v/debian-squeeze-di-rc2-i386-businesscard.iso /mnt
Hi,
Andreas Henriksson:
DEB_BUILDGOPTIONS=noopt nostrip debug dpkg-buildpackage -uc -us
this should spit out .deb packages in /tmp/foobar containing
non-optimized debuggage binaries.
You install them with dpkg -i /tmp/foobar/*.deb
For now i helped myself with vim and make.
I will follow your
Hi,
after some more calories and sleep i now see two problems in
libarchive:
- ISO 9660 images can be read in a single pass only if the directory
entry of any file is stored at a lower address than the file's
content.
This makes multi-session image unsuitable for libarchive.
No
Hi,
the situation now appears a bit better than first perceived in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=610783
The demand of libarchive that all directory entries have to come
before any content block eases the task of producing digestible
addresses for symbolic links, device files
Hi,
Tim Kientzle:
Hmmm Are you working with libarchive 2.8.4?
Yes. That is what Debian installed when being asked for bsdtar.
There have been a number of fixes in trunk specifically
to handle symlinks and other empty data files; maybe some
of those need to be backported.
Argh ? All
Hi,
Michihiro NAKAJIMA:
I think it is the same thing that I fixed in libarchive trunk/r2940.
We should have Cc'ed you earlier.
+ if (file-size == 0 location = 0) {
+ /* Do not appear before any directoy entries. */
+ if (file-offset == 0)
+ file-offset
Hi,
the new development snapshot of GNU xorriso is uploaded.
http://www.gnu.org/software/xorriso/xorriso-1.0.1.tar.gz
Version timestamp 2011.01.26.133107, MD5 d90b1502f3d4c116931024497a260f83
For a test i created a new ISO image from the content of
debian-squeeze-di-rc2-i386-businesscard.iso
Hi,
the new daily image nicely passed my tests
http://cdimage.debian.org/cdimage/daily-builds/daily/current/i386/iso-cd/debian-testing-i386-businesscard.iso
It boots with readable help texts, unpacks completely with unaltered
libarchive-2.8.4 and with patched libarchive-2.8.4.
If there are
Hi,
Leandro Lucarella:
Burning some files in a data DVD using brasero is very slow. I get 2.6x
speed at most and my drive is 8x capable. Using growisofs directly,
i get a 6.6x speed average (which seems reasonable for a 8x drive).
Josselin Mouette:
My guess goes for a bug in libburn;
Hi,
reading the initial message on
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567056
and especially the list
Versions of packages brasero depends on:
i wonder whether libburn is involved at all.
ii libbrasero-media0 2.28.3-2 CD/DVD burning library for GNOME -
In
Hi,
--enable-dvd-obs-64k
or
--enable-track-src-odirect
Thomas,
I'm not actually sure whether these options would affect the rest of the
drives and use cases in an unpredicted way. If they are safe, I'm more than
happy to enable them in the next package upload, so that the library
Hi,
for some reason i did not get the last two
mails from Leandro.
Only good that George brought me back to the
topic.
I propose to next explore libisofs without a
burn process being involved.
If Brasero can burn to a disk file as drive
target, then try whether it is as slow as with
optical
Hi,
I'm sorry, I'm running a home mail server using a dynamic IP address
Your mails are marked as spam but i do not
allow my mail provider's automat to drop any
mails.
I now got the two missing mails
Date: Mon, 8 Feb 2010 15:14:58 -0300
Date: Mon, 8 Feb 2010 15:16:11 -0300
just together
Hi,
growisofs
-use-the-force-luke=notray
-use-the-force-luke=4gms
-dvd-compat
-speed=8
-use-the-force-luke=tty
-Z
/dev/sr0=/proc/self/fd/0
Yes, it is growisofs working.
The options are ok for a burn run without mkisofs
being
Hi,
i forgot to mention that probably i am in charge
for any problems _inside_ the ISO generator.
The log says:
BraseroLibisofs creating volume
...
BraseroLibisofs Adding graft disc path = [[REMOVED]]
...
BraseroLibisofs Writing to pipe
I assume this is our libburnia libisofs.
So if
Package: linux-2.6
Version: 2.6.26-21
Severity: normal
Hi,
i experience with eSATA and USB failures to read
DVD+RW if the drive tray gets loaded automatically
or if it is still blinking from ongoing loading.
E.g. with dd:
$ dd if=/dev/sr0 of=/dev/null bs=2048 count=1
dd: opening
Hi,
i am the upstream developer of libburn.
If you suspect bugs in libburn then please notify
me either directly or via
libburn-hack...@pykix.org
Josselin Mouette wrote:
Thanks for the report, this looks like a bug in libburn.
There's a new upstream release available,
There are no changes
Hi,
Maybe there's a way to fix this with a targeted patch in a point
release, if there is no clear reason for the ISOs to be created with
too-tight permissions?
This was fixed by
http://libburnia-project.org/changeset/3537/libburn/trunk
Released 16 Jan 2011 as libburn-1.0.0 resp. GNU
Package: linux-2.6
Version: 2.6.32-35
Severity: normal
Hi,
i am experiencing problems between Debian 6.0.2 and a Sandisk
Cruzer U3 memory stick (4 GB).
These sticks appear as USB hub with an emulated CD-ROM drive and
a memory stick storage device. So Linux creates /dev/srN as well
as /dev/sdX
Hi,
$ xorrisofs dummy/ dummy.iso
$ $ od -t x1 dummy.iso
000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
*
1334000
Yes. This is reproducible in the upstream development version.
It seems to be related to the fact that the output fd is
read-only to a disk file.
The problem must have
Hi,
me:
xorrisofs dummy/ | cat dummy.iso
George Danchev:
Yes, this works as expected.
I have to correct my first mail.
Of course, the file descriptor is write-only, not read-only.
First a fine ISO image gets written and then the multi-session
mechanism kicks in unprepared. It overwrites
Hi,
Niv Sardi wrote:
as the release goal says if you can
make a case for using it then we should ship
It now appears as misconfiguration of libacl-dev, which explicitely
refers in its libacl.la to the removed libattr.la.
apt-get downloaded it from
Hi,
Samuel Thibault wrote:
libisofs not building was becoming more and more a problem, so I patched
the libacl.la file by hand (yes, a bad thing).
A change in the Debian package configurations of libisofs and libisoburn
for hurd-i386 would avoid unnecessary problems.
Currently the support for
Hi,
i am currently the developer of libburn and libisofs.
https://bugzilla.gnome.org/show_bug.cgi?id=655601
I know about such problems, but i do not know how to get into a
discussion with Brasero developers.
My impression is that the libisofs plugin causes libisofs to end
prematurely. libburn
Hi,
Paul Menzel wrote:
So unfortunately it looks like there is no list for Brasero and you need
to use the GNOME Bugzilla bug tracker.
Well, there is a list, the last entry is of january 2012, and it
complains about the burn errors which seem to have emerged in
spring 2011.
Hi,
Josselin Mouette wrote:
That would be brasero-list:
https://mail.gnome.org/mailman/listinfo/brasero-list
Is there a chance that we could work together to find out what's wrong ?
If not George Danchev's patch already brings insight, that is.
Released libisofs-1.2.2 would be a good test
Hi,
George Danchev wrote:
Thomas (or anyone else), could you please try brasero on your squeeze box (I
currently don't have any burners at reach),
Ok, for once ... :))
I will cry on your shoulder if it freezes my good old fvwm display.
Actually i avoided trying myself because i do not want to
Hi,
PS: Somehow the Debian bug report address was not in CC but it was
archived [1] anyway. Did you put it in BCC? Anyway, I added it back to
the CC list.
I thought i addressed my mails
To: 617...@bugs.debian.org
Cc: all others.
but To: shows up with rpn...@free.fr.
I am using a halfways
Hi,
George Danchev wrote:
$ dpkg-checkbuilddeps # to check you have all build-dependencies installed
$ dpkg-buildpackage
Ok. The messages from remnant root-owned result files tell me
that this is indeed 2.30.3-2.
dpkg-source: error: cannot write brasero_2.30.3-2.dsc: Permission denied
Hi,
Command for what?
For building the Brasero that was downloaded as source.
dpkg-buildpackage seems to be the right one.
But as George put, the problems are about Data projects, that
means - as far as I understand - to choose some files from your disk and
burn them directly to a CD/DVD
Hi,
i had a look at brasero build logs and have to drop the appealing theory
of sizeof(off_t) == 4.
The compiler gets a sufficient macro to avoid this: -D_FILE_OFFSET_BITS=64
I now managed to build Brasero brasero-2.30.3-2 from the Debian sources.
It shows no differences to the previously
Hi,
in order to apply George's patch anyway, i have tried to disable
libburn so that growisofs would be used with DVD.
No success.
Both, growisofs and libburn are enabled but also greyed, so that i
cannot change their checkboxes.
Whatever, just in case it brings any new insight:
$ cd
Hi,
Paul Menzel wrote:
Until then I suggest to not bother anymore with that problem.
It gives libisofs a bad name.
Probably the squeeze Brasero is two notches too old.
This comment could explain why:
https://bugzilla.gnome.org/show_bug.cgi?id=655601#c5
... Nico Zanferrari 2012-01-16
Hi,
Alain Rpnpif wrote:
This works fine for CR-RW only but not
with CD-R (I have crashed 2 CD-R to confirm).
With CD-R, some files are full of 00H.
This supports the theory of poor compatibility of drive and media.
Blank CD-RW and CD-R are handled identically by burn software.
They make no
Hi,
Hm, did you try to mess up with gconf-editor
Not yet.
But i try now:.
I do not see an alternative to
apps|brasero|config|priority|libisofs-image
Well i now set
apps|brasero|config|priority|growisofs-burn 1
This did not change anything. Now growisofs process to see while the
DVD burn
Hi,
- Disabling the option Burn the image directly without saving to disc
(see screen shot) creates a working CDs (that can be ejected
automatically too).
I will have to try at least the eject aspect.
But anyway, I updated to brasero 3.4.1 and I can still reproduce the bug.
How did you do
Hi,
I get that growisofs is not recommended for burning CD-R[W]
It flatly refuses:
:-( /dev/sr0: media is not recognized as recordable DVD: A
The growisofs runs were surely with DVD or BD.
simple solution is to remove the offending plugin from brasero plugin
directory
Hi,
Simon Wenner wrote:
xorriso seems to work as expected.
Your report and the one of Alain Rpnpif support the theory that your drives
dislike CD write type TAO with your particular CD media or in general.
I failed to force Brasero into using the other write type. (Details below.)
I see in
Hi,
get the source package (apt-get source) and just edit
plugins/libburnia/burn-libburn.c
Does it still have that name ?
Are there other occasions of burn_write_opts_set_write_type() in 3.4 ?
(Meanwhile i stirred up the system enough to get this:
Message from syslogd@debian2 at Jul 7
Hi,
on the risk to discourage Simon from testing SAO, i have to report
a fact that weakens my TAO/SAO theory in his special case.
Brasero writes TAO too, when copying an image from hard disk to CD,
or when storing a newly generated image intermediately on hard disk.
I had hoped to find the final
Hi,
for the records: I managed to get my changes in burn-libburn.c into
effect by copying from
brasero-2.30.3/plugins/libburnia/.libs/libbrasero-libburn.so
to
/usr/lib/brasero-0/plugins/libbrasero-libburn.so
I assume it is better to achieve this the Debian way.
At least i could verify that
Hi,
since traditionally the padding of 300 kB is added by genisoimage or
mkisofs, i have tested an alternative proposal in burn-libisofs.c.
iso_write_opts_new (opts, 2);
iso_write_opts_set_relaxed_vol_atts(opts, 1);
+ iso_write_opts_set_tail_blocks(opts, 150);
Hi,
i see i made a mistake when writing:
The problem was introduced in october 2012 by
It was introduced in october 2010, not 2012.
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Hi,
1. Specify the volume ID, which can be considered to be the name of the
image.
Ok.
2. Other burning applications use the volume ID to set the volume name.
What would be the difference between volume id and volume name ?
Like:
IMAGE_23
Joliet allows 16 UCS-2
Hi,
i made further changes in
http://libburnia-project.org/changeset/4857
in order to get the search string volume name into the text.
(Further i forgot to update the change date of them nam page.)
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to
Hi,
i think i can spot a byte eating problem in
http://git.gnome.org/browse/brasero/commit/?id=5ff86b48
resp. the master-branch commit
http://git.gnome.org/browse/brasero/commit/?id=1b8397ee252df2d554682ca2d694d5937fbf6e39
Hi,
+ res = burn_drive_convert_fs_adr (stdio:/tmp/my_emulated_drive,
libburn_device);
Isn't there a quotation mark missing before the comma ?
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Hi,
I am also going to print out the sector size. (Or just use GDB.)
The loop condition (read_bytes == sector_size) suggests that
it must be 2048. Only this alignment is guaranteed for the
output of libisofs.
(Actually it would be a good reason for the 50 % bug if libisofs
would not obey this
Hi,
i have to correct myself:
004 002 C D 0 0 1 001 \0 \0 \0 \0 \0
i wrote:
It should sit at block 17.
So it looks like we lose 17 blocks at start.
Well, it sits now at block 8.
So we lost 9 blocks before it.
Have a nice day :)
Thomas
--
To
Hi,
(i got this via pkg-libburnia-de...@lists.alioth.debian.org)
Paul Menzel wrote:
Thomas Schmitt pointed out a bug in libburn 1.2.2 [2] that it always
reports that 2048 bytes are reported to be missing when a premature
ending occurs. This is fixed upstream in changeset 4762 [2] and libburn
Hi,
staring at lines 201, 202, and 216 of
http://git.gnome.org/browse/brasero/tree/plugins/libburnia/burn-libisofs.c
i realize that this loop drops every second block !
read_bytes = priv-libburn_src-read_xt (priv-libburn_src,
Hi,
- while (priv-libburn_src-read_xt (priv-libburn_src, buf,
sector_size) == sector_size) {
+ while (read_bytes == sector_size) {
I am building it right now.
Crossing fingers ...
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to
Hi,
000 001 C D 0 0 1 001 \0
Yes. That is the start of a Primary Volume Descriptor block.
Please mount the medium and use diff to compare the files in
the image with their originals on hard disk. Just to be sure.
(Mounting does not check all
Hi,
Paul Menzel wrote in his patch:
Substituting this command with the variable fixes the problem reported in
GNOME Bugzilla bug 655601.
I have to stress that the found bug does _not_ explain the
original report of
https://bugzilla.gnome.org/show_bug.cgi?id=655601
(which is what i call the
Hi,
The log shows some Growisofs message and not the one I have.
Although, could it be that it is dependent on the libburn version?
The libburn plugin was not used. Only the libisofs one.
A run with growisofs as burn engine would also suffer from the bug
we found in the libisofs plugin.
But
Hi,
a Brasero flaw was found in the course of Debian bug 688229.
It would provide an explanation for the problems which are
described here. Especially it is involved when burning directly
to optical media and not involved when writing ISO filesystems
to hard disk.
The problem was introduced in
Hi,
Rick Thomas wrote:
When booting the Debian netinst powerpc installer from a USB flash disk you
may see a mesage
WARNING: Bootstrap partition type is wrong: Apple_HFS
type should be: Apple_Bootstrap
[...]
Any idea what makes it do that? Can if be fixed?
Apple_HFS is
Hi,
brasero (libisofs)DEBUG : Processed 2119108 of 2119108 KB (100 %)
It went well, at least as far as libisofs was involved.
So this is not the problem with premature end after 50 %.
And it is not the riddling CD problem, where Brasero CDs are
unreadable, whereas xorriso burned CDs
Hi,
Paul Menzel wrote:
$ dd if=/dev/sr1 bs=2048 skip=16 count=1 | od -c
...
000 \0 0 034 001 \0 \0 001 034 0 F 034 + \0 \0 +
020 034 F p \t 023 022 1 ! \0 \0 \0 \0 001 \0 \0 001
040 034 \0 I \0 M \0 G \0 _ \0 2 \0 4 \0 2 \0
Hi,
Could you please CC me
I will try to remember. :)
But maybe you better subscribe by a mail to
688229-subscr...@bugs.debian.org
Is there some way to simulate a burner to find out what happened?
libburn would accept burner addresses like
stdio:/tmp/my_emulated_drive
which would behave
Hi,
I could not
find a way to set the name for the medium. That name is later used by
programs like `udisks` to name the mount point.
The current default seems to »ISOIMAGE«.
The property which has content ISOIMAGE by default is called
Volume Id. To be set by xorriso command -volid.
man
Package: linux-2.6
Version: 2.6.32-35
Severity: normal
I experienced a kernel Oops at three occasions when i switched off
a USB CD drive while it was in use by an application.
It first happened with qemu (stress test), then with blkid (gnawing
on medium with LEC uncorrectable error), and now
Hi,
Ben Hutchings wrote:
Please
update to the current stable point release (Debian 6.0.3) and let us
know whether the bug is fixed.
I am not a skilled Debian admin. So i need instructions for any Debian
specific action you want me to perform.
Following the advise of the maintainer of my
Hi,
cat /proc/version
Says:
Linux version 2.6.32-5-amd64 (Debian 2.6.32-38) (b...@decadent.org.uk) (gcc
version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Oct 3 03:59:20 UTC 2011
I was confused by the similarity of 2.6.32-5-amd64 and 2.6.32-38
which made me think that -38 should replace -5.
Hi,
i read on http://lists.debian.org/debian-devel/2012/01/msg00168.html
For optical media, I am not really sure: it may use ElTorito or load a
file /efi/boot/bootarch.efi from the ISO-9660 or UDF filesystem, so
this should be checked.
GRUB2 grub-mkrescue can produce (U)EFI bootable ISO 9660
Hi,
Regular El Torito then.
At least grub-mkrescue makes it that way. Better ask a grub-devel for
advise and options.
UEFI booting requires a GPT and a special partition, which would
probably be impossible to implement along with the MBR hack for hybrid
booting.
I am clueless enough to
Hi,
READ TRACK INFORMATION
52 01 00 00 00 ff 00 00 14 00
From drive: 20b
00 26 01 01 00 07 41 01 00 00 00 00 00 00 00 00 00 3f b0 00
This reports that the Next Writable Address is 0 and that 0x3fb000
(=4173824) blocks are free.
RESERVE TRACK
53 00 00 00 00 00 3b 1a 60 00
xorriso :
Hi,
mrvn@storage:~% xorriso -outdev /dev/hda
Media status : is blank
Allegedly no impact.
Did you always use the same medium or did you try several ones
from that pack ?
mrvn@storage:~% cat iso | xorriso -as cdrecord -v dev=/dev/hda -eject -
libburn : FATAL : SCSI error on write(544,16):
Hi,
i am the upstream programmer of libburn.
If i can do anything to help fixing the problem, please tell me.
About the doxygen complaints (of which i am unsure whether they are
the reason for the stalled build process):
Hi,
Matthias Klose wrote:
fix it in libburn or disable building the docs.
upstream did tell you that they didn't want to update that
for newer doxygen versions.
If you mean me, as upstream of libburn, then you got me wrong.
I am willing to help Debian packaging in any way. Just give
me clear
Hi,
Helmut Grohne wrote:
As for the libburn maintainers, I suggest to change the comment in the
header to not include the verbatim string burn_abort(0) in order to
not confuse doxygen.
Done by
http://www.libburnia-project.org/changeset/5122
Do you have more advise for me ?
E.g. for this
Hi,
sorry, i forgot to Cc: the cloned bug 718694 in my answer to 718151.
Helmut Grohne wrote:
As for the libburn maintainers, I suggest to change the comment in the
header to not include the verbatim string burn_abort(0) in order to
not confuse doxygen.
Done by
Hi,
i have uploaded
http://www.gnu.org/software/xorriso/xorriso-1.3.1.tar.gz
with improved time measurement in the SCSI log.
The time measurement is now done in userspace by gettimofday()
or optional clock_gettime(CLOCK_MONOTONIC).
The shown granularity is microseconds.
Additionally there is
Package: dvd+rw-tools
Version: 7.1-6
Severity: normal
Tags: upstream patch
Hi,
it is a long standing bug of growisofs to throw an error at
the end of a burn run to previously blank BD-R media:
:-[ CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB]: Input/output error
See also
Hi,
this would be a blow for burn programs. I am maintaining libburn
and its applications cdrskin and xorriso. So i am interested in this
problem.
The main suspect would be the kernel in this case. The programs send
SCSI commands via ioctl(SG_IO) and wait until this ioctl call ends.
If they are
Hi,
Michael Gilbert wrote:
It seems like the wrong fs type was used.
Could you elaborate your theory ?
Can Brasero be talked into producing wrong fs type ?
What type of filesystem do you have in mind ?
The posted block, which should contain the ISO 9660 PVD, shows
pieces of a Joliet tree:
Hi,
under the assumption that your Brasero is configured to use libburn,
it is me who is responsible for the lower levels of drive operation.
I propose we discuss the problem on that lower level first in order
to either find a bug of libburn or to tell Brasero maintainers what
Brasero is
Hi,
* Wodim: refuses to use BD altogether
One should not even use it with DVD.
XF Burn: [...] and works fine :-)
This one is supposed to use libburn as backend.
At least http://packages.debian.org/squeeze/xfburn says so.
In that case, xorriso should work fine too. So you should next
bring
Hi,
Can you think of any other way for me upgrade to a newer Brasero
version?
I do not use Brasero or other GUI frontends (except my emerging
xorriso-tcltk, which is more a proof-of-concept than an end-user
tool).
Unfortunately, it
cannot be installed without changing literally everything
Hi,
1.2.4 apparently comes with quite a number of improvements in the EFI area,
And it had some bugs with -partition_offset and GPT.
I am in the progress of releasing 1.2.6 with libisoburn/xorriso
release note:
* Bug fix: -partition_offset 16 kept -isohybrid-gpt-basdat from writing
Hi,
out of curiosity i compared systemrescuecd-x86-3.2.0.iso and
debian-wheezy-amd64-efi-test5.iso.
One important difference is that systemrescuecd has no MBR or GPT.
The whole system area is filled with zeros, where test5 is generously
equipped with hard disk partition tables. I see MBR, GPT,
Hi,
I just have not found a command-line tool that is convenient enough to use.
Well, convenience is a relative thing.
I need:
- data CDs / DVDs / BDs
I could offer you xorriso.
http://www.gnu.org/software/xorriso
It is entirely specialized on ISO 9660 filesystems which it puts onto
Hi,
will hopefully fix a number of the issues we're seeing with UEFI.
What problems are there in particular ?
Similar as with BIOS we have two main starting points of booting:
El Torito for CD, DVD, BD.
GPT for hard disk and alike.
But i do not know whether the distinction between both is as
Hi,
We'll just have to see if we get any more feedback.
Please keep me informed about any problems which are suspicious
to come from the early boot stages when the firmware has to find
its first piece of software on the medium.
(There are potential problems with partition tables at later
Hi,
libburn : FATAL : Cannot reserve track of 7164592128 bytes
It should be able to do so. So why does it not ?
libburn : SORRY : Asynchronous SCSI error on SYNCHRONIZE CACHE: [3 0C 00]
Write error
Probably libburn should not synchronize after the failed track
reservation.
Is the medium
Hi,
(Thank you for flying xorriso.)
The problem seems to be in growisofs.c function builtin_dd()
which inquires by
capacity = get_capacity (ioctl_handle);
before doing
pwrite64_method = poor_mans_setup (ioctl_handle,
outoff+tracksize);
Hi,
(Somehow my subscription to bug 709971 did not forward
your recent mail to me. I found it by Google.)
my 5. Child was born on 20.6.
Congrats !
Please give me advice for the next tests. Should I repeat the xorriso
write and read tests on the same time?
The improved time measurement
Hi,
i expect that Brasero 2.30 is too old for getting support.
Probably you should try to reproduce the problem with a newer
version.
Your suspicion about missing burn-free cannot be outruled.
DVD-R do get sent a mode page 05, where burn-free can be
enabled or disabled by the BUFE bit.
(Most
Hi,
i found a source tree of Brasero 2.30.3 on my test machine
which is still running Squeeze. (Advise needed for upgrade.)
There are two occurences of the libburn call about burn-free.
One of them is for pseudo blanking of DVD+RW.
So the only one that would matter is the one in
Hi,
there is a discussion going on, which might be related
to this bug report:
http://www.spinics.net/lists/linux-scsi/msg69679.html
This discussion states that SG_IO is serialized by a mutex,
and that this probably can be eased.
It does not explain why Winfried experiences a reduction
of
Hi,
i am the upstream programmer and ithus to blame for the
manual's state.
* No indication of default behavior for eash option.
Did I miss something hidden some where? Is the first one default?
The rule of thumb is that the core features of ISO 9660
are default and that xorriso specific
Hi,
Cyril Brulebois wrote:
genisoimage: Error: './tmp/miniiso/cd_tree/boot/.' and
'./tmp/miniiso/cd_tree/boot/..' have the same ISO9660 name ''.
[...]
Probably some FS-dependent fun? Anyone would have a clue about it?
Looks like an internal error of genisoimage.
'.' should be mapped to a
Hi,
(you forgot to CC the Debian bug report 702...@bugs.debian.org)
Is the medium still reported as blank ?
Yes, it is.
So we could do more experiments without media waste.
xorriso -report_about ALL -scsi_log on \
...your.other.xorriso.arguments... \
21 | tee -i
Hi,
libburn : FATAL : SCSI error on write(0,16): [3 0C 00] Write error
...
What can I do now?
Other media or other drive, i fear.
Neither the burn program nor the operating system are at fault.
It is simply that the drive answers any attempt to start writing
by an error message. We have
Hi,
please make sure to package libburn-1.3.0.pl01.tar.gz
and not libburn-1.3.0.tar.gz.
A nasty regression has been found in cdrskin-1.2.8 and cdrskin-1.3.0:
Option -msinfo on DVD and BD reported identical numbers for the start
of the most recent session and the predicted start of the next
1 - 100 of 446 matches
Mail list logo
