From sh at lutzhaase.com Mon Nov 9 00:25:32 2009 From: sh at lutzhaase.com (Sven-Hendrik Haase) Date: Mon, 09 Nov 2009 01:25:32 +0100 Subject: [Debburn-devel] Bug: Can't put files bigger than 4GiB on disk In-Reply-To: <4AE04A26.60204@lutzhaase.com> References: <4AE02912.5090004@lutzhaase.com> <10447175213716@212.46.126.165> <4AE04A26.60204@lutzhaase.com> Message-ID: <4AF7617C.60508@lutzhaase.com> On 22.10.2009 14:03, Sven-Hendrik Haase wrote: > On 22.10.2009 12:33, Thomas Schmitt wrote: >> Hi, >> >> >>> it appears there is a bug in the current cdrkit version that doesn't >>> allow me to put files bigger than 4GiB on a disk. I tried calling >>> mkisofs with >>> >>> -udf -allow-limited-size -iso-level 3 >>> >>> Sadly, no success there, the files on disk remain unreadable. Am I doing >>> anything wrong here or is it actually a bug? >>> >> >> Not knowing about genisoimage with large files >> and especially not about -allow-limited-size, >> i have to stress that in the past at least Linux >> was not able to read files >= 4 GiB in ISO images >> properly. >> (Such files have to be split into several >> pieces, called "extents", and the reading system >> has to put them together.) >> >> Recent Linux kernels are said to work better. >> Mine is of summer 2007 and cannot read some bytes >> from the end of multi-extent files in images >> created by libisofs. But users of recent Ubuntu >> report that there are no problems any more. >> >> >> man genisoimage says: >> >> -allow-limited-size >> ... >> The result is an inconsistent filesystem and users need >> to make sure that they really use UDF rather than ISO9660 driver >> to read a such disk. >> >> This sounds slightly frightening. >> Maybe you should try without. >> >> If you are using Linux for reading: >> Did you enforce mounting of UDF by mount -t udf ? >> >> >> Have a nice day :) >> >> Thomas >> >> >> > > Actually it appears you guys are right. I just did some testing using > a 10GiB file and I ran into no issues at all. The issue I reported was > with a squashfs on an iso actually, so I tested 10GiB squashfs on iso > and that was just fine as well. This magic might be explained by > kernel 2.6.31 which came with some fixes that might concern this bug I > experienced. I think for now we can consider this closed, sorry for > the "false alarm". > > If I'm to run into this again, I'll revive this thread. > > -- Sven-Hendrik > ------------------------------------------------------------------------ > > _______________________________________________ > Debburn-devel mailing list > Debburn-devel at lists.alioth.debian.org > http://lists.alioth.debian.org/mailman/listinfo/debburn-devel I'd like to revive this issue because I have now found the real cause. The problem is that genisoimage isn't able to generate a true iso-level-3 image. It simply refuses to run when using a file that would fill a DVD by itself (say, 4.3 GiB) and offers using udf instead. This is wrong behavior since iso-level-3 can handle much larger files than udf. I checked this against mkisofs from cdrtools and sure enough, that one produces proper iso-level-3 images using large files. Can you guys fix this in cdrkit? -- Sven-Hendrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marcio.Teixeira at numerica.us Fri Nov 20 23:26:12 2009 From: Marcio.Teixeira at numerica.us (Marcio Teixeira) Date: Fri, 20 Nov 2009 16:26:12 -0700 Subject: [Debburn-devel] Bug report: Incompatibility with HL-DT-SH DVD+RW GH50N Message-ID: Hi, My company has recently purchased five brand new Dell Vostro 420 computers for running Linux and in testing out these new machines I've identified what I think is an incompatibility with wodim and the drives used by Dell (an HL-DT-SH DVD+RW GH50N). While our solution going forward will likely be to swap out these drives with others, I thought I would e-mail this list to see if there is any information I can provide that will help the wodim developers address this issue. Originally the problem was identified in Fedora 10, which uses wodim 1.1.8, but I have thus verified the problem persists in Fedora 12, which has wodim 1.1.9. In either case, swapping out the drive with another resolves the issue. I've also upgraded the firmware on the drive to the latest available from Dell and the problem persists. I'm not sure what kind of diagnostic output will be useful to help identify this problem, but attached is the output of wodim (I am showing a dummy run, real runs look much the same, but I've already got enough coasters for several rounds of beer). -- Marcio ----- [root at localhost scripts]# wodim -v -dummy dev=/dev/dvd speed=2 /tmp/cdimage.raw wodim: No write mode specified. wodim: Asuming -tao mode. wodim: Future versions of wodim may have different drive dependent defaults. TOC Type: 1 = CD-ROM scsidev: '/dev/dvd' devname: '/dev/dvd' scsibus: -2 target: -2 lun: -2 Linux sg driver version: 3.5.27 Wodim version: 1.1.9 SCSI buffer size: 64512 Device type : Removable CD-ROM Version : 5 Response Format: 2 Capabilities : Vendor_info : 'HL-DT-ST' Identification : 'DVD+-RW GH50N ' Revision : 'B102' Device seems to be: Generic CD-ROM. Current: 0x0009 (CD-R) Profile: 0x0012 (DVD-RAM) Profile: 0x0011 (DVD-R sequential recording) Profile: 0x0015 (DVD-R/DL sequential recording) Profile: 0x0016 (DVD-R/DL layer jump recording) Profile: 0x0014 (DVD-RW sequential recording) Profile: 0x0013 (DVD-RW restricted overwrite) Profile: 0x001A (DVD+RW) Profile: 0x001B (DVD+R) Profile: 0x002B (DVD+R/DL) Profile: 0x0010 (DVD-ROM) Profile: 0x0009 (CD-R) (current) Profile: 0x000A (CD-RW) Profile: 0x0008 (CD-ROM) Profile: 0x0002 (Removable disk) Using generic SCSI-3/mmc CD-R/CD-RW driver (mmc_cdr). Driver flags : MMC-3 SWABAUDIO BURNFREE Supported modes: TAO PACKET SAO SAO/R96P SAO/R96R RAW/R96R Drive buf size : 1053696 = 1029 KB Beginning DMA speed test. Set CDR_NODMATEST environment variable if device communication breaks or freezes immediately after that. Drive DMA Speed: 15696 kB/s 89x CD 11x DVD FIFO size : 4194304 = 4096 KB Track 01: data 16 MB Total size: 18 MB (01:51.45) = 8359 sectors Lout start: 19 MB (01:53/34) = 8359 sectors Current Secsize: 2048 ATIP info from disk: Indicated writing power: 5 Is not unrestricted Is not erasable Disk sub type: Medium Type A, high Beta category (A+) (3) ATIP start of lead in: -11634 (97:26/66) ATIP start of lead out: 359846 (79:59/71) Disk type: Short strategy type (Phthalocyanine or similar) Manuf. index: 3 Manufacturer: CMC Magnetics Corporation Blocks total: 359846 Blocks current: 359846 Blocks remaining: 351487 Speed set to 706 KB/s Starting to write CD/DVD at speed 4.0 in dummy TAO mode for single session. Last chance to quit, starting dummy write in 0 seconds. Operation starts. Waiting for reader process to fill input buffer ... input buffer ready. Starting new track at sector: 0 Track 01: 0 of 16 MB written.Errno: 5 (Input/output error), write_g1 scsi sendcmd: no error CDB: 2A 00 00 00 01 D1 00 00 1F 00 status: 0x2 (CHECK CONDITION) Sense Bytes: 70 00 05 00 00 00 00 0A 2A 30 02 80 21 02 00 00 Sense Key: 0x5 Illegal Request, Segment 0 Sense Code: 0x21 Qual 0x02 (invalid address for write) Fru 0x0 Sense flags: Blk 0 (not valid) cmd finished after 0.004s timeout 40s write track data: error after 952320 bytes wodim: The current problem looks like a buffer underrun. wodim: It looks like 'driveropts=burnfree' does not work for this drive. wodim: Please report. wodim: Make sure that you are root, enable DMA and check your HW/OS set up. Writing time: 13.669s Average write speed 8.2x. Fixating... WARNING: Some drives don't like fixation in dummy mode. Fixating time: 63.241s wodim: fifo had 79 puts and 16 gets. wodim: fifo was 0 times empty and 5 times full, min fill was 92%. [root at localhost scripts]# [root at localhost scripts]# wodim -version Cdrecord-yelling-line-to-tell-frontends-to-use-it-like-version 2.01.01a03-dvd Wodim 1.1.9 Copyright (C) 2006 Cdrkit suite contributors Based on works from Joerg Schilling, Copyright (C) 1995-2006, J. Schilling From kraai at ftbfs.org Sun Nov 15 17:11:06 2009 From: kraai at ftbfs.org (Matt Kraai) Date: Sun, 15 Nov 2009 17:11:06 -0000 Subject: [Debburn-devel] wordendc used in wodim/cue.c before it's declared Message-ID: <20091115165648.GE2728@ftbfs.org> Hi, In the latest version of wodim/cue.c, wordendc is used before it's defined, which causes the file to fail to compile. The attached patch fixes this problem by reverting to the old code (which used getdelim to return the wordendc) and renaming getdelim. -- Matt http://ftbfs.org/kraai -------------- next part -------------- Index: wodim/cue.c =================================================================== --- wodim/cue.c (revision 837) +++ wodim/cue.c (working copy) @@ -253,6 +253,7 @@ static char *peekword(void); static char *lineend(void); static char *markword(char *delim); +static char getwordendc(void); static char *getnextitem(char *delim); static char *neednextitem(char *delim); static char *nextword(void); @@ -745,7 +746,7 @@ if (kp == NULL) cueabort("Unknown filetype '%s'", word); - if (wordendc == '/') { + if (getwordendc() == '/') { word = needitem(); if (*astol(++word, &secsize) != '\0') cueabort("Not a number '%s'", word); @@ -1126,6 +1127,12 @@ return (linep); } +static char +getwordendc() +{ + return (wordendc); +} + static char * getnextitem(char *delim) {