Why is the new jigdo test template soo large?
Any clue? http://cdimage.debian.org/pub/cdimage-testing/cd/jigdo-area/i386/jigdotemplates/ -- Rahmat M. Samik-Ibrahim -- vLSM.org -- http://rms46.vLSM.org/ -- Fetch my GNUPG public key at http://rms46.vlsm.org/pgp/pub.txt --- signature.asc Description: This is a digitally signed message part
jigdo CD directory contains DVD images
Hello there, it seems a mistake was made on the primary mirror for CD jigdo files - the files at http://cdimage.debian.org/pub/cdimage-testing/cd/jigdo-area/i386/ are for DVD images. Until this is fixed, you can get the files from our master location at http://gluck.debian.org/cdimage/testing/cd/jigdo-area/i386/ Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
cd -- dvd
Hello, I think that in http://cdimage.debian.org/pub/cdimage-testing/cd/jigdo-area/i386/ isnt CD but DVD version. HAND Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
SUGGESTION: add timestamp directories
Hello: Is it possible to ATLEAST add timestamp directories for cdimage-testing? Eg:http://cdimage.debian.org/pub/cdimage-testing/040607/cd/jigdo-area/i386/ ^^ or wherever it is more appropriate. It would be even better, if you create testing images with time stamp names Eg: sarge-040607-i386-1.iso regards, -- Rahmat M. Samik-Ibrahim -- vLSM.org -- http://rms46.vLSM.org/ -- Fetch my GNUPG public key at http://rms46.vlsm.org/pgp/pub.txt --- signature.asc Description: This is a digitally signed message part
JTE (Jigdo Template Export) v1.0
Guys (especially Richard), I've been looking for a while at ways to make jigdo run faster when generating template files from iso images. (See http://lists.debian.org/debian-cd/2003/12/msg00041.html for my original mail). The core problem is that once we have an ISO image, jigdo essentially has to brute-force that image back into a binary blob (template file) and a list of files needed to rebuild the image (jigdo file). On my home system with a very good disks and a reasonable processor, creating jigdo files for a DVD iso image can take several hours. Multiply that up by 11 architectures... There are a few ways to improve this that I can see: 1. Modify jigdo so it knows about the internals of ISO images and can efficiently scan them (bad, not very generic for jigdo) 2. Write a helper tool to dump extra information for jigdo to use alongside the ISO image (helper tool written, but modifying jigdo to use this looks HARD) 3. Patch mkisofs to write .jigdo and .template files alongside the ISO image I've now done #3, and the patch for mkisofs is at http://www.einval.com/~steve/software/CD/mkisofs-JTE.patch.gz In the same directory I have a tool to dump the contents of (and rebuild images from) .jte files and another one to dump the contents of .template files. How to use it: == To use this code, specify the location of the output .jigdo, .template and .jte files alongside the ISO image. The .jte file is an intermediate helper file that I'll probably lose for the next release. You can also specify the minimum size beneath which files will just be dropped into the binary template file data rather than listed as separate files to be found on the mirror. For example: mkisofs -J -r -o /home/steve/test1.iso \ -jigdo-helper /home/steve/test1.jte \ -jigdo-jigdo /home/steve/test1.jigdo \ -jigdo-template /home/steve/test1.template \ -jigdo-min-file-size 16384 \ /mirror/jigdo-test If the -jigdo-* options are not used, the normal mkisofs execution path is not affected. The above invocation will create 4 output files. I've tested extensively with various input data and I can recreate ISO images using jigdo-file and the wrapper jigdo-mirror. How it works: = I've hooked all the places in mkisofs where it will normally write image data. All the normal data write calls (dir entries etc.) I simply pass through and build into the template file. Any *file* data entries are passed through with information about the original file. If that file is large enough, I grab the filename and the MD5 of the file's data so I can just write a file match record into the template file (and then the jigdo file). How fast is it? === On my *laptop* (600MHz P3, slow laptop disk) I can make a template file in parallel with the ISO image from a typical 500MB data set in about 2 minutes. By simply not creating the ISO (-o /dev/null), this time halves again. The data set I'm using here is a copy of the woody i386 r2 update CD, as it's a handy image I had lying around. What's left to do? == 1. Testing! :-) This is where you lot come in! Please play with this some more and let me know if you have any problems, especially with data corruption. More features: 2. Add support for -jigdo-exclude option(s), so that we can exclude (from the jigdo) README.* etc and other files that go on Debian CDs but often change on the mirrors. Reasonably easy to do, and I'm playing with this now. 3. Add pattern-matching in the .jigdo file (e.g. /mirror/debian - Debian:). Again, should be easy. 4. Cosmetic cleanup of the .jigdo output. Easy 5. MUCH harder: re-reading and re-encoding .iso images that have been modified since they were first written. This is necessary for the boot code used on several architectures in debian-cd. I see how to do it - basically diff the image on disk to the one we would recreate from the .template file and write a new template file to match that. It's going to take some work... I hope people find this useful - at the moment I shudder at the thought of releasing sarge (10+ CDs, netinst, business card, 2 DVDs per arch) without making this kind of change. It'll take a week to generate the release images otherwise... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] It's actually quite entertaining to watch ag129 prop his foot up on the desk so he can get a better aim. [ seen in ucam.chat ] signature.asc Description: Digital signature
Re: Bug#253033: installation-reports
Peter Yellman wrote: http://cdimage.debian.org/pub/cdimage-testing/cd/jigdo-area/i386/sarge-i386-1.jigdo Multiple attempts -- at least 5. Tried linux, expert, linux26, expert26. Never offered the opportunity to configure network. Tried with 2 different NICs - a common Macronix, and an Intel e100. Installer seemed to see NIC -- module was loaded in alt console, but never started network configuration. This is a known problem with the full CDs, depsite numerous requests to the debian-cd guys to fix this, they do not include the netcfg udeb necessary to get the network configured. They also don't include a usable set of packages to get X working, or some hardware working post-install, so I cannot recommend you use them if you want a working system -- use the netinst CDs. Selecting network module in expert mode resulted in message to the effect requested module not available. Please don't paraphrase error messages. What exactly did you select from the menu, and what was the exact error message you received? -- see shy jo signature.asc Description: Digital signature
Re: Bug#253033: installation-reports
On Mon, Jun 07, 2004 at 09:15:20AM -0400, Joey Hess wrote: Peter Yellman wrote: http://cdimage.debian.org/pub/cdimage-testing/cd/jigdo-area/i386/sarge-i386-1.jigdo Multiple attempts -- at least 5. Tried linux, expert, linux26, expert26. Never offered the opportunity to configure network. Tried with 2 different NICs - a common Macronix, and an Intel e100. Installer seemed to see NIC -- module was loaded in alt console, but never started network configuration. This is a known problem with the full CDs, depsite numerous requests to the debian-cd guys to fix this, they do not include the netcfg udeb necessary to get the network configured. They also don't include a usable set of packages to get X working, or some hardware working post-install, so I cannot recommend you use them if you want a working system -- use the netinst CDs. I must have blinked and missed these. If you can give me a list of which files are needed, or a pointer as to how to work it out I'll get onto this later today for you. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Support the Campaign for Audiovisual Free Expression: http://www.eff.org/cafe/ signature.asc Description: Digital signature
Excluding udebs from powerpc businesscard/netinst
We could do with cutting down the size of the powerpc CDs a bit. Here's a first stab at an exclude-udebs-powerpc, which may help. Please apply it only for sid; it can be ported back to sarge after rc1 is out and we've verified that everything still works. It sucks that (a) we have to duplicate this information and (b) there's no easy way to find out what packages went into a d-i CD image short of messing around in build logs. Perhaps we could ship some kind of an initrd manifest with each initrd, which would be useful to end users (think trying to work out if a new enough version of some package is included in your image), d-i developers, and debian-cd? # These udebs build the d-i cdrom initrd. As such, there is no reason # to keep another copy of them on the CD in udeb form. # # This duplicates data found in the file build/pkg-lists/cdrom/powerpc, # in d-i Subversion. cdrom-core-modules-* console-keymaps-at console-keymaps-usb discover-data-udeb discover-udeb discover1-data-udeb discover1-udeb eject-udeb firewire-core-modules-* fs-common-modules-* ide-modules-* input-modules-* kbd-chooser pcmcia-cs-udeb pcmcia-modules-* pcmcia-storage-modules-* scsi-common-modules-* scsi-core-modules-* scsi-modules-* socket-modules-* usb-modules-* usb-storage-modules-* # Not needed with the 2.4 kernel on powerpc. userdevfs Thanks, -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#253033: installation-reports
Steve McIntyre wrote: I must have blinked and missed these. If you can give me a list of which files are needed, or a pointer as to how to work it out I'll get onto this later today for you. See http://lists.debian.org/debian-cd/2004/05/msg00036.html -- see shy jo signature.asc Description: Digital signature
Re: Excluding udebs from powerpc businesscard/netinst
On Mon, Jun 07, 2004 at 03:26:24PM +0100, Colin Watson wrote: We could do with cutting down the size of the powerpc CDs a bit. Here's a first stab at an exclude-udebs-powerpc, which may help. For what it's worth, some quick calculations suggest that this will save about 11MB from powerpc businesscard and netinst images, which is a not inconsiderable win. -- Colin Watson [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: JTE (Jigdo Template Export) v1.0
On Mon, Jun 07, 2004 at 02:02:24PM +0100, Steve McIntyre wrote: 1. Modify jigdo so it knows about the internals of ISO images and can efficiently scan them (bad, not very generic for jigdo) 2. Write a helper tool to dump extra information for jigdo to use alongside the ISO image (helper tool written, but modifying jigdo to use this looks HARD) 3. Patch mkisofs to write .jigdo and .template files alongside the ISO image I've now done #3, and the patch for mkisofs is at That's really cool!!! Many thanks for doing this! Something like #2 was my favourite: Write a special .iso image, but omit the file data from it, just embed information about the names of files which were omitted. Later, tell jigdo-file to process the results and write out proper .jigdo/.template files. I guess it's my fault for not offering to add support to jigdo-file for this, sorry Steve. IMHO, it would have prevented some code from being duplicated in jte and jigdo-file, permitted the use of jigdo-file's cache for checksums (= even faster!), and resulted in a smaller patch to mkisofs which has better chances of being accepted by mkisofs upstream. And (unsurprisingly) it doesn't look /that/ hard to me. ;) To use this code, specify the location of the output .jigdo, .template and .jte files alongside the ISO image. The .jte file is an intermediate helper file that I'll probably lose for the next release. What does the .jte file contain now, and why is it needed? How fast is it? === On my *laptop* (600MHz P3, slow laptop disk) I can make a template file in parallel with the ISO image from a typical 500MB data set in about 2 minutes. By simply not creating the ISO (-o /dev/null), this time halves again. The data set I'm using here is a copy of the woody i386 r2 update CD, as it's a handy image I had lying around. Yum. :) More features: 2. Add support for -jigdo-exclude option(s), so that we can exclude (from the jigdo) README.* etc and other files that go on Debian CDs but often change on the mirrors. Reasonably easy to do, and I'm playing with this now. 3. Add pattern-matching in the .jigdo file (e.g. /mirror/debian - Debian:). Again, should be easy. We'd get both 2. and 3. for free with the post-processing by jigdo-file approach, hmm... 5. MUCH harder: re-reading and re-encoding .iso images that have been modified since they were first written. This is necessary for the boot code used on several architectures in debian-cd. I see how to do it - basically diff the image on disk to the one we would recreate from the .template file and write a new template file to match that. It's going to take some work... But scanning the changed image would also need a lot of time... I think a different approach looks more promising: Write a special dd-jigdo program which behaves and works like the original dd in every respect, except that it works directly on the .template. A simple version of such a program could get away without modifying the .jigdo file, and the .template format does not make it necessary to recompress all the data in the template - just a part of it needs to be recompressed. Alternatively: While you're busy hacking on mkisofs, why not add the functionality there? The use of dd by debian-cd only illustrates that mkisofs lacks a feature here! I think dd is the only tool used by debian-cd, to write a boot sector for some arches - or is there something else? Cheers, Richard -- __ _ |_) /| Richard Atterer | GnuPG key: | \/¯| http://atterer.net | 0x888354F7 ¯ '` ¯ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: JTE (Jigdo Template Export) v1.0
On Mon, Jun 07, 2004 at 05:00:04PM +0200, Richard Atterer wrote: On Mon, Jun 07, 2004 at 02:02:24PM +0100, Steve McIntyre wrote: 1. Modify jigdo so it knows about the internals of ISO images and can efficiently scan them (bad, not very generic for jigdo) 2. Write a helper tool to dump extra information for jigdo to use alongside the ISO image (helper tool written, but modifying jigdo to use this looks HARD) 3. Patch mkisofs to write .jigdo and .template files alongside the ISO image I've now done #3, and the patch for mkisofs is at That's really cool!!! Many thanks for doing this! Something like #2 was my favourite: Write a special .iso image, but omit the file data from it, just embed information about the names of files which were omitted. Later, tell jigdo-file to process the results and write out proper .jigdo/.template files. Yup, that's what I was planning to do. But (as I said a while ago) I don't grok C++ at all and mktemplate.cc is _scary_, especially the hand-unrolled loop in the middle of scanImage(). I guess it's my fault for not offering to add support to jigdo-file for this, sorry Steve. IMHO, it would have prevented some code from being duplicated in jte and jigdo-file, permitted the use of jigdo-file's cache for checksums (= even faster!), and resulted in a smaller patch to mkisofs which has better chances of being accepted by mkisofs upstream. And (unsurprisingly) it doesn't look /that/ hard to me. ;) :-) To be honest, the code I have is fairly small and self-contained, and might even be easier to port if necessary - it's all written in ANSI C. Also, on the caching front - this new code shouldn't slow things down too much anyway, as we're already reading all the file data through mkisofs. Most modern machines will MD5 data blocks faster than they can read them. It's also not a bad idea to have two different implementations of some of this code now - it makes it more accessible for other people to hack on it. It might also have shown up any bugs where your code didn't match the spec. To use this code, specify the location of the output .jigdo, .template and .jte files alongside the ISO image. The .jte file is an intermediate helper file that I'll probably lose for the next release. What does the .jte file contain now, and why is it needed? The .jte file _is_ the output for #2 above, as I wrote a while ago. I was hacking on it further, then decided to move more intelligence into the mkisofs patch itself. It's essentially my own simple version of a .template file. More features: 2. Add support for -jigdo-exclude option(s), so that we can exclude (from the jigdo) README.* etc and other files that go on Debian CDs but often change on the mirrors. Reasonably easy to do, and I'm playing with this now. 3. Add pattern-matching in the .jigdo file (e.g. /mirror/debian - Debian:). Again, should be easy. We'd get both 2. and 3. for free with the post-processing by jigdo-file approach, hmm... They won't be hard, and I'm on a roll now. These will be written tonight... :-) 5. MUCH harder: re-reading and re-encoding .iso images that have been modified since they were first written. This is necessary for the boot code used on several architectures in debian-cd. I see how to do it - basically diff the image on disk to the one we would recreate from the .template file and write a new template file to match that. It's going to take some work... But scanning the changed image would also need a lot of time... I think a different approach looks more promising: Write a special dd-jigdo program which behaves and works like the original dd in every respect, except that it works directly on the .template. A simple version of such a program could get away without modifying the .jigdo file, and the .template format does not make it necessary to recompress all the data in the template - just a part of it needs to be recompressed. Absolutely - I'm hoping to just be able to modify a small chunk of the compressed template data, and of course then we don't need to touch the contents of the .jigdo. But we _will_ have to update the template MD5, of course. Alternatively: While you're busy hacking on mkisofs, why not add the functionality there? The use of dd by debian-cd only illustrates that mkisofs lacks a feature here! I think dd is the only tool used by debian-cd, to write a boot sector for some arches - or is there something else? It varies by platform, I'm afraid. Several arches have a post-iso process to bless / make a CD bootable. Alpha uses isomarkboot, for example. I'd expect most of the changes to be contained at the beginning of the image, but we can't guarantee that. Depending on how intelligent the BIOS / firmware is on the arch in question, we may have to scan most of the image to make sure we don't miss anything. :-( I think maybe it's time to check out what these boot progs do, and see if we can do it directly
Re: cd -- dvd
I think that in http://cdimage.debian.org/pub/cdimage-testing/cd/jigdo-area/i386/ isnt CD but DVD version. This was a mistake I made (cut and paste is not good if you don't change what needs to be changed) but it was autofixed this morning as the weekly build finished. Regards... -- Manty/BestiaTester - http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Why is the new jigdo test template soo large?
Any clue? Maybe you got the dvd template that a bug I made put instead of the cd one. If it was that, it should be solved now, if it isn't please tell us. Regards... -- Manty/BestiaTester - http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: jigdo CD directory contains DVD images
it seems a mistake was made on the primary mirror for CD jigdo files - the Yes, my fault, should be solved now! Regards... -- Manty/BestiaTester - http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: jogdo-files fr die Testing-Distribution auf CD
Ich habe heute versucht, die CD-images für die Testing-Version von Debian herunterzuladen. Dabei gab jigdo-lite für Windows mir den Fehler, daß unter Windows keine Image, die größer ist als 2 GB gemacht werden kann. No german here, but I'd say... it was my fault, and it is solved now, if not, please try to explain in english what the problem is :-) Regards -- Manty/BestiaTester - http://manty.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: We received your mail
ALL I WANT IS TO GET BACK ON TO MY CROSSWORDS BY MY MEMBER ID WHICH I FORGOT. PLEASE GIVE ME MY PASS WORD AND MY MEMBER ID. THANK YOU. I HAVE BEEN TRYING TO GET THIS ID FOR FOR 3 DAYS. IT IS FRUSTRATING. AND I WANT MY PUZZLE. WRITE BACK ASAP PLEASE.
USB memory stick
Debian team, I am having a slight problem with the live debian cd, because my computer does not have a cd drive. Would it be possible to write the cd images to a usb memory stick and let it work? Your help would be very much apreciated. yours sincerely, Maarten Weijman
new cd covers
to whom it may concern, i have produced some cd covers and would like to share them with the rest of the community. the tarball can be viewed at http://www.deviantart.com/view/7903891/ or a direct download at http://files.deviantart.com/f/2004/159/0/d/Debian_3_0_r2_CD_Pack.tar thank you for your time Joe Wiles --- auto signature generator --- SEMPER UBI SUB UBI [ Always wear underwater ] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#253033: installation-reports
On Mon, Jun 07, 2004 at 10:29:31AM -0400, Joey Hess wrote: Steve McIntyre wrote: I must have blinked and missed these. If you can give me a list of which files are needed, or a pointer as to how to work it out I'll get onto this later today for you. See http://lists.debian.org/debian-cd/2004/05/msg00036.html When was the last time you checked? Looking at the jigdo file for the latest sarge image #1: sledge:/mirror/sarge-cd/jigdo$ zgrep netcfg *jigdo sarge-i386-1.jigdo:GfQ50NysZ7YJVUyG9VK-Uw=Debian:pool/main/n/netcfg/netcfg_0.63_i386.udeb netcfg seems to be there. And also discover bits: DKW499kv8oF0e_2gCgz_GA=Debian:pool/main/d/discover-data/discover-data_2.2004.05.03-3_all.deb KRk5OVkmzLA1IoPEqv9Rng=Debian:pool/main/d/discover/discover_2.0.4-5_i386.deb cJygCm3NWHvifSl5794VqQ=Debian:pool/main/d/discover/libdiscover2_2.0.4-5_i386.deb These are all in the .jigdo file marked Info='Generated on Sat, 5 Jun 2004 22:52:18 -0600' so maybe people have just fixed the problem this weekend, perhaps. I'm writing the latest full CD#1 to a CD-RW now to test it. -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] I suspect most samba developers are already technically insane... Of course, since many of them are Australians, you can't tell. -- Linus Torvalds signature.asc Description: Digital signature
Re: Bug#253033: installation-reports
Steve McIntyre wrote: See http://lists.debian.org/debian-cd/2004/05/msg00036.html When was the last time you checked? Looking at the jigdo file for the latest sarge image #1: I have not tried it since I wrote the above mail. I'll download it tonight and try it tomorrow. -- see shy jo signature.asc Description: Digital signature
Re: Bug#253033: installation-reports
On Tue, Jun 08, 2004 at 12:56:42AM +0100, Steve McIntyre wrote: sledge:/mirror/sarge-cd/jigdo$ zgrep netcfg *jigdo sarge-i386-1.jigdo:GfQ50NysZ7YJVUyG9VK-Uw=Debian:pool/main/n/netcfg/netcfg_0.63_i386.udeb netcfg seems to be there. And also discover bits: DKW499kv8oF0e_2gCgz_GA=Debian:pool/main/d/discover-data/discover-data_2.2004.05.03-3_all.deb KRk5OVkmzLA1IoPEqv9Rng=Debian:pool/main/d/discover/discover_2.0.4-5_i386.deb cJygCm3NWHvifSl5794VqQ=Debian:pool/main/d/discover/libdiscover2_2.0.4-5_i386.deb These are all in the .jigdo file marked Info='Generated on Sat, 5 Jun 2004 22:52:18 -0600' so maybe people have just fixed the problem this weekend, perhaps. I'm writing the latest full CD#1 to a CD-RW now to test it. Hmmm. That wasn't very successful. Netcfg loaded fine off the CD, but only after I loaded it by hand. The 3c59x driver for the network card in the test machine just didn't get loaded. Looking at the *nic* .udebs on the image, they seem quite old (9th May); is that normal? -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Every time you use Tcl, God kills a kitten. -- Malcolm Ray signature.asc Description: Digital signature
[no subject]
"Are DVD images of Debian available? Yes - as far as we know, Debian is the only Linux distribution to offer full-size DVD images for download! Because of their size, these images are distributed exclusively with jigdo. At the moment, only unofficial DVD images for the "unstable" release and official ones for the "testing" release can be downloaded." Fedora core also offers dvdiso that are bootable.seems your alpha dvdiso isn't for some reason tho, i've tried and it gives a bootstrap failure just an fyiRob
Re: Bug#253033: installation-reports
Steve McIntyre wrote: Hmmm. That wasn't very successful. Netcfg loaded fine off the CD, but only after I loaded it by hand. The 3c59x driver for the network card in the test machine just didn't get loaded. Looking at the *nic* .udebs on the image, they seem quite old (9th May); is that normal? I don't know about the dates, if the nic-modules udeb is for the 2.4.26 kernel and is version 0.62, then it's current. I think that the problem with netcfg is that it's not in .disk/udeb_include for these images; its priority does not cause it to be loaded by default, though we should revisit that since we seem to want it everywhere. Anyway, listing it, ethdetect, pcmcia-cs-udeb, and wireless-tools-udeb in .disk/udeb_include may fix that. -- see shy jo signature.asc Description: Digital signature
Re: Bug#253033: installation-reports
On Mon, Jun 07, 2004 at 09:12:41PM -0400, Joey Hess wrote: Steve McIntyre wrote: Hmmm. That wasn't very successful. Netcfg loaded fine off the CD, but only after I loaded it by hand. The 3c59x driver for the network card in the test machine just didn't get loaded. Looking at the *nic* .udebs on the image, they seem quite old (9th May); is that normal? I don't know about the dates, if the nic-modules udeb is for the 2.4.26 kernel and is version 0.62, then it's current. I think that the problem with netcfg is that it's not in .disk/udeb_include for these images; its priority does not cause it to be loaded by default, though we should revisit that since we seem to want it everywhere. Anyway, listing it, ethdetect, pcmcia-cs-udeb, and wireless-tools-udeb in .disk/udeb_include may fix that. Cool. I'll try that now. There's nothing listed there atm: sledge:/home/steve# less /mnt/.disk/udeb_include /mnt/.disk/udeb_include: No such file or directory -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] Further comment on how I feel about IBM will appear once I've worked out whether they're being malicious or incompetent. Capital letters are forecast. Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html signature.asc Description: Digital signature
Why the new cd image default 2.6 kernel is k7 ?
When I using linux26 install , d_i install kernel-image-2.6.6-1-k7 package, but my machine is P3 ! BTW: When d_i use 2.4 kernel can't find my buslogic disk ! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
