Re: boot parameter interface=auto can't adaptation the correct NIC
I've suffered the same issue in some netcards (nexcom and portwell HW).
The usleep of netcfg.c is not enought to up the interface and detect the
link up in auto mode (buggy driver or buggy hardware?? :-/).
In my case the sleep goes to some seconds (4-5 secs.).
BR
2010/12/13 Floris Bos i...@je-eigen-domein.nl
Hi,
On Monday, December 13, 2010 04:15:46 am Qin Bo wrote:
2010/12/10 Lennart Sorensen lsore...@csclub.uwaterloo.ca
Is this another case of a driver/NIC taking longer to get link up after
being enabled than the installer is willing to wait? I seem to recall
a bnx2 user a few days ago reporting a similar problem.
How can i find the bnx2 problem? I had set netcfg/dhcp_timeout=60 as
boot
parameter, the problem still reproduce.
But I still think the netcfg didn't got the correct interface, then
couldn't get the IP address from dhcp server.
Because I had read the netcfg source:netcfg.c netcfg-common.c, i can't
find
where the program deal with interface=auto.
You need netcfg/choose_interface=auto
As far as the detection goes, it is this part in netcfg.c:
==
interface_up(*ifaces);
usleep(250);
if (ethtool_lite (*ifaces) == 1) /* CONNECTED */ {
di_info(found link on interface %s, making it the
default., *ifaces);
defiface = strdup(*ifaces);
interface_down(*ifaces);
break;
} else {
#ifdef WIRELESS
struct wireless_config wc;
#endif /* WIRELESS */
di_info(found no link on interface %s., *ifaces);
==
A 250 us delay is kinda short.
It takes 3 seconds for the link of my test box to get up.
(on-board Intel 82574L NIC, connected to a HP 1810G gigabit switch).
--
Yours sincerely,
Floris Bos
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
Archive:
http://lists.debian.org/201012130441.46315.i...@je-eigen-domein.nl
Bug#606396: installation-reports: Squeeze Beta1 on Apple iBook G4 (powerpc)
Andrzej P, le Wed 08 Dec 2010 21:41:16 +, a écrit : I used the default single partition setup suggested by 'partman'. I assume that the suggested partitioning is correct. I was puzzled however that the suggested scheme includes a 2.5 GB swap space since the Installation Manual states On 32-bit architectures (i386, m68k, 32-bit SPARC, and PowerPC), the maximum size of a swap partition is 2GB. [C.3. Recommended Partitioning Scheme]. Is this no longer true? On i386 it's no longer true. I'm not sure for sparc and powerpc, but I'd tend to think the same. Porters? On sparc there is a restriction which applies to older machines. If the disk was originally formatted on a machine with an old version of the OBP it will have a disk label which cannot support slices larger than 2Gb. If you try to create any slice (not just swap) larger than 2Gb on such a disk only the first 2Gb will be readable. This is normally only a problem if you try to put a large disk into into a very old 32 bit machine or move a disk between old and newer machines. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/a06ba1ed94e8da51693a4707c9afe60a.squir...@webmail.gradwell.com
Bug#606396: installation-reports: Squeeze Beta1 on Apple iBook G4 (powerpc)
c...@pop3.netunix.com, le Mon 13 Dec 2010 12:06:30 -, a écrit : On sparc there is a restriction which applies to older machines. If the disk was originally formatted on a machine with an old version of the OBP it will have a disk label which cannot support slices larger than 2Gb. If you try to create any slice (not just swap) larger than 2Gb on such a disk only the first 2Gb will be readable. Ok, but that's actually a partitioning limitation, not a swap limitation, right? (e.g. if I assemble several partitions in something like an lvm, 2GB swap should be possible) This is normally only a problem if you try to put a large disk into into a very old 32 bit machine or move a disk between old and newer machines. Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101213124210.gp5...@const.bordeaux.inria.fr
Re: Bug#606952: lilo: conflicts with grub[-pc]
Michael Prokop m...@debian.org wrote on 2010-12-13 11:11: Now version 1:22.8-9 introduces: Conflicts: grub-legacy, grub-pc I don't see any reason why this should be enforced, actually this avoids deployments of systems where users can choose between lilo and grub as bootloader as both can't be distributed at the same time with the conflicts mentioned above. To manage newer kernel in Debian the system need hook scripts for kernel and initrd which can be found in /etc/kernel and /etc/initramfs/. These hook scripts will always be executed after kernel update or initrd update. If more then one bootloader is installed, each bootloader (say: grub- legacy, grub-pc or others) will try to install his code into MBR while kernel or initrd will be updated. This is not usefull. IMO this is a bug that shouldn't reach squeeze, therefore choosing severity serious. I think these defined Conflicts does not break the regular functionality of a Debian system, but provide clarification, which bootloader make the work. So the severity should be minor. I have CCed to debian-boot, perhaps there is someone who have more arguments. Have a nice day, Joachim (Germany) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101213160004.36adb...@jupiter.home
Bug#606973: Installation was successfull at Asus Notebook
Package: installation-reports Boot method: USB hostpowered DVD Image version: Self-made boot-cd with actual squeeze installer Date: 12.12.2010 Machine: ASUS Notebook Z7750 Processor: Pentium M 1,6GHz Memory: 512MB Partitions: Dateisystem Typ1K‐Blöcke Benutzt Verfügbar Ben% Eingehängt auf /dev/sda1 ext4 9611492 4376988 4746264 48% / tmpfstmpfs 256968 0256968 0% /lib/init/rw udev tmpfs 252580 208252372 1% /dev tmpfstmpfs 25696888256880 1% /dev/shm /dev/sda6 ext446588296 30707488 13514244 70% /home Output of lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 82855PM Processor to I/O Controller [8086:3340] (rev 21) Subsystem: ASUSTeK Computer Inc. Device [1043:186a] Kernel driver in use: agpgart-intel 00:01.0 PCI bridge [0604]: Intel Corporation 82855PM Processor to AGP Controller [8086:3341] (rev 21) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [8086:24c2] (rev 03) Subsystem: ASUSTeK Computer Inc. Device [1043:1869] Kernel driver in use: uhci_hcd 00:1d.1 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [8086:24c4] (rev 03) Subsystem: ASUSTeK Computer Inc. Device [1043:1869] Kernel driver in use: uhci_hcd 00:1d.2 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [8086:24c7] (rev 03) Subsystem: ASUSTeK Computer Inc. Device [1043:1869] Kernel driver in use: uhci_hcd 00:1d.7 USB Controller [0c03]: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller [8086:24cd] (rev 03) Subsystem: ASUSTeK Computer Inc. Device [1043:1868] Kernel driver in use: ehci_hcd 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 83) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge [8086:24cc] (rev 03) 00:1f.1 IDE interface [0101]: Intel Corporation 82801DBM (ICH4-M) IDE Controller [8086:24ca] (rev 03) Subsystem: ASUSTeK Computer Inc. Device [1043:1869] Kernel driver in use: ata_piix 00:1f.3 SMBus [0c05]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller [8086:24c3] (rev 03) Subsystem: ASUSTeK Computer Inc. Device [1043:1869] Kernel driver in use: i801_smbus 00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller [8086:24c5] (rev 03) Subsystem: ASUSTeK Computer Inc. M6800N [1043:1713] Kernel driver in use: Intel ICH 00:1f.6 Modem [0703]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller [8086:24c6] (rev 03) Subsystem: ASUSTeK Computer Inc. M6800N [1043:1826] Kernel driver in use: Intel ICH Modem 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] [1002:4e50] Subsystem: ASUSTeK Computer Inc. Device [1043:1772] Kernel driver in use: radeon 02:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5788 Gigabit Ethernet [14e4:169c] (rev 03) Subsystem: ASUSTeK Computer Inc. Device [1043:1735] Kernel driver in use: tg3 02:01.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev ac) Subsystem: ASUSTeK Computer Inc. Device [1043:1864] Kernel driver in use: yenta_cardbus 02:01.1 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev ac) Subsystem: ASUSTeK Computer Inc. Device [1043:1864] Kernel driver in use: yenta_cardbus 02:01.2 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C552 IEEE 1394 Controller [1180:0552] (rev 04) Subsystem: ASUSTeK Computer Inc. Device [1043:1867] Kernel driver in use: firewire_ohci 02:02.0 Network controller [0280]: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection [8086:4220] (rev 05) Subsystem: Intel Corporation Device [8086:2701] Kernel driver in use: ipw2200 Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Clock/timezone setup: [O] User/password setup:[O] Install tasks: [O] Install boot loader:[O] Overall install:[O] Comments/Problems: No problems detected. Installation was successfully. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d063bf6.5030...@yahoo.de
Re: Bug#606952: lilo: conflicts with grub[-pc]
On Mon, Dec 13, 2010 at 04:00:04PM +0100, Joachim Wiedorn wrote: Michael Prokop m...@debian.org wrote on 2010-12-13 11:11: Now version 1:22.8-9 introduces: Conflicts: grub-legacy, grub-pc I don't see any reason why this should be enforced, actually this avoids deployments of systems where users can choose between lilo and grub as bootloader as both can't be distributed at the same time with the conflicts mentioned above. To manage newer kernel in Debian the system need hook scripts for kernel and initrd which can be found in /etc/kernel and /etc/initramfs/. These hook scripts will always be executed after kernel update or initrd update. If more then one bootloader is installed, each bootloader (say: grub- legacy, grub-pc or others) will try to install his code into MBR while kernel or initrd will be updated. This is not usefull. This is a misunderstanding of GRUB. /etc/kernel/*/zz-update-grub only updates /boot/grub/grub.cfg, and never touches the MBR. The only time the grub-pc package touches the MBR is when the grub-pc package itself is installed or upgraded, and even that can be turned off in debconf. -- Colin Watson [cjwat...@debian.org] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101213153926.ga4...@master.debian.org
Re: Bug#606952: lilo: conflicts with grub[-pc]
* Joachim Wiedorn ad_deb...@joonet.de [Mon Dec 13, 2010 at 04:00:04PM +0100]: Michael Prokop m...@debian.org wrote on 2010-12-13 11:11: Now version 1:22.8-9 introduces: Conflicts: grub-legacy, grub-pc I don't see any reason why this should be enforced, actually this avoids deployments of systems where users can choose between lilo and grub as bootloader as both can't be distributed at the same time with the conflicts mentioned above. To manage newer kernel in Debian the system need hook scripts for kernel and initrd which can be found in /etc/kernel and /etc/initramfs/. These hook scripts will always be executed after kernel update or initrd update. If more then one bootloader is installed, each bootloader (say: grub- legacy, grub-pc or others) will try to install his code into MBR while kernel or initrd will be updated. This is not usefull. update-grub just generates the grub.cfg, the lilo package doesn't execute lilo (and therefore doesn't touch MBR) as long as there's no /etc/lilo.conf. So both packages can and do co-exist. IMO this is a bug that shouldn't reach squeeze, therefore choosing severity serious. I think these defined Conflicts does not break the regular functionality of a Debian system, It breaks existing deployment environments. but provide clarification, which bootloader make the work. So the severity should be minor. Drop the conflicts in the lilo package and everything will continue to work as it used to? regards, -mika- signature.asc Description: Digital signature
Bug#606976: Kernel panic with Squeeze (AMD64) d-i beta 2
Package: installation-reports Boot method: CD and USB stick Image version: http://cdimage.debian.org/cdimage/squeeze_di_beta2/amd64/iso-cd/debian-squeeze-di-beta2-amd64-netinst.iso Date: Dec 13, 2010 Machine: Dell XPS 630i Processor: Core 2 Quad 2.4 GHz Memory: 4 GB Partitions: N/A Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [E ] Detect network card: [ ] Configure network: [ ] Detect CD: [ ] Load installer modules: [ ] Detect hard drives: [ ] Partition hard drives: [ ] Install base system: [ ] Clock/timezone setup: [ ] User/password setup: [ ] Install tasks: [ ] Install boot loader: [ ] Overall install: [E ] Comments/Problems: I've tried d-i beta 2 on Dell XPS 630i. I first tried creating a USB memory stick with the installer .iso on it (following a standard procedure); the install USB stick works on my other computer (Lenovo T410s). However, on 630i it always fails at the beginning of the install process. The message, when kernel panics, typically goes like this: ... (no apparent error messages thru this point) ... [0.597991] List of all partitions: [0.600310] No filesystem could mount root, tried: [0.602749] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,3) ... (call trace output after this) ... (This output is from an attempt to use CD install medium.) I have tried adding rootdelay=10 option for the kernel, without any effect. I have observed the same symptom with the netinst .iso burned on a blank CD. In fact, I have never been able to use d-i successfully on 630i (I've tried the same thing several months ago). Last time I installed Debian, I had to install off a Lenny install medium and then do dist-upgrade. Is there any way to get Squeeze d-i to work on this machine? Any help is appreciated. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktimoekuztsj-eeuhtc0ke-=wfk-tgabgr+rdj...@mail.gmail.com
archdetect as a .deb
The Ubuntu ARM folks have asked me to look into providing archdetect as a .deb, so that they can use it in some situations outside d-i as a single common way to name the current subarchitecture. This seems reasonable enough to me, and since libdebian-installer is already available as a .deb it wouldn't be very difficult to arrange. The main issue is naming: since .udebs and .debs share a common namespace, it can't just be archdetect.deb unless the .udeb is renamed (which seems likely to be awkward?). Does anyone have an idea what it should be called? archdetect-deb offends my sense of aesthetics ... Thanks, -- Colin Watson [cjwat...@ubuntu.com] -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101213153030.gk21...@riva.ucam.org
Bug#606981: unblock: kbd/1.15.2-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Hello -release and -boot,
Please approve (udeb) and unblock package kbd:
As discussed in #606186, users are currently asked for their keyboard
layout twice during the installation process; this is particularly
annoying considering that the second question, in general, has no effect
on the installed system.
A simple reordering of Depends: and Recommends: in console-tools and kbd
avoids this problem by preferring console-setup over console-data,
avoiding the latter altogether. It would be nice if this little fix
could make it into Squeeze.
I’ve also dared to add a one-line patch to fix an important regression
(#66).
unblock kbd/1.15.2-2
Thanks,
Michael
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (900, 'testing'), (600, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.30-2-686 (SMP w/2 CPU cores)
Locale: LANG=de_AT.utf8, LC_CTYPE=de_AT.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
--
Michael Schutte | mi...@{uiae.at,debian.org}
Innsbruck, Austria| happily accepting encrypted mail
OpenPGP: 0x16fb 517b a866 c3f6 8f11 1485 f3e4 122f 1D8C 261A
signature.asc
Description: Digital signature
Bug#606396: installation-reports: Squeeze Beta1 on Apple iBook G4 (powerpc)
On Mon, Dec 13, 2010 at 01:42:10PM +0100, Samuel Thibault wrote: c...@pop3.netunix.com, le Mon 13 Dec 2010 12:06:30 -, a écrit : On sparc there is a restriction which applies to older machines. If the disk was originally formatted on a machine with an old version of the OBP it will have a disk label which cannot support slices larger than 2Gb. If you try to create any slice (not just swap) larger than 2Gb on such a disk only the first 2Gb will be readable. Ok, but that's actually a partitioning limitation, not a swap limitation, right? (e.g. if I assemble several partitions in something like an lvm, 2GB swap should be possible) This is normally only a problem if you try to put a large disk into into a very old 32 bit machine or move a disk between old and newer machines. This limitation is mostly irrelevant because Debian only supports 64-bit UltraSPARC, so the only case we have to worry about is the disk from an older to a newer machine. As for the original question, I can't speak for sure, since I'm not a SPARC porter, but it only seems logical that a 64-bit kernel (which, again, is what they all are in Debian) will be able to address more than 2GiB of swap. -- brian m. carlson / brian with sandals: Houston, Texas, US +1 832 623 2791 | http://www.crustytoothpaste.net/~bmc | My opinion only OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187 signature.asc Description: Digital signature
Bug#605774: Bug also present in debian-squeeze-di-beta2-powerpc-netinst.iso
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Just to give the info, I have tested the debian-squeeze-di-beta2-powerpc-netinst.iso. The fix for bug#605774 didn't reach the last installer iso. xavier -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0GUYoACgkQVIZi0A5BZF4p1QCgsEypccXhU3rnSghUNxGeRFLX sM0AoKh3Dk54YQ2nLXzA8gG0hIoFhLY5 =6d1z -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d06518a.6060...@ipno.in2p3.fr
Re: Bug#606952: lilo: conflicts with grub[-pc]
Michael Prokop m...@debian.org wrote on 2010-12-13 16:36: update-grub just generates the grub.cfg, the lilo package doesn't execute lilo (and therefore doesn't touch MBR) as long as there's no /etc/lilo.conf. So both packages can and do co-exist. Thank for more information - and also thanks to Colin. I only see one problem if grub-pc and lilo is full configured and then the both hook scripts will be executed, e.g.: 1) /etc/kernel/postinst.d/zz-update-grub - update grub.cfg 2) /etc/kernel/postinst.d/zz-lilo - update MBR (for lilo) Result: lilo is the bootloader 3) the package grub-pc will be updated- update MBR (for grub) Result: grub is the bootloader Is this the result that the admin want? I don't know. It breaks existing deployment environments. What do you want to say here? Please give me a (short) example. Drop the conflicts in the lilo package and everything will continue to work as it used to? Yes, apart from the case I have written above. But o.k. if nobody found my builded example realistic it is the easiest to remove the Conflicts. Have a nice day, Joachim (Germany) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101213175348.7d4f6...@jupiter.home
Re: Bug#606441: unblock: yaboot/1.3.13a-1squeeze1
On Fri, Dec 10, 2010 at 10:33:44PM -0500, Milan Kupcevic wrote: Well, the whole situation you are describing actually motivated me to do something about it. And I did what was possible to do in short period of time. Any bugreport I could read? Well given I don't even know if an IBM p520 power6+ machine is expected to work with Debian, I haven't filled one. I pointed out a few drivers and other issues I hit, although they seemed to get no interest from anyone. There is a bug report in grub2 (upstream) about the issues left to solve for the IBM pseries servers. You have hands on that machine, I do not. Fix the issue, produce patch, we are eager to see the solution. Also take a look at this thread, we discuss about IBM p520 power6+ machine: http://lists.debian.org/debian-powerpc/2010/12/msg00032.html Well the video=ofonly seemed normal to me given the installer even mentions it as sometimes needed. The dual reboot thing I had noticed a few times, but I must admit I hadn't really put much thought into why it happened sometimes. grub2 does work once you manually generate the image and install it on a boot partition, and it supports software raid (something yaboot didn't, although it appears the 1.3.16 version now in unstable might), so it worked out OK for me. Please provide fully working and tested yaboot 1.3.16 Debian package and propose its upload, I'm sure it will override this one. Or even better, provide fully functional grub2 package for power platform. I'm sure it will get approved quickly. Well it is already uploaded in unstable. So someone already did that on December 1st (that someone being the long missed debian maintainer of yaboot). As for grub2, I think I will go try the latest version and see if any of the proposed patches for not having devaliases got in. If so, fixing grub-install for the pseries should be pretty simple. Of course even if 1.99 in experimental (which has some devalias fixes in it by the looks of it) works, I doubt squeeze wants to go to it if it puts x86 booting at risk given it is a less tested version. If we do not get yaboot 1.3.13a-1squeeze1 and fixed yaboot-installer bug #605932 into squeeze, it will be uninstallable, without manual tweaking, on all machines with SATA, SAS, and SCSI controllers (this includes all Mac G5 machines). All Mac G5 machines also need fixed initramfs-tools bug #603981. Certainly 1.3.13a-1squeeze1 fixing compatibility with the new kernel on machines yaboot always worked on is very useful and worthwhile. FYI: a bug report #605774 regarding ehea network driver was submitted on December 03, 2010 by Xavier Grave and was fixed in SVN promptly. It will get to squeeze install CD soon. Yeah I noticed. And finally we should get back to the subject of this message. Do you advocate for or against getting yaboot/1.3.13a-1squeeze1 into squeeze? I am not against yaboot/1.3.13a-1squeeze1. It is certainly better than what was there before. But I would be much more for allowing 1.3.16 currently in unstable, but given it only gained the patches from the 1.3.13a-1squeeze1 version yesterday, I doubt that's going to happen. A release is supposed to happen soon after all. Why, or why not? I am mainly amazed anyone would bother patching an old version with known failures that are known to be addressed in newer versions (for which there are bug reports requesting the new version), especially when that new version is already uploaded in unstable. Maybe it wasn't uploaded yet when this patched version was being made. I have been pretty much resigned to the fact that grub2 isn't quite ready on powerpc, so I figured I would just work to make sure the next release (after Squeeze) worked with grub2 on IBM power boxes so my life will be easier. In the mean time I would continue to manually maintain a patched grub2 that works on the box I run. It just seems to late to teach the installer about a new partitioning scheme on the IBM powerpc machines to support grub2. Of course I had also thought yaboot development was dead (so software raid support would never happen), and that a package update in Debian wasn't going to happen anyhow, so grub2 was the only thing worth persuing, but apparently that has changed this summer with a new upstream maintainer and new this month a new Debian package, supposedly with software raid support. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101213171319.gv12...@caffeine.csclub.uwaterloo.ca
Bug#606984: PowerMac G4 (Digital Audio) sound
Package: debian-installer Wrong sound module, snd-aoa, is loaded on PowerMac3,4. Currently the most usable sound driver for this machine is snd-powermac. To make it load on boot, the following modules ought to be blacklisted: snd-aoa snd-aoa-codec-tas snd-aoa-fabric-layout snd-aoa-i2sbus snd-aoa-soundbus and: snd-powermac should be added to /etc/modules. This could be a temporary solution, until snd-aoa will support the machine. -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlkti=6xwqzdg3ccwcuvalochaxbgx3zxeayw-bp...@mail.gmail.com
Re: Bug#606952: lilo: conflicts with grub[-pc]
* Joachim Wiedorn ad_deb...@joonet.de [Mon Dec 13, 2010 at 05:53:48PM +0100]: Michael Prokop m...@debian.org wrote on 2010-12-13 16:36: update-grub just generates the grub.cfg, the lilo package doesn't execute lilo (and therefore doesn't touch MBR) as long as there's no /etc/lilo.conf. So both packages can and do co-exist. Thank for more information - and also thanks to Colin. I only see one problem if grub-pc and lilo is full configured and then the both hook scripts will be executed, e.g.: 1) /etc/kernel/postinst.d/zz-update-grub - update grub.cfg 2) /etc/kernel/postinst.d/zz-lilo - update MBR (for lilo) Result: lilo is the bootloader 3) the package grub-pc will be updated- update MBR (for grub) Result: grub is the bootloader Is this the result that the admin want? I don't know. It's better than not having the option to have grub and lilo both installed at the same time at all, IMHO. The fact that iff lilo.conf is present lilo will be executed can be documented proberly with an according warning in for example the long description of the package as well as in the README.Debian. It breaks existing deployment environments. What do you want to say here? Please give me a (short) example. Think of a chroot style installer (working offline and without udebs) where grub and lilo both are available but only one of them will be configured as bootloader (either because of user's choice or because lilo does not support the specific setup and grub will be used therefore). Drop the conflicts in the lilo package and everything will continue to work as it used to? Yes, apart from the case I have written above. But o.k. if nobody found my builded example realistic it is the easiest to remove the Conflicts. I understand your concerns and would love to have an configurable option to specify which bootloader should be the *active* one so it's possible to have grub, lilo, extlinux, $WHATEVER_BOOTLOADER installed at the same time but execute only the hooks/scripts of the according/specified bootloader. Am I right that there's also no configureable option (chmod -x ... doesn't count as such) to disable the scripts inside /etc/kernel at all? (For example /etc/kernel/postinst.d/zz-update-grub bugs on me, see #597084.) regards, -mika- signature.asc Description: Digital signature
Re: boot parameter interface=auto can't adaptation the correct NIC
On Mon, Dec 13, 2010 at 11:15:46AM +0800, Qin Bo wrote: How can i find the bnx2 problem? I had set netcfg/dhcp_timeout=60 as boot parameter, the problem still reproduce. But I still think the netcfg didn't got the correct interface, then couldn't get the IP address from dhcp server. Because I had read the netcfg source:netcfg.c netcfg-common.c, i can't find where the program deal with interface=auto. It might have been the tg3 mentioned here: http://lists.debian.org/debian-boot/2010/12/msg00230.html hard to keep track of all the network types. If the logs were correct, it certainly looks like the interface was brought up and udhcpc tried it, but didn't wait long enough for link to come up first, and gave up and went to the next interface. Maybe gigabit interfaces are slow to come up, and the delay in udhcpc or the installer needs to be longer. -- Len Sorensen -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101213172503.gw12...@caffeine.csclub.uwaterloo.ca
Re: Bug#606952: lilo: conflicts with grub[-pc]
Michael Prokop m...@debian.org wrote on 2010-12-13 18:18: It's better than not having the option to have grub and lilo both installed at the same time at all, IMHO. The fact that iff lilo.conf is present lilo will be executed can be documented proberly with an according warning in for example the long description of the package as well as in the README.Debian. That is an idea. Am I right that there's also no configureable option (chmod -x ... doesn't count as such) to disable the scripts inside /etc/kernel at all? (For example /etc/kernel/postinst.d/zz-update-grub bugs on me, see #597084.) The hook script is an ordinary shell script. We could use a condition: exist lilo and is lilo configured for zz-update-grub, or exist grub and is grub configured for zz-lilo. But it seems such changes are to late for Squeeze. They concern more packages. Have a nice day, Joachim (Germany) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101213192435.106e5...@jupiter.home
Bug#537271: debian-installer: network may not be usable as soon as link is up
On Thursday, July 16, 2009 05:39:24 pm you wrote: the debian-installer seems to assume that the network is usable as soon as the link comes up, which may not be the case if the 802.1d spanning tree protocol is in use, in which case it can be up to ~30 seconds before the switch port will forward ethernet frames. i've noticed that trying to preseed a network install on a machine attached to an STP-enabled switch usually fails since as soon as the network link is up, d-i attempts to perform a reverse DNS lookup and fetch the preseed.cfg file via HTTP, both of which timeout and fail before the switch port the machine is attached to enters the forwarding state. a nice strategy to detect if the network is usable might be to send ARP requests for the default gateway's IP address and consider the network up only after the default gateway is reachable. it looks like there is a busybox version of the arping utility that could help accomplish this. Quick dirty workaround if enabling arping in busybox (or implementing the same in C in netcfg itself) is not an option, may also be to simply increase the number of ARP retries. echo 60 /proc/sys/net/ipv4/neigh/eth0/mcast_solicit -- Yours sincerely, Floris Bos -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012131946.46699@je-eigen-domein.nl
Re: archdetect as a .deb
Colin Watson, le Mon 13 Dec 2010 15:30:30 +, a écrit : The main issue is naming: since .udebs and .debs share a common namespace, it can't just be archdetect.deb unless the .udeb is renamed (which seems likely to be awkward?). What do you mean by awkward here? Can't it just be archdetect-udeb? Does anyone have an idea what it should be called? archdetect-deb offends my sense of aesthetics ... Samuel -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101213191005.ga6...@const.famille.thibault.fr
d-i meeting - 2010.12.15, 20h30 GMT
Hi all, Next Debian Installer meeting will take place on IRC, OFTC network, #debian- boot, 2 weeks after previous meeting . It is scheduled for next Wednesday - 2010.12.15, 20:30 UTC [1] Here's a short summary from the previous meeting: http://lists.debian.org/debian-boot/2010/12/msg00134.html Thanks all for attending. -- Melhores cumprimentos/Best regards, Miguel Figueiredo http://www.DebianPT.org -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201012131958.34623.el...@debianpt.org
Re: archdetect as a .deb
On Mon, Dec 13, 2010 at 13:30, Colin Watson cjwat...@ubuntu.com wrote: The Ubuntu ARM folks have asked me to look into providing archdetect as a .deb, so that they can use it in some situations outside d-i as a single common way to name the current subarchitecture. This seems reasonable enough to me, and since libdebian-installer is already available as a .deb it wouldn't be very difficult to arrange. The main issue is naming: since .udebs and .debs share a common namespace, it can't just be archdetect.deb unless the .udeb is renamed (which seems likely to be awkward?). Does anyone have an idea what it should be called? archdetect-deb offends my sense of aesthetics ... Shouldn't it be part of dpkg? -- Otavio Salvador O.S. Systems E-mail: ota...@ossystems.com.br http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktin6rlzonnys1knwivg91opjpdcx7r70o4ncn...@mail.gmail.com
Bug#606973: marked as done (Installation was successfull at Asus Notebook)
Your message dated Mon, 13 Dec 2010 20:47:31 + with message-id 201012132047.31845.el...@debianpt.org and subject line Re: Bug#606973: Installation was successfull at Asus Notebook has caused the Debian Bug report #606973, regarding Installation was successfull at Asus Notebook 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 this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 606973: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=606973 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: installation-reports Boot method: USB hostpowered DVD Image version: Self-made boot-cd with actual squeeze installer Date: 12.12.2010 Machine: ASUS Notebook Z7750 Processor: Pentium M 1,6GHz Memory: 512MB Partitions: Dateisystem Typ1K‐Blöcke Benutzt Verfügbar Ben% Eingehängt auf /dev/sda1 ext4 9611492 4376988 4746264 48% / tmpfstmpfs 256968 0256968 0% /lib/init/rw udev tmpfs 252580 208252372 1% /dev tmpfstmpfs 25696888256880 1% /dev/shm /dev/sda6 ext446588296 30707488 13514244 70% /home Output of lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 82855PM Processor to I/O Controller [8086:3340] (rev 21) Subsystem: ASUSTeK Computer Inc. Device [1043:186a] Kernel driver in use: agpgart-intel 00:01.0 PCI bridge [0604]: Intel Corporation 82855PM Processor to AGP Controller [8086:3341] (rev 21) 00:1d.0 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #1 [8086:24c2] (rev 03) Subsystem: ASUSTeK Computer Inc. Device [1043:1869] Kernel driver in use: uhci_hcd 00:1d.1 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #2 [8086:24c4] (rev 03) Subsystem: ASUSTeK Computer Inc. Device [1043:1869] Kernel driver in use: uhci_hcd 00:1d.2 USB Controller [0c03]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) USB UHCI Controller #3 [8086:24c7] (rev 03) Subsystem: ASUSTeK Computer Inc. Device [1043:1869] Kernel driver in use: uhci_hcd 00:1d.7 USB Controller [0c03]: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 EHCI Controller [8086:24cd] (rev 03) Subsystem: ASUSTeK Computer Inc. Device [1043:1868] Kernel driver in use: ehci_hcd 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev 83) 00:1f.0 ISA bridge [0601]: Intel Corporation 82801DBM (ICH4-M) LPC Interface Bridge [8086:24cc] (rev 03) 00:1f.1 IDE interface [0101]: Intel Corporation 82801DBM (ICH4-M) IDE Controller [8086:24ca] (rev 03) Subsystem: ASUSTeK Computer Inc. Device [1043:1869] Kernel driver in use: ata_piix 00:1f.3 SMBus [0c05]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) SMBus Controller [8086:24c3] (rev 03) Subsystem: ASUSTeK Computer Inc. Device [1043:1869] Kernel driver in use: i801_smbus 00:1f.5 Multimedia audio controller [0401]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller [8086:24c5] (rev 03) Subsystem: ASUSTeK Computer Inc. M6800N [1043:1713] Kernel driver in use: Intel ICH 00:1f.6 Modem [0703]: Intel Corporation 82801DB/DBL/DBM (ICH4/ICH4-L/ICH4-M) AC'97 Modem Controller [8086:24c6] (rev 03) Subsystem: ASUSTeK Computer Inc. M6800N [1043:1826] Kernel driver in use: Intel ICH Modem 01:00.0 VGA compatible controller [0300]: ATI Technologies Inc RV350 [Mobility Radeon 9600 M10] [1002:4e50] Subsystem: ASUSTeK Computer Inc. Device [1043:1772] Kernel driver in use: radeon 02:00.0 Ethernet controller [0200]: Broadcom Corporation NetXtreme BCM5788 Gigabit Ethernet [14e4:169c] (rev 03) Subsystem: ASUSTeK Computer Inc. Device [1043:1735] Kernel driver in use: tg3 02:01.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev ac) Subsystem: ASUSTeK Computer Inc. Device [1043:1864] Kernel driver in use: yenta_cardbus 02:01.1 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev ac) Subsystem: ASUSTeK Computer Inc. Device [1043:1864] Kernel driver in use: yenta_cardbus 02:01.2 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C552 IEEE 1394 Controller [1180:0552] (rev 04) Subsystem: ASUSTeK Computer Inc. Device [1043:1867] Kernel driver in use: firewire_ohci 02:02.0 Network controller [0280]: Intel Corporation PRO/Wireless 2200BG [Calexico2] Network Connection [8086:4220] (rev 05) Subsystem: Intel Corporation Device [8086:2701] Kernel
Bug#599772: SOLVED
I tested this with console-setup-udeb 1.61 and still had exactly
the same problem as the original poster. But I solved it, and in
the process found a good technique to reverse-engineer the myriad of
undocumented preseed variables.
First the solution.
First (and I realise the original poster is aware of this, but saying
so again won't hurt) remember that keyboard-related variables must be
preseeded from the kernel command line, not from a preseed file (this
is because the keyboard must be successfully configured before the
network is configured and the network must be successfully configured
before any preseed file can be retrieved; search the very nice article
describing this at http://www.hps.com/~tpg/notebook/autoinstall.php
for Preseeding Surprises).
Only a few of months ago, a squeeze Xen PV required only one preseed
variable to be set:
console-keymaps-at/keymap=us
but *now* two are required and they're both different from this
previously used variable:
keyboard-configuration/layoutcode=us
keyboard-configuration/xkb-keymap=us
This fixed it for me.
Can I make a plea that when developers change the names of preseed
variables or introduce new ones, that they also make corresponding
*and immediate* changes to the example preseed files (e.g. the one
at http://www.debian.org/releases/squeeze/example-preseed.txt). It
would save a *lot* of struggle.
(Bugs where the documentation needs to be aligned with program
bahaviour are no less serious than bugs where program behaviour needs
to be aligned with documentation.)
Secondly, I thought it might help other people struggling with
this to know how I worked out the names of the relevant variables.
I'm preseeding a system with default values; e.g. en_US.UTF8 locale,
us territory, us mirrors, etc; there are *many* variables whose
values contain the string 'us'. This made it very hard for me to
isolate the variables that I was interested in.
In the case of this keyboard layout problem, I waited for the Choose
keymap interactive selection menu to appear, and then I manually
selected the obscurest keyboard layout I could, which was Ukrainian
(with apologies to Ukrainians). Unfortunately, that triggered a rather
unexpected follow-up question, so I went back (with some difficulty)
and selected Brazilian keyboard layout instead. Once the installation
completed (with this wrong, but deliberately selected keyboad
layout), I ran 'grep -rli br /var/log/installer' ('br' for 'Brazil'
or 'Brazilian' or whatever code keyboard layouts might be coded in)
which lead me to the file /var/log/installer/cdebconf/questions.dat,
which is a text file which contains the names of the preseed variables
and their values. Once there, I just search for 'br' and found the
name of the preseed variables that were set to this value. Yahoo! :)
HTH
Alexis Huxley
ahux...@gmx.net
--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20101213213426.ga25...@torchio.pasta.net
Debian installer build: failed or old builds
Debian installer build overview --- Failed or old builds: * OLD BUILD:hppa Jun 07 00:12 bui...@lafayette build_cdrom http://d-i.debian.org/daily-images/hppa/daily/build_cdrom.log * OLD BUILD:hppa Jun 07 00:16 bui...@lafayette build_netboot http://d-i.debian.org/daily-images/hppa/daily/build_netboot.log * OLD BUILD:hppa Jun 07 00:21 bui...@lafayette build_miniiso http://d-i.debian.org/daily-images/hppa/daily/build_miniiso.log * OLD BUILD:mipsel Dec 09 00:12 bui...@rem build_cobalt_netboot-2.6_serial http://d-i.debian.org/daily-images/mipsel/daily/build_cobalt_netboot-2.6_serial.log * OLD BUILD:mipsel Dec 09 00:18 bui...@rem build_cobalt_netboot-2.6_ssh http://d-i.debian.org/daily-images/mipsel/daily/build_cobalt_netboot-2.6_ssh.log * OLD BUILD:mipsel Dec 09 00:20 bui...@rem build_cobalt_netboot-2.6_common http://d-i.debian.org/daily-images/mipsel/daily/build_cobalt_netboot-2.6_common.log * OLD BUILD:mipsel Dec 09 00:24 bui...@rem build_malta_netboot-2.6 http://d-i.debian.org/daily-images/mipsel/daily/build_malta_netboot-2.6.log * OLD BUILD:mipsel Dec 09 00:29 bui...@rem build_sb1-bcm91250a_netboot-2.6 http://d-i.debian.org/daily-images/mipsel/daily/build_sb1-bcm91250a_netboot-2.6.log * OLD BUILD:sparc Jul 12 11:04 stapp...@dd build_cdrom http://people.debian.org/~stappers/d-i/sparc/daily/build_cdrom.log * OLD BUILD:sparc Jul 12 11:08 stapp...@dd build_netboot http://people.debian.org/~stappers/d-i/sparc/daily/build_netboot.log * OLD BUILD:sparc Jul 12 11:11 stapp...@dd build_miniiso http://people.debian.org/~stappers/d-i/sparc/daily/build_miniiso.log Totals: 113 builds (0 failed, 11 old) -- To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1psjfl-0004lh...@ravel.debian.org
Bug#605774: Bug also present in debian-squeeze-di-beta2-powerpc-netinst.iso
Quoting Xavier Grave (xavier.gr...@ipno.in2p3.fr): -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Just to give the info, I have tested the debian-squeeze-di-beta2-powerpc-netinst.iso. The fix for bug#605774 didn't reach the last installer iso. That's expected as no new kernel udebs were built since then. This will happen in the RC1 release, I think. signature.asc Description: Digital signature
