Re: mkisofs
Debian User wrote: > What if you don't know the size, say, you are trying to burn someone's > cd to have a copy for yourself. > Peter Horton wrote: > try dd if=. count=`isosize' isosize is in the xcdroast and the cdwrite package. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Potato and Woody CD builds
On Sun, 31 Dec 2000, Philip Charles wrote: [...] > I took a good look at the CD trees. > > Potato binary. No change as there is nothing in pool yet. > Potato source. The source that lives in pool ends up in ../main/source/ > on the CDs. The files are listed in Sources.gz on the CD. Okay, I don't expect problems there since there'll always be potato->pool symlinks. > Woody binary. Packages in potato and pool end up on the CDs each with > their own files system ie ../potato/ and ../pool/ > However, these packages are _not_ included in Packages on > the CDs. Neither are they included in ?.Packages used in > the CD build, but they are found in ?.packages. > Woody source. The source that lives in pool ends up in ../main/source/ > on the CDs and is included in Sources.gz. However, the > source that lives in potato has its own potato file system > and is _not_ included in Sources.gz. Neither are they > found in ?.sources or ?.sources.main used in the CD build. > But, files in pool are included in these lists. > > IMHO the major problem is the building of the Packages and Sources files > for the CDs. This is only a temporary problem; once the new apt-cdrom supports it we can just copy the entire (gpg-signed) main archive's Packages(.gz) to the CD. Until that time it would be easiest to generate just one big Packages file per CD, executing "dpkg-scanpackages . [override] . > Packages" in the CD's root directory. This will pick up every .deb on the CD and AFAICS current apt-cdrom should handle this nicely. (You shouldn't even have to delete the other Packages already present.) > A successful new Millennium to everyone. Thanks! Best wishes to all, Anne Bezemer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Potato and Woody CD builds
On Tue, 2 Jan 2001, jason andrade wrote: > guys, how many CD images are we talking about for woody and sid ? > > i don't bother counting US/NonUS as separate cd images because > i only mirror/create the non us cd1.. it was 3 per arch plus > 3 for source for potato.. > > is it correct from the last few mails to assume woody has 5 cds > and sid has 6 ? (yow!) per architecture ? Woody 4 for binary, sid 5 (nearly 6). And this is with woody==testing, so I guess by release time woody will have grown to 6 CDs too. Source appears to be just a little bigger than binary, so if we get a 7th source CD it'll only contain some 100MB. Regards, Anne Bezemer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: regarding potato images
On Wed, 3 Jan 2001, Jim Westveer wrote: > On 02-Jan-2001 Adam Di Carlo wrote: > > Jim Westveer <[EMAIL PROTECTED]> writes: > > > >> On 01-Jan-2001 Adam Di Carlo wrote: > >> > Um, I thought it went like this for i386: > >> > > >> > CD#1: vanilla kernel > >> > CD#2: compact > >> > CD#3: idepci > > > > Yes, I agree. > > > The debian-cd now in CVS will put boot blocks on > ALL i386 disks in the following fashion. > > CD#1: default kernel from boot-disks(i386) > CD#2: compact > CD#3: idepc > CD#n: default kernel from boot-disks(i386) Okay. Boot team: be sure to post a note to -cd as soon as you think of other interesting flavours ;-) Regards, Anne Bezemer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs
On Sat, 6 Jan 2001, Tibor D. wrote: > Debian User wrote: > > > What if you don't know the size, say, you are trying to burn someone's > > cd to have a copy for yourself. > > Peter Horton wrote: > > > try dd if=. count=`isosize' > isosize is in the xcdroast and the cdwrite package. dd if=/dev/cdrom of=whereever bs=2k count=$(expr $(isosize /dev/cdrom) / 2048) [$( ) == ` ` but nestable] Regards, Anne Bezemer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs
On Sat, 6 Jan 2001, Robert Waldner wrote: > >> The ISO image read of the CD is probably a sector or two > >> too long. If you know the correct size then you can just do > > I would think that the image created with dd is a few bytes (less than > a sector) too small, because dd reads until it runs out of useful data, > but the cd consists of 2k-sectors, the last one is padded with zeroes > until it´s full. At least that´s what the "-pad"-option in cdrecord is > for... Not entirely. -pad for _audio_ tracks adds 0's to get a full last 2352-byte block (which is required by standards). -pad for _data_ tracks always adds 30kB of 0's to make it compatible with buggy early 2.0 (IIRC) Linuxes and some other *UXes. Data tracks are always 2048-multiples, and if not then that's a serious bug in mkisofs (or equiv). Regards, Anne Bezemer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rsync problems with 2.2_rev2 binary-m68k-1.iso
On 4 Jan 2001, Goswin Brederlow wrote: > > " " == Ian Smith <[EMAIL PROTECTED]> writes: > > > 0100,0100,0100I'm attempting to create an > > Is that supposed to be html mail? > > > .iso file from a pseudo-image that I downloaded from > > ftp.us.debian.org. I keep on getting bad checksums. I've > > tried rsync with multiple servers using the command in the > > pseudo-image kit: > > > > rsync --verbose --progress --stats --block-size=8192 > > rsync.kernel.org::pub/mirrors/Times New > > Romandebian-cd/2.2_rev2/m68k/binary- m68k-1.iso > > . > > This html stuff will certainly break everything. Appart from that you > should use --partial so that a timeout won't kill your file and -c to > allways checksum. Using --partial WILL kill your valuable pseudo-image if rsync fails after 1 byte has been transferred. So either back up your pseudo-image or do NOT use --partial. The -c doesn't have any effect in this case (it is intended to be used with --times only). Regards, Anne Bezemer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rsync problems with 2.2_rev2 binary-m68k-1.iso
On Thu, 4 Jan 2001, Ian Smith wrote: > 0100,0100,0100I'm attempting to create an .iso file from a >pseudo-image that I > downloaded from ftp.us.debian.org. I keep on getting bad > checksums. There is a strange bug in rsync that sometimes causes it to fail with a "file changed during transfer?" error. But if the md5sum matches, the .iso is okay. See at the bottom of http://cdimage.debian.org/~costar/pseudo-image-kit/ for more info. > I've tried rsync with multiple servers using the > command in the pseudo-image kit: > > > rsync --verbose --progress --stats --block-size=8192 > rsync.kernel.org::pub/mirrors/Times New >Romandebian-cd/2.2_rev2/m68k/binary- > m68k-1.iso . > > > I connect to the server, then, after waiting approx. 10 minutes I > get a new H:\ prompt. No progress bar, no status report. What > am I doing wrong here? Try another server. And don't forget the last `.' on the line. If you get problems with multiple rsync mirrors, please report back. Regards, Anne Bezemer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Potato and Woody CD builds
On Sat, 6 Jan 2001, J.A. Bezemer wrote: > Woody 4 for binary, sid 5 (nearly 6). And this is with woody==testing, so I > guess by release time woody will have grown to 6 CDs too. > > Source appears to be just a little bigger than binary, so if we get a 7th > source CD it'll only contain some 100MB. yow.. i was hoping to start making woody/testing ISO images available for download but perhaps now i can only do that for i386 (6*650 == 4G.. blah). that's starting to become a scary amount of disk space for debian-cd mirrors. i still carry slink images.. i hope the cost of fibrechannel disk drops dramatically in the near future given the cost of archives increase :-( regards, -jason -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Potato and Woody CD builds
What if we do something like this: dpkg-scanpackages . > Packages dpkg-scanpackages .. >> Packages in order to get the stuff from different areas of pool and dists into a Packages file? We won't have the standard sort order but at least it allows the Packages file in dists/sid/main to reference stuff found in dists/potato/main and pool/main on the same CD. It's a bit of a hack but it might do for now. If I am correct in my thinking, it appears that debian-cd is placing the needed deb files on the CD so the immediate problem is to build proper Packages.* files. So I guess the approach for now is to do this before making md5sums and images. I am willing to try it out. Does anyone see a reason it won't work? BTW - My idea is to replace the Packages, Packages.cd and Packages.cd files since they do not currently reference all the deb files installed on the cd rather than create a single large one. On Sat, 6 Jan 2001, J.A. Bezemer wrote: > Date: Sat, 6 Jan 2001 15:35:47 +0100 (CET) > From: "J.A. Bezemer" <[EMAIL PROTECTED]> > To: Philip Charles <[EMAIL PROTECTED]> > Cc: debian-CD list <[EMAIL PROTECTED]> > Subject: Re: Potato and Woody CD builds > Resent-Date: Sat, 6 Jan 2001 09:36:07 -0500 > Resent-From: [EMAIL PROTECTED] > > > On Sun, 31 Dec 2000, Philip Charles wrote: > [...] > > I took a good look at the CD trees. > > > > Potato binary. No change as there is nothing in pool yet. > > Potato source. The source that lives in pool ends up in ../main/source/ > > on the CDs. The files are listed in Sources.gz on the CD. > > Okay, I don't expect problems there since there'll always be potato->pool > symlinks. > > > Woody binary. Packages in potato and pool end up on the CDs each with > > their own files system ie ../potato/ and ../pool/ > > However, these packages are _not_ included in Packages on > > the CDs. Neither are they included in ?.Packages used in > > the CD build, but they are found in ?.packages. > > Woody source. The source that lives in pool ends up in ../main/source/ > > on the CDs and is included in Sources.gz. However, the > > source that lives in potato has its own potato file system > > and is _not_ included in Sources.gz. Neither are they > > found in ?.sources or ?.sources.main used in the CD build. > > But, files in pool are included in these lists. > > > > IMHO the major problem is the building of the Packages and Sources files > > for the CDs. > > This is only a temporary problem; once the new apt-cdrom supports it we can > just copy the entire (gpg-signed) main archive's Packages(.gz) to the CD. > > Until that time it would be easiest to generate just one big Packages file per > CD, executing "dpkg-scanpackages . [override] . > Packages" in the CD's root > directory. This will pick up every .deb on the CD and AFAICS current apt-cdrom > should handle this nicely. (You shouldn't even have to delete the other > Packages already present.) > > > A successful new Millennium to everyone. > > Thanks! > > Best wishes to all, > > Anne Bezemer > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > +--+ + Paul Wade Greenbush Technologies Corporation + + mailto:[EMAIL PROTECTED] http://www.greenbush.com/ + +--+ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rsync problems with 2.2_rev2 binary-m68k-1.iso
> " " == J A Bezemer <[EMAIL PROTECTED]> writes: > On 4 Jan 2001, Goswin Brederlow wrote: >> > " " == Ian Smith <[EMAIL PROTECTED]> writes: >> >> > 0100,0100,0100I'm attempting to create >> an >> >> Is that supposed to be html mail? >> >> > .iso file from a pseudo-image that I downloaded from > >> ftp.us.debian.org. I keep on getting bad checksums. I've > >> tried rsync with multiple servers using the command in the > >> pseudo-image kit: >> >> >> > rsync --verbose --progress --stats --block-size=8192 > >> rsync.kernel.org::pub/mirrors/Times New > >> Romandebian-cd/2.2_rev2/m68k/binary- m68k-1.iso >> > . >> >> This html stuff will certainly break everything. Appart from >> that you should use --partial so that a timeout won't kill your >> file and -c to allways checksum. > Using --partial WILL kill your valuable pseudo-image if rsync > fails after 1 byte has been transferred. So either back up your > pseudo-image or do NOT use --partial. It will? I thought that option will keep the partial download. Why does it not merge the old file with the downloaded changes and keep that? MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Still busy...
On Fri, 5 Jan 2001, Richard Atterer wrote: > Hi all, > > Just in case you're wondering what has become of me and my plans of a > new CD download tool: I've been programming for the last two weeks, > working on the first step; a tool that is given the CD image and a > list of filenames and finds out which of the files are contained at > which offsets in the image. It also writes out a "template" file with > instructions on how to recreate the image. > > I've made some progress already (~80% done with that first tool), but > unfortunately the rest of my life will demand more of my time again > starting with next week, so I'm not sure how much longer it'll take > me. But watch this space! Thanks for the update! One idea that might be useful: You probably cut each file in X-byte blocks and compare checksums. Since we're talking about terribly much files that we don't want to checksum more than once, it may prove worthwile to scan all files at once and save the results in a temporary file (checksum <-> filename/offset; sorted?) and use that to compare against. Oh, and you probably already know that files in an iso image 1) can only start at 2048-byte multiples and 2) are always contiguous (no fragmentation). Regards, Anne Bezemer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Potato and Woody CD builds
On Sun, 7 Jan 2001, jason andrade wrote: > On Sat, 6 Jan 2001, J.A. Bezemer wrote: > > > Woody 4 for binary, sid 5 (nearly 6). And this is with woody==testing, so I > > guess by release time woody will have grown to 6 CDs too. > > > > Source appears to be just a little bigger than binary, so if we get a 7th > > source CD it'll only contain some 100MB. > > yow.. i was hoping to start making woody/testing ISO images available for download > but perhaps now i can only do that for i386 (6*650 == 4G.. blah). > > that's starting to become a scary amount of disk space for debian-cd mirrors. Once we get the Private CD Cooker working, there won't be very much use for CD image mirrors any more. > i still carry slink images.. If you get _any_ downloads of these, people are most certainly mistaken... Regards, Anne Bezemer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Potato and Woody CD builds
On Sat, 6 Jan 2001 [EMAIL PROTECTED] wrote: > What if we do something like this: > > dpkg-scanpackages . > Packages > dpkg-scanpackages .. >> Packages > > in order to get the stuff from different areas of pool and dists into a > Packages file? Actually, that was my initial thought too. But that requires quite precise knowledge of places to scan. And since we're doing workarounds anyway, one big Packages file is the easiest thing to do, and requires no specific knowledge at all. Both dpkg-scanpackages and apt-cdrom handle this fine. Remember this is only a temporary workaround, so don't bother about it too much. (And preferably don't write complex code that can break at many places ;-) > BTW - My idea is to replace the Packages, Packages.cd and Packages.cd > files since they do not currently reference all the deb files installed on > the cd rather than create a single large one. When apt-cdrom sees a Packages(.gz) in some directory, it won't scan directories below that. So if there is one big Packages in the CD's root, the "too-few" Packages files won't be seen at all (and even if they're seen, apt is smart enough to combine them nicely). And I don't care about the Packages.cd(.gz), people should have converted to apt-cdrom by now. Regards, Anne Bezemer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rsync problems with 2.2_rev2 binary-m68k-1.iso
On 6 Jan 2001, Goswin Brederlow wrote: > > " " == J A Bezemer <[EMAIL PROTECTED]> writes: > > > On 4 Jan 2001, Goswin Brederlow wrote: > > >> > " " == Ian Smith <[EMAIL PROTECTED]> writes: > >> > >> > 0100,0100,0100I'm attempting to create > >> an > >> > >> Is that supposed to be html mail? > >> > >> > .iso file from a pseudo-image that I downloaded from > > >> ftp.us.debian.org. I keep on getting bad checksums. I've > > >> tried rsync with multiple servers using the command in the > > >> pseudo-image kit: > >> > >> > >> > rsync --verbose --progress --stats --block-size=8192 > > >> rsync.kernel.org::pub/mirrors/Times New > > >> Romandebian-cd/2.2_rev2/m68k/binary- m68k-1.iso > >> > . > >> > >> This html stuff will certainly break everything. Appart from > >> that you should use --partial so that a timeout won't kill your > >> file and -c to allways checksum. > > > Using --partial WILL kill your valuable pseudo-image if rsync > > fails after 1 byte has been transferred. So either back up your > > pseudo-image or do NOT use --partial. > > It will? I thought that option will keep the partial download. Yep, but with the "good" file name, which means your original file needs to be deleted. > Why does it not merge the old file with the downloaded changes and > keep that? You should write the rsync people; I think they'll find it an interesting idea. Regards, Anne Bezemer -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs
Well, if you're lucky it'll only be a few sectors too long. Use the length of the image you've got minus 2K. Test and repeat. You might want to look at the image with a hex editor for clues. P. On Fri, Jan 05, 2001 at 07:05:33PM -0500, Debian User wrote: > What if you don't know the size, say, you are trying to burn someone's > cd to have a copy for yourself. > Peter Horton wrote: > > > On Fri, Jan 05, 2001 at 11:49:10AM -0500, Antonio Rodriguez wrote: > > > Hi Steve, hi all. Tried > > > dd if=/dev/scd0 of=d3.iso > > > with my deb official cd 3 (potato rev2). > > > md5sum d3.iso gives not the supposed value. > > > When I do it from xcdroast I get the right md5sum. > > > Where is the problem? Are you sure that there no options left out > > > somewhere? > > > > The ISO image read of the CD is probably a sector or two > > too long. If you know the correct size then you can just do > > > > dd if=/dev/scd0 of=d3.iso bs=2k count= -- P. Horton Software Engineer http://www.colonel-panic.com Linux 2.4.0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: mkisofs
On Sat, Jan 06, 2001 at 09:11:13AM +0100, Robert Waldner wrote: > >> The ISO image read of the CD is probably a sector or two > >> too long. If you know the correct size then you can just do > > I would think that the image created with dd is a few bytes (less than > a sector) too small, because dd reads until it runs out of useful data, > but the cd consists of 2k-sectors, the last one is padded with zeroes > until its full. At least thats what the "-pad"-option in cdrecord is > for... > > So Id try `dd if=dev/scd0 of=bla.iso ibs=2048 obs=2048 sync`, > out of `man dd`: >sync pad every input block with NULs to ibs-size > > Or is there an error in my knowledge? > I thought the kernel read a complete sector or none at all. Doesn't the '-pad' option add 15 *sectors* of zeroes to the end of the image ? P. -- P. Horton Software Engineer http://www.colonel-panic.com Linux 2.4.0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rsync problems with 2.2_rev2 binary-m68k-1.iso
> " " == J A Bezemer <[EMAIL PROTECTED]> writes: >> It will? I thought that option will keep the partial download. > Yep, but with the "good" file name, which means your original > file needs to be deleted. >> Why does it not merge the old file with the downloaded changes >> and keep that? > You should write the rsync people; I think they'll find it an > interesting idea. Well, I'm thinking of writeing that feature along with client side unpacking/repacking of data. But it needs some design tweaks I have to discuss with some friends and the rsync people. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: rsync problems with 2.2_rev2 binary-m68k-1.iso
On 7 Jan 2001, Goswin Brederlow wrote: > Well, I'm thinking of writeing that feature along with client side > unpacking/repacking of data. But it needs some design tweaks I have to > discuss with some friends and the rsync people. i mailed andrew about this some months ago.. hadn't heard anything back though. am hoping to mention it to him again when i (hopefully) see him at linux.conf.au in a couple of weeks. it'd also be good to fix a couple of other bugs i notice with rsync at the moment o daemon process don't die.. i have to daily kill "undead" rsync daemons otherwise it hits the user limit o rsync often times out on large directory scans. e.g i can't directly use rsync to keep a couple of local mirrors synced with the whole debian archive.. it just times out. i have to break it up into a per dist rsync base :-( -jason -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Potato and Woody CD builds
[---8<---8<---8<---] > > i still carry slink images.. > > If you get _any_ downloads of these, people are most certainly mistaken... Well, maybe :/ However the LRP Linux Router Project (www.linux-router.org) is based on slink. At least they are usefull to ppl. who want to compile packages (programs) for LRP, since an LRP dist. is to small to provide a devel. env. I actually want these myself for just this purpose, please keep them up there a little longer, k? :) (w8ing for my 1Mbit leased line). Anyone have a complete CD set of official slink (2.1_r5 correct?) that they'd be willing to part with? I'd also really like to get a hold of m68k (AMIGA) CD's or ISO images of this release. Any pointers? Regards, Per -- Per Gustav Ousdal <[EMAIL PROTECTED]> SirCon DA, Postbox 12, 4440 Tonstad, Norway Tlf: +47 3837 Fax: +47 38371119 http://www.sircon.no -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Potato and Woody CD builds
On Sun, 7 Jan 2001, Per Gustav Ousdal wrote: > [---8<---8<---8<---] > > > > i still carry slink images.. > > > > If you get _any_ downloads of these, people are most certainly mistaken... i don't think so. there are still legacy systems out there. i still have people asking for access to redhat 5.2 (and in some cases 4.2!) distributions because they have a working and in some cases "blackbox" to them system and they don't feel any need to upgrade. > Anyone have a complete CD set of official slink (2.1_r5 correct?) that > they'd be willing to part with? i'd love this too.. i only have 2.1r4 images.. i don't think r5 ever came out on cdimage.debian.org. -jason -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
