Bug#393116: problem with network card
Package: debian-testing-i386-netinst.iso Boot method: CD Image version: 14-10-2006 from www.debian.orgDate: 14-10-2006 Machine: Clone Pc: MB Asus P5LD2-SE Processor: Intel Dual Core 3,4 GHZ Memory: 1Gb Partitions: I have not been able them to create, i have 2 partition of NTFS and 50Gb of free space, to install GNU/Debian Output of lspci and lspci -n: Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot worked: [O] Configure network HW: [E] Config network: [ ] Detect CD: [ ] Load installer modules : [ ] Detect hard drives: [ ] Partition hard drives: [ ] Create file systems:[ ] Mount partitions: [ ] Install base system: [ ] Install boot loader: [ ] Reboot: [ ] Comments/Problems: it does not recognize the network card, is an "on board card", type Realtek RTL8168 / 8111 PCI-E Gigabit NIC more information in ASUS web: http://www.asus.com/products4.aspx?l1=3&l2=11&l3=185&model=1022&modelmenu=1
Processed: Re: Bug#393116: problem with network card
Processing commands for [EMAIL PROTECTED]: > reassign 393116 installation-reports Bug#393116: problem with network card Warning: Unknown package 'debian-testing-i386-netinst.iso' Bug reassigned from package `debian-testing-i386-netinst.iso' 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: Erratic, unusable mouse behaviour in g-i
On Saturday 14 October 2006 20:29, Joel Johnson wrote: > Indeed, using the most recent daily built installer works just fine > with the mouse (Logitech MX1000). Bug#384543 can in all likelihood also > be closed. That is great; thanks for confirming. I've also requested the submitter of #384543 to try again, but I expect you are right. Will wait to hear from him a bit before closing the bug. Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#152152: FWD: roger philhower Please do not come to work today
Good Morning roger philhower, Learn how to make 1.5 - 3.5k daily from your home. 888.701.3877 Contact me at my number if you can return calls. Thanks, Darren Hilton -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#393179: [l10n]: bad french translation in two screen titles
Package: installation-reports Version: 2.20 Severity: minor Tags: l10n Hi, I installed Etch beta3 in french with the "install" method (not installgui). I found two bad french translations: * "Choose language" screen: - the title is not translated in french. * "Select a keyboard layout" screen: - the french trranslated title is too long, the two last caracters are not showed (Sarge installer have also the same bug). Florentin Duneau -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#393179: [l10n]: bad french translation in two screen titles
> I installed Etch beta3 in french with the "install" method (not > installgui). > > I found two bad french translations: > > * "Choose language" screen: > - the title is not translated in french. That is somewhat impossible to achieve. By debconf construction, dialog window titles are set at the beginning of the postinst script that is run. When you run localechooser for the first time, the language is not set yet and, obviously, the title is the package description in English. When you run it a second time, the dialog title is really "Choisir la langue / Choose language" (keeping English is on purpose in case someone chooses the wrong language by mistake). > > * "Select a keyboard layout" screen: > - the french trranslated title is too long, the two last caracters are >not showed (Sarge installer have also the same bug). This has been corrected since beta3 (this was not a bug in the translation, this was a bug in the debcofn backend). signature.asc Description: Digital signature
RFC: Possible (partial) solution for device persistence issue
I have written a very simple (or at least small) script intended to be run during finish-install that converts devices listed in /target/etc/fstab from regular device names to uuids (as far as possible). Although this is not a perfect solution, I feel it is an acceptable solution for Etch. By doing this at the very end of the installation, there is no chance that we break anything in the installer itself, while still making the fstab less vulnerable to changes in the device order. The script relies on the fact that the kernel currently also generates "normal" device names for disks. It is only a partial solution as the set up of the boot loader (especially the definition of the root partition) may still be wrong. I've tested this successfully on a LVM setup. The attached fstab is from that install. Comments welcome. Cheers, FJP P.S. IIRC someone once sent a similar script to the list, but I was unable to find it :-( From what I remember, the script was more complex. Not sure if that means I'm missing a lot... 40fstab_hd_entries Description: application/shellscript # /etc/fstab: static file system information. # # proc/proc procdefaults0 0 # /dev/mapper/Debian-root UUID=54eb0e28-f41b-486b-9b47-2e8d484e9417 / ext3 defaults,errors=remount-ro 0 1 # /dev/sda1 UUID=297e4922-7842-4dd2-9f56-09581968bc64 /boot ext3defaults 0 2 /dev/mapper/Debian-swap_1 noneswapsw 0 0 /dev/hdc/media/cdrom0 udf,iso9660 user,noauto 0 0 /dev/fd0/media/floppy0 autorw,user,noauto 0 0 pgpMQBQY6EKl4.pgp Description: PGP signature
Re: Verification of installation-guide-i386 docs regarding alternative installation method
Op 14-10-2006 om 17:56 schreef Wiktor Wandachowicz: > Dear maintainers, > > Recently I've been playing with alternative Ubuntu installation method > without official installation media (https://launchpad.net/bugs/64765). > During my experiments I've found that several steps in the installation > guide are misleading or lead to an error. > > However, I thought about trying to repeat a similar procedure with Debian > Etch to make sure that everone could benefit from my efforts (not only > Ubuntu). This method of installation is referenced as: > > "D.3. Installing Debian GNU/Linux from a Unix/Linux System" [1] > > I would like to ask you if there is interest in verifying installation > steps as described in the installation guide and updating the docs if > problems could be found? Has anybody tested this method recently and > can assist me with my efforts? I'm really willing to do the testing > and contribute my work to the Debian community. > As I understand the E-mail is the question: | Who cares if installation manual is verified? The answer is: Yes, we are interrested in feedback. Geert Stappers in an attempt to say "Go ahead, do the things that you think that are good." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Verification of installation-guide-i386 docs regarding alternative installation method
Op 15-10-2006 om 19:55 schreef Geert Stappers: > Op 14-10-2006 om 17:56 schreef Wiktor Wandachowicz: > > Dear maintainers, > > [ ubuntu reviewed ] > > > > However, I thought about trying to repeat a similar procedure with Debian > > Etch to make sure that everone could benefit from my efforts (not only > > Ubuntu). This method of installation is referenced as: > > > > "D.3. Installing Debian GNU/Linux from a Unix/Linux System" [1] > > > > I would like to ask you if there is interest in verifying installation > > steps as described in the installation guide and updating the docs if > > problems could be found? Has anybody tested this method recently and > > can assist me with my efforts? I'm really willing to do the testing > > and contribute my work to the Debian community. > > > > As I understand the E-mail is the question: > > | Who cares if installation manual is verified? > > > The answer is: > > Yes, we are interrested in feedback. > > > > Geert Stappers > in an attempt to say >"Go ahead, do the things that you think that are good." > > > [1] > > http://ftp.us.debian.org/debian/pool/main/i/installation-guide/installation-guide-i386_20060726_all.deb I forget to ask to review recent versions. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFC: Possible (partial) solution for device persistence issue
Op 15-10-2006 om 19:06 schreef Frans Pop: > I have written a very simple (or at least small) script intended to be run > during finish-install that converts devices listed in /target/etc/fstab > from regular device names to uuids (as far as possible). > > Although this is not a perfect solution, I feel it is an acceptable > solution for Etch. > By doing this at the very end of the installation, there is no chance that > we break anything in the installer itself, while still making the fstab > less vulnerable to changes in the device order. > The script relies on the fact that the kernel currently also generates > "normal" device names for disks. > > It is only a partial solution as the set up of the boot loader (especially > the definition of the root partition) may still be wrong. > > I've tested this successfully on a LVM setup. The attached fstab is from > that install. > > Comments welcome. > > Cheers, > FJP > > # /etc/fstab: static file system information. > # > # > proc/proc procdefaults0 0 > # /dev/mapper/Debian-root > UUID=54eb0e28-f41b-486b-9b47-2e8d484e9417 / ext3 > defaults,errors=remount-ro 0 1 > # /dev/sda1 > UUID=297e4922-7842-4dd2-9f56-09581968bc64 /boot ext3defaults > 0 2 > /dev/mapper/Debian-swap_1 noneswapsw 0 0 > /dev/hdc/media/cdrom0 udf,iso9660 user,noauto 0 0 > /dev/fd0/media/floppy0 autorw,user,noauto 0 0 I'm not happy with /etc/fstab like that. The comments like '/dev/mapper/Debian-root' and '/dev/sda1' are fine, but I'm really unhappy with the entries that start with 'UUID='. I also have the unpleasent feeling that "fixing" device persistence by forcing persistence by UUID usage is solving a wrong described problem. The thing I would like to see is that the _difference_ in device naming between d-i kernel plus fellows and installed kernel plus fellows is solved. Infact I don't understand why device naming does differ. AFAIK are the d-i kernel and the installed kernel from the same build. That d-i uses different tools (busybox, libc?) then installed kernel, will have it good reason. But it is no reason that devices naming differs ... Cheers Geert Stappers -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Recommend to tag #380226 "etch-ignore"; #379835 downgraded to important
On Thursday 12 October 2006 07:59, Frans Pop wrote: > I have today uploaded a version of partman-partitioning that includes a > check for NTFS 3.1 partitions and refuses to resize in that case; > earlier NTFS partitions (NT, XP, 2000) should still be resizable. > As partman is now "safe" I am downgrading #379835 to important. FYI After the report that Windows XP also uses NTFS 3.1, I have expanded the check I've used and it should now be possible again to resize XP partitions using the installer. Vista partitions are still blocked. Note that this means that only a partitions holding Vista itself is blocked, not any separate NTFS data partitions... An possible additional check would be to see if the partition is correctly alligned on a cylinder, but programming that is beyond me ATM. Cheers, FJP pgpdNmFEML7Af.pgp Description: PGP signature
Re: RFC: Possible (partial) solution for device persistence issue
15 жовтня 2006 о 23:45 +0200 Geert Stappers написав(-ла): > Infact I don't understand why device naming does differ. AFAIK are the > d-i kernel and the installed kernel from the same build. That d-i uses > different tools (busybox, libc?) then installed kernel, will have it > good reason. But it is no reason that devices naming differs ... > Probably because drivers are loaded in different order, this can also happen on the installed system without any change to libraries or tools. And with current changes to the kernel (parallel probing of devices) that will happen more an more often (but it may be fixed in similar way as for network interfaces, see /etc/udev/persistent-net-generator.rules). -- Eugeniy Meshcheryakov signature.asc Description: Digital signature
Re: RFC: Possible (partial) solution for device persistence issue
On Sunday 15 October 2006 23:45, Geert Stappers wrote: > The thing I would like to see is that the _difference_ in device naming > between d-i kernel plus fellows and installed kernel plus fellows is > solved. See the discussions that we have had about this in the past. The culprit is the kernel/udev: that can load drivers in a different order any time. It is not something we can solve in the installer. The experts have said that using uuid is the best solution. I agree that it is extremely ugly. pgp85eGOBMDZ0.pgp Description: PGP signature
kernel-wedge 2.28 MIGRATED to testing
FYI: The status of the kernel-wedge source package in Debian's testing distribution has changed. Previous version: 2.26 Current version: 2.28 -- This email is automatically generated; [EMAIL PROTECTED] is responsible. See http://people.debian.org/~henning/trille/ for more information. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
tasksel 2.56 MIGRATED to testing
FYI: The status of the tasksel source package in Debian's testing distribution has changed. Previous version: 2.54 Current version: 2.56 -- This email is automatically generated; [EMAIL PROTECTED] is responsible. See http://people.debian.org/~henning/trille/ for more information. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#381244: Bug 381244: suggested patch
I've attached a patch which should implement the proposed solution.
--
David Härdeman
Index: debian/partman-auto-lvm.templates
===
--- debian/partman-auto-lvm.templates (revision 41740)
+++ debian/partman-auto-lvm.templates (working copy)
@@ -5,7 +5,7 @@
Template: partman-auto-lvm/new_vg_name
Type: string
-Default: Debian
+Default: ${DEFAULT}
_Description: Name of the volume group for the new system:
Template: partman-auto-lvm/new_vg_name_exists
Index: debian/changelog
===
--- debian/changelog(revision 41740)
+++ debian/changelog(working copy)
@@ -1,3 +1,10 @@
+partman-auto-lvm (18) UNRELEASED; urgency=low
+
+ * Use hostname as the default vg name, fall back to Debian if not set.
+Closes: #381244.
+
+ -- David Härdeman <[EMAIL PROTECTED]> Mon, 16 Oct 2006 00:15:23 +0200
+
partman-auto-lvm (17) unstable; urgency=low
* Display selected target for partitioning when choosing a recipe.
Index: auto-lvm_tools.sh
===
--- auto-lvm_tools.sh (revision 41740)
+++ auto-lvm_tools.sh (working copy)
@@ -103,6 +103,17 @@
}
auto_lvm_perform() {
+ # Set the default vg name to use,
+ # try hostname and fall back to "Debian"
+ local defvgname
+ if [ -r /etc/hostname ]; then
+ defvgname=$(cat /etc/hostname)
+ fi
+ if [ -z "$defvgname" ]; then
+ defvgname="Debian"
+ fi
+ db_subst partman-auto-lvm/new_vg_name DEFAULT "$defvgname"
+
# Choose name, create VG and attach each partition as a physical volume
noninteractive=true
while true; do
Bug#392897: ntfsresize error is ignored, confusing the user
severity 392897 minor retitle 392897 Error handling for resize operations needs improvement thanks On Saturday 14 October 2006 06:00, Carl Fink wrote: > I suspect you don't have a routine to trap that particular error > message, so it just gets ignored. It should instead be passed along to > the user, because it's important. Thanks for your report. Yes, that was not being handled very gracefully, although the output from ntfsresize can be checked in the syslog. I've improved the error checking a bit and those changes will be available in daily images within the next few days. The user should now at least get a red screen with a message that resizing is not possible and will be pointed to the syslog. There should also be a better distinction between different causes of errors. Error checking for resize operations in general could be improved a lot; for many operations it is currently just assumed they will succeed. Cheers, FJP pgp7vXU4OaqCq.pgp Description: PGP signature
Processing of partman-partitioning_43_i386.changes
partman-partitioning_43_i386.changes uploaded successfully to localhost along with the files: partman-partitioning_43.dsc partman-partitioning_43.tar.gz partman-partitioning_43_i386.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: Re: Bug#392897: ntfsresize error is ignored, confusing the user
Processing commands for [EMAIL PROTECTED]: > severity 392897 minor Bug#392897: ntfsresize error is ignored, confusing the user Severity set to `minor' from `important' > retitle 392897 Error handling for resize operations needs improvement Bug#392897: ntfsresize error is ignored, confusing the user 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]
partman-partitioning_43_i386.changes ACCEPTED
Accepted: partman-partitioning_43.dsc to pool/main/p/partman-partitioning/partman-partitioning_43.dsc partman-partitioning_43.tar.gz to pool/main/p/partman-partitioning/partman-partitioning_43.tar.gz partman-partitioning_43_i386.udeb to pool/main/p/partman-partitioning/partman-partitioning_43_i386.udeb Override entries for your package: partman-partitioning_43.dsc - source debian-installer partman-partitioning_43_i386.udeb - optional debian-installer 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]
Re: powermac fan control modules detection ...
Ccing debian-kernel for maks, and debian-boot for Frans, or whoever will commit my patches. On Mon, Oct 16, 2006 at 08:59:43AM +1000, Benjamin Herrenschmidt wrote: > On Sun, 2006-10-15 at 12:16 +0200, Sven Luther wrote: > > Hi, ... > > > > I am working at integrating fan control into d-i and initramfs-tools. > > > > For this, we currently use the following list of modules : > > > > /lib/modules/2.6.17-2-powerpc64/kernel/drivers/macintosh/therm_pm72.ko > > /lib/modules/2.6.17-2-powerpc64/kernel/drivers/macintosh/windfarm_core.ko > > > > /lib/modules/2.6.17-2-powerpc64/kernel/drivers/macintosh/windfarm_cpufreq_clamp.ko > > > > /lib/modules/2.6.17-2-powerpc64/kernel/drivers/macintosh/windfarm_lm75_sensor.ko > > > > /lib/modules/2.6.17-2-powerpc64/kernel/drivers/macintosh/windfarm_max6690_sensor.ko > > /lib/modules/2.6.17-2-powerpc64/kernel/drivers/macintosh/windfarm_pid.ko > > /lib/modules/2.6.17-2-powerpc64/kernel/drivers/macintosh/windfarm_pm112.ko > > /lib/modules/2.6.17-2-powerpc64/kernel/drivers/macintosh/windfarm_pm81.ko > > /lib/modules/2.6.17-2-powerpc64/kernel/drivers/macintosh/windfarm_pm91.ko > > > > /lib/modules/2.6.17-2-powerpc64/kernel/drivers/macintosh/windfarm_smu_controls.ko > > > > /lib/modules/2.6.17-2-powerpc64/kernel/drivers/macintosh/windfarm_smu_sat.ko > > > > /lib/modules/2.6.17-2-powerpc64/kernel/drivers/macintosh/windfarm_smu_sensors.ko > > /lib/modules/2.6.17-2-powerpc64/kernel/drivers/i2c/busses/i2c-powermac.ko > > > > I wonder if anyone is missing. > > > > Benh, am i right in thinking that those modules are only needed for 64bit > > powermac hardware ? > > i2c-powermac.ko is also useful for various other things on 32 bits. All > the other ones in your list are indeed 64 bits only. Ok. I also saw there where two such modules existing in the 32bit case. I get : $ ls /lib/modules/2.6.17-2-powerpc/kernel/drivers/macintosh/ ans-lcd.ko apm_emu.ko therm_adt746x.ko therm_windtunnel.ko windfarm_core.ko Does windfarm_core make sense to build on 32bit ? I suppose we can load adt746x and windtunnel, what about the other two ? > You also need to make sure cpufreq_64 is enabled for them to work. So, i should add some of the below modules : /lib/modules/2.6.17-2-powerpc64/kernel/drivers/cpufreq/cpufreq_conservative.ko /lib/modules/2.6.17-2-powerpc64/kernel/drivers/cpufreq/cpufreq_ondemand.ko /lib/modules/2.6.17-2-powerpc64/kernel/drivers/cpufreq/cpufreq_powersave.ko /lib/modules/2.6.17-2-powerpc64/kernel/drivers/cpufreq/cpufreq_stats.ko /lib/modules/2.6.17-2-powerpc64/kernel/drivers/cpufreq/cpufreq_userspace.ko And also load them ? Maybe write something to /sys/.../cpufreq too. > > Also, i wonder if there is some way for detecting which machine needs which > > module ? Some /proc/device-tree parsing ? Or maybe simply a /proc/cpuinfo > > model matrix ? > > i2c-powermac.ko : should pretty much be built-in Well, it is not all that needed on IBM or genesi hardware for example. > Then, it depends on the machine. The "main" modules tend to auto-load > the other ones, but there is a bug where it misses > windfarm_cpufreq_clamp. and windfarm_pm112 blatantly "forgets" to > autoload anything. So the rule is: > > Machine type: > > - PowerMac7,2, PowerMac7,3, RackMac3,1: therm_pm72 > > - PowerMac8,1, PowerMac8,2: windfarm_pm81 + windfarm_cpufreq_clamp > > - PowerMac9,1: windfarm_pm91 + windfarm_cpufreq_clamp > > - PowerMac11,2: windfarm_pm112 + windfarm_cpufreq_clamp + > windfarm_smu_sat + windfarm_smu_sensors + windfarm_smu_controls + > windfarm_max6690_sensor.ko + windfarm_lm75_sensor.ko > > - PowerMac12,1: (iMac G5 + iSight, I welcome > somebody in australia giving me hardware access to one for a week or two > to fix that). > > I'll do some patches to fix autoloading of sub-modules so that only the > "main" one is needed. Ok, but in the meantime, we will work from the above list. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Processed: merge 392897 375546
Processing commands for [EMAIL PROTECTED]: > forcemerge 392897 375546 Bug#392897: Error handling for resize operations needs improvement Bug#375546: partman-partitioning: failure to resize partitions should provide more informative error messages Forcibly Merged 375546 392897. > End of message, 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]
Hola
Hola, no se si me recuerdas ... espero noticias tuyas saludos, bye -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
