Bug#454691: Checked with previously working 2007-11-19 and 2007-12-05-2 and they fail
As Christian says it's probably a temporary error in testing. It is relatively recent as the 2007-12-05-2 install earlier this evening worked, but now it doesn't (tested after 2007-12-06-2 failed). Also, I'd like to mention the reason I was testing a new install, which is that on reboot lvm on crypt fails to load (the message was 'cannot find /dev/sdb1'). sdb is the second logical disk on a Dell PERC 3/DCL (AMI MegaRAID Elite 1600) hardware raid, and sdb1 is the partition with the lvm on top of a crypt (lvm on sdb1_crypt, crypt on sdb1). This probably belongs with the package that is responsible for loading lvm and/or crypt partitions. I can't do more testing or give you more information (or file a proper installation report) until I can install though. I'd like to note that this partitioning scheme works for Etch, so this is a regression. Regards, Daniel -- And that's my crabbing done for the day. Got it out of the way early, now I have the rest of the afternoon to sniff fragrant tea-roses or strangle cute bunnies or something. -- Michael Devore GnuPG Key Fingerprint 86 F5 81 A5 D4 2E 1F 1C http://gnupg.org No more sea shells: Daniel's Webloghttp://cshore.wordpress.com pgpd1TAzxh4yw.pgp Description: PGP signature
Bug#454493: Display PCI slot for nics, if available
dann frazier wrote: > * Modify cdebconf to support multi-line choice fields. Make each >interface choice be a multi-lined option that includes things like >vendor, model, mac, slot. eth0: foo bar description, eth0: mac address: xxx:xxx... [slot 1] That would be one way to do it without modifying debconf. You could also get rid of the "eth0: " prefix if you wanted to by using Choices-C. Although while all these controls and detail can be nice, I'd generally prefer that d-i just figured out which nic has link and a dhcp server and got on with it. -- see shy jo signature.asc Description: Digital signature
Bug#454691: Installation Report 2007-12-06-2
Quoting Daniel Dickinson ([EMAIL PROTECTED]): > Installation of the standard system (no desktop) failed during the download > and install of the select task. Looking at the syslog revealed that > findutils was marked for removal and that the system was waiting for "I know > this is a very bad idea" to be input. (hint: not much value added in this post, but it seems worth a thread as followup..:-)) Apart from a probably temporary problem in testing that should be investigated and probably reassigned to the right package, I wonder whether we would do something in D-I (apt-setup ?) to intercept such critical messages and display something to users. signature.asc Description: Digital signature
Bug#454618: [sparc] netra x1 - flapping interfaces / not installable
On Thursday 06 December 2007, Florian Lohoff wrote: > Without having overly much kernel experience i had a look at dmfe.c > and without testing i would guess this would at least prohibit > dmfe to claim the resources when the mac is obviously '0'. This is something that's really off-topic to (read: over the heads of) the d-boot list/team and should be taken to the kernel developers at [EMAIL PROTECTED], CC: [EMAIL PROTECTED] If they feel your suggestion are correct, that would be perfect, but us lowly installer developers basically just have to deal with whatever the kernel gives us :-P Cheers, FJP signature.asc Description: This is a digitally signed message part.
Bug#454493: Display PCI slot for nics, if available
On Thu, Dec 06, 2007 at 01:34:25AM +0100, Frans Pop wrote: > On Wednesday 05 December 2007, dann frazier wrote: > > This patch to hw-detect adds slot information, if available, to the > > network device name. Its not uncommon for HP (or our customers) to > > have systems with many network devices, and knowing the physical slot > > number of an adapter makes configuration that much easier. > > I have several reservations against this patch: > - to have it work for all installation methods you'd need to to include > this acpi module (and others?) in initrds, which is something we don't > do lightly [1] Understood. Note that this implementation doesn't *require* the module, it just takes advantage of it if its available. And, if other non-ACPI platforms begin populating the 'slot' sysfs field in the future, the installer would automatically work with it. In fact, as to Otavio's point, it probably makes sense to do the module loading outside of hw-detect (e.g. his acpi-support-udeb suggestion), and just let hw-detect use the interface if its available. > - the "slot" indication is not translatable in the current patch I didn't think to make this translatable, but yes, it should be. > - the descriptions are already quite long and this will truncate some of > them even more than they already are Yeah, I expected someone would point this out. There are possible hacks like filtering out redundant words/phrases like "Ethernet Controller", but I think what we really need is to get out of the single-line description, more on this below. > - I'm not sure that as a user it would be clear to me what exactly a Slot > is in this context I could change this to "PCI Slot" or "PCI Card Slot", and would even prefer it, but that will of course take more space. > - looking at your screenshot it does not seem to add all that much > identification as there are still several NICs with identical slots The snapshot was taken from a machine w/ dual-port cards installed, so it is correct for both nics to claim the same slot. This case does leave some ambiguity, but much less ambiguity than before. > - it seems only a partial solution as not all NICs will be get a slot > identifier Again, it decreases ambiguity. In my screenshot, you can see that two nics aren't in slots because they are built into the system board. You don't know which one is which, but in a system with 20 nics, it certainly saves you some time finding the right one. (And 20 NICs really isn't a contrived example, but is of course a small minority of Debian users). > - I'm not sure that it makes sense to print slot if it's the only > identification Can you restate this one - I didn't really follow it. > We've had other requests to provide additional identification of NICs (see > #450605 and merged BRs) and so far we (or at least I) have been thinking of > some way to display the MAC address, possibly by allowing to switch between > display of the current descriptions and MAC address. That would help some users, but I'd like to see us find a more general way to display all the available information that a user might use for identification. And I expect a separate display, or "view" for each may prove not to scale. I do like the genearl principle of Geert's proposal: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450605#31 With the exception that I don't like splitting the option list from the selection widget (and as Bastian points out, its not possible anyway). Some brainstorming: * Modify cdebconf to permit per-option descriptions, and use those descriptions to provide details about each nic. Frontends could use this to implement a "more info" button, or just include the description text in-line. * Modify cdebconf to support multi-line choice fields. Make each interface choice be a multi-lined option that includes things like vendor, model, mac, slot. * Change the flow from "select iface" -> "configure iface" to: "select iface" v "display info about iface & confirm" v "configure iface" This is probably the only one possible w/ today's cdebconf, but its pretty non-intuitive. -- dann frazier -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454641: net-isntaller/troubles ASUS ASPIRE 4520
Package: installation-reports Boot method: Image version: Date: Machine: Processor: AMD Turion 64 x1 MK-38 Memory: 1024 MB DDR II 667 MHz; Partitions: sda1(ext3-primary-boot-29504.08MB) sda2(extended)[sda5(swap-logical-2138.58) sda6(ext3-logiacal-88388.86)] DD: /dev/sda (SATA) Size: 120034123776 bytes, 120.0 GB Heads: 255 Sectors per track: 63 Cylinders: 14593 --- NOTE: I used archlinux livecd to get lspci. lspci -nn --- 00:00.0 RAM memory [0500]: nVidia Corporation Unknown device [10de:0547] (rev a2) 00:01.0 ISA bridge [0601]: nVidia Corporation Unknown device [10de:0548] (rev a2) 00:01.1 SMBus [0c05]: nVidia Corporation Unknown device [10de:0542] (rev a2) 00:01.2 RAM memory [0500]: nVidia Corporation Unknown device [10de:0541] (rev a2) 00:01.3 Co-processor [0b40]: nVidia Corporation Unknown device [10de:0543] (rev a2) 00:02.0 USB Controller [0c03]: nVidia Corporation Unknown device [10de:055e] (rev a2) 00:02.1 USB Controller [0c03]: nVidia Corporation Unknown device [10de:055f] (rev a2) 00:04.0 USB Controller [0c03]: nVidia Corporation Unknown device [10de:055e] (rev a2) 00:04.1 USB Controller [0c03]: nVidia Corporation Unknown device [10de:055f] (rev a2) 00:06.0 IDE interface [0101]: nVidia Corporation Unknown device [10de:0560] (rev a1) 00:07.0 Audio device [0403]: nVidia Corporation MCP67 High Definition Audio [10de:055c] (rev a1) 00:08.0 PCI bridge [0604]: nVidia Corporation Unknown device [10de:0561] (rev a2) 00:09.0 IDE interface [0101]: nVidia Corporation Unknown device [10de:0550] (rev a2) 00:0a.0 Ethernet controller [0200]: nVidia Corporation Unknown device [10de:054c] (rev a2) 00:0c.0 PCI bridge [0604]: nVidia Corporation Unknown device [10de:0563] (rev a2) 00:0e.0 PCI bridge [0604]: nVidia Corporation Unknown device [10de:0563] (rev a2) 00:12.0 VGA compatible controller [0300]: nVidia Corporation Unknown device [10de:0533] (rev a2) 00:18.0 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration [1022:1100] 00:18.1 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map [1022:1101] 00:18.2 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller [1022:1102] 00:18.3 Host bridge [0600]: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control [1022:1103] 01:09.0 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394 Controller [1180:0832] (rev 05) 01:09.1 Generic system peripheral [0805]: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 22) 01:09.2 System peripheral [0880]: Ricoh Co Ltd R5C843 MMC Host Controller [1180:0843] (rev 12) 01:09.3 System peripheral [0880]: Ricoh Co Ltd R5C592 Memory Stick Bus Host Adapter [1180:0592] (rev 12) 01:09.4 System peripheral [0880]: Ricoh Co Ltd xD-Picture Card Controller [1180:0852] (rev 12) 07:00.0 Ethernet controller [0200]: Atheros Communications, Inc. AR5006EG 802.11 b/g Wireless PCI Express Adapter [168c:001c] (rev 01) --lspci -nnv--- 00:00.0 RAM memory [0500]: nVidia Corporation Unknown device [10de:0547] (rev a2) Subsystem: Acer Incorporated [ALI] Unknown device [1025:0127] Flags: bus master, 66MHz, fast devsel, latency 0 Capabilities: [44] HyperTransport: Slave or Primary Interface Capabilities: [dc] HyperTransport: MSI Mapping 00:01.0 ISA bridge [0601]: nVidia Corporation Unknown device [10de:0548] (rev a2) Subsystem: Acer Incorporated [ALI] Unknown device [1025:0127] Flags: bus master, 66MHz, fast devsel, latency 0 I/O ports at 1d00 [size=256] 00:01.1 SMBus [0c05]: nVidia Corporation Unknown device [10de:0542] (rev a2) Subsystem: Acer Incorporated [ALI] Unknown device [1025:0127] Flags: 66MHz, fast devsel, IRQ 10 I/O ports at 3080 [size=64] I/O ports at 3040 [size=64] I/O ports at 3000 [size=64] Capabilities: [44] Power Management version 2 00:01.2 RAM memory [0500]: nVidia Corporation Unknown device [10de:0541] (rev a2) Subsystem: nVidia Corporation Unknown device [10de:cb84] Flags: 66MHz, fast devsel 00:01.3 Co-processor [0b40]: nVidia Corporation Unknown device [10de:0543] (rev a2) Subsystem: Acer Incorporated [ALI] Unknown device [1025:0127] Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 11 Memory at f420 (32-bit, non-prefetchable) [size=512K] 00:02.0 USB Controller [0c03]: nVidia Corporation Unknown device [10de:055e] (rev a2) (prog-if 10 [OHCI]) Subsystem: Acer Incorporated [ALI] Unknown device [1025:0127] Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 17 Memory at f4486000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Manage
Bug#454618: [sparc] netra x1 - flapping interfaces / not installable
On Thu, Dec 06, 2007 at 07:48:34PM +0100, Florian Lohoff wrote:
> Reading only 0's from an eeprom in the driver can be detected. Why cant
> the dmfe driver refuse to load (or better not claim the resources) in this
> case? It used to be the case for hundrets of isa modules that they were
> loaded, tried if their hardware was there and later if not just notified
> that they failed to load. I know - these were the old days and we are
> now pleased with an in kernel module loader and all that fancy stuff
> but can't this be done ?!? It might mean to really rewrite a little of
> module init logic and not really look at the chip at ifup time. My guess
> is that nobody until now was annoyed enough to actually write the code :)
Without having overly much kernel experience i had a look at dmfe.c
and without testing i would guess this would at least prohibit
dmfe to claim the resources when the mac is obviously '0'.
The only problem this brings up is with cards where the mac address
is 0 due to a production problem - Those would be basically
unusable without a reverting patch. The MAC beeing 0
is obviously only a symptom and the difference might even be much
more easy to detect. So using the MAC is most likely a crude hack.
From my understanding for every driver registered all unclaimed devices
will be probed. So with this dmfe will hopefully refuse to play with
the device and return ENODEV which will let tulip when loaded claim the
device. Somebody with more understanding of the DMFE will need to have a
look here and make guesses on how to differentiate dmfes from tulips.
diff --git a/drivers/net/tulip/dmfe.c b/drivers/net/tulip/dmfe.c
index b4891ca..c023ec0 100644
--- a/drivers/net/tulip/dmfe.c
+++ b/drivers/net/tulip/dmfe.c
@@ -362,6 +362,7 @@ static int __devinit dmfe_init_one (struct pci_dev *pdev,
struct net_device *dev;
u32 pci_pmr;
int i, err;
+ u8 macor=0;
DECLARE_MAC_BUF(mac);
DMFE_DBUG(0, "dmfe_init_one()", 0);
@@ -464,8 +465,15 @@ static int __devinit dmfe_init_one (struct pci_dev *pdev,
cpu_to_le16(read_srom_word(db->ioaddr, i));
/* Set Node address */
- for (i = 0; i < 6; i++)
+ for (i = 0; i < 6; i++) {
dev->dev_addr[i] = db->srom[20 + i];
+ macor |= db->srom[20 + i];
+ }
+
+ if (!macor) {
+ err = -ENODEV;
+ goto err_out_res;
+ }
err = register_netdev (dev);
if (err)
Flo
--
Florian Lohoff [EMAIL PROTECTED] +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
signature.asc
Description: Digital signature
Bug#318194: as a requirement
Hi I'm 28 years old I read your profile online and I was intrested in getting to know you better Reply to me and tell me about yourself if you want to chat I will send a pic and some of my info right away email me at [EMAIL PROTECTED] , that will be sent to me directly Thank you -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454618: [sparc] netra x1 - flapping interfaces / not installable
On Thu, Dec 06, 2007 at 06:39:08PM +0100, Frans Pop wrote: > On Thursday 06 December 2007, Florian Lohoff wrote: > > This is the very same problem as #360699 reported which was closed. > > Because it is not a problem we can solve in the installer, nor is it > apparently a problem that can be solved in the kernel: there are two series > of different, partially incompatible hardware which use the same PCI IDs... Reading only 0's from an eeprom in the driver can be detected. Why cant the dmfe driver refuse to load (or better not claim the resources) in this case? It used to be the case for hundrets of isa modules that they were loaded, tried if their hardware was there and later if not just notified that they failed to load. I know - these were the old days and we are now pleased with an in kernel module loader and all that fancy stuff but can't this be done ?!? It might mean to really rewrite a little of module init logic and not really look at the chip at ifup time. My guess is that nobody until now was annoyed enough to actually write the code :) > > Unloading dmfe.ko and loading tulip.ko (and removing dmfe.ko to > > dismiss further loading) helps ... > > This is documented in: > http://www.debian.org/releases/etch/sparc/ch02s06.html.en#nics-sparc-trouble > > An easier way to prevent loading dmfe.ko is to boot the installer > with 'install dmfe.blacklist=yes'. This is already documented in the > development version of the installation guide: > http://d-i.alioth.debian.org/manual/en.sparc/ch02s06.html#nics-sparc-trouble Thanks for the hint Flo -- Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature
Re: How to preseed install via pppoe (for A-DSL)?
On Tue, Nov 27, 2007 at 02:41:11PM +0200, Eddy Petrișor wrote: > Josef Wolf wrote: [ ... ] > > The next interesting point is that eth0 is not configured at the time > > ppp-udeb runs. Seems like ppp-udeb is configured before netcfg. Could > > This is normal and that is the whole point. To make ppp-udeb configure the > networking instead of netcfg. I am still somewhat confused. Is ppp-udeb meant to completely replace netcfg? Shouldn't it ask for netcfg/get_domain then? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to force d-i to ask for domain name?
On Mon, Dec 03, 2007 at 03:59:39PM +0100, Geert Stappers wrote: > Op 02-12-2007 om 14:26 schreef Josef Wolf: > > On Sat, Dec 01, 2007 at 12:44:30PM +0100, Geert Stappers wrote: > > > > An option might be a modified netcfg. > > > Build the udeb after your hack and place it in the local udeb directory > > > before rebuilding d-i. > > > > Sorry, I don't really understand what you try to tell me here. > > After the "An option might be a modified netcfg.", > I added a few words how to include a modified netcfg. > > Now more words how to include a modified netcfg: > > * the source of netcfg is the d-i source under the packages directory > * hack the source of netcfg > * do "dpkg-buildpackage" to get a netcfg udeb > * place that udeb in the local udeb directory under d-i/installer/build > * do "./daily_build build" to get your modified d-i I'd rather stay with the original package. It turns out that ubuntu has lowered the priority for netcfg/get_domain from high to medium. Anybody knows why they have done this? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454618: [sparc] netra x1 - flapping interfaces / not installable
On Thursday 06 December 2007, Florian Lohoff wrote: > This is the very same problem as #360699 reported which was closed. Because it is not a problem we can solve in the installer, nor is it apparently a problem that can be solved in the kernel: there are two series of different, partially incompatible hardware which use the same PCI IDs... > Unloading dmfe.ko and loading tulip.ko (and removing dmfe.ko to > dismiss further loading) helps ... This is documented in: http://www.debian.org/releases/etch/sparc/ch02s06.html.en#nics-sparc-trouble An easier way to prevent loading dmfe.ko is to boot the installer with 'install dmfe.blacklist=yes'. This is already documented in the development version of the installation guide: http://d-i.alioth.debian.org/manual/en.sparc/ch02s06.html#nics-sparc-trouble Cheers, FJP -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#454618: [sparc] netra x1 - flapping interfaces / not installable
Package: debian-installer Version: snapshot-20071127 Hi, i just tried installing Debian/Etch on an Sun Netra X1 and it failed. I retried with a current snapshot from here: http://people.debian.org/~stappers/d-i/images/20071127-12:10/netboot/boot.img and it fails the same way. When gettint to the network configuration both ethernets immediatly start flapping and DHCP does not succeed. Dec 6 17:24:17.459 MEZ: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to down Dec 6 17:24:21.060 MEZ: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to up Dec 6 17:24:23.460 MEZ: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to down Dec 6 17:24:27.060 MEZ: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to up Dec 6 17:24:29.460 MEZ: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to down Dec 6 17:24:33.060 MEZ: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to up Dec 6 17:24:35.460 MEZ: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to down Dec 6 17:24:41.260 MEZ: %LINK-3-UPDOWN: Interface FastEthernet0/3, changed state to up This seems to be caused by the driver unable to assign a MAC Address: eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:9 eth1 Link encap:Ethernet HWaddr 00:00:00:00:00:00 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:10 Base address:0x100 This is the very same problem as #360699 reported which was closed. Unloading dmfe.ko and loading tulip.ko (and removing dmfe.ko to dismiss further loading) helps ... 00:05.0 Ethernet controller: Davicom Semiconductor, Inc. 21x4x DEC-Tulip compatible 10/100 Ethernet (rev 31) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- SERR+ TAbort- SERR+ signature.asc Description: Digital signature
Partman reorganization - day 2
Today I've implemented the dynamic loading of partman-lvm and partman-crypto only when there is sufficient memory available [1]. This should result in a better experience for installs where there is limited memory available. In principle partman-md (RAID support) could be loaded in the same manner, but I'm not sure if there is a real need to do so ATM (only 750kB installed size for partman-md, mdcfg-utils, mdadm-udeb). I was able to test this by including the new partman udebs in a businesscard image (which was surprisingly easy using debian-cd). The tests showed that about 7.5MB free memory is required when partman is started to successfully use guided LVM partitioning. I have not yet managed to do the restructuring of removing existing LVM data. Hopefully I'll manage to do that tomorrow. Please wait with reimplementation of removing existing crypto volumes until after that. Cheers, FJP [1] Commit log entry: Dynamically load support for LVM and crypto Only load components for LVM and crypto support when there is sufficient free memory. For crypto this only loads base support components; additional crypto components will only be loaded on demand. Support for guided (encrypted) LVM partitioning is only loaded if partman-auto has already been loaded (which it may not be for lowmem installs). The priority of partman-(auto-)lvm and partman-(auto-)crypto is lowered to optional to allow dynamic loading by partman-base. The dynamic loading is done from the main partman script instead of an init.d script to avoid interference from anna's progress bar with the init.d progress bar. The limit of 7500kB for LVM is based on tests on i386 (VirtualBox with 5GB hard disk); the limit of 11000kB for crypto is based on the existing limit used in partman-crypto for loading additional components. signature.asc Description: This is a digitally signed message part.
