Hi,
> isoinfo gave me this..
Looks like quite a normal bootable ISO 9660 filesystem image.
Much like the Debian and Ubuntu ISOs which get burned to DVD
all over the world.
Still hard to believe that the problem should sit in this
image and not in burner drive and medium.
How much evidence do y
Hi,
i am the upstream developer of libburn, libisofs, and libisoburn.
Some clarifications:
cdrskin can replace wodim for pure data CDs and pure audio CDs.
It cannot produce mixed mode CDs like CD-XA or "Video CD".
(With DVD and BD it is simply superior to wodim.)
xorriso can produce HFS+ inside
Hi,
there is a feature with cdrskin which was intended to help
its integration into cdrkit.
man cdrskin describes this option:
fallback_program=command
Set a command name to be executed if cdrskin encounters a known
cdrecord option which it does not yet support. If a non-emp
Hi,
> I'm not sure we want to continuously give it back until it builds (which
> it might on schroeder, since it didn't fail there yet)...
I would assume the problem is deterministic and depends on
the exact tree of file names which is given to genisoimage
as input.
So adding a few names of empty
Hi,
i can reproduce the problem with the current development
version of xorriso.
Regrettably i cannot just use stat() instead of lstat() because
i need to obtain absolute paths when inserting files into the
ISO image model. This is because the working directory may change.
So i will have to expl
Hi,
Linux semantics is that component ".." hops up to the parent
directory of the link-resolved current tree node.
xorriso hopped up to the previous path component.
I have uploaded a new development snapshot.
Please test whether it solves the problem. In a directory
of your choice, do
wget ht
Hi,
> > Please test whether it solves the problem.
> It does--thanks!
Ok. Next release is planned within about a month.
The changeset which fixed the problem is a bit large
for backporting to stable:
http://libburnia-project.org/changeset/5241
although it should be applicable for libisoburn-1
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,
> :-[ WRITE@LBA=538f0h failed with SK=4h/TRACKING SERVO FAILURE]:
This is a problem between drive and medium.
It does not necessary mean that either of them is bad.
But at least the combination does not work properly.
Try other media. If the problem persists, get another drive.
Have a nice
Hi,
(For some reason my subscription to this bug does not work.
Better Cc: me.)
> I guess this backup tool
> creates iso's witch are not compattible with DVD file system.
> (Universal Disk Format (UDF), ISO/IEC 13346 and/or ECMA
The error message originally stems from the drive's firmware.
I
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 perfo
Hi,
since IA64 is said to boot via EFI, you'd probably need a GPT
(with "protective MBR").
Do you have a particular system at hand which would boot
via MBR or GPT ?
Are you apt to equip the ISO image with a GPT which contains
an EFI System partition that points to the file /boot/boot.img ?
(Firs
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 a
Hi,
> these programs are usable on
> all architectures even if the bootloader isn't available,
Be aware that neither old isohybrid.pl nor new isohybrid.c are
independent of the SYSLINUX version.
I can forward this warning by H. Peter Anvin (hpa), the author
of ISOLINUX, from personal experience
Hi,
uploaded is a new (semi-stable) development snapshot
http://www.gnu.org/software/xorriso/xorriso-1.3.7.tar.gz
with the new features for PALO on HP-PA, which are now promised to
stay compatible in future releases.
MD5: 961939a15cdb2b9893fbe25f453d9ac4
Version timestamp : 2014.04.09.073038
Hi,
the proposed patch for the boot sector documentation looks at the
topic from the PALO user perspective. But the perspective of the
file boot_sectors.txt is the one of an ISO 9660 producer.
So i would like to re-arrange the info.
How about this for the command line part ? Would it be technica
Hi,
> > How to recognize a PALO that is "newer" ?
> It should be palo 1.92 or higher.
> > ... PALOHDRVERSION ...
> I could update it to 5.
I think it is appropriate.
Readers of libisofs docs and of PALO could make a clear connection.
> We shouldn't make xorriso more complicated than necessary.
Hi,
the GPT header CRC of
http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso
looks ok now for me and for gdisk of oldstable (which formerly
complained about amd64 ISOs). Now it says:
GPT fdisk (gdisk) version 0.8.1
Partition ta
Hi,
my newest bug about gdisk hating an ISO with GPT and MBR is
not affecting debian-cd. (Further it is not GRUB2 specific.)
I can reproduce the user's symptoms with gdisk 0.8.1 and can work
around them by explicitely disabling multi-session emulation when
producing the ISO. This disabling is def
Hi,
Chris Bainbridge:
> I still can't create a partition, which was the original aim. Is it
> supposed to work?
I succeeded with gdisk on my oldstable test machine (help texts and
clueless actions of mine not shown):
--
$ dd if=debi
Hi,
the trusty-desktop-amd64+mac.iso which boots on that machine
bears one single El Torito boot image, an isohybrid MBR, and
partition offset 16. Just like Debian i386 ISOs.
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "un
Hi,
> I am also a bit curious to know how the information regarding which
> versions of software were used to create the .ISO . It seems this
> info. is embedded in the .iso generated
xorriso by default writes its version info into the Preparer Id
field of the ISO Primary Volume Descriptor (super
Hi,
because debian-cd also records the arguments of its xorriso run,
it should be not too hard to repack it with a newer xorriso,
which produces better GPT. E.g. xorriso-1.3.2 from Debian Sid.
You will need to copy the MBR from the original ISO
dd if=debian-7.3.0-amd64-netinst.iso bs=512 count
Hi,
it is embarrassing to see the own bugs mummified since a
full year. You should rather enjoy the fresh and juicy bugs
of version 1.3.6.pl01.
Funnily nobody complains that the wrong GPT header checksum
would prevent booting from USB stick via EFI.
Doesn't (U)EFI check ? Do all tested machines b
Hi,
thank you for flying xorriso.
I already asked at debian-cd why the option -isohybrid-apm-hfsplus
is used with a boot image that contains a FAT filesystem.
The option advertises the FAT in an Apple Partition Map as HFS+
partition.
It is rather intended to advertise a HFS+ image for booting Mac
Hi,
> the bug in question is supposed to have existed in upstream until 1.3.4?
No.
It was introduced by 1.2.4 and fixed by 1.3.0.
So the version in Debian testing should be ok.
It's just that xorriso-1.3.6.pl01 is the newest upstream release,
which i would of course like to see in Debian testing.
Hi,
in january we had a conversation about xorriso and PALO.
I implemented the boot sector as learned from genisoimage:
version number 4 and the short command line at byte 24 to 151.
Further there is the proposed version 5 with long command line at
byte 1024 to 2047, and the yet unexplained "ipl_
Hi,
> > Because our discussion stalled, i did not publish the enhancements
> > of libisofs API and xorriso CLI with the recent release 1.3.6.
> That's really sad!
> It would have been easier for me, if you would have added them, even
> if they were not perfect.
Ah no. It's a tiny bit inconvenien
Hi,
looking at your description of ipl_entry computation
- after midnight - makes me search for alternatives.
I would have to duplicate a non-trivial part of PALO
which then would have to be validated against the
original code. From then on, i would have to maintain
it without having much clue.
Hi,
> Because of how palo is built, it ensures, that the entry point is always
> "zero".
That's very convenient for all of us.
> I will test your xorriso as soon as possible.
Lemme check whether defining the macro
Libisofs_enable_unreleased_hppa_palO
in libisofs/libisofs.h of the current GNU
Hi,
> I tried with the xorriso -as mkisofs command, with no luck.
> This command terminates with a SIGBUS no matter of the options I pass on
> the command line.
Ouch.
I have no Debian of arch "sparc" in reach.
> xorriso -as mkisofs -r -J -o ./tmp/miniiso/mini.iso -G /boot/isofs.b -B
> ... ./t
Hi,
> I may provide you access to a shell account on my machines if needed.
Yes, please.
Plus a directory tree
./tmp/miniiso/cd_tree
which can cause the xorriso crash.
> Sparc architecture is extremely picky about alignement. Bad alignement,
> yields SIGSEGV whereas intel only do it in the l
Hi,
Sébastien Bernard:
> result from strcmp('\','\0001' is 0)
> result from strcmp('\','\0001' is -1)
> Typicaly, an endianness error.
But one in strcmp(), not in your code or the one of genisoimage.
You compare an empty string with a string that contains one
character 0x01.
This is under
Hi,
> Program received signal SIGBUS, Bus error.
> add_worker (w_type=3, d=0x161128 , f=0xd1b20
> 149 a->u = *(union w_list_data *)data;
Other than expected from the first report in bug 731806,
the problem does not sit in libisofs but in libburn/async.c.
(Other predecessor developer
Hi,
---
sorry, i sent the first copy of this to the predecessor bug 731806.
---
> Program received signal SIGBUS, Bus error.
> add_worker (w_type=3, d=0x161128 , f=0xd1b
Hi,
i can reproduce the SIGBUS only when gcc got option -O2.
(I removed all -O2 from ./configure, ran make clean and make.)
I can silence the error, with -O2 enabled, by replacing
a->u = *(union w_list_data *)data;
with
memcpy(&(a->u), data, sizeof(union w_list_data));
So this se
Hi,
sorry for mis-posting the first reply for bug 746254 to this bug 731806.
Meanwhile it turned out that the SIGBUS vanishes if i do not
compile with -O2 or if i replace "a->u =" by memcpy().
So it seems worth to check whether genisoimage resp. strcmp() work
properly if not compiled with -O2.
Hi,
the change from "a->u =" to memcpy() seems to have enabled
production of SPARC bootable images.
I did on the shell account provided by Sebastien without experiencing
any error indication:
cd /home/thomas
/home/thomas/xorriso-1.3.7/xorriso/xorriso -as mkisofs \
-r -J -o test.iso -G
Hi,
Patrick Baggett:
> Could you explain the context around this code? Perhaps the source is
> not really "alignment safe" and could use some patching upstream? I'd
> be happy to provide advice or code samples.
The context was misposted to bug report 731806 as message #87:
https://bugs.debian.o
Hi,
i wrote:
> struct write_opts write;
> ...
> add_worker(Burnworker_type_writE, d,
> (WorkerFunc) write_disc_worker_func, &o);
Urgh. I copied the wrong struct definition. Line 592 bears of course:
struct write_opts o;
which is used in the call of add_worker().
Ha
Hi,
> I really need a disassembly and to be able to probe the runtime
> stack a bit, so that really means that I need to build the code. :)
The current example would be a bit too opulent, i guess:
-rwxr-xr-x 1 thomas thomas 3753398 avril 28 17:49 xorriso/xorriso
(wget http://www.gnu.org/softw
Hi,
> No, it's plain wrong. Unions are fine, if used properly. You aren't
> using them properly.
Duh. You convinced me. The callers do it wrong, indeed.
They would have to use local union variables instead of their actual
structs. The parameter of add_worker() should be a pointer to the
union, no
Hi,
Sebastien's machine now has a xorriso-1.3.7 (the current development
snapshot) with changed libburn/async.c.
The callers of add_worker() now declare:
union w_list_data o;
rather than
struct union_member o;
The type of the fourth parameter of add_worker has been changed
fro
Hi,
finally the problem turned out to be caused by libburn's
wrong usage of the call parameter stack.
The copy source of the failing statement is allocated too
small by the caller of function add_worker:
struct write_opts write;
and then copied with the size of
union w_list_data
This bug is
Hi,
Sébastien Bernard:
> Cheers to team work.
Special cheers to Patrick Baggett !
And thanks to all who cared for this problem. I'd need more
users who don't shrug but complain and tell me that i'm wrong.
The bug fix is now committed as
http://libburnia-project.org/changeset/5324
(We still d
Hi,
the libisoburn tarball which contains xorriso is indeed GPLv2+.
(The GNU xorriso package gets derived a GPLv3+ from this.)
Nevertheless it is not intentional that the binary from libisoburn
becomes GPLv3 by linking an optional library. Especially it then
still states at run time:
$ xorriso
Hi,
this is now fixed by
http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/revision/1155
Thank you for reporting.
> If the maintainer does, please feel free to forward.
Currently i, the upstream, am less busy than the maintainer.
Filing Debian bugs is a fine way to contact me.
Ot
Hi,
i asked bug-libreadline for advise how to detect GPLv3 versions.
The answer is: readline.h macro RL_VERSION_MAJOR >= 6 means GPLv3+.
There is no API call provided to detect the version at run time.
So Debian should please do its best to prevent libisoburn compiled
with libreadline-5 from runn
Hi,
Steven Chamberlain:
> I'm unfamiliar with xorriso but the man page mentions "-joliet on"
The problem is that argument "--" marks the end of the parameter
list of xorriso command "-as mkisofs".
Both versions of grub-mkrescue start xorriso with that command and
use mkisofs-ish options to define
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 s
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
stage
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);
wh
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 with
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 up
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,
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 supposed
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
brin
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 everythi
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, an
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
op
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 listmas...@
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 all
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 debian-bugs-dist-requ...@lists.debia
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: EC
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? Conta
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 UNSUBSC
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 476
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 debian-bugs-dist-requ...@lists.d
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 oc
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 ar
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
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 behav
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.
ma
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.
https://mail.gno
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 b
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 t
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 halfwa
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
Aft
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/DV
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 instal
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 brasero-2
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-1
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 y
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 ("install_path"/l
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 Bra
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 21
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/boot.efi from the ISO-9660 or UDF filesystem, so
> this should be checked.
GRUB2 grub-mkrescue can produce (U)EFI bootable ISO 9660 i
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,
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 i
1 - 100 of 449 matches
Mail list logo
