Bug#592005: Debian installer fails because the initial ramdisk does not include unusual USB storage drivers
Package: kernel-wedge Version: 2.64 Severity: serious The daily squeeze installer builds aren't working on my NSLU2 (armel). I think that the problem is related to bug 534324 [1]. The USB disk enclosure I am using uses a Cypress chipset, and the installer image doesn't include ums-cypress.ko, which seems to be required with 2.6.32 for this chipset. Therefore, the installer does not find any disks onto which the operating system can be installed. Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- 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/aanlktimkb84yzevcj13obawpf49mz6=1klrmefckk...@mail.gmail.com
Bug#506252: success: d-i lenny rc1 on nslu2 armel
On Sun, Nov 23, 2008 at 10:28, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > * Devin Carraway <[EMAIL PROTECTED]> [2008-11-19 13:31]: >> Timezone setup was fine, but the system RTC does not appear to be running, >> so attempts to write to the hardware clock (which require an RTC poll) >> failed, causing a brief (but properly detected by the installer) hang. >> Installed files were timestamped correctly, but on post-install reboot the >> clock was wrong (also if the clock isn't running the hwclock access on boot >> will stall, taking hours for the first boot, but I'd disabled that before >> the reboot.) > > Rod, Gordon, do you know what to do about this situation? I think RTC > works fine here, but what can we do in the case described by Devin? This problem didn't occur when I last checked the RC1 installer image. Sounds like a hardware problem. I wonder if removing and then reinstalling the NSLU2 battery will solve the problem [1] (search for rtc on the page). Alternatively, you could boot the Linksys firmware, and then try the installer again. Gordon [1] http://www.nslu2-linux.org/wiki/Debian/TroubleShooting -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#406007: installation-report: RC1 installer (NSLU2) does not use swap before partitioning
Hi Kevin On Mon, Sep 15, 2008 at 00:47, Kevin Price <[EMAIL PROTECTED]> wrote: > From memory, it was something like > > sda1 1 GB swap Are you sure the swap size was 1 GB? The swap size listed in the kernel OOM logs was only 248968kB: Aug 20 01:04:50 kernel: [42950317.65] mkfs.ext3 invoked oom-killer: gfp_mask=0x1200d2, order=0, oomkilladj=0 ... Aug 20 01:04:50 kernel: [42950317.66] Free swap = 206988kB Aug 20 01:04:50 kernel: [42950317.66] Total swap = 248968kB Aug 20 01:04:50 kernel: [42950317.66] 8192 pages of RAM Aug 20 01:04:50 kernel: [42950317.66] 381 free pages Aug 20 01:04:50 kernel: [42950317.66] 817 reserved pages Aug 20 01:04:50 kernel: [42950317.66] 675 slab pages Aug 20 01:04:50 kernel: [42950317.66] 0 pages shared Aug 20 01:04:50 kernel: [42950317.66] 2354 pages swap cached Aug 20 01:04:50 kernel: [42950317.66] Out of memory: kill process 7270 (mkfs.ext3) score 617 or a child Aug 20 01:04:50 kernel: [42950317.66] Killed process 7270 (mkfs.ext3) Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#406007: installation-report: RC1 installer (NSLU2) does not use swap before partitioning
On Sat, Sep 13, 2008 at 05:35, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > Actually, this is what the installer does, are or least is supposed to > do. Kevin Price ran into this problem too recently and I'm not sure > how to interpret his finding. Maybe someone more familiar with > partman (or the kernel?) can comment. > > Here is what Kevin found: > > | >> I think it should have formatted and activated swap first, and then > | >> afterwards start formatting the ext3 partitions. That would avoid the > error. > | > > | > That's what the installer does. It partitions the disk, formats and > | > activates swap and then formats the other partitions. > | > | That surprises me. On a closer look into the log, you're right. > | > | From a user's POV, the first mkfs-ext3 attempt failed, but just starting > | it again worked out ok. > | > | Now from looking into the log, it looks strange: It adds swap, then > | attempts to format ext3, then comes OOM and kills mkfs.ext3. Then comes > | the interesting part: It seems to add swap again. That time mkfs.ext3 > | runs OK. So maybe the first time adding swap, the swap gets disbled > | immediately after, triggering OOM? > | > | See the attached log excerpt. I don't see this problem on the NSLU2 with the default partitioning scheme. Sep 14 20:16:00 kernel: [42949829.95] Adding 248968k swap on /dev/sda5. Priority:-1 extents:1 across:248968k Sep 14 20:16:04 partman: mke2fs 1.41.1 (01-Sep-2008) Sep 14 20:18:41 kernel: [42949991.56] kjournald starting. Commit interval 5 seconds Sep 14 20:18:41 kernel: [42949991.56] EXT3 FS on sda2, internal journal Sep 14 20:18:41 kernel: [42949991.56] EXT3-fs: mounted filesystem with ordered data mode. Kevin, what partitioning scheme were you trying to implement? What is also interesting in Kevin's logs is that the kernel log messages indicate that swap was present and available. Aug 20 01:04:50 kernel: [42950317.65] mkfs.ext3 invoked oom-killer: gfp_mask=0x1200d2, order=0, oomkilladj=0 ... Aug 20 01:04:50 kernel: [42950317.66] Free swap = 206988kB Aug 20 01:04:50 kernel: [42950317.66] Total swap = 248968kB Aug 20 01:04:50 kernel: [42950317.66] 8192 pages of RAM Aug 20 01:04:50 kernel: [42950317.66] 381 free pages Aug 20 01:04:50 kernel: [42950317.66] 817 reserved pages Aug 20 01:04:50 kernel: [42950317.66] 675 slab pages Aug 20 01:04:50 kernel: [42950317.66] 0 pages shared Aug 20 01:04:50 kernel: [42950317.66] 2354 pages swap cached Aug 20 01:04:50 kernel: [42950317.66] Out of memory: kill process 7270 (mkfs.ext3) score 617 or a child Aug 20 01:04:50 kernel: [42950317.66] Killed process 7270 (mkfs.ext3) I wonder if the system had nothing else left to page out to swap [1]. I'm not sure what to do about this problem through, but it would be nice to know whether there is a partitioning scheme that causes the problem to occur. [1] http://kerneltrap.org/mailarchive/linux-kernel/2008/6/11/2092024 -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#498795: Should automatically load required udebs for the nslu2
On Sat, Sep 13, 2008 at 13:17, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > Gordon, can you please test the patch below. The easiest way is > probably to unpack a daily image, add the script to > /lib/debian-installer-startup.d/ and to repack the image (but you can > of course rebuild rootskel with this patch and stick the udeb into > localudebs). The patch works on the NSLU2. I didn't see partman-auto, partman-ext3, and usb-storage-modules-* in the list of installer modules as you described. I think that this change is a huge improvement because it makes the installer more seamless for the user. It may trouble some of the etch installer users at first, but I think that they'll soon get over not having to select the correct modules ;-) Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#496166: DFSG installer fails on Linksys NSLU2
Package: hw-detect Version: 1.65 Severity: important Tags: d-i, patch Debian Installer images that do not contain the IXP4xx NPE-B microcode cause the installation of Debian on the Linksys NSLU2 to fail, unless the user has access to a serial console. The installer detects that the ixp4xx_eth module has requested the NPE-B microcode, and displays following text in the "Detect network hardware" dialog box: --- Some of your hardware needs non-free firmware files to operate. The firmware can be loaded from removable media, such as a USB stick or floppy. The missing firmware files are: NPE-B If you have such media available now, insert it, and continue. Load missing firmware from removable media? --- The installer will appear to freeze for users that do not have serial console access, and they will never be able to proceed. Martin Michlmayr proposed the following workaround, which works, but he wasn't sure whether this was the correct way to solve the problem [1]. Index: oldsys-preseed === --- oldsys-preseed (revision 55149) +++ oldsys-preseed (working copy) @@ -46,6 +46,9 @@ INTERFACE=eth0 else INTERFACE=eth1 + if [ "$NONINTERACTIVE" = "yes" ]; then + add "$FILE" "hw-detect/load_firmware" "boolean" "false" + fi fi fi if [ "$NET_CONFIG" != "static" ]; then Gordon [1] http://lists.debian.org/debian-boot/2008/08/msg00646.html -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Potential problem with DFSG installations on NSLU2
Hi Martin On Thu, Aug 21, 2008 at 02:52, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > Can you try the following patch? I don't know how the firmware > handling is done, but at the moment oldsys-preseed will use eth1 if > /lib/firmware/NPE-B is not available. So for now we can simply skip > the firmware question in this case, but I'm pretty sure this is not > the right thing to do, so we have to look again at this after lenny. > I've no idea how firmware is handled, so I hope joeyh can look into > this. > > Index: oldsys-preseed > === > --- oldsys-preseed (revision 55149) > +++ oldsys-preseed (working copy) > @@ -46,6 +46,9 @@ >INTERFACE=eth0 >else >INTERFACE=eth1 > + if [ "$NONINTERACTIVE" = "yes" ]; then > + add "$FILE" > "hw-detect/load_firmware" "boolean" "false" > + fi > fi >fi >if [ "$NET_CONFIG" != "static" ]; then The patch works. Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Potential problem with DFSG installations on NSLU2
Hi Martin On Thu, Aug 21, 2008 at 02:52, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > Can you try the following patch? I don't know how the firmware > handling is done, but at the moment oldsys-preseed will use eth1 if > /lib/firmware/NPE-B is not available. So for now we can simply skip > the firmware question in this case, but I'm pretty sure this is not > the right thing to do, so we have to look again at this after lenny. > I've no idea how firmware is handled, so I hope joeyh can look into > this. I should have posted the log from the installer. It looks like check-missing-fimeware.sh in the hw-detect package checks for and loads missing firmware. I don't understand its implementation (yet), so I can't suggest a better patch right now. Aug 21 12:50:02 check-missing-firmware: no missing firmware in /tmp/missing-firmware Aug 21 12:50:04 net/hw-detect.hotplug: Detected hotpluggable network interface eth0 Aug 21 12:50:04 net/hw-detect.hotplug: Detected hotpluggable network interface eth1 Aug 21 12:50:04 net/hw-detect.hotplug: Detected hotpluggable network interface lo Aug 21 12:50:06 kernel: [42949405.12] firmware: requesting NPE-B Aug 21 12:50:06 kernel: [42949405.19] eth1: link up, 100Mbps, full-duplex, lpa 0x45E1 Aug 21 12:50:07 check-missing-firmware: missing firmware files (NPE-B) for ixp4xx_eth Aug 21 12:50:13 main-menu[871]: (process:915): ip: SIOCSIFFLAGS: No such file or directory Aug 21 12:50:13 main-menu[871]: INFO: Menu item 'ethdetect' succeeded but requested to be left unconfigured. I'll try out the the patch later today. Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Potential problem with DFSG installations on NSLU2
Hi All In the past, Debian could be installed on an NSLU2 using the installer image that did not contain the NPE-B firmware by using a USB to Ethernet adapter. I tried this configuration with a daily snapshot last night, and was presented with the following text in the "Detect network hardware" dialog box. --- Some of your hardware needs non-free firmware files to operate. The firmware can be loaded from removable media, such as a USB stick or floppy. The missing firmware files are: NPE-B If you have such media available now, insert it, and continue. Load missing firmware from removable media? --- I confirmed that my USB to Ethernet adapter is detected by checking that the modules were loaded (asix and usbnet in this case). ~ # lsmod Module Size Used by asix 14496 0 usbnet 15622 1 asix evdev 8608 0 ohci_hcd 18212 0 ehci_hcd 35148 0 ixp4xx_eth 12216 0 ixp4xx_npe 7936 2 ixp4xx_eth ixp4xx_beeper 2720 0 firmware_class 7552 1 ixp4xx_npe ixp4xx_qmgr 5336 1 ixp4xx_eth usbcore 128252 5 asix,usbnet,ohci_hcd,ehci_hcd For users without serial console access, the installation with this configuration will appear to freeze, and they will never be able to proceed. Is this the intended behaviour? I realize that not many people will install Debian on the NSLU2 without using an image that contains the NPE-B microcode, but it seems that this configuration should still be supported. Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for Debian Installer testing, before D-I Beta1 release
On Wed, Feb 6, 2008 at 6:56 AM, Gordon Farquharson <[EMAIL PROTECTED]> wrote: > Installation on the Linksys NSLU2 will be broken until nslu2-utils > 0.10+r71-14 [1] transitions into testing. This version of nslu2-utils > is only required for DSFG installer images (i.e. no firmware) and for > installer images using kernel versions 2.6.24 and greater. The "and" above should really be an "or". The daily installer images now work. Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Call for Debian Installer testing, before D-I Beta1 release
Hi All On Feb 4, 2008 3:34 PM, Otavio Salvador <[EMAIL PROTECTED]> wrote: > We're starting the work for D-I Beta1 release and we would like ask to > everyone to test the installer as much as possible, especially in not > so common architectures where we receive less general testing. Installation on the Linksys NSLU2 will be broken until nslu2-utils 0.10+r71-14 [1] transitions into testing. This version of nslu2-utils is only required for DSFG installer images (i.e. no firmware) and for installer images using kernel versions 2.6.24 and greater. Gordon [1] http://packages.qa.debian.org/n/nslu2-utils.html -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation on NSLU2 does not complete (initramfs nslu2 hook requires user interaction)
Hi Joey On Feb 2, 2008 7:14 PM, Joey Hess <[EMAIL PROTECTED]> wrote: > Martin Michlmayr wrote: > > * Joey Hess <[EMAIL PROTECTED]> [2008-02-02 16:16]: > > > I've uploaded with this patch. Is ixp4xx_eth built into the 2.6.24 > > > kernels in unstable? > > > > No, it's a module. > > So something still needs to be done to get udev to load it? No. I updated Krzysztof's driver so that udev now loads it automatically. The reason the module wasn't being loaded automatically was because a commit in 2.6.24 [1] adds "platform:" to the modalias string for platform devices. On ixp4xx, the Ethernet driver (ixp4xx_eth) is registered as a platform device: LKG7102D7:~# udevinfo -a -p /sys/devices/platform/ixp4xx_eth.16 looking at device '/devices/platform/ixp4xx_eth.16': KERNEL=="ixp4xx_eth.16" SUBSYSTEM=="platform" DRIVER=="" ATTR{modalias}=="platform:ixp4xx_eth" udev uses the modalias string to load the module, and in this case udev tried to modprobe platform:ixp4xx_eth instead of ixp4xx_eth: LKG7102D7:~# udevtest /sys/devices/platform/ixp4xx_eth.16 ... import_uevent_var: import into environment: 'PHYSDEVBUS=platform' import_uevent_var: import into environment: 'MODALIAS=platform:ixp4xx_eth' main: looking at device '/devices/platform/ixp4xx_eth.16' from subsystem 'platform' wait_for_sysfs: file '/sys/devices/platform/ixp4xx_eth.16/bus' appeared after 0 loops main: run: 'socket:/org/kernel/udev/monitor' main: run: '/sbin/modprobe --use-blacklist platform:ixp4xx_eth' All I needed to do was to add MODULE_ALIAS("platform:ixp4xx_eth"); to the Krzysztof's driver. With this change, depmod adds an alias line (alias platform:ixp4xx_eth ixp4xx_eth) to modules.alias which allows modprobe to load the right module. The same thing was happening with the ixp4xx-beeper module, but I have updated that in the kernel as well. Gordon [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=43cc71eed1250755986da4c0f9898f9a635cb3bf -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation on NSLU2 does not complete (initramfs nslu2 hook requires user interaction)
Hi Joey and Martin On Dec 15, 2007 8:19 AM, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > * Gordon Farquharson <[EMAIL PROTECTED]> [2007-12-15 02:13]: > > > if ls -l /sys/class/net/$iface/device | grep -q ixp4xx_mac; then > > > echo "firmware in use" > > It does work (I updated the script above to use the commands in svn > > revision 130). > > Gordon, can you also check which with Krzysztof's driver? I bet this > one uses a different name. Attached is a patch to the nslu2-utils initramfs nslu2 hook that updates the nslu2-utils package to work with Krzysztof's driver. I have also taken the liberty of adding some logic to the initramfs local-top nslu2 script to remove the module loading message that only applies to kernel versions less than 2.6.18. Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 Index: initramfs-tools/hooks/nslu2 === --- initramfs-tools/hooks/nslu2 (revision 132) +++ initramfs-tools/hooks/nslu2 (working copy) @@ -7,7 +7,7 @@ } need_ethernet() { - if [ -n "$(lsmod |egrep 'ixp400_eth|ixp4xx_npe')" ]; then + if [ -n "$(lsmod |egrep 'ixp400_eth|ixp4xx_npe|ixp4xx_eth')" ]; then return 0 else return 1 @@ -50,7 +50,7 @@ fi fi ;; -*) +2.6.1[8-9]* | 2.6.20* | 2.6.2[1-3]*) if [ ! -e "/lib/firmware/NPE-B" ]; then echo "Warning: ixp4xx_npe ethernet driver firmware file /lib/firmware/NPE-B not found" >&2 if need_ethernet; then @@ -65,6 +65,21 @@ fi fi ;; +*) +if [ ! -e "/lib/firmware/NPE-B" ]; then +echo "Warning: ixp4xx_npe ethernet driver firmware file /lib/firmware/NPE-B not found" >&2 +if need_ethernet; then +for iface in $(route -n | grep "^0.0.0.0 " | grep UG | sed 's/.* //'); do +if [ -n "$iface" ] && readlink /sys/class/net/"$iface"/device 2>/dev/null | grep -q ixp4xx_eth; then +echo "Warning: This system is using the ixp4xx_eth ethernet module;" >&2 +echo "it's not safe to create an initramfs image for the new kernel" >&2 +echo "without the firmware file." >&2 +pause_error +fi +done +fi +fi +;; esac # Record the root filesystem device for use during boot, since the slug's Index: initramfs-tools/scripts/local-top/nslu2 === --- initramfs-tools/scripts/local-top/nslu2 (revision 132) +++ initramfs-tools/scripts/local-top/nslu2 (working copy) @@ -16,7 +16,10 @@ # This driver is non-free; load if available. # As of 2.6.18, it's replaced with a free driver that will be loaded by # udev. -echo "Loading Intel IXP400 ethernet driver" -if ! modprobe ixp400_eth; then - echo "Failed to load Intel IXP400 ethernet driver" +version=$(uname -r | cut -c -6) +if [ "$version" \< "2.6.18" ]; then + echo "Loading Intel IXP400 ethernet driver" + if ! modprobe ixp400_eth; then + echo "Failed to load Intel IXP400 ethernet driver" + fi fi
Re: Installation on NSLU2 does not complete (initramfs nslu2 hook requires user interaction)
Hi Martin On Dec 15, 2007 8:19 AM, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > * Gordon Farquharson <[EMAIL PROTECTED]> [2007-12-15 02:13]: > > > if ls -l /sys/class/net/$iface/device | grep -q ixp4xx_mac; then > > > echo "firmware in use" > > It does work (I updated the script above to use the commands in svn > > revision 130). > > Gordon, can you also check which with Krzysztof's driver? I bet this > one uses a different name. The name is different with Krzysztof's driver: lrwxrwxrwx 1 root root 0 Feb 1 01:17 /sys/class/net/eth0/device -> ../../../devices/platform/ixp4xx_eth.16 Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Installation on NSLU2 does not complete (initramfs nslu2 hook requires user interaction)
Hi Joey On Dec 12, 2007 1:26 PM, Joey Hess <[EMAIL PROTECTED]> wrote: > iface=$(ip route | grep '^default' | cut -d ' ' -f 5) > if ls -l /sys/class/net/$iface/device | grep -q ixp4xx_mac; then > echo "firmware in use" > else > echo "firmware not in use" > fi > > Does this work on your slugs with and without the firmware? I have > an unreleased nslu2-utils in svn that adds this test. It does work (I updated the script above to use the commands in svn revision 130). On a slug with the NPE firmware: ++ route -n ++ grep '^0.0.0.0 ' ++ grep UG ++ sed 's/.* //' + iface=eth0 + '[' -n eth0 ']' + readlink /sys/class/net/eth0/device + grep -q ixp4xx_mac + echo 'firmware in use' firmware in use On a slug without the NPE firmware: ++ route -n ++ grep '^0.0.0.0 ' ++ grep UG ++ sed 's/.* //' + iface=eth1 + '[' -n eth1 ']' + readlink /sys/class/net/eth1/device + grep -q ixp4xx_mac + echo 'firmware not in use' firmware not in use I also built nslu2-utils from the repository and installed it on a machine that does not have the NPE firmware. It it generated the initramfs without user intervention, whereas 0.10+r71-13 complained that the firmware file did not exist and required user intervention before it would generate the initramfs. Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Installation on NSLU2 does not complete (initramfs nslu2 hook requires user interaction)
Hi Joey Installation on the NSLU2 using the daily build from 2007/12/01 stops when generating the initramfs: Dec 3 05:15:48 in-target: update-initramfs: Generating /boot/initrd.img-2.6.22-3-ixp4xx Dec 3 05:18:21 in-target: Warning: ixp4xx_npe ethernet driver firmware file /lib/firmware/NPE-B not found Dec 3 05:18:21 in-target: Warning: This system has an ethernet module loaded; it's not safe to Dec 3 05:18:21 in-target: create an initramfs image for the new kernel without the firmware file. Dec 3 05:18:21 in-target: Dec 3 05:18:22 in-target: Press Ctrl-C to abort build, or Enter to continue nslu2-utils is version 0.10+r71-13, but I don't see any changes to the initramfs hook that should cause this problem. I am using a DFSG image that does not contain the NPE-B firmware. /target # lsmod Module Size Used by ext3 136232 1 jbd59208 1 ext3 vfat 13184 0 fat55452 1 vfat ext2 67720 0 mbcache 8996 2 ext3,ext2 sd_mod 26704 3 usb_storage80139 2 scsi_mod 114156 2 sd_mod,usb_storage asix 17920 0 usbnet 19560 1 asix evdev 10304 0 ixp4xx_mac 19284 0 ixp4xx_beeper 3424 0 ixp4xx_qmgr 8396 5 ixp4xx_mac ohci_hcd 18468 0 ehci_hcd 33292 0 ixp4xx_npe 14144 2 ixp4xx_mac firmware_class 10240 1 ixp4xx_npe usbcore 129244 6 usb_storage,asix,usbnet,ohci_hcd,ehci_hcd /target # ifconfig eth1 Link encap:Ethernet HWaddr 00:14:BF:FE:2A:4E inet addr:192.168.1.67 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:74379 errors:0 dropped:0 overruns:0 frame:0 TX packets:54288 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:105886452 (100.9 MiB) TX bytes:4298207 (4.0 MiB) loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 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:0 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Daily Images Fail to Install
dBoot partitions found on MTD device IXP4XX-Flash.0 Creating 6 MTD partitions on "IXP4XX-Flash.0": 0x-0x0004 : "RedBoot" NSLU2 MAC: 00:14:bf:71:02:d7 0x0004-0x0006 : "SysConf" 0x0006-0x0008 : "Loader" 0x0008-0x001e : "Kernel" 0x001e-0x007e : "Ramdisk" 0x007e-0x0080 : "FIS directory" mice: PS/2 mouse device common for all mice i2c /dev entries driver x1205 0-006f: chip found, driver version 1.0.7 x1205 0-006f: rtc core: registered x1205 as rtc0 i2c-gpio i2c-gpio.0: using pins 7 (SDA) and 6 (SCL) Registered led device: ready Registered led device: status Registered led device: disk-1 Registered led device: disk-2 NET: Registered protocol family 26 TCP bic registered NET: Registered protocol family 1 NET: Registered protocol family 17 XScale DSP coprocessor detected. x1205 0-006f: setting the system clock to 2007-11-24 07:03:36 (1195887816) Freeing init memory: 100K /build/buildd/cdebconf-0.125/src/debconf.c:135 (main): Cannot initialize debconf template database -- Gordon Farquharson GnuPG Key ID: 32D6D676
Bug#448036: Memory savings
Hi Martin On Oct 26, 2007 2:49 AM, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > lowmem 2 Oct 25 13:45:22 - Oct 25 14:49:07 1:04 > lowmem 1 Oct 25 16:54:59 - Oct 25 19:46:35 2:52 I still get the same results with lowmem level 1 installations and flash-kernel_1.5 (corrected menu-item number) and main-menu_1.22. I thought that maybe now the installation order was fixed, I may get a different result. Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#448325: marked as done (Incorrect installation order on NSLU2 with main-menu_1.22)
Hi Joey On 10/29/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > * Joey Hess <[EMAIL PROTECTED]> [2007-10-29 16:12]: > > Debian Bug Tracking System wrote: > > > Thanks, Joey. Installations now work properly on NSLU2. > > > > FWIW, I can't see how flash-kernel ordering would influence > > localechooser/clock-setup ordering at all. Also, main-menu is still at > > version 1.22 for arm, 1.22 has not built yet. It's not clear to me which > > versions Gordon is testing with. In my test with 1.21, localechooser and > > clock-setup ran at the right times. Thanks for resolving this bug, Joey. Not that it matters much anymore, but in my testing, I had used a locally built copy of main-menu_1.22 for arm when I built the installer. The flash-kernel-installer version was 1.4. Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange installation order
Hi Otavio On 10/27/07, Otavio Salvador <[EMAIL PROTECTED]> wrote: > Can you both file a proper bug on main-menu so we can add it on the > blocker list? I submitted #448325. Please adjust the severity as appropriate. Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#448325: Incorrect installation order on NSLU2 with main-menu_1.22
Package: main-menu Version: 1.22 Severity: serious It appears that main-menu_1.22 causes an incomplete installation on the Linksys NSLU2. Martin Michlmayr reported an unusual installation order on the NSLU2 [1]. The installer image used for that test used main-menu_1.21. Based on the discussion in the thread, main-menu_1.22 was uploaded, but now the installer fails to run flash-kernel-installer. As a result, the system fails to boot, because the kernel and initrd are not written to the system flash. Also, clock-setup is not run during the installation and localechooser is out of order and left unconfigured. The order of the installation was extracted from the installer /var/log/syslog and is shown below. $ grep 'Menu item' syslog Oct 27 05:18:53 main-menu[1161]: INFO: Menu item 'kbd-chooser' selected Oct 27 05:18:54 main-menu[1161]: INFO: Menu item 'ethdetect' selected Oct 27 05:19:10 main-menu[1161]: INFO: Menu item 'netcfg' selected Oct 27 05:19:12 main-menu[1161]: INFO: Menu item 'network-console' selected Oct 27 05:20:54 main-menu[2481]: INFO: Menu item 'choose-mirror' selected Oct 27 05:21:23 main-menu[2481]: INFO: Menu item 'download-installer' selected Oct 27 05:22:59 main-menu[2481]: INFO: Menu item 'bootstrap-base' selected Oct 27 06:19:07 main-menu[2481]: INFO: Menu item 'user-setup-udeb' selected Oct 27 06:19:32 main-menu[2481]: INFO: Menu item 'apt-setup-udeb' selected Oct 27 06:20:36 main-menu[2481]: INFO: Menu item 'pkgsel' selected Oct 27 06:56:31 main-menu[2481]: INFO: Menu item 'nobootloader' selected Oct 27 06:56:46 main-menu[2481]: INFO: Menu item 'finish-install' selected Oct 27 06:58:58 main-menu[25048]: INFO: Menu item 'localechooser' selected Oct 27 06:58:59 main-menu[25048]: INFO: Menu item 'localechooser' succeeded but requested to be left unconfigured. Oct 27 06:59:01 main-menu[25048]: INFO: Menu item 'localechooser' selected Oct 27 06:59:01 main-menu[25048]: INFO: Menu item 'localechooser' succeeded but requested to be left unconfigured. Oct 27 06:59:06 main-menu[25048]: INFO: Menu item 'save-logs' selected The installer image was built from svn://svn.debian.org/d-i/trunk/installer, SVN revision 49892. Gordon [1] http://lists.debian.org/debian-boot/2007/10/msg00563.html -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange installation order
Hi Martin On 10/20/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > at the end. After flash-kernel-installer, it suddenly presented me > with localechooser. lowmem removed the logs and then I got > clock-setup, user-setup, apt-setup, pkgsel. Just to confirm: localechooser supposed to run at this point in the installation so that the time zone is set correctly. Therefore, the only item that is out of order is flash-kernel-installer. Is this correct? Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange installation order
Hi Martin On 10/27/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > * Gordon Farquharson <[EMAIL PROTECTED]> [2007-10-27 01:02]: > > I built an installer with main-menu_1.22, and flash-kernel was never > > run during the installation. > > Was localechooser run before or after base-installer? I briefly tried > an image based on 1.22 and it seemed localechooser was still not run > before base-installer, but it was a quick test only and maybe I got > something wrong. Looks like localechooser was selected after finish-install. $ grep 'Menu item' syslog Oct 27 05:18:53 main-menu[1161]: INFO: Menu item 'kbd-chooser' selected Oct 27 05:18:54 main-menu[1161]: INFO: Menu item 'ethdetect' selected Oct 27 05:19:10 main-menu[1161]: INFO: Menu item 'netcfg' selected Oct 27 05:19:12 main-menu[1161]: INFO: Menu item 'network-console' selected Oct 27 05:20:54 main-menu[2481]: INFO: Menu item 'choose-mirror' selected Oct 27 05:21:23 main-menu[2481]: INFO: Menu item 'download-installer' selected Oct 27 05:22:59 main-menu[2481]: INFO: Menu item 'bootstrap-base' selected Oct 27 06:19:07 main-menu[2481]: INFO: Menu item 'user-setup-udeb' selected Oct 27 06:19:32 main-menu[2481]: INFO: Menu item 'apt-setup-udeb' selected Oct 27 06:20:36 main-menu[2481]: INFO: Menu item 'pkgsel' selected Oct 27 06:56:31 main-menu[2481]: INFO: Menu item 'nobootloader' selected Oct 27 06:56:46 main-menu[2481]: INFO: Menu item 'finish-install' selected Oct 27 06:58:58 main-menu[25048]: INFO: Menu item 'localechooser' selected Oct 27 06:58:59 main-menu[25048]: INFO: Menu item 'localechooser' succeeded but requested to be left unconfigured. Oct 27 06:59:01 main-menu[25048]: INFO: Menu item 'localechooser' selected Oct 27 06:59:01 main-menu[25048]: INFO: Menu item 'localechooser' succeeded but requested to be left unconfigured. Oct 27 06:59:06 main-menu[25048]: INFO: Menu item 'save-logs' selected Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Strange installation order
Hi Martin On 10/25/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > I copied th etch main-menu binary to the image and saw the same > problem. Did I actually have to rebuild the image with etch main-menu > or should copying the binary have been enough? I guess it was enough > and that the bug is somewher else... I built an installer with main-menu_1.22, and flash-kernel was never run during the installation. Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#448036: [EMAIL PROTECTED]: Re: Memory savings]
Hi Joey On 10/25/07, Joey Hess <[EMAIL PROTECTED]> wrote: > Martin Michlmayr wrote: > > Below are the last few messages in syslog. I ran out of time before I > > was able to fully investigate this problem, so I don't know if it is a > > symptom of using lowmem level 1 for the installation. > > > > Oct 22 12:08:44 LKG7102D7 /usr/sbin/cron[1790]: (CRON) INFO (pidfile fd = 3) > > Oct 22 12:08:44 LKG7102D7 /usr/sbin/cron[1791]: (CRON) STARTUP (fork ok) > > Oct 22 12:08:44 LKG7102D7 /usr/sbin/cron[1791]: (CRON) INFO (Running > > @reboot jobs) > > Oct 22 12:08:51 LKG7102D7 kernel: eth1: no IPv6 routers present > > Oct 22 12:17:01 LKG7102D7 /USR/SBIN/CRON[1891]: (root) CMD ( cd / && > > run-parts --report /etc/cron.hourly) > > Does /etc/inittab have a correctly configured getty? Cron is probably > just the last service started. I haven't managed to recreate this problem with newer daily builds. Gordon -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Memory savings
05:44:23 apt-install: update-initramfs: Generating /boot/initrd.img-2.6.22-2-ixp4xx Oct 22 05:47:15 apt-install: Warning: ixp4xx_npe ethernet driver firmware file /lib/firmware/NPE-B not found Oct 22 05:47:15 apt-install: Warning: This system has an ethernet module loaded; it's not safe to Oct 22 05:47:15 apt-install: create an initramfs image for the new kernel without the firmware file. Oct 22 05:47:15 apt-install: Oct 22 05:47:15 apt-install: Unable to abort; system will probably be broken! Oct 22 05:49:23 apt-install: Reading package lists... elapsed time = 300 seconds -- Gordon Farquharson GnuPG Key ID: 32D6D676 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: installation errors
Hi Dan On Aug 17, 9:10 am, Dan Burt <[EMAIL PROTECTED]> wrote: > when the system is fully up and running, yes, 3 disks. > > but for installation, just the one. I think what Martin was suggesting in his previous message, was try booting with only one disk a attached to see if that works. If it does, then modify your fstab to mount the root disk by UUID [1], then make sure that configuration works, and _then_ only attach the other disks. Gordon [1] http://www.nslu2-linux.org/wiki/Debian/HomePage -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Hi Frans On Apr 18, 8:30 am, Frans Pop <[EMAIL PROTECTED]> wrote: > Huh? Do any debian kernels have IPv6 compiled in then? Probably not (I haven't checked), but I think what he meant by "compiled in" could refer literately to compiled in or loaded as a module. Sorry for the sloppy wording. > Anyway, at least so far it seems that all these issues are specific to arm > somehow, so I'll leave it to you (arm porters) to trace them. It is tricky, because I can't reproduce the problem on my NSLU2 :-) But I'll keep working on it. Gordon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Hi Frans On Apr 16, 9:31 pm, Frans Pop <[EMAIL PROTECTED]> wrote: > Just tried if I could reproduce this IPv6 problem and I cannot, at least > not by just pointing an install to this same mirror and not even after > manually loading the ipv6-modules udeb. > Wonder if that too is something specific to this NSLU2 image... I have been unable to reproduce this problem on my test NSLU2 using a different mirror (ftp.uk.debian.org). This mirror is one that a user on debian-arm is reporting the same problem. Martin Guy reported that he gets these messages when using a kernel that didn't have IPv6 support compiled in, which seems like it would make sense. Gordon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Re: Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Hi Markus On 4/16/07, Markus Knapp <[EMAIL PROTECTED]> wrote: Last week I got a new NSLU2, took the new install-image from http://www.slug-firmware.net/d-dls.php and tried to install. Hardly everithing went good till the installation of the base system. There I got the same error as mentioned here: initramfs-tools could not be installed. I'm not sure why you think what you are seeing is related to #407460, but somebody has reported a similar problem in debian-arm, so let's continue this discussion there for now. Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: NSLU2 install report
On 3/21/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote: * Stephane List <[EMAIL PROTECTED]> [2007-03-19 17:00]: > - it was not clear which Kernel I should choose (I don't remember > exactly, but there's 3 choices looking like : linux, linux 2.6 and > linux-2.6.18.4-ipx4xx) I think I've seen this during an installation once recently, but this really shouldn't happen. It should automatically pick the right one. Have other people seen this too? I've saw this message on an amd64 system last weekend. I haven't done a recent installation on the NSLU2, but I hadn't seen it on the NSLU2 before. > - there's a small message while installing kernel-2.6.18-4 : > ? 09:58:50 Err file capture.c: line 86 (capture_start): > assertion failed: (capture_opts->state == CAPTURE_STOPPED) I've never seen this. Anyone? I'll test out the installer this weekend to see if I can reproduce the message. Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413373: Patch for flash-kernel to improve speed
Hi Geert On 3/4/07, Geert Stappers <[EMAIL PROTECTED]> wrote: My gut feeling[1] says it should be So $tmp is unconditional overwritten with $ifile You are essentially raising the issue that the flash-kernel code does not currently handle initramfs files that are larger than 4 MB in a clean way. In the current code, nslu2_swap will only succeed if the size of the initramfs file is a multiple of 4 bytes. To ensure this assumption is true, the initramfs is padded to 4 MB. That is, there is the potential for an error if there are no padding bytes required. Furthermore, the size of the mtdblock that contains the initramfs is 6 MB, so if the initramfs is greater than 6 MB (again no padding required), the write will fail. In the patch I submitted, $tmp will not exist if $pad is less than 0 (as you pointed out), and therefore the initramfs will not be written to the flash. This situation is bad, because the kernel would have already been written, but with either version of the code, the potential exists for the mtdblock to contain an invalid initramfs after the kernel has been written. It seem that in the long term, the code should be modified so that if either the kernel or the initramfs are too large to fit in the mtdblock partitions, neither is written to the flash and a useful error is reported to the user. but I have no clue to what the 4M corresponds. It is the arbitrarily chosen size to which the initramfs is padded to ensure that the image can be endian swapped (AFAIK). I know that if one tries to pad the initramfs to the size that is modulo 4 bytes greater than the actual size (which seems that it should be all that is required to swap the image), the kernel fails to recognize the initramfs as a valid image. I don't know the reason for this behaviour though. Something else: "isize" is not used in the proposed + dd if=$ifile of=$tmp ibs=4M conv=sync 2>/dev/null not calculating $isize will also speed up flashing the kernel. isize is still used. It is the parameter which is passed to sercomm_header. Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#413373: Patch for flash-kernel to improve speed
Package: flash-kernel Version: 1.1 Tags: Patch The attached patch reduces the running time of flash-kernel on the NSLU2 by almost 30 seconds. The change should also apply to the Thecus N2100, but I am not able to test it. # /usr/bin/time -f "elapsed %e system %S user %U" flash-kernel Flashing kernel: done. Flashing initramfs: done. elapsed 122.09 system 2.93 user 0.72 # /usr/bin/time -f "elapsed %e system %S user %U" ./flash-kernel Flashing kernel: done. Flashing initramfs: done. elapsed 93.85 system 2.95 user 0.78 Gordon -- Gordon Farquharson --- flash-kernel.orig 2007-03-03 11:42:45.0 -0700 +++ flash-kernel 2007-03-03 13:30:35.0 -0700 @@ -131,10 +131,9 @@ size=$(grep "Ramdisk" /proc/mtd | cut -d " " -f 2) size=$(printf "%d" 0x$size) isize=$(wc -c $ifile | awk '{print $1}') - cat $ifile > $tmp pad=$(expr $size - $isize - 16) if [ "$pad" -gt 0 ]; then - dd if=/dev/zero bs=$pad count=1 2>/dev/null >> $tmp + dd if=$ifile of=$tmp ibs=4M conv=sync 2>/dev/null fi ( sercomm_header $isize
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
On 2/25/07, Gordon Farquharson <[EMAIL PROTECTED]> wrote: How about the following idea for a quick and simple workaround to this problem (it is based on something Steve suggested earlier in the thread). Include the ixp4xx NPE driver modules in both the official and unofficial installer images and modify oldsys-preseed with the patch below. I have tested the installer (revision 45431) both with and without the NPE-B microcode and everything worked fine on my setup. I also tested the case where the user may have both a USB to Ethernet adapter and the NPE-B microcode, and everything worked. For these tests, I told the installer to use packages from unstable to work around #412572 because the fix hadn't hit testing by the time I started yesterday and I was too lazy to recompile apex with a different kernel command line. All my tests have been using a static IP address which is configured in the NSLU2 flash. I should probably try a DHCP served address just to make sure that it doesn't change anything. Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Hi Martin I tried a build of the installer from trunk (revision 45431) and nearly fell of my chair: --- [!!] Install the base system Unable to install initramfs-tools An error was returned while trying to install the initramfs-tools package onto the target system. Check /var/log/syslog or see virtual console 4 for the details. --- Needless to say that this problem did not occur when I tested my changes to oldsys-preseed on Sunday night. The notable difference in the build since Sunday night is the new kernel 2.6.18.dfsg.1-11 and associated udebs. However, the problem does not seem to be due to apt seg faulting. ~ # chroot /target sh-3.1# apt-get -f install Reading package lists... Done Building dependency tree... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Here is the relevant output from syslog: Feb 27 05:47:18 base-installer: info: Using kernel 'linux-image-2.6-ixp4xx' Feb 27 05:47:19 base-installer: info: Setting do_initrd='yes'. Feb 27 05:47:19 base-installer: info: Setting link_in_boot='yes'. Feb 27 05:47:20 base-installer: info: Available initramfs generator(s): 'initramfs-tools yaird' Feb 27 05:47:21 apt-install: Reading package lists... Feb 27 05:47:21 apt-install: Feb 27 05:47:21 apt-install: Building dependency tree... Feb 27 05:47:27 apt-install: Feb 27 05:47:28 apt-install: The following extra packages will be installed: Feb 27 05:47:28 apt-install: busybox klibc-utils libklibc libvolume-id0 udev Feb 27 05:47:28 apt-install: The following NEW packages will be installed: Feb 27 05:47:28 apt-install: busybox initramfs-tools klibc-utils libklibc libvolume-id0 udev Feb 27 05:47:29 apt-install: 0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded. Feb 27 05:47:29 apt-install: Need to get 932kB of archives. Feb 27 05:47:29 apt-install: After unpacking 2541kB of additional disk space will be used. Feb 27 05:47:29 apt-install: WARNING: The following packages cannot be authenticated! Feb 27 05:47:29 apt-install: libvolume-id0 udev busybox libklibc klibc-utils initramfs-tools Feb 27 05:47:29 apt-install: E: Feb 27 05:47:29 apt-install: There are problems and -y was used without --force-yes Feb 27 05:47:29 apt-install: Feb 27 05:47:29 base-installer: error: exiting on error base-installer/kernel/failed-package-install In the chroot: sh-3.1# apt-get install libvolume-id0 udev busybox libklibc klibc-utils initramfs-tools Reading package lists... Done Building dependency tree... Done The following NEW packages will be installed: busybox initramfs-tools klibc-utils libklibc libvolume-id0 udev 0 upgraded, 6 newly installed, 0 to remove and 0 not upgraded. Need to get 932kB of archives. After unpacking 2541kB of additional disk space will be used. WARNING: The following packages cannot be authenticated! libvolume-id0 udev busybox libklibc klibc-utils initramfs-tools Install these packages without verification [y/N]? n E: Some packages could not be authenticated Looks like a problem with the signatures for these packages. Is this problem just on ARM or installer-wide, or does the problem lie somewhere else ? Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
ne. # MAC addresses must be written in lowercase. # USB device 13b1:0018 (asix) SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:14:bf:fe:2a:4e", NAME="eth1" * Unofficial (with ixp4xx_* and NPE microcode): $ cat /etc/network/interfaces # This file describes the network interfaces available on your system # and how to activate them. For more information, see interfaces(5). # The loopback network interface auto lo iface lo inet loopback # The primary network interface allow-hotplug eth0 iface eth0 inet static address 192.168.1.67 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 205.171.3.65 205.171.2.65 dns-search example.org $ cat /etc/udev/rules.d/z25_persistent-net.rules # This file was automatically generated by the /lib/udev/write_net_rules # program, probably run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single line. # MAC addresses must be written in lowercase. # USB device 13b1:0018 (asix) SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:14:bf:fe:2a:4e", NAME="eth1" # Unknown net device (/class/net/eth0) (ixp4xx_mac) SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:14:bf:71:02:d7", NAME="eth0" -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Introduction
Hi Joey On 2/23/07, Joey Hess <[EMAIL PROTECTED]> wrote: The slug boots into lowmem level 2, in which all standard priority udebs are not automatically selected. Amoung those not auto-selected is usb-storage-modules. So if you don't manually pick it from the list, no disk.. Did I miss your point - do you think that it should be included manually regardless of lowmem level 2 given that to complete a Debian installation, a disk is essential ? Is this possible ? Wouldn't this idea also apply to scsi-core-modules ? Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Introduction
Hi Joey On 2/23/07, Joey Hess <[EMAIL PROTECTED]> wrote: The slug boots into lowmem level 2, in which all standard priority udebs are not automatically selected. Amoung those not auto-selected is usb-storage-modules. So if you don't manually pick it from the list, no disk.. Martin's instructions [1], which most people use as a guide when installing Debian, tells one that usb-storage-modules needs to be selected for the installation to succeed. Gordon [1] http://www.cyrius.com/debian/nslu2/install.html -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Introduction
Hi Geert On Feb 20, 2:10 pm, [EMAIL PROTECTED] (Geert Stappers) wrote: > Welcome aboard! Thanks ! Gordon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Introduction
Hi All Frans Pop asked me to introduce myself to debian-boot as I have recently been given commit access to the installer subversion repository. Over the past five months or so, I have been helping Martin Michlmayr prepare etch on the ARM-based Linksys NSLU2. I have been most active in testing and contributing to the Debian kernel, but also have been regularly testing and helping fix installer daily builds. My guest account on alioth is gordon-guest. Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403195: installation: Finnish timezone not selected by the etch installer
On 2/19/07, Frans Pop <[EMAIL PROTECTED]> wrote: I would advise against that. If you do, the language question will be asked too during timezone configuration and that really does not make any sense anymore at that point. Thanks, Frans. Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403195: installation: Finnish timezone not selected by the etch installer
On 2/19/07, Gordon Farquharson <[EMAIL PROTECTED]> wrote: Just for interest, I'm going to see what happens if one includes localechooser in the installer image, but no preselected country. Badness ! That's what happens. If localechooser is included in the installer initrd and a country is not preseeded, localechooser will ask the user to select a country before the network is configured. Martin, do you want to remove localechooser from the installer for all ARM platforms or just ixp4xx ? Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403195: installation: Finnish timezone not selected by the etch installer
On 2/18/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote: 16:20 < fjp> What about not including countrychooser in the initrd and not preseeding the country? 16:21 < fjp> s/countrychooser/localechooser/ 16:22 < fjp> It is what s/390 does with locale preseeded to C. Then the country gets asked for the timezone as tzconfig depends on localechooser. (IIRC) Gordon, do you think you could try that? It works ! I removed localechooser from the installer image by adding 'localechooser -' to pkg-lists/netboot/arm/ixp4xx.cfg, and I commented out the line add "$FILE" "countrychooser/country-name" "select" "United States" in packages/oldsys-preseed/oldsys-preseed. With these changes, the installer allows one to select a country after partitioning the drive, but before selecting time zone, as Frank suggested. Just for interest, I'm going to see what happens if one includes localechooser in the installer image, but no preselected country. Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403195: installation: Finnish timezone not selected by the etch installer
On 2/19/07, Gordon Farquharson <[EMAIL PROTECTED]> wrote: How do I tell the installer not add a preselected country to preseed.cfg ? Found it ! packages/oldsys-preseed/oldsys-preseed Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403195: installation: Finnish timezone not selected by the etch installer
Hi Martin On 2/18/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote: 16:20 < fjp> What about not including countrychooser in the initrd and not preseeding the country? 16:21 < fjp> s/countrychooser/localechooser/ 16:22 < fjp> It is what s/390 does with locale preseeded to C. Then the country gets asked for the timezone as tzconfig depends on localechooser. (IIRC) Gordon, do you think you could try that? I removed localechooser from the installer image by adding 'localechooser -' to pkg-lists/netboot/arm/ixp4xx.cfg and confirmed that initrd/usr/bin/localechooser no longer existed in the installer initrd. However, the preseed.cfg file that exists/is created in the root directory of the installer, still contains a selected country, and therefore the time zone menu still only gives me US time zones from which to select. ~ # cat preseed.cfg # Preseed file to make d-i download udebs from unstable, useful for daily # builds and development builds. d-i mirror/udeb/suite string unstable d-i mirror/udeb/suite seen false d-i ethdetect/use_firewire_ethernet boolean false d-i debian-installer/locale string C d-i countrychooser/country-name select United States d-i lowmem/low note d-i netcfg/get_hostname string debian d-i netcfg/get_domain string example.org d-i network-console/password password install d-i network-console/password-again password install d-i partconf/already-mounted boolean false d-i netcfg/choose_interface select eth0 d-i netcfg/get_ipaddress string 192.168.1.67 d-i netcfg/get_netmask string 255.255.255.0 d-i netcfg/get_gateway string 192.168.1.1 d-i netcfg/get_nameservers string 205.171.3.65 205.171.2.65 d-i netcfg/confirm_static boolean true d-i netcfg/disable_dhcp boolean true d-i netcfg/get_hostname string LKG7102D7 How do I tell the installer not add a preselected country to preseed.cfg ? Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Hi Marco On 2/12/07, Marco d'Itri <[EMAIL PROTECTED]> wrote: > being added on my test system, does this tells whether something like > DRIVERS=="?*" is matching or not ? Apparently not. I see that I already suggested this in my first reply on december 14. Yeah, your comment in your previous email is what prompted me to ask the question :-) > It seems that the real question is what sequence of events causes an > interface to be named eth1_rename, as opposed to the next available > interface name (e.g. eth1). I'll see if I can figure this out from the I explained this today. Ok, I thought that you meant that the interface would be renamed to the next available interface name e.g. 'eth0' would become 'eth1', not 'eth1_rename'. Sorry for the misunderstanding. I do not think I can help you further if you ignore what I write. Ok. Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Hi Marco On 2/12/07, Marco d'Itri <[EMAIL PROTECTED]> wrote: On Feb 12, Steve Langasek <[EMAIL PROTECTED]> wrote: > > No, wait... When a new network interface is added it will get the next > > available name, this is a supported configuration. > Ok, so this is true when the built-in device is loaded first at boot time > and is initially assigned eth0, there is no rule saying to rename it, and > there is a rule saying to rename another interface to eth0? If there is already a rule to rename some other device to eth0 then the current eth0 will be renamed to the first free name and a new rule will be created for it. Will udev add this new rule to /etc/udev/rules.d/z25_persistent-net.rules ? Since no new rules are being added on my test system, does this tells whether something like DRIVERS=="?*" is matching or not ? It seems that the real question is what sequence of events causes an interface to be named eth1_rename, as opposed to the next available interface name (e.g. eth1). I'll see if I can figure this out from the code. Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Hi Steve On 2/12/07, Steve Langasek <[EMAIL PROTECTED]> wrote: The problem seems as simple as that the ipx4xx driver is *not* included in d-i, but is included in the installed kernel; so in the installer, the module is never loaded resulting in the USB adapter getting the eth0 name, but after a reboot the ipx4xx driver is found first, breaking the handling of persistent device names. Yup. The original reason it wasn't included in the installer is because including it without the NPE-B microcode causes the NLSU2 built-in ethernet adapter to be named eth0, and the installer, by default, uses eth0 to provide the installation interface. This situation makes the installer inaccessible to users without a serial console attached to the NSLU2. Which means in turn that a simple fix would be to make ixp4xx available in the installer so that it can be detected; it certainly makes sense to me that the onboard ethernet ought to be "eth0", even if it needs extra firmare to be usable. Currently, if we include the ixp4xx NPE driver, and tell the installer to use eth1 (the USB to ethernet adapter) by default, we would prevent people that do not have a USB to ethernet adapter from using the unofficial Debian installer image that includes the NPE-B microcode and which is made available through http://www.slug-firmware.net/. We would have to change the installer default interface based on whether or not we had the NPE-B microcode present in the image. This solution will only work if interfaces are always detected in the same order, which may not be reliable. Adding an extra naming rule should never fail, so, although I dislike this solution, it seems more reliable. It does mean that the interface name for the built-in ethernet will depend how you installed Debian on the NSLU2, and this could cause headaches down the line in terms of support (maybe). Finally, as popular as NSLU2 is, this is still a hardware-specific bug, and as such I'm inclined to downgrade this bug report. I'm happy for us to have a well-supported NSLU2 installer in etch, but I don't see that this should be a blocker for the release if it's not addressed in a timely manner. I was hesitant with deciding on the severity of the bug, because 99% will use the unofficial installer image which works great. This bug only affect the probably less than 1% that use a DFSG installation. However, it looks like we should be able to find a solution that works for etch. Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Hi Marco On 2/10/07, Gordon Farquharson <[EMAIL PROTECTED]> wrote: On 1/18/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > Well, I still believe this is a problem with udev. CCing Marco. I just tested a patch [1,2] that was applied to udev to fix the network interface renaming code to see if it would solve this bug, but no luck. The USB ethernet adapter is still (most often) renamed eth1_rename despite the rule to name it eth0 in /etc/udev/rules.d/z25_persistent-net.rules. Gordon [1] http://git.kernel.org/git/?p=linux/hotplug/udev.git;a=commitdiff;h=ca714ef70e549aad486a62f4d6ef849572e3a7f1 [2] http://marc.theaimsgroup.com/?l=linux-hotplug-devel&m=116956926523008&w=2 -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
On 1/18/07, Martin Michlmayr <[EMAIL PROTECTED]> wrote: Well, I still believe this is a problem with udev. CCing Marco. Marco, a while ago, you suggested that the problem could be due to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389250 but I still see the problem with 2.6.20 which includes the patch that apparently fixes 389250. Do you any further ideas ? Martin, in the meantime, what do you think about adding a script to the installer to add the following rule to /etc/udev/rules.d/z25_persistent-net.rules: # Built-in Ethernet Adapter (NPE-B microcode not present) SUBSYSTEM=="net", DRIVERS=="ixp4xx_mac", NAME="eth1" It is a hack, but adding this rule causes the USB Ethernet adapter to be named eth0 as opposed to eth1_rename. The system would therefore be accessible after an installation without the NPE-B microcode, which means that we could downgrade the severity of the bug. I'm not sure where to put such a script in the installer though. Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409747: apex-nslu2 1.4.14 breaks current debian-installer build
Hi Marc On 2/6/07, Marc Singer <[EMAIL PROTECTED]> wrote: I already posted the change. I suppose you could make D-I accept either? It's a bit of a hack, but it does now. Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407460: USB ethernet interface renamed after installation on NSLU2 which causes the system to be inaccessible
Package: debian-installer Version: 20061102 Severity: serious I'm not sure which package to assign this bug to, but since it causes the system to be inaccessible after an install, debian-installer seems like a good place to start. Summary of the problem: After an installation of Debian on the Linksys NSLU2, the system is inaccessible because the USB ethernet interface is renamed eth1_rename. Background: The NSLU2 is an ARM based network available storage device. Support for installing Debian on this system has been added to etch. The NSLU2 has a single built-in ethernet adapter for which a driver has been written and included in the Debian 2.6.18 kernel. However, Debian installer images cannot use this driver, because the network processor engine (NPE) in the IXP4xx CPU requires non-free microcode. Therefore, a USB to ethernet adapter is required to install Debian. Problem description: Debian installs without problems using the USB to ethernet adapter. During the installation, a udev rule is written which names the USB to ethernet adapter to eth0: # cat /etc/udev/rules.d/z25_persistent-net.rules # This file was automatically generated by the /lib/udev/write_net_rules # program, probably run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single line. # MAC addresses must be written in lowercase. # USB device 13b1:0018 (asix) SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:14:bf:fe:2a:4e", NAME="eth0" However, when booting after the installation, the NPE driver seems to assume control of the interface name eth0, which causes something to rename the interface of the USB to ethernet adapter to eth1_rename. From the boot log: IXP4XX NPE driver Version 0.2.0 initialized input: ixp4xx beeper as /class/input/input0 IXP4XX Q Manager 0.2.0 initialized. ixp4xx_mac driver 0.2.1: eth0 on NPE-B with PHY[1] initialized eth1: register 'asix' at usb-:00:01.2-2, ASIX AX88772 USB 2.0 Ethernet, 00:14:bf:fe:2a:4e usbcore: registered new driver asix the output of ifconfig -a: # ifconfig -a eth0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:192.168.1.67 Bcast:192.168.1.255 Mask:255.255.255.0 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) eth1_rena Link encap:Ethernet HWaddr 00:14:BF:FE:2A:4E 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) and the /etc/network/interfaces created by the installer # The primary network interface allow-hotplug eth0 iface eth0 inet static address 192.168.1.67 netmask 255.255.255.0 network 192.168.1.0 broadcast 192.168.1.255 gateway 192.168.1.1 # dns-* options are implemented by the resolvconf package, if installed dns-nameservers 205.171.3.65 205.171.2.65 dns-search example.org This configuration causes the system to be inaccessible unless the user has added a connector for a serial port to the NSLU2. This procedure requires soldering; something most users are not going to do. Here is the relevant output from /dev/hotplug.log with hotplug logging enabled: HOTPLUG_TIME='Thu Jan 18 08:08:22 MST 2007' PHYSDEVPATH=/devices/platform/ixp4xx_mac.0 SUBSYSTEM=net OLDPWD=/ DEVPATH=/class/net/eth0 ACTION=add UDEV_LOG=3 COMMENT=Unknown net device (/class/net/eth0) (ixp4xx_mac) UDEVD_EVENT=1 PHYSDEVDRIVER=ixp4xx_mac INTERFACE=eth0 PHYSDEVBUS=platform SEQNUM=684 Note that eth1 or eth1_rename does not appear in the log. I have tried the latest version of the NPE driver (0.3.1) that has been checked into the Debian kernel repository, but there is no change in the behaviour. IXP4XX NPE driver Version 0.3.0 initialized IXP4XX Q Manager 0.2.1 initialized. ixp4xx_mac driver 0.3.1: eth0 on NPE-B with PHY[1] initialized eth1: register 'asix' at usb-:00:01.2-2, ASIX AX88772 USB 2.0 Ethernet, 00:14:bf:fe:2a:4e I am using the version of debian-installer in trunk, and linux-2.6 2.6.18.dfsg.1-9 (linux-image-2.6.18-4-ixp4xx). I'm still looking for a solution to the problem. Any suggestions would be helpful. Other bugs that may be related: #405845, #406948, and #389250 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=389250 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=405845 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=406948 Gordon -- Gordon Farquharson -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Corrupt dpkg database? No kernels found
On Dec 3, 11:00 pm, Frans Pop <[EMAIL PROTECTED]> wrote: > Could this be due to download errors as described in #401435? > > To test, does disabling TCP window scaling early in the install help? > echo 0 > /proc/sys/net/ipv4/tcp_window_scaling Other people have reported apt-get seg faulting on architectures other than arm. Is anybody else seeing the installer fail in this way with the daily installer builds ? Gordon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Corrupt dpkg database? No kernels found
On Dec 3, 11:00 pm, Frans Pop <[EMAIL PROTECTED]> wrote: > Could this be due to download errors as described in #401435? > > To test, does disabling TCP window scaling early in the install help? > echo 0 > /proc/sys/net/ipv4/tcp_window_scaling I sent a reponse to your message about 9 hours ago, but it hasn't appeared on the list. Here is a summary of my message. I disabled TCP window scaling in the daily build (dated 2006-12-04) initramfs scripts, and instead of the installer stalling at "71% Updating the list of available packages", it failed with "Unable to install initramfs-tools" which is where I was before. So, although disabling TCP window scaling changed something, it didn't fixed the problem. I'm not convinced that it even did anything, because the behaviour of the installer has not been consistent from day to day. There is a new version of apt (0.6.46.3-0.2) that got uploaded yesterday, but the installer was not able to use it because it hadn't reached the mirrors. Also, that version of apt was released to fix a bug on amd64 when running 'apt-get source', so I suspect that it is not going to fix the problem I am seeing. I have posted the results of my testing to http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401263. It seems like this problem is caused by apt-get creating corrupt package cache files when initially setup, and I have offered to send copies of these file to the apt maintainers for analysis. I have had no response yet. Gordon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Corrupt dpkg database? No kernels found
Hi Frans On Dec 3, 3:30 pm, Frans Pop <[EMAIL PROTECTED]> wrote: > On Sunday 26 November 2006 11:56, Martin Michlmayr wrote: > > > I just got an error during the installation because no kernel was > > found. syslog complained about missing dependencies and advised that > > "apt-get -f install" should be run. I entered the target and issues > > that command but apt-get segfaulted. >Has a proper bug report to track this issue been filed now? It looks (to me) like a corrupt pkgcache.bin file is being created when apt is first setup during the install [1]. So, here is a wild, probably not very well thought out idea. Since this problem has only started occurring recently, has something changed in the installation sequence that would cause apt to behave in this way, i.e. is it possible that the installer is abusing apt in some way ? I suspect the answer is no, but I thought that I'd ask anyway. Gordon [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401263;msg=70 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Corrupt dpkg database? No kernels found
On Dec 3, 7:10 pm, "Gordon Farquharson" <[EMAIL PROTECTED]> wrote: > Right now, I'm in the middle of trying the daily build dated 2006-12-02 > to see if anything has changed. For the first time since the daily build dated 2006-11-28, something different happened during the installation. On the first attempt of using the daily build image dated 2006-12-02, the installer could not find any kernel packages for the system. On the second attempt, the installer stalled at "71% Updating the list of available packages". The first symptom could suggest a networking problem like #401435 that Frans pointed out. The second message occurs (I think) when apt-get creates pkgcache.bin and srcpkgcache.bin. It looks like apt got stuck creating srcpkgcache.bin: ~ # ls -l /target/var/cache/apt drwxr-xr-x3 root root12288 Dec 4 03:09 archives -rw-r--r--1 root root 12582912 Dec 4 03:23 pkgcache.bin -rw-r--r--1 root root 6422934 Dec 4 03:23 srcpkgcache.bin Here are the last few messages from the log file for the second run: Dec 4 03:22:42 debootstrap: Setting up apt (0.6.46.2) ... Dec 4 03:22:42 debootstrap: Dec 4 03:22:42 debootstrap: Setting up aptitude (0.4.3-1) ... Dec 4 03:22:43 debootstrap: Dec 4 03:22:43 debootstrap: Setting up apt-utils (0.6.46.2) ... Dec 4 03:22:43 debootstrap: Dec 4 03:22:43 debootstrap: Setting up klogd (1.4.1-18) ... Dec 4 03:22:43 debootstrap: Stopping kernel log daemon: klogd Dec 4 03:22:43 debootstrap: Dec 4 03:22:43 debootstrap: Warning: Fake start-stop-daemon called, doing nothing Dec 4 03:22:43 debootstrap: . Dec 4 03:22:44 debootstrap: Starting kernel log daemon: klogd Dec 4 03:22:45 debootstrap: Dec 4 03:22:45 debootstrap: Warning: Fake start-stop-daemon called, doing nothing Dec 4 03:22:45 debootstrap: . Dec 4 03:22:45 debootstrap: Dec 4 03:22:45 debootstrap: Setting up tasksel-data (2.56) ... Dec 4 03:22:45 debootstrap: Setting up sysklogd (1.4.1-18) ... Dec 4 03:22:46 debootstrap: Stopping system log daemon: syslogd Dec 4 03:22:46 debootstrap: Dec 4 03:22:46 debootstrap: Warning: Fake start-stop-daemon called, doing nothing Dec 4 03:22:46 debootstrap: . Dec 4 03:22:47 debootstrap: Starting system log daemon: syslogd Dec 4 03:22:47 debootstrap: Dec 4 03:22:47 debootstrap: Warning: Fake start-stop-daemon called, doing nothing Dec 4 03:22:47 debootstrap: . Dec 4 03:22:47 debootstrap: Dec 4 03:22:47 debootstrap: Setting up tasksel (2.56) ... Dec 4 03:22:54 debootstrap: Dec 4 03:22:56 base-installer: Get:1 http://debian.osuosl.org etch Release.gpg [378B] Dec 4 03:22:57 base-installer: Hit http://debian.osuosl.org etch Release Dec 4 03:22:57 base-installer: Get:2 http://debian.osuosl.org etch/main Packages/DiffIndex [2038B] Dec 4 03:23:05 base-installer: Fetched 2416B in 9s (261B/s) Dec 4 03:23:05 base-installer: Reading package lists... Next, I'll try out Frans's suggestion of disabling the TCP window scaling early in the install. Maybe all of these problems are due to networking issues. Gordon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Corrupt dpkg database? No kernels found
On Dec 3, 3:30 pm, Frans Pop <[EMAIL PROTECTED]> wrote: > > that command but apt-get segfaulted.Has a proper bug report to track this > > issue been filed now? No, not yet (AFAIK). I've been trying to get to the root of the problem. For an update on the status, have a look at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401263. The seg fault appears to be caused by a corrupted /var/cache/pkgcache.bin, but I'm not sure why this file gets corrupted. Right now, I'm in the middle of trying the daily build dated 2006-12-02 to see if anything has changed. Gordon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Corrupt dpkg database? No kernels found
On Dec 1, 2:40 am, "Gordon Farquharson" <[EMAIL PROTECTED]> wrote: > (gdb) run -f install > Starting program: /usr/bin/apt-get -f install > Reading package lists... Done > Building dependency tree... Done > Correcting dependencies... > Program received signal SIGSEGV, Segmentation fault. > 0x4008d100 in pkgDepCache::Update (this=0x3f020, D= > {Dep = 0x41fef230, Type = pkgCache::DepIterator::DepRev, Owner = > 0x3ec38}) at depcache.cc:464 > 464 depcache.cc: No such file or directory. > in depcache.cc > (gdb) Odd... I tried the installer again but with the daily build dated 2006-11-30 and now apt-get seg faults at a different spot. sh-3.1# gdb apt-get GNU gdb 6.5-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "arm-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -f install Starting program: /usr/bin/apt-get -f install Reading package lists... Done Building dependency tree... 50% Program received signal SIGSEGV, Segmentation fault. 0x4008b864 in pkgDepCache::CheckDep (this=0x3f020, Dep= {Dep = 0x407f0a68, Type = pkgCache::DepIterator::DepVer, Owner = 0x3ec38}, Type=1, [EMAIL PROTECTED]) at depcache.cc:157 157 depcache.cc: No such file or directory. in depcache.cc (gdb) where #0 0x4008b864 in pkgDepCache::CheckDep (this=0x3f020, Dep= {Dep = 0x407f0a68, Type = pkgCache::DepIterator::DepVer, Owner = 0x3ec38}, Type=1, [EMAIL PROTECTED]) at depcache.cc:157 #1 0x40090fb0 in pkgDepCache::CheckDep (this=0x3f020, Dep= {Dep = 0x407f0a68, Type = pkgCache::DepIterator::DepVer, Owner = 0x3ec38}, Type=1) at ../build/include/apt-pkg/depcache.h:142 #2 0x4008be58 in pkgDepCache::DependencyState (this=0x3f020, [EMAIL PROTECTED]) at depcache.cc:360 #3 0x4008f74c in pkgDepCache::Update (this=0x3f020, Prog=0xbe840350) at depcache.cc:431 #4 0x400902b8 in pkgDepCache::Init (this=0x3f020, Prog=0xbe840350) at depcache.cc:91 #5 0x400c9284 in pkgCacheFile::Open (this=0xbe8408d8, [EMAIL PROTECTED], WithLock=true) at cachefile.cc:101 #6 0x0002e39c in CacheFile::Open (this=0xbe8408d8, WithLock=true) at apt-get.cc:96 #7 0x0002e4e4 in CacheFile::OpenForInstall (this=0xbe8408d8) at apt-get.cc:107 #8 0x00023114 in DoInstall ([EMAIL PROTECTED]) at apt-get.cc:1415 #9 0x40072e80 in CommandLine::DispatchArg (this=0xbe840e04, Map=0xbe840d94, NoMatch=true) at contrib/cmndline.cc:337 #10 0x00011050 in main (argc=3, argv=0xbe840e84) at apt-get.cc:2606 Gordon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Corrupt dpkg database? No kernels found
On Nov 30, 10:00 am, "Gordon Farquharson" <[EMAIL PROTECTED]> wrote: > Unless anybody can come up with any other ideas or suggestions, my next > step is to recompile apt-get with debugging information. A bit of progress last night - I managed to compile apt-get with debugging symbols after finding http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=306937. A big thank you to Andreas Henriksson for posting the patch on the day that I needed it (was that a coincidence ?). Here is the output from gdb: sh-3.1# gdb apt-get GNU gdb 6.5-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "arm-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -f install Starting program: /usr/bin/apt-get -f install Reading package lists... Done Building dependency tree... Done Correcting dependencies... Program received signal SIGSEGV, Segmentation fault. 0x4008d100 in pkgDepCache::Update (this=0x3f020, D= {Dep = 0x41fef230, Type = pkgCache::DepIterator::DepRev, Owner = 0x3ec38}) at depcache.cc:464 464 depcache.cc: No such file or directory. in depcache.cc (gdb) and in depcache.cc: 455 // DepCache::Update - Update the deps list of a package /*{{{*/ 456 // - 457 /* This is a helper for update that only does the dep portion of the scan. 458It is mainly ment to scan reverse dependencies. */ 459 void pkgDepCache::Update(DepIterator D) 460 { 461// Update the reverse deps 462for (;D.end() != true; D++) 463{ 464 unsigned char &State = DepState[D->ID]; 465 State = DependencyState(D); 466 BTW, I had to switch to apt 0.6.46.3 from unstable because the patch didn't apply nicely to 0.6.46.2 from testing. This is as far as I have got for this evening. Gordon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Corrupt dpkg database? No kernels found
On Nov 26, 4:20 am, Martin Michlmayr <[EMAIL PROTECTED]> wrote: > I just got an error during the installation because no kernel was > found. syslog complained about missing dependencies and advised that > "apt-get -f install" should be run. I entered the target and issues > that command but apt-get segfaulted. After manually installing a .deb > with dpkg, apt-get worked fine... this seems like a corrupted dpkg > databaseto me. Has anyone seen this before? It sounds similar to > something someone recently mentioned on -mips. I'm on ARM and several > test installations in the last few days worked fine. To diagnose this problem further, I downloaded gdb with wget, but instead of installing it with dpkg, I unpacked it with ar and then untar'd data.tar.gz to /target. I then chroot'd to /target and ran apt-get with gdb. Here is a full output: ~ # cd /root /root # wget http://debian.osuosl.org/debian/pool/main/g/gdb/gdb_6.5.dfsg-2_arm.deb Connecting to debian.osuosl.org[64.50.236.52]:80 gdb_6.5.dfsg-2_arm.d 100% |*| 2481 KB 00:00 ETA /root # ar -x gdb_6.5.dfsg-2_arm.deb /root # ls control.tar.gz debian-binary data.tar.gz gdb_6.5.dfsg-2_arm.deb /root # cd /target /target # tar xzvf /root/data.tar.gz . ./usr ./usr/share ./usr/share/man ./usr/share/man/man1 ./usr/share/man/man1/gdb.1.gz ./usr/share/man/man1/gdbserver.1.gz ./usr/share/man/man1/gdbtui.1.gz ./usr/share/man/man1/arm-linux-gnu-run.1.gz ./usr/share/doc ./usr/share/doc/gdb ./usr/share/doc/gdb/NEWS.gz ./usr/share/doc/gdb/refcard.dvi.gz ./usr/share/doc/gdb/refcard.ps.gz ./usr/share/doc/gdb/changelog.gz ./usr/share/doc/gdb/README.Debian ./usr/share/doc/gdb/copyright ./usr/share/doc/gdb/README.gz ./usr/share/doc/gdb/refcard.tex.gz ./usr/share/doc/gdb/changelog.Debian.gz ./usr/share/menu ./usr/share/menu/gdb ./usr/lib ./usr/bin ./usr/bin/gdbtui ./usr/bin/gdb ./usr/bin/gdbserver ./usr/bin/arm-linux-gnu-run ./usr/bin/gcore /target # cd ~ # chroot /target sh-3.1# gdb apt-get GNU gdb 6.5-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "arm-linux-gnu"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run -f install Starting program: /usr/bin/apt-get -f install (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) Reading package lists... Done Building dependency tree... Done Correcting dependencies... Program received signal SIGSEGV, Segmentation fault. 0x4005e62c in pkgDepCache::Update () from /usr/lib/libapt-pkg-libc6.3-6.so.3.11 (gdb) Unless anybody can come up with any other ideas or suggestions, my next step is to recompile apt-get with debugging information. Gordon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Corrupt dpkg database? No kernels found
Martin Michlmayr cyrius.com> writes: > I just got an error during the installation because no kernel was > found. syslog complained about missing dependencies and advised that > "apt-get -f install" should be run. I entered the target and issues > that command but apt-get segfaulted. After manually installing a .deb > with dpkg, apt-get worked fine... this seems like a corrupted dpkg > database to me. Has anyone seen this before? It sounds similar to > something someone recently mentioned on -mips. I'm on ARM and several > test installations in the last few days worked fine. > > Logs: > > Nov 26 10:31:21 apt-install: Reading package lists... > Nov 26 10:31:21 apt-install: > Nov 26 10:31:21 apt-install: Building dependency tree... > Nov 26 10:31:33 apt-install: > Nov 26 10:31:33 apt-install: You might want to run `apt-get -f install' to correct these: > Nov 26 10:31:33 apt-install: The following packages have unmet dependencies: > Nov 26 10:31:33 apt-install: base-files: Depends: awk > Nov 26 10:31:33 apt-install: netbase: Depends: openbsd-inetd but it is not installable or > Nov 26 10:31:33 apt-install: inet-superserver > Nov 26 10:31:35 base-installer: info: Found kernels '' The daily build of the installer dated 27-Nov-2006 fails in a similar way for me, execpt that it is initramfs-tools as opposed to base-file that has unmet dependencies. Nov 29 02:32:35 apt-install: Nov 29 02:32:35 apt-install: You might want to run `apt-get -f install' to correct these: Nov 29 02:32:35 apt-install: The following packages have unmet dependencies: Nov 29 02:32:35 apt-install: initramfs-tools: Depends: klibc-utils (>= 1.4.19-2) but it is not going to be installed Nov 29 02:32:35 apt-install:Depends: busybox (>= 1:1.01-3) but it is not going to be installed or Nov 29 02:32:35 apt-install: busybox-cvs-static (>= 20040623-1) but it is not installable Nov 29 02:32:35 apt-install:Depends: udev (>= 0.086-1) but it is not going to be installed Nov 29 02:32:35 apt-install: libtext-charwidth-perl: Depends: perlapi-5.8.8 but it is not installable Nov 29 02:32:35 apt-install: libtext-iconv-perl: Depends: perlapi-5.8.8 but it is not installable Nov 29 02:32:35 base-installer: error: exiting on error base-installer/kernel/failed-package-install ~ # chroot /target/ sh-3.1# mount -t proc none /proc sh-3.1# apt-get -f install Reading package lists... Done Building dependency tree... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. Gordon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]