Bug#391664: partman-auto-crypto: Some questions and issues
On Sun, Oct 08, 2006 at 12:27:00AM +0200, Frans Pop wrote: Package: partman-auto-crypto Version: 2 (1) In autopartition-crypto there is a somewhat dangerous double use of "$dev"; it would possibly be better to use separate variables. be better to use separate variables. Ok I also wonder what that loop actually does. Why is it needed to loop over $DEVICES when you have been passed a specific $dev? Would it be possible that some other disk already has a method "crypto" (from a previous installation maybe) and thus is used by mistake? The loop is there because it needs to look not for the $dev device but the virtual device-mapper device which has been created ontop of the device pointed to by $dev after the crypto_setup step. It should be a bit smarter and make sure the virtual-$dev <-> $dev mapping is correct thoughand it should probably exit the loop once that is established...but I don't think the loop can be removed... (2) Choosing guided partitioning again after setting up crypto and choosing regular LVM fails because encrypted partition is in use... (3) Choosing guided partitioning again after setting up crypto and choosing regular partitioning works, but encrypted volume and LVM stuff is still shown... For both (2) and (3) we should just make sure things are cleaned up properly as we are going to scratch the disk anyway. How can an encrypted partition be "released"? "dmsetup remove " or "cryptsetup remove ". This is a generic problem with partman-crypto as well. The best thing to do would probably be to extend the checks that are already done for LVM-exists-on-device and extend them to also check (+ warn) and wipe crypto on a device which is going to be auto-partitioned. I'll try to find time this week to look into it. -- David Härdeman
Re: [Debian Installer] General release plan for RC1
Le mardi 10 octobre 2006 à 07:18 +0200, Tshepang Lekhonkhobe a écrit : > On 10/8/06, Loïc Minier <[EMAIL PROTECTED]> wrote: > > On Sun, Oct 08, 2006, Attilio Fiandrotti wrote: > > > Just today mike emmel fixed the "boom" bug, it should technically > > > possible switching to GTK+ 2.10.x. > > > > Repeating this here for other readers: 2.10.6-2 in experimental was > > uploaded today with the fix. > > So are getting GNOME 2.16 for Etch? Frans Pop scared me a bit saying > we are stuck with 2.14 :-( The current plan is to ship GNOME 2.14 in etch [1]. This was a hard decision to make, but we prefer shipping a rock-solid and polished 2.14 version rather than a buggy 2.16 version with which Ubuntu is having many issues. [1] http://oskuro.net/blog/freesoftware/gnome-2.16-etch-2006-10-06-21-45 -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Bug#385629: debian-installer: Encrypted filesystem setup and swap
Hi, I am playing around with the installer and I believe I have hit this problem. If I select automatically set up LVM and crypto I get a good setup, but if I then go to Configure encrypted partitions I am told I can't as swap is not encrypted. The swap is an LVM partition on a dm-crypt device, so I think partman-crypto's detection of encrypted swap in this case is not working. I believe partman-auto-crypto was loaded. Thanks for your work, James [Also it seems that I cannot delete an encrypted partition, even if I get to free space on it, it still says "In use for ...", is there a way to do this? It was annoying having to restart the installer every time I wanted to try something different. Could you point me to the apprpriate package for this, I'm not sure it is partman-crypto] -- James Westby --GPG Key ID: B577FE13-- http://jameswestby.net/ seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Debian Installer] General release plan for RC1
On 10/8/06, Loïc Minier <[EMAIL PROTECTED]> wrote: On Sun, Oct 08, 2006, Attilio Fiandrotti wrote: > Just today mike emmel fixed the "boom" bug, it should technically > possible switching to GTK+ 2.10.x. Repeating this here for other readers: 2.10.6-2 in experimental was uploaded today with the fix. So are getting GNOME 2.16 for Etch? Frans Pop scared me a bit saying we are stuck with 2.14 :-(
Bug#391879: marked as done (INTL:de typo in german translation)
Your message dated Mon, 9 Oct 2006 20:33:05 +0200 with message-id <[EMAIL PROTECTED]> and subject line Bug#391879: INTL:de typo in german translation 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: debian-installer Severity: minor Tags: l10n Hi, today I installed Debian Etch on a friends workstation, in german. First of all congratulations, you really do a good job and I like the new installer. I just wanted to report a little typo in it, on the list where you can select the task of a harddisk (filesystem or lvm-volume, crypto-volume etc.), is written "Physikalisches Volume fuer Verschluesselung" where you should just s/Volume/Volumen/, this is also wrong in 2 other list elements. Regards -- .''`. Mario Iseli <[EMAIL PROTECTED]> : :' :proud user of Debian unstable `. `'` `- Debian - when you have better things to do than fixing a system --- End Message --- --- Begin Message --- On Mon, Oct 09, 2006 at 07:13:11PM +0200, Christian Perrier wrote: > Quoting Mario Iseli ([EMAIL PROTECTED]): > > today I installed Debian Etch on a friends workstation, in german. First > > of all congratulations, you really do a good job and I like the new > > installer. I just wanted to report a little typo in it, on the list > > where you can select the task of a harddisk (filesystem or lvm-volume, > > crypto-volume etc.), is written "Physikalisches Volume fuer > > Verschluesselung" where you should just s/Volume/Volumen/, this is also > > wrong in 2 other list elements. That's not a typo. "Volume" is just English and not related to Volumen (which might be a translation as i notice now the first time). I even hesitated to translate "logical" and "physical". "Logical Volume" is really common in German texts, "logisches Volume" hopefully too. I always think about "loudness" (Lautstärke) when I hear "volume" and I'm sure many other people also see no relation of volume and Volumen (even if it is valid). Nevertheless I added a few real typos in the installer. If you find these you will get a cooky from me :-) Jens --- End Message ---
Bug#392042: software RAID volumes can not be partitioned
Package: debian-installer Severity: important debian installer lets one setup a raid fairly easily. however, it gives no indication that one can't partition an array, but one has to partition the base disks and create the arrays out of the partitions. In fact, the installer will go ahead an partition the disk for if you tell it to do it automatically. took me way too long to figure out what the problem was, as I'm used to using 3ware cards where they just deal with whole disks, and I'd partition the array itself. -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (650, 'testing'), (600, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.16-2-686 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Adding RAID 6 support to the Installation Disk
Frans Pop wrote: On Monday 09 October 2006 16:31, Dr. Harold K. Brown, P.E. wrote: I believe it would be beneficial for Etch users to have a Raid 6 installation option that really works at time of installation. I can help with testing and even do some patches. My time is limited, and I do know time is short with the upcoming planned Etch stable release. If the installation team is open for this, please contact me and let me know the best way to approach this if there is a desire to include this capability into the installation disk. Adding support is always great. However, as you rightly say, the timing is tight. Too tight IMO: we are currently preparing the first Release Candidate of the installer for Etch and we will be hard pressed to solve the outstanding issues for that. Of course, if it is only a question of adding the driver and no changes are needed in the installer itself, getting support is completely up to the kernel team and the installer will follow almost automatically. I don't really see us adding new functionality in the installer itself at this late date, especially as it cannot be tested before the driver has been included by the kernel team _and_ the installer has been switched to 2.6.18. Your contributions to get support it will still be very welcome though and they would certainly be considered for addition after Etch. If the changes are small, ready in time and tested, we could even reconsider. This would require an addition of a device driver with a risk factor that I believe to be low. Currently the drive is open source and has been included into the Git Tree at kernel.org. The driver is supported by the company now and complies with the kernel code writing standards. I believe the drivers will be included in the 2.6.19 or 2.6.20 kernel.org. However, I understand that Etch will use 2.6.16 or 2.6.18 and thus the driver will not be included. Please contact the kernel team for this. It is not an installer team decision. Cheers, FJP The only support that should be needed in the installer is the driver being available during install-boot and for inclusion in the initial boot images made during install. It basically should operate just as the 3ware RAID drivers do (which I installed onto just fine with Etch B3); that is, I do not think any special detection, etc. is needed. It's a hardware RAID board and, in general, makes the RAID array just looks like one big disk to the installer ( or more if you built the array that way). Thanks R.Parr, RHCE, Temporal Arts -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Adding RAID 6 support to the Installation Disk
(This is the last message I will CC you; if you're not yet subscribed to the list, please do.) On Tuesday 10 October 2006 01:45, Andre Luis Lopes wrote: > RParr escreveu: > > I, for one, would very much welcome this. I am not a kernel beater > > but I would be willing to do what I can to help test/whatever to see > > this happen. > > Then smile -> > http://packages.debian.org/changelogs/pool/main/l/linux-2.6/linux-2.6_2 >.6.18-2/changelog#versionversion2.6.18-2 Well, this does make it possible to build custom images of d-i with 2.6.18 and to see what happens... This may help: http://people.debian.org/~fjp/talks/debconf6/paper/ http://d-i.alioth.debian.org/svn/debian-installer/installer/doc/custom-kernel.txt (last doc is somewhat outdated...) Cheers, FJP pgpnhubycfFDN.pgp Description: PGP signature
Re: package selection in preseed File
On Monday 09 October 2006 23:07, Alexander Vogel wrote: > What is meant by "in some other way"? > Is there something like dpkg -i snmp.deb (just as an bad example), i > can use ? What's recommended? The preferred method to install individual packages from a script (e.g. preseed late) is to use apt-install. It is listed in this README file (sarge version): http://svn.debian.org/wsvn/d-i/tags/packages/debian-installer-utils/1.08/README?op=file&rev=0&sc=0 Note that this is run with the noninteractive debconf frontend, so you won't be able to do any configuration. Cheers, FJP pgpyVQhvm7r7N.pgp Description: PGP signature
Re: Adding RAID 6 support to the Installation Disk
On Monday 09 October 2006 16:31, Dr. Harold K. Brown, P.E. wrote: > I believe it would be beneficial for Etch users to have a Raid 6 > installation option that really works at time of installation. I can > help with testing and even do some patches. My time is limited, and I > do know time is short with the upcoming planned Etch stable release. > If the installation team is open for this, please contact me and let me > know the best way to approach this if there is a desire to include this > capability into the installation disk. Adding support is always great. However, as you rightly say, the timing is tight. Too tight IMO: we are currently preparing the first Release Candidate of the installer for Etch and we will be hard pressed to solve the outstanding issues for that. Of course, if it is only a question of adding the driver and no changes are needed in the installer itself, getting support is completely up to the kernel team and the installer will follow almost automatically. I don't really see us adding new functionality in the installer itself at this late date, especially as it cannot be tested before the driver has been included by the kernel team _and_ the installer has been switched to 2.6.18. Your contributions to get support it will still be very welcome though and they would certainly be considered for addition after Etch. If the changes are small, ready in time and tested, we could even reconsider. > This would require an addition of a device driver with a risk factor > that I believe to be low. Currently the drive is open source and has > been included into the Git Tree at kernel.org. The driver is supported > by the company now and complies with the kernel code writing standards. > I believe the drivers will be included in the 2.6.19 or 2.6.20 > kernel.org. However, I understand that Etch will use 2.6.16 or 2.6.18 > and thus the driver will not be included. Please contact the kernel team for this. It is not an installer team decision. Cheers, FJP pgp1BdAVNrIfM.pgp Description: PGP signature
Re: Adding RAID 6 support to the Installation Disk
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, RParr escreveu: > > I, for one, would very much welcome this. I am not a kernel beater but > I would be willing to do what I can to help test/whatever to see this > happen. Then smile -> http://packages.debian.org/changelogs/pool/main/l/linux-2.6/linux-2.6_2.6.18-2/changelog#versionversion2.6.18-2 - -- André Luís Lopes [EMAIL PROTECTED] http://people.debian.org/~andrelop Public GPG KeyID : 9D1B82F6 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFKt8xW4/i9Z0bgvYRAlRTAJ4s2yy7Mj7rPq3e6GwSb7666iOWkgCgpJnG nXozRHZeP6FkEmrFe19fVxU= =AVxd -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: blade 150 and 2.6
On Tuesday 10 October 2006 01:11, Riccardo Tortorici wrote: > If everyone is experiencing issues with those kernel releases, maybe > it's better to remove them from unstable. That is not really an option. The 2.6.18 kernel is scheduled for release with Etch. What needs to happen is that the bug is fixed in 2.6.18 in Debian before the release. For that it would be good if an RC bug was filed against linux-2.6. I see that the issue is already being worked on by Jurij with the upstream Sparc kernel maintainer: http://marc.theaimsgroup.com/?l=linux-sparc&m=116038215730519&w=2 Cheers, FJP pgp0ZDgymgevy.pgp Description: PGP signature
Re: Adding RAID 6 support to the Installation Disk
Dr. Harold K. Brown, P.E. wrote: Currently, I am using the ARC-1220 Areca raid controller with the RAID 6 engine under Debian. The system is i386 based and the only hard drives on the system is the Raid 6 drive set. This is a hardware raid solution. I believe it would be beneficial for Etch users to have a Raid 6 installation option that really works at time of installation. I can help with testing and even do some patches. My time is limited, and I do know time is short with the upcoming planned Etch stable release. If the installation team is open for this, please contact me and let me know the best way to approach this if there is a desire to include this capability into the installation disk. This would require an addition of a device driver with a risk factor that I believe to be low. Currently the drive is open source and has been included into the Git Tree at kernel.org. The driver is supported by the company now and complies with the kernel code writing standards. I believe the drivers will be included in the 2.6.19 or 2.6.20 kernel.org. However, I understand that Etch will use 2.6.16 or 2.6.18 and thus the driver will not be included. This may be one of the best Raid 6 solutions on the market at this time and it does seem to work well with Debian. Another Areca customer made a Debian install disk based on Sarge, which I have been using. It works well, but does not have the driver support for other common devices like sound that are in the newer kernels. The install disk used the 2.6.8 kernel. I have used the manufacturer's provided drivers on kernels 2.6.8, 2.6.16 (Debian version), and 2.6.18 (kernel.org version). I used the drivers from the git Tree and personally installed the drivers in 2.6.16 deb source and 2.6.18 kernel.org source so that I could configure the drivers though make menuconfig. The drivers are installed as modules. Both kernels seem to work fine. Note, that the purpose of this system configuration is to be 100% RAID 6 where in such a case it would be very convenient to have RAID 6 support at time of installation. Test data so far seems to support that this may very well be possible, at least for the test hardware set under use. Some Functional Test Results Follow: The following outlines one of the experiments that I performed. Keep in mind that the only hard drives on the system is the RAID 6 set. I configured 4 drives using the Raid's boot bios software. Once the RAID 6 was configured, Debian was installed from CD using a modified Sarge installation disk. During the actual install, while loading the base system I randomly pulled one of the 4 drives from the system, then in a few minutes pulled another. The alarms sounded, but the install proceeded. After a few minutes I put the drives back into the system. Keep in mind that I am proceeding with the installation without any delay while the two drives are pulled out and then put back into the system. Once the drives re-synced, I did it again and again with differing drives. I then: 1) Added the driver to the stock 2.6.18 kernel from kernel.org, 2) With the 2.6.18 kernel loaded, did a distribution upgrade from Sarge to Etch (Testing). 3) Then modified the Debian 2.6.16 kernel source and installed. All of this work was done on the test system with the RAID 6 set as the only hard drive. I did numerous demonstrations allowing any that came by to randomly select one or two drives and pull them out at will. The system is still in use and under test. Results are good. I asked on the kernel list, some time ago, before the last stable release, if the Areca driver could be included before the stable release so as to be installable, etc.. The response at the time was if it was included in an upstream kernel it might be able to be backported and included in the stable release kernel. At the time the Areca driver had not been accepted (I thought it had but it had not). Now it has been (included in 2.6.19 change log). So it might be possible to get it included in the 2.6.18 for the next stable. I, for one, would very much welcome this. I am not a kernel beater but I would be willing to do what I can to help test/whatever to see this happen. Thanks R.Parr, RHCE, Temporal Arts -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: blade 150 and 2.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Oct 9, 2006, at 7:24 PM, Luigi Gangitano wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il giorno 08/ott/06, alle ore 22:42, Riccardo Tortorici ha scritto: The latest kernel version in unstable is 2.6.18. You do know that the kernel packages got renamed from kernel-image to linux-image at some point, right? :-). Yeah, I was convinced i did a dist-upgrade but not :) Now I've upgraded from 2.6.8 to 2.6.18 but I get this error if I boot with the new image: NVRAM: Low battery voltage! CLOCK: Clock was stopped. Kick start Boot with 2.6.8 is ok. As far as I can see, this message is in time.c from kernel sources... What if I'll comment those lines? Is it a dirty procedure or it's safe? I can confirm this on my SunBlade 100 too. It appeared in 2.6.17. Last known-to-work version is 2.6.16 even if I can't make the aty framebuffer work again when compiling with gcc-4.1 (which, BTW, is default for sid as of now). I've tried to bypass the check of NVRAM by comment the functions in time.c and removing all the references. This time freezes in "Booting Linux", it seems those functions are mandatory. I've attached the commented lines. If everyone is experiencing issues with those kernel releases, maybe it's better to remove them from unstable. Ric - - Riccardo Tortorici - Linux Registered User #365170 Count yourself @ http://counter.li.org/ ! - -- Encrypted Mails Welcome GPG key: 0xF3FCE306 available on wwwkeys.pgp.net GPG key fingerprint = C1C4 CA17 5135 8F5C 94C2 3347 4A22 67DB F3FC E306 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFKtc4SiJn2/P84wYRAq+0AJ4jjYGeRK6KD6T+xtii8akGW/ZWLQCbBSx1 cAeGnXgdp/CEftgS18cRKvo= =XpLG -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
package selection in preseed File
Hello, I need some information: In the file http://www.debian.org/releases/sarge/example-preseed.txt i found this : # You can choose to install any combination of tasks that are available. # Available tasks as of this writing include: Desktop environment, # Web server, Print server, DNS server, File server, Mail server, # SQL database, Laptop, Standard system, manual package selection. The # last of those will run aptitude. You can also choose to install no # tasks, and force the installation of a set of packages in some other # way. We recommend always including the Standard system task. What is meant by "in some other way"? Is there something like dpkg -i snmp.deb (just as an bad example), i can use ? What's recommended? i hope i expressed my problem in an understandable way tia alex -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[g-i] arm port
Last week, after reading [1], I wanted to see how hard it'd be to port the graphical installer on arm. I set up a sid VM and checked out a copy of the d-i build environment as described in [2] I then created a patch ([3]) based on the existing g-i build environments and tried to compile which took me to the first problem: The following packages have unmet dependencies: rootskel-gtk: Depends: mouse-modules but it is not installable E: Broken packages make[2]: *** [stamps/get_udebs-rpc_gtk-miniiso-stamp] Error 100 make[1]: *** [_build] Error 2 make: *** [build_rpc_gtk-miniiso] Error 2 I then rebuilt a version of rootskel-gtk removing the dependency on mouse-modules (this means there'll be a problem with missing modules...) and copied it in localudebs. Compilation went fine to the end producing initrd.gz vmlinuz-2.6.17-2-rpc Before proceeding with testing the above files, I tried to start the frontend in a chroot and noticed that I got a black screen; asked for some help ([5]) on the directfb ML and, as suggested by Denis, I tried to hack the directfb-0.9.25.1 package (using [6]) and finally managed to see something [7] As suggested by Denis the problem is that directfb supports RGB and not BGR, but looks like the fb is BGR. regards, Davide [1] http://www.aurel32.net/info/debian_arm_qemu.php [2] http://wiki.debian.org/DebianInstaller/GUIBuild [3] http://www.webalice.it/zinosat/g-i/g-i_arm.patch [4] http://www.webalice.it/zinosat/g-i/rootskel-gtk_0.12_arm.udeb [5] http://mail.directfb.org/pipermail/directfb-dev/2006-October/002362.html [6] http://www.webalice.it/zinosat/g-i/50_arm_rgb.patch [7] http://www.webalice.it/zinosat/g-i/g-i_arm.png signature.asc Description: Digital signature
Bug#391395: installation report
-- Forwarded Message --
Subject: Re: Bug#391395: installation report
Date: Monday 09 October 2006 18:34
From: Alexis Lee1 <[EMAIL PROTECTED]>
To: Frans Pop <[EMAIL PROTECTED]>
Hi Frans,
`lspci -n`: 00:1f.1 0101: 8086:24cb (rev 01)
`dmesg`:
... cut ...
hda: IC35L040AVVN07-0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: LTN486S, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
ACPI: PCI Interrupt :00:1d.0[A] -> GSI 16 (level, low) -> IRQ 185
... cut ...
hda: max request size: 128KiB
hda 78156288 sectors (40016MB) w/1863KiB Cache, CHS=65535/16/63,
UDMA(100) hda: cache flushes supported
hda: hda1 hda2 < hda5 hda6 hda7 >
hdc: ATAPI 48X CD-ROM drive, 120kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
ACPI: PCI Interrupt :00:1d.1[B] -> GSI 19 (level, low) -> IRQ 193
... cut ...
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
Intel ISA PCIC probe: not found.
hdc: media error (bad sector): status=0x51 { DriveReady SeekComplete
Error }
hdc: media error (bad sector): error=0x30 { LastFailedSense=0x03 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 64
isofs_fill_super: bread failed, dev=hdc, iso_blknum=16, block=16
hdc: media error (bad sector): status=0x51 { DriveReady SeekComplete
Error }
hdc: media error (bad sector): error=0x30 { LastFailedSense=0x03 }
ide: failed opcode was: unknown
end_request: I/O error, dev hdc, sector 64
isofs_fill_super: bread failed, dev=hdc, iso_blknum=16, block=16
-- end of text --
`ls -l /dev/hdc`: /dev/hdc -> ide/host0/bus1/target0/lun0/cd
`ls -l /dev/cdroms/cdrom0`: /dev/cdroms/cdrom0 ->
ide/host0/bus1/target0/lun0/cd (the same)
`ls -l /dev/ide/host0/bus1/target0/lun0/cd`: block device, node numbers
22,0
`df`:
tmpfs 514068 436 513632 0% /dev
tmpfs 514068 436 513632 0% /dev
tmpfs 514068 436 513632 0% /.dev
`mkdir boo; mount /dev/hdc boo`:
mount: /dev/hdc is write-protected, mounting read-only
mount: /dev/hdc is write-protected, mounting read-only
(taking a long time)
mount: /dev/hdc is write-protected, mounting read-only
mount: Mounting /dev/hdc on boo failed: Invalid argument
I get much the same if I specify "-t iso9660", but faster.
Thanks in advance,
Alexis
---
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#391879: INTL:de typo in german translation
Quoting Mario Iseli ([EMAIL PROTECTED]): > Package: debian-installer > Severity: minor > Tags: l10n > > Hi, > > today I installed Debian Etch on a friends workstation, in german. First > of all congratulations, you really do a good job and I like the new > installer. I just wanted to report a little typo in it, on the list > where you can select the task of a harddisk (filesystem or lvm-volume, > crypto-volume etc.), is written "Physikalisches Volume fuer > Verschluesselung" where you should just s/Volume/Volumen/, this is also > wrong in 2 other list elements. Pointing Jens Seidel, who currently coordinates the german translation effort for D-I. Jens, please close this bug report as soon as you have fixed it in the SVN: reassigning it to the few packages it belongs would be a bug waste of energy. (if you don't think this is a bug, just close it, of course: isn't s/volume/volumen a singular/plural difference and in that situation I'm not sure that plural is needed) signature.asc Description: Digital signature
partman ext2r0 broken?
I just tried to do an installation on a Cobalt MIPS machine after being away from the machine for several months and I get an error during partitioning. When it wants to format /boot, which is to get an ext2 r0 (old ext2) partition, it fails with: The ext2 (revision 0) file system creation in partition #1 of IDE1 master (hda) failed. In /var/log/syslog I see: Jan 1 00:11:29 partman: Filesystem features not supported with revision 0 filesystems partman says for this partition: Mount options: defaults Does anyone have an idea what might have broken ext2 r0 support? -- Martin Michlmayr http://www.cyrius.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of linux-kernel-di-sparc_0.64sarge2_sparc.changes
linux-kernel-di-sparc_0.64sarge2_sparc.changes uploaded successfully to localhost along with the files: linux-kernel-di-sparc_0.64sarge2.dsc linux-kernel-di-sparc_0.64sarge2.tar.gz kernel-image-2.4.27-3-sparc32-di_0.64sarge2_sparc.udeb nic-modules-2.4.27-3-sparc32-di_0.64sarge2_sparc.udeb ppp-modules-2.4.27-3-sparc32-di_0.64sarge2_sparc.udeb cdrom-core-modules-2.4.27-3-sparc32-di_0.64sarge2_sparc.udeb scsi-core-modules-2.4.27-3-sparc32-di_0.64sarge2_sparc.udeb scsi-modules-2.4.27-3-sparc32-di_0.64sarge2_sparc.udeb loop-modules-2.4.27-3-sparc32-di_0.64sarge2_sparc.udeb ipv6-modules-2.4.27-3-sparc32-di_0.64sarge2_sparc.udeb ext3-modules-2.4.27-3-sparc32-di_0.64sarge2_sparc.udeb reiserfs-modules-2.4.27-3-sparc32-di_0.64sarge2_sparc.udeb xfs-modules-2.4.27-3-sparc32-di_0.64sarge2_sparc.udeb md-modules-2.4.27-3-sparc32-di_0.64sarge2_sparc.udeb kernel-image-2.4.27-3-sparc64-di_0.64sarge2_sparc.udeb nic-modules-2.4.27-3-sparc64-di_0.64sarge2_sparc.udeb ppp-modules-2.4.27-3-sparc64-di_0.64sarge2_sparc.udeb ide-modules-2.4.27-3-sparc64-di_0.64sarge2_sparc.udeb cdrom-core-modules-2.4.27-3-sparc64-di_0.64sarge2_sparc.udeb firewire-core-modules-2.4.27-3-sparc64-di_0.64sarge2_sparc.udeb scsi-core-modules-2.4.27-3-sparc64-di_0.64sarge2_sparc.udeb scsi-modules-2.4.27-3-sparc64-di_0.64sarge2_sparc.udeb loop-modules-2.4.27-3-sparc64-di_0.64sarge2_sparc.udeb ipv6-modules-2.4.27-3-sparc64-di_0.64sarge2_sparc.udeb ext3-modules-2.4.27-3-sparc64-di_0.64sarge2_sparc.udeb reiserfs-modules-2.4.27-3-sparc64-di_0.64sarge2_sparc.udeb xfs-modules-2.4.27-3-sparc64-di_0.64sarge2_sparc.udeb md-modules-2.4.27-3-sparc64-di_0.64sarge2_sparc.udeb usb-modules-2.4.27-3-sparc64-di_0.64sarge2_sparc.udeb firmware-modules-2.4.27-3-sparc64-di_0.64sarge2_sparc.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
glantank_0.3_arm.changes ACCEPTED
Accepted: glantank-installer_0.3_arm.udeb to pool/main/g/glantank/glantank-installer_0.3_arm.udeb glantank-utils_0.3_arm.deb to pool/main/g/glantank/glantank-utils_0.3_arm.deb glantank_0.3.dsc to pool/main/g/glantank/glantank_0.3.dsc glantank_0.3.tar.gz to pool/main/g/glantank/glantank_0.3.tar.gz Override entries for your package: glantank-installer_0.3_arm.udeb - optional debian-installer glantank-utils_0.3_arm.deb - optional admin glantank_0.3.dsc - source admin Announcing to debian-devel-changes@lists.debian.org Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processing of glantank_0.3_arm.changes
glantank_0.3_arm.changes uploaded successfully to localhost along with the files: glantank_0.3.dsc glantank_0.3.tar.gz glantank-utils_0.3_arm.deb glantank-installer_0.3_arm.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Adding RAID 6 support to the Installation Disk
Currently, I am using the ARC-1220 Areca raid controller with the RAID 6 engine under Debian. The system is i386 based and the only hard drives on the system is the Raid 6 drive set. This is a hardware raid solution. I believe it would be beneficial for Etch users to have a Raid 6 installation option that really works at time of installation. I can help with testing and even do some patches. My time is limited, and I do know time is short with the upcoming planned Etch stable release. If the installation team is open for this, please contact me and let me know the best way to approach this if there is a desire to include this capability into the installation disk. This would require an addition of a device driver with a risk factor that I believe to be low. Currently the drive is open source and has been included into the Git Tree at kernel.org. The driver is supported by the company now and complies with the kernel code writing standards. I believe the drivers will be included in the 2.6.19 or 2.6.20 kernel.org. However, I understand that Etch will use 2.6.16 or 2.6.18 and thus the driver will not be included. This may be one of the best Raid 6 solutions on the market at this time and it does seem to work well with Debian. Another Areca customer made a Debian install disk based on Sarge, which I have been using. It works well, but does not have the driver support for other common devices like sound that are in the newer kernels. The install disk used the 2.6.8 kernel. I have used the manufacturer's provided drivers on kernels 2.6.8, 2.6.16 (Debian version), and 2.6.18 (kernel.org version). I used the drivers from the git Tree and personally installed the drivers in 2.6.16 deb source and 2.6.18 kernel.org source so that I could configure the drivers though make menuconfig. The drivers are installed as modules. Both kernels seem to work fine. Note, that the purpose of this system configuration is to be 100% RAID 6 where in such a case it would be very convenient to have RAID 6 support at time of installation. Test data so far seems to support that this may very well be possible, at least for the test hardware set under use. Some Functional Test Results Follow: The following outlines one of the experiments that I performed. Keep in mind that the only hard drives on the system is the RAID 6 set. I configured 4 drives using the Raid's boot bios software. Once the RAID 6 was configured, Debian was installed from CD using a modified Sarge installation disk. During the actual install, while loading the base system I randomly pulled one of the 4 drives from the system, then in a few minutes pulled another. The alarms sounded, but the install proceeded. After a few minutes I put the drives back into the system. Keep in mind that I am proceeding with the installation without any delay while the two drives are pulled out and then put back into the system. Once the drives re-synced, I did it again and again with differing drives. I then: 1) Added the driver to the stock 2.6.18 kernel from kernel.org, 2) With the 2.6.18 kernel loaded, did a distribution upgrade from Sarge to Etch (Testing). 3) Then modified the Debian 2.6.16 kernel source and installed. All of this work was done on the test system with the RAID 6 set as the only hard drive. I did numerous demonstrations allowing any that came by to randomly select one or two drives and pull them out at will. The system is still in use and under test. Results are good. Hal
glantank_0.2_arm.changes ACCEPTED
Accepted: glantank-installer_0.2_arm.udeb to pool/main/g/glantank/glantank-installer_0.2_arm.udeb glantank-utils_0.2_arm.deb to pool/main/g/glantank/glantank-utils_0.2_arm.deb glantank_0.2.dsc to pool/main/g/glantank/glantank_0.2.dsc glantank_0.2.tar.gz to pool/main/g/glantank/glantank_0.2.tar.gz Override entries for your package: glantank-installer_0.2_arm.udeb - optional debian-installer glantank-utils_0.2_arm.deb - optional admin glantank_0.2.dsc - optional admin Announcing to debian-devel-changes@lists.debian.org Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#251898:
Quoting martin f krafft <[EMAIL PROTECTED]>: > I cannot imagine how partman would hang due to the resync of RAIDs. > Can you please try to reproduce this problem? Hm, not sure: I vaguely remember, that the hardware in question was a then current Dell server with two hard-disks. If nobody faced the problem again, I suggest to close the bug. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
glantank_0.1_arm.changes ACCEPTED
Accepted: glantank-installer_0.1_arm.udeb to pool/main/g/glantank/glantank-installer_0.1_arm.udeb glantank-utils_0.1_arm.deb to pool/main/g/glantank/glantank-utils_0.1_arm.deb glantank_0.1.dsc to pool/main/g/glantank/glantank_0.1.dsc glantank_0.1.tar.gz to pool/main/g/glantank/glantank_0.1.tar.gz Override entries for your package: glantank-installer_0.1_arm.udeb - optional debian-installer glantank-utils_0.1_arm.deb - optional admin glantank_0.1.dsc - optional admin Announcing to debian-devel-changes@lists.debian.org Thank you for your contribution to Debian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#267168: after thought on patch
After thinking a bit more, I realized adding a bit more information
serves better for logging. Here is an updated patch which adds more
logging message in the fail function.
Osamu
--- cdrom-detect.postinst.orig 2006-10-09 19:31:46.0 +0900
+++ cdrom-detect.postinst 2006-10-09 22:21:28.0 +0900
@@ -9,7 +9,9 @@
}
fail () {
- log "CDROM-detect failed."
+ log "CDROM-detect failed: device=$device"
+ log "Unmounting CD just to be sure."
+ umount /cdrom 2>/dev/null || true
exit 1
}
@@ -38,21 +40,6 @@
mounted=1
db_set cdrom-detect/cdrom_device $device
break
- else
- log "CDROM-mount failed (error=$?): device=$device"
- log "Unmounting CD just to be sure."
- umount /cdrom 2>/dev/null || true
- log "Trying it again."
- if mount -t iso9660 -o ro,exec $device /cdrom; then
- log "CDROM-mount succeeded: device=$device"
- mounted=1
- db_set cdrom-detect/cdrom_device $device
- break
- else
- log "CDROM-mount failed again (error=$?):
device=$device"
- log "Unmounting CD just to be sure and giving
it up."
- umount /cdrom 2>/dev/null || true
- fi
fi
done
@@ -66,6 +53,8 @@
db_go
db_get cdrom-detect/retry
if [ "$RET" = "true" ]; then
+ log "Unmounting CD just to be sure."
+ umount /cdrom 2>/dev/null || true
continue
else
fail
@@ -116,9 +105,7 @@
mounted=1
break
else
- log "CDROM-mount failed (error=$?): device=$device"
- log "Unmounting CD just to be sure and giving it up."
- umount /cdrom 2>/dev/null || true
+ fail
fi
else
fail
@@ -130,10 +117,9 @@
log "Detected CD '$CDNAME'"
else
log "The available CD is not a Debian CD!"
- umount /cdrom
db_input critical cdrom-detect/wrong-cd || [ $? -eq 30 ]
db_go
- exit 1
+ fail
fi
# Get all the pool directories into the dentry cache, to cut down on seek
@@ -173,7 +159,6 @@
log "Error reading Release file; unable to determine distribution"
db_input critical cdrom-detect/no-release || [ $? -eq 30 ]
db_go
- umount /cdrom
fail
fi
Processed: your mail
Processing commands for [EMAIL PROTECTED]: > submitter 251898 [EMAIL PROTECTED] Bug#251898: long delay because RAID has to sync Changed Bug submitter from Martin Michlmayr <[EMAIL PROTECTED]> to [EMAIL PROTECTED] > 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]
Bug#248110: marked as done (installation-reports: Sarge netinst beta-4 on Sony Vaio PCG-GRX690)
Your message dated Mon, 9 Oct 2006 22:03:43 +0900 with message-id <[EMAIL PROTECTED]> and subject line I am happy with beta 3 release 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-reports Debian-installer-version: sarge-i386-netinst.iso 2004-05-02 03:00 (Beta-4) uname -a: linux goofy 2.4.25-1-386 #2 Wed Apr 14 19:38:08 EST 2004 i686 unknown Date: Sun, 08 May 2004 Method: Tried both linux and linux26 = No major unexpected hardware issues. Just some issues on usability. Key points: (1) 2.6 kernel needs to be upgraded to 2.6.5 series for Sony Vaio. (2) grub install location needs kinder explanation. (Very important) (3) The query in "Time zone configuration" is confusing (important) (4) Password setup query typo. (minor) (Extra) How do I capture boot screen? I foregot it... :-( Details: (1) 2.6 kernel needs to be upgraded to 2.6.5 series. Since the kernel experiences panic with older 2.6 kernel but I found the latest 2.6.5 one seems to work OK, why not update kernel on sarge-i386-netinst.iso. (Old ones were crashing system on my gradually upgraded sid one in /dev/hda5.) (2) grub install location needs kinder explanation. When installing GRUB boot loader on a hard disk, it asks something like: "The device can be specified GRUB's "(hdn)" notation..." while input box has "(hd0)" in it. This is surely intimidating phrases. More verbose phrase or button to HELP screen are needed here since this is the critical action. For example, addition of few lines will makes it much clearer and less intimidating: The device can be specified HURD's "(hdn)" notation or Linux's "/dev/hdx". For example: (hd0) or /dev/hda -- MBR of the 1st IDE disk (hd0,3) or /dev/hda4 -- 4th primary partition of the 1st IDE disk (hd1,4) or /dev/hdb5 -- 1st logical partition of the 2nd IDE disk (I think skipping devfs names are OK. Also SCSI can be skipped since those who dare to use SCSI should read the manual.) Also adding some pointer for how to update GRUB information will be a good idea. (3) The query in "Time zone configuration" is confusing The nuance of "system time" varies depending on program or documentation causing some confusion (/etc/default/rcS and "man hwclock"). (At least to me since woody) Also you may have BIOS time set previously for Windows but you may want to use UTC for BIOS time after installing Linux. Why not change this "Time zone configuration" query something along following: Unix system time (GMT) is set during the boot process from the hardware (BIOS) clock (configured by /etc/default/rcS). Although it is recommended to set this hardware clock to GMT for Linux-only system, Other OS such as windows will require you to set hardware clock to the localtime for compatibility. Your hardware clock currently indicates ??. (You can adjust this hardware clock time value from BIOS or from Linux with hwclock command later.) Will the system time set from the hardware clock assuming it is GMT? (If no, it will assume it to be the localtime.) <*No*> I think /etc/default/rcS entry should be ===NOW=== # Set UTC=yes if your system clock is set to UTC (GMT), and UTC=no if # not. ===CORRECT=== # Set UTC=yes if your system clock is set during boot process by # assuming the hardware (BIOS) clock being calibrated as UTC (GMT), # and UTC=no if not. (4) Password setup query typo. The query of "Password setup" has two practically identical lines. (one with "the", the other with "a"). These are redundant. Configuration information: Machine: Sony Vaio PCG-GRX690 (P4+ATI radeon mobility 7500) Processor: P4 Memory: 512MB Root Device: IDE on /dev/hda and installed system into /dev/hda9 (5GB) Root Size/partition table: Manual using previous one. Disk /dev/hda: 60.0 GB, 60011642880 bytes 16 heads, 63 sectors/track, 116280 cylinders Units = cylinders of 1008 * 512 = 516096 bytes Device Boot Start End Blocks Id System /dev/hda1 1 3107915663343+ 7 HPFS/NTFS /dev/hda2 31079 11628042941714f W95 Ext'd (LBA) /dev/hda5 31079 6156715366141 83 Linux /dev/hda6 61567 65631 2048256 82 Linux swap /dev/hda7 65631 75337 4891761 83 Linux /d
Bug#251898: (no subject)
submitter 251898 [EMAIL PROTECTED] thanks Wolfgang, I cannot imagine how partman would hang due to the resync of RAIDs. Can you please try to reproduce this problem? -- .''`. martin f. krafft <[EMAIL PROTECTED]> : :' : proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck - http://debiansystem.info `- Debian - when you have better things to do than fixing systems "in any hierarchy, each individual rises to his own level of incompetence, and then remains there." -- murphy (after dr. laurence j. peter) signature.asc Description: Digital signature (GPG/PGP)
Bug#267168: cdrom-detect: How about changing to wishlist bugs
Package: cdrom-detect
Version: 1.17
Followup-For: Bug #267168
This bug and its friends which are still there as nomal bugs are now
almost finished for me in etch beta 3 release.
I am taliking:
#247960, #258316, #259264, #262140, #265636, #267168, #314163
Also, the following bug may be merged to above list.
#284455
I think these can be changed to a single wishlist bug for documentation
request to mention faulty CDROM hardware issue now. If you document
this, this closes half the normal bugs for this package :-)
Wishlist content:
In "Chapter 5.3 Troubleshooting the Installation Process" right after
"5.3.1. Floppy Disk Reliability", I sugest to include following
| 5.3.2. CD-ROM Reliability
|
| In some older faulty CD-ROM drives, detecting and reading CD-ROM during
| the boot process may fail in various funny ways. This can be worked
| around simply by detecting CD-ROM again after the fasilure incident.
I also attach a patch which clean code around this failed CD-ROM detect
situation. This removes my old workaround and always use "fail"
function with "unmount" in it under "exit 1" situation for cleaner
consistency. I also think failing soon when manual detection failed is
the better way than looping to execute autodetection again. (untested
patch).
Here is the background and explanation:
Essentially, the issue was how to work around faulty hardware which
kernel has diffuculty handling by itself. After you have implimented
if [ -z "$suite" ]
test in this program, there is no bug by this program from my
perspective.
All we need to do is restart instaler from cdrom-detect phase.
Bad hardware should suffer a bit. So what :-)
Let me review previous history by my vague memory and explain what I am
talking.
When trying to install to a machine with old CD-ROM drive on my old DELL
machine and others, CDROM mounts fails in many funny ways.
The first trial of working around this isuue was retry mounting.
Then with newer kernel, it seems the mounting itself happens after
several kernel error messages but no error from mount command. The
mounted contents of CD-ROM are not right. I mean that symlinks shows up
as zero length normal files. This cause read failure in the
for distlink in stable testing unstable
loop as expected. This leaves $suite unset.
Since there is unmount before fail there now, we can rerun cdrom-detect
without problem. That was headiache in RC1 days.
If this patch is too intrusive to your taste, please do not apply this
now. Since SVN repo and 1.17 seems to be the same or just white space
difference, I made patch from unstable source.
I have not tested this patch with actual installer. I attach here only
to indicate my point and wishing this be considered at least for the
post-etch release. This patch is at least more current to SVN version
than the old ones on BTS.
I hope this helps.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable'), (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-1-686
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
--
~\^o^/~~~ ~\^.^/~~~ ~\^*^/~~~ ~\^_^/~~~ ~\^+^/~~~ ~\^:^/~~~ ~\^v^/~~~ +
Osamu Aoki <[EMAIL PROTECTED]> Yokohama Japan, GPG-key: A8061F32
.''`. Debian Reference: post-installation user's guide for non-developers
: :' : http://qref.sf.net and http://people.debian.org/~osamu
`. `' "Our Priorities are Our Users and Free Software" --- Social Contract
--- cdrom-detect.postinst.orig 2006-10-09 19:31:46.0 +0900
+++ cdrom-detect.postinst 2006-10-09 21:46:37.0 +0900
@@ -10,6 +10,8 @@
fail () {
log "CDROM-detect failed."
+ log "Unmounting CD just to be sure."
+ umount /cdrom 2>/dev/null || true
exit 1
}
@@ -38,21 +40,6 @@
mounted=1
db_set cdrom-detect/cdrom_device $device
break
- else
- log "CDROM-mount failed (error=$?): device=$device"
- log "Unmounting CD just to be sure."
- umount /cdrom 2>/dev/null || true
- log "Trying it again."
- if mount -t iso9660 -o ro,exec $device /cdrom; then
- log "CDROM-mount succeeded: device=$device"
- mounted=1
- db_set cdrom-detect/cdrom_device $device
- break
- else
- log "CDROM-mount failed again (error=$?):
device=$device"
- log "Unmounting CD just to be sure and giving
it up."
- umount /cdrom 2>/dev/null || true
- fi
fi
done
@@ -66,6 +53,8 @@
db_go
db_get cdrom-detect/retry
if
Default kernel image after dist-upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everybody, I've recently experienced a machine hang [1] after a kernel upgrade by dist-upgrade. Is there a way to make debian not to install as default image in lilo/ silo the new kernel image when you make a dist-upgrade? It would be nice if debian will wait for confirmation when stuff like that are performed. Regards, Ric [1] http://lists.debian.org/debian-sparc/2006/10/msg00035.html - - Riccardo Tortorici - Linux Registered User #365170 Count yourself @ http://counter.li.org/ ! - -- Encrypted Mails Welcome GPG key: 0xF3FCE306 available on wwwkeys.pgp.net GPG key fingerprint = C1C4 CA17 5135 8F5C 94C2 3347 4A22 67DB F3FC E306 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFFKirASiJn2/P84wYRAnm0AJ4nG5mzOIxFJYtMtHo58HlgEgmdPQCfT4wa 1Drlpzb8her40pzpmdiRPDc= =Gw/q -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#391879: INTL:de typo in german translation
Package: debian-installer Severity: minor Tags: l10n Hi, today I installed Debian Etch on a friends workstation, in german. First of all congratulations, you really do a good job and I like the new installer. I just wanted to report a little typo in it, on the list where you can select the task of a harddisk (filesystem or lvm-volume, crypto-volume etc.), is written "Physikalisches Volume fuer Verschluesselung" where you should just s/Volume/Volumen/, this is also wrong in 2 other list elements. Regards -- .''`. Mario Iseli <[EMAIL PROTECTED]> : :' :proud user of Debian unstable `. `'` `- Debian - when you have better things to do than fixing a system -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
