Re: preseeding d-i mirror/suite
On Thursday 09 March 2006 03:35, Frans Pop wrote: > On Thursday 09 March 2006 03:24, Mike Fogel wrote: > > The installer will then try to download a file from our apache mirror > > from DOCUMENT_ROOT/dists/**sarge**/Release. (no asterisks) But it's > > not there... it's over in DOCUMENT_ROOT/dists/**stable**/Release. > > Your mirror needs symlinks for the codenames: > ln -s stable sarge > ln -s testing etch > ln -s unstable sid Thinking about this again (and how I do it myself), it would be a lot better to mirror on the codenames and create symlinks for the suites. The advantage is that when Debian releases, your "stable" symlink will still point to "sarge", and so the release will only happen for you internally after _you_ change the release. This gives you a bit more control. With the current setup (mirroring stable and creating a sarge symlink), stable will change to etch as soon as Debian releases and so the sarge symlink will become incorrect which could lead to unexpected behavior. pgpS7FMjbZZ9x.pgp Description: PGP signature
Re: D-I Etch Beta2 - Status update (4)
On Thu, Mar 09, 2006 at 03:31:21AM +0100, Frans Pop wrote: > On Tuesday 07 March 2006 13:52, Frans Pop wrote: > > Note: full CD images are not yet available, but hopefully will be soon. > > I'll send an update when they are. > > Full CDs are now available for testing too. Can someone now upload the new partman-base ? It should (hopefully) fix the prep problem, and we waited for beta2 to be out before uploading it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: D-I Etch Beta2 - Status update (4)
On Thursday 09 March 2006 11:29, Sven Luther wrote: > On Thu, Mar 09, 2006 at 03:31:21AM +0100, Frans Pop wrote: > > On Tuesday 07 March 2006 13:52, Frans Pop wrote: > > > Note: full CD images are not yet available, but hopefully will be > > > soon. I'll send an update when they are. > > > > Full CDs are now available for testing too. > > Can someone now upload the new partman-base ? It should (hopefully) fix > the prep problem, and we waited for beta2 to be out before uploading > it. Please read: Beta2 is not out yet, these are test builds of the full CDs. Also, I've asked you to test your changes before they are uploaded and I've seen no indication that you have done so. It is completely normal to test changes in software after you make them as developer _before_ uploading them into the archive. pgpFa2gZchS1C.pgp Description: PGP signature
Re: D-I Etch Beta2 - Status update (4)
On Thu, Mar 09, 2006 at 11:51:20AM +0100, Frans Pop wrote: > On Thursday 09 March 2006 11:29, Sven Luther wrote: > > On Thu, Mar 09, 2006 at 03:31:21AM +0100, Frans Pop wrote: > > > On Tuesday 07 March 2006 13:52, Frans Pop wrote: > > > > Note: full CD images are not yet available, but hopefully will be > > > > soon. I'll send an update when they are. > > > > > > Full CDs are now available for testing too. > > > > Can someone now upload the new partman-base ? It should (hopefully) fix > > the prep problem, and we waited for beta2 to be out before uploading > > it. > > Please read: Beta2 is not out yet, these are test builds of the full CDs. Ah, ... sorry, then, still it is an upload to unstable should be ok, but i understand your reticence. > Also, I've asked you to test your changes before they are uploaded and > I've seen no indication that you have done so. It is completely normal to Simple enough, i can't do so. adding partman-base to the ramdisk make it grow beyond the capacity of my prep box to load it. > test changes in software after you make them as developer _before_ > uploading them into the archive. Nice, then i wonder how this could ever be broken in the first place, clearly something did changes that where not tested and uploaded them. But them i guess others are thrusted, and different rules apply to them, since poor stupid sven has no idea about anything, and particularly not about partition tables and parted, right ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Pkg-cryptsetup-devel] Re: Status of partman-crypto
On 07/03/2006 Max Vozeler wrote: > Jonas, I'm going into some details about partman-crypto and > detailed questions about dm-crypt and LUKS. I hope you don't > mind that I bombard you with questions like this... :-) no problem :-) > I've uploaded a snapshot of partman-crypto in form of a bootable > mini.iso image so you can see what it currently looks like: > http://nusquama.org/~max/d-i/20060307/crypto-mini.iso great, i'll give it a try during the next days. > > > This is the part I'm most clueless about. :-) > > > Which key types are supported and which are recommended > > > for dm-crypt and LUKS respectively? > > > > what do you mean with key types? random keys are only supported > > by dm-crypt, luks requires a persistent key. but appart from > > that, i don't know of any limits. you can use whatever file you > > like as a key. binary, text, and also random data. > > To illustrate, the user will be presented with a dialog that > looks roughly like this: > > Use as: Device-mapper encryption (dm-crypt) > Encryption: > Key size: > Key type: > > Use as: Device-mapper encryption (LUKS) > Encryption: > Key size: > Key type: > > I wonder which choices make sense to offer for the "Key type" > option with LUKS and with plain dm-crypt respectively. From what > I learned until now, I think the choices would be "random" and > "passphrase" for plain dm-crypt and just "passphrase" for LUKS. > Both dm-crypt and LUKS I think accept a plain passphrase and > take care of hashing themselves. i would add keyfile. random, passphrase and keyfile for dm-crypt, passphrase and keyfile for luks. keyfile should be a file that the user provides, or it should be created during the installation. > To put my question in a different way: cryptsetup can use a > passphrase and be told to use a random key. Are there other ways > to produce keys that cryptsetup can use? For keyfiles, for > example, how are they stored and made available to cryptsetup on > the installed system? This probably again shows my lack of > knowledge about both systems :-) the keyfiles are provides through the filesystem. i may store a key in /etc/keys/mykey. or i can store it on a usbstick, flashcard, cdrom, floppy, whatever. cryptsetup currently has no facilities to support removable media, but theoretically all this is possible. > > i don't know what loop-AES keyfiles are, but for dm-crypt and > > luks any random file can be used as key. the more random it's > > content is, the more secure it is. so when users choose to > > create a key file instead of using an existant one, i'dd > > suggest to use 'dd if=/dev/random of=keyfile'. > > This actually seems similar to loop-AES. So another stupid > question from me :-) Can dm-crypt/LUKS setups be used with > keyfiles in encrypted form (eg. using openssl or gnupg) and can > /etc/crypttab be setup so that the user will be asked for a > passphrase to decrypt the keyfile? a wishlist bug against crypsetup adds support for openssl encrypted keys. i planned to do some work related to this task within the next weeks. > For loop-AES it works like this: Actual encryption keys are > created from /dev/random and then encrypted using gnupg and a > passphrase (or a public key). When the system starts, mount or > losetup call gnupg to decrypt the keyfile and use the keys > therein to setup the loop encryption. it's no problem to implent this in cryptsetup packages as well. > It seems to me that, if it's possible, it would be preferred > to use encrypted keyfiles. They have the advantage that the > actual encryption keys are strongly random (as in /dev/random) > while users need only memorize a passphrase that they can > choose and change. ok, so you mean that the key for actually encrypting the disk is more secure than a simple passphrase. i would also like to support unencrypted keys, stored on removable media, but this needs some more work to be done. > Cool - this should all not be difficult to do. The part that > probably involves most work is to build udeb versions of > cryptsetup and the libraries it uses. It think some parts do > already exist as udebs (libdevmapper?). then we still need libgcrypt11, libgpg-error0, libpopt0, libuuid1, dmsetup and cryptsetup. i'll look into it soon. > > but /dev/zero is not really a good source for random data, is > > it? even /dev/urandom is considered as insecure, so i'dd rather > > try to give /dev/random more entropy instead of using less > > secure sources. > > The way I understand it we don't need the data that is written > to be strongly random. For loop-AES - I suppose it's similar for > dm-crypt - the initialization is used to make it more difficult > for an adversary to see which blocks actually contain encrypted > data and are worth trying to crack. If the data is indisting- > uishable from random data, it should do. [0] no, i don't mean filling the device with random data before encrypting it. this is recommented too
/cdrom/dists/sid/Release don't exist
Hi! I downloaded the "DebianInstaller daily developmental builds" from http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/debian-testing-i386-netinst.iso and started the installation in expert mode and chose unstable as dist. When I came to "Install base system" stage the installer was searching for "file:///cdrom/dists/sid/Release" that does not exist and the installation could not continue. /Fredrik Kers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: D-I Etch Beta2 - Status update (4)
On Thu, Mar 09, 2006 at 03:31:21AM +0100, Frans Pop wrote: > The last udeb we need for Beta2 will migrate tomorrow, so the build of the > final Beta2 CD images will start on Friday. That means that the release > itself will probably happen on Saturday. Good timing! Geert Stappers In an attempt to give a compliment (or is the joke too much incrowd?) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /cdrom/dists/sid/Release don't exist
On Thursday 09 March 2006 17:15, Fredrik Kers wrote: > I downloaded the "DebianInstaller daily developmental builds" from > http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/i >so-cd/debian-testing-i386-netinst.iso and started the installation in > expert mode and chose unstable as dist. When I came to "Install base > system" stage the installer was searching for > "file:///cdrom/dists/sid/Release" that does not exist and the > installation could not continue. That is correct. You can not install unstable using a netinst CD, only testing. You should use a businesscard CD instead. Note to self: add a check in choose-mirror that does not allow to change the suite if installing from CD (or iso) and .disk/base_installable is present. Cheers, FJP pgpofXQ7SkzMP.pgp Description: PGP signature
Re: [Pkg-cryptsetup-devel] Re: Status of partman-crypto
On Thursday 09 March 2006 17:22, Jonas Meurer wrote: > the keyfiles are provides through the filesystem. i may store a key in > /etc/keys/mykey. or i can store it on a usbstick, flashcard, cdrom, > floppy, whatever. cryptsetup currently has no facilities to support > removable media, but theoretically all this is possible. If you're going to consider putting keys needed to mount the root filesystem on removable media during installation, please keep in mind that that would mean that the drivers for the removable media will need to be included on the initrd that is generated by base-installer. pgpLz9CuFVj7R.pgp Description: PGP signature
Su mensaje era portador de virus
ATENCIÓN! Se ha detectado virus en su mensaje. El virus ha sido eliminado del mensaje y no será entregado. Para su seguridad le recomendamos que emplee un antivirus actualizado en su sistema informático. Los datos del mensaje son: =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Emisor: debian-boot@lists.debian.org Destinatario: [EMAIL PROTECTED] ----- msg-79113-2.html Infectado: HTML/[EMAIL PROTECTED] message.scr Infectado: W32/[EMAIL PROTECTED] =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= --- Begin Message --- --- End Message ---
Bug#355853: marked as done (installation-report: missing request for lspci output)
Your message dated Thu, 9 Mar 2006 19:11:40 +0100 with message-id <[EMAIL PROTECTED]> and subject line Bug#355853: installation-report: missing request for lspci output has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: installation-report Version: 2.12 and subversion from Alioth Severity: wishlist Tags: patch Hello, Current install-report.template doesn't contain Output of lspci and lspci -n: It was bugreport #355796 where I missed that information request the first time. I think it is a good thing to have it back, hence this patch: --- install-report.template (revision 35335) +++ install-report.template (working copy) @@ -7,6 +7,7 @@ Machine: Partitions: +Output of lspci and lspci -n: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Explaining why it is not needed anymore, would also be nice. Cheers Geert Stappers --- End Message --- --- Begin Message --- On Wed, Mar 08, 2006 at 11:09:57AM +0100, Geert Stappers wrote: > It was bugreport #355796 where I missed that information request the > first time. I just saw #356089 which has "hardware report", that provides the lspci output. So, this BR can (and is) be closed. Cheers Geert Stappers --- End Message ---
Bug#356105: Package: installation-reports
Package: installation-reportsBoot method: BootCD (Debian Installer testing datedImage version: Date: Machine: IBM Thinkpad T41Processor: 1.6M CentrinoMemory: 1GbPartitions: --Output of lspci and lspci -n:--Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try itInitial boot worked:[O]Configure network HW: [O]Config network: [O]Detect CD: [O]Load installer modules: [O] Detect hard drives: [O]Partition hard drives: [O]Create file systems:[O]Mount partitions: [O]Install base system:[E]Install boot loader:[O]Reboot: [O] Comments/Problems: Base Installation fails. Problem -- SUITE variable points to sid instead of etch. Work around for installation: In /usr/lib/debootstrap/functions, replace $SUITE with etch. Permanent solution : simlink on the cdrom /cdrom/dists/etch pointing to /cdrom/dists/sid -- Naheed Vora6e 61 68 65 65 64 40 67 6d 61 69 6c 2e 63 6f 6d
Processed: Re: Bug#356103: Sarge installation report
Processing commands for [EMAIL PROTECTED]: > reassign 356103 installation-reports Bug#356103: Sarge installation report Warning: Unknown package 'sarge' Bug reassigned from package `sarge' to `installation-reports'. > -- Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian-in-workers] Country names for Bengali
On Sun, Feb 26, 2006 at 08:49:22AM +0100, Christian Perrier wrote: > > Christian already informed that the bn_BD locale has an issue, I will > > try to dig out. > > You can ask for help on debian-i18n, at least to be pointed at correct > documentation about collation rules writing. > > Denis barbier gave a very interesting talk at last Debconf about this > (which talk, dammit, I couldn't attend because I had a D-I talk > immediately after it). Slides are available at http://people.debian.org/~barbier/talks/debconf5/glibc-locale.pdf I wrote a first draft of collation rules, based on informations found in http://tdil.mit.gov.in/bangla.pdf http://www.unicode.org/cldr/data/common/collation/bn.xml http://developer.mimer.com/collations/charts/bengali.htm Could a native speaker please send a sorted list of words, say around 50, one word per line? I can then check that the file is not modified when passed to the sort command. Denis -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Fwd: D-I Etch Beta2 - Status update (4)
(full original message kept for d-boot) Thanks very much for your message Mike. I've decided, based on your report, to ask RM to hint initramfs-tools 0.53c for testing early and wait for that for Beta2. To be honest, I was aware of the issue and had planned to check if testing was affected, but it slipped my mind. This really should be fixed before the release. Cheers, FJP On Thursday 09 March 2006 22:10, mike clapper wrote: > Just an update regarding the hppa version. > > I downloaded the netinstall iso and installed this on a c160. > Then only problem I had turned out to be an issue with initrd as > documented in the attached. > > The net install worked perfectly - the installer is improved from the > previous version. The problem I encounted was a failure to boot > from the hard drive following the installation - attached is a copy of > the error. > > To resolve it, I booted from the cd, mounted the partitions for / and > /boot on /mnt then > > #cd /mnt > #chroot . > > I installed the initrd-tools from the debian mirror, then in the > subdir /usr/share/initramfs-tools/scripts/init-premount > > #mv udev-helper udev_helper > > then run mkinitrd to rebuild the initrd image with the renamed file. > > After installing the new initrd image, the system booted normally. > > > Mike > > > - boot error -- > Begin: Running /scripts/init-premount ... > eval: 1: array_udev-helper=udev: not found > eval: 1: array_udev-helper=: not found > > Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 > ide: Assuming 50MHz system bus speed for PIO modes; override with > idebus=xx Done. > Begin: Mounting root file system... ... > Begin: Running /scripts/local-top ... > Done. > ALERT! /dev/sda4 does not exist. Dropping to a shell! > > > BusyBox v1.01 (Debian 1:1.01-4) Built-in shell (ash) > Enter 'help' for a list of built-in commands. > > /bin/sh: can't access tty; job control turned off > / # > > > > > > mv > > > -- bug report -- > Bug#355235: marked as done (initramfs-tools: file name illegal > invariable names) > > * To: maximilian attems <[EMAIL PROTECTED]> > * Subject: Bug#355235: marked as done (initramfs-tools: file name > illegal invariable names) > * From: [EMAIL PROTECTED] (Debian Bug Tracking System) > * Date: Sun, 05 Mar 2006 14:18:31 -0800 > * Message-id: <[EMAIL PROTECTED]> > * Old-return-path: <[EMAIL PROTECTED]> > * References: <[EMAIL PROTECTED]> > <[EMAIL PROTECTED]> > > Your message dated Sun, 05 Mar 2006 13:47:49 -0800 > with message-id <[EMAIL PROTECTED]> > and subject line Bug#355235: fixed in initramfs-tools 0.53b > has caused the attached Bug report to be marked as done. > > This means that you claim that the problem has been dealt with. > If this is not the case it is now your responsibility to reopen the > Bug report if necessary, and/or fix the problem forthwith. > > (NB: If you are a system administrator and have no idea what I am > talking about this indicates a serious mail system misconfiguration > somewhere. Please contact me immediately.) > > Debian bug tracking system administrator > (administrator, Debian Bugs database) > > > --- Begin Message --- > > * To: [EMAIL PROTECTED] > * Subject: initramfs-tools: file name illegal in variable names > * From: Tollef Fog Heen <[EMAIL PROTECTED]> > * Date: Sat, 04 Mar 2006 11:42:45 +0100 > * Message-id: <[EMAIL PROTECTED]> > * User-agent: Mail/News 1.5 (X11/20060213) > > Package: initramfs-tools > Severity: important > > > From the 0.52 changelog: > > * scripts/init-premount/udev-helper: Renamed from > scripts/init-premount/ide. > > As - is not valid in shell variable names and initramfs-tools uses > shell variable names for handling dependencies, this will cause errors > like: > > eval: 1: array_udev-helper=udev: not found > eval: 1: array_udev-helper=: not found > > > on boot. > > Please rename the file to udev_helper to work around this. > > - tfheen > > > --- End Message --- > > --- Begin Message --- > > -- Forwarded message -- > From: Frans Pop <[EMAIL PROTECTED]> > Date: Mar 7, 2006 7:17 AM > Subject: Re: D-I Etch Beta2 - Status update (4) > To: [EMAIL PROTECTED] > > > (already sent to d-boot) > > On Tuesday 07 March 2006 13:52, Frans Pop wrote: > > I am very happy to announce that the debian-installer images targeted > > for Beta2 are now in testing (except AMD64) and that daily (etch_d-i) > > netinst and buisinesscard CD images using them are now available from > > [1]. These images use the 2.6.15-7 kernel. > > To avoid confusion, the direct link to the correct images is: > http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/$arch/ >iso-cd/ pgpu5mKzD4och.pgp Description: PGP signature
Re: [Pkg-cryptsetup-devel] Re: Status of partman-crypto
Hi all, On Thu, Mar 09, 2006 at 05:22:07PM +0100, Jonas Meurer wrote: > On 07/03/2006 Max Vozeler wrote: > > I've uploaded a snapshot of partman-crypto in form of a bootable > > mini.iso image so you can see what it currently looks like: > > http://nusquama.org/~max/d-i/20060307/crypto-mini.iso > > great, i'll give it a try during the next days. When you do, please try a newer snapshot instead of the one above. That one had a couple of problems. I've uploaded a new snapshot (20060310) that also includes the cdebconf newt plugin for helping the entropy collection. (cdebconf-newt-entropy) http://nusquama.org/~max/d-i/20060310/crypto-mini.iso There are already two errata items for this snapshot: Partition erase is broken: It consumes lots and lots of memory and can cause the OOM killer to step in. Make sure to select "Erase data: no" for the encrypted partitions for now. The second erratum concerns the installed system. fstab still ends up with 2 in fs_passno for encrypted loop partitions. Of course it can't fsck the encrypted backing device and so the boot fails with an error. You can choose ^D to continue and change passno to 0 afterwards. > i would add keyfile. random, passphrase and keyfile for > dm-crypt, passphrase and keyfile for luks. keyfile should be a > file that the user provides, or it should be created during the > installation. I will add provisions for the missing key types shortly. Using keyfiles that the user provides on removable media is still an unsolved problem, but one I'd eventually like to attack. There are use cases apart from working around the low-entropy problem where using an existing keyfile makes a lot of sense - for example when it should be pubkey encrypted. Thinking about it and relating to Frans reply - it seems to me that loading keyfile from removable media has much in common with loading extra (non-free or updated) udebs and firmware files for use by the installer. Perhaps a solution for one use could help solve the other use too. > [explanations about keyfiles] Again many thanks for explaining. > a wishlist bug against crypsetup adds support for openssl > encrypted keys. i planned to do some work related to this task > within the next weeks. That would be excellent! > > For loop-AES it works like this: Actual encryption keys are > > created from /dev/random and then encrypted using gnupg and a > > passphrase (or a public key). When the system starts, mount or > > losetup call gnupg to decrypt the keyfile and use the keys > > therein to setup the loop encryption. > > it's no problem to implent this in cryptsetup packages as well. One advantage of gnupg keyfiles over openssl keyfiles is that they can also be encrypted asymmetrically for one or more perhaps already existing keys. But openssl keyfiles are also very good.. For loop-AES setups there is an extra advantage from using gnupg keyfiles: root can encrypt the keyfile to one or more users so they can access the encrypted partition without getting access to the encryption keys used, which can later be revoked. (Only as an aside - this is not directly relevant :-) > > It seems to me that, if it's possible, it would be preferred > > to use encrypted keyfiles. They have the advantage that the > > actual encryption keys are strongly random (as in /dev/random) > > while users need only memorize a passphrase that they can > > choose and change. > > ok, so you mean that the key for actually encrypting the disk > is more secure than a simple passphrase. i would also like to > support unencrypted keys, stored on removable media, but this > needs some more work to be done. Yes. We can do that for cryptsetup setups - no problem. > then we still need libgcrypt11, libgpg-error0, libpopt0, > libuuid1, dmsetup and cryptsetup. > > i'll look into it soon. I think libuuid1 and also dmsetup are already built as udebs. If you need any help with this, I'm sure people on debian-boot would be able and happy to help. As would I. > no, i don't mean filling the device with random data before > encrypting it. this is recommented too, and could be provided > as an option function in the installer. but what i meant here > is creating the keys with data from /dev/random. Ah, I must have misunderstood. I think we are in perfect agreement then :-) > if you've any work that could be done by us (the cryptsetup > maintainer team), let us know. > > next tasks will be: > - add support for gnupg/openssl encrypted keys to cryptdisks > - add support for removable devices to cryptdisks > - add udebs for cryptsetup and its dependencies. Sounds very good to me! I will continue to send you questions when they come up and let you know about things that we/you can already do to prepare cryptsetup support. cheers, Max -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#356105: Package: installation-reports
reassign 356105 choose-mirror retitle 356105 Should not allow user to select unstable for netinst/full CD installs thanks On Thursday 09 March 2006 20:04, Naheed Vora wrote: > Base Installation fails. Problem -- SUITE variable points to sid > instead of etch. > Work around for installation: In /usr/lib/debootstrap/functions, > replace $SUITE with etch. That must have been because you used u netinst or full CD image to install unstable, which is just not supported. (We do need to block that option though so users cannot make that mistake.) > Permanent solution : simlink on the cdrom /cdrom/dists/etch pointing to > /cdrom/dists/sid No. Use a businesscard image instead. That will allow you to install unstable without any problems. Thanks for your report. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#356105: Package: installation-reports
Processing commands for [EMAIL PROTECTED]: > reassign 356105 choose-mirror Bug#356105: Package: installation-reports Bug reassigned from package `installation-reports' to `choose-mirror'. > retitle 356105 Should not allow user to select unstable for netinst/full CD > installs Bug#356105: Package: installation-reports Changed Bug title. > thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
