Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
On Wed, May 20, 2009 at 09:04:38AM -0700, Tony Godshall wrote: Reboot with USB stick plugged in: now I get a long pause immediately after md: raid1 personality registered for level 1 I look in dmesg for a usb-storage device: nothing. I look for /dev/sd[a-z]*: nothing So I can't mount the memory stick to capture dmesg output and I cant put it to the hard drive. For the record, I'm seeing exactly the same thing too here. I'm booting off a pendrive with the debian installer on it so the pen-drive is clearly being recognised. I can mount it if the system is running i386. I'm also unable to get the network working (bnx2 not being loaded but is loaded under i386) and the disk controller doesn't seem to be working properly. Given that neither the NIC, USB storage or Disk controller are working properly but do under i386, could this be a deeper issue with the Kernel incorrectly loading modules or something? Can I also request that the subject of this bug be corrected to something more accurate please? Andrew -- Systems Developer e: andrew.nic...@luns.net.uk im: a.nic...@jabber.lancs.ac.uk t: +44 (0)1524 5 10147 Lancaster University Network Services is a limited company registered in England and Wales. Registered number: 4311892. Registered office: University House, Lancaster University, Lancaster, LA1 4YW signature.asc Description: Digital signature
Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
On Fri, May 22, 2009 at 09:10:01AM -0700, Tony Godshall wrote: On Fri, May 22, 2009 at 3:43 AM, Andrew Robert Nicols andrew.nic...@luns.net.uk wrote: For the record, I'm seeing exactly the same thing too here. I'm booting off a pendrive with the debian installer on it so the pen-drive is clearly being recognised. I can mount it if the system is running i386. I'm also unable to get the network working (bnx2 not being loaded but is loaded under i386) and the disk controller doesn't seem to be working properly. Also seeing this on CD/DVD installations. Works fine under Ubuntu Jaunty (tried today). Andrew -- Systems Developer e: andrew.nic...@luns.net.uk im: a.nic...@jabber.lancs.ac.uk t: +44 (0)1524 5 10147 Lancaster University Network Services is a limited company registered in England and Wales. Registered number: 4311892. Registered office: University House, Lancaster University, Lancaster, LA1 4YW signature.asc Description: Digital signature
Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
On Fri, May 22, 2009 at 3:43 AM, Andrew Robert Nicols andrew.nic...@luns.net.uk wrote: On Wed, May 20, 2009 at 09:04:38AM -0700, Tony Godshall wrote: Reboot with USB stick plugged in: now I get a long pause immediately after md: raid1 personality registered for level 1 I look in dmesg for a usb-storage device: nothing. I look for /dev/sd[a-z]*: nothing So I can't mount the memory stick to capture dmesg output and I cant put it to the hard drive. For the record, I'm seeing exactly the same thing too here. I'm booting off a pendrive with the debian installer on it so the pen-drive is clearly being recognised. I can mount it if the system is running i386. I'm also unable to get the network working (bnx2 not being loaded but is loaded under i386) and the disk controller doesn't seem to be working properly. Given that neither the NIC, USB storage or Disk controller are working properly but do under i386, could this be a deeper issue with the Kernel incorrectly loading modules or something? Can I also request that the subject of this bug be corrected to something more accurate please? Thanks for the additional clues. I concur re the subject. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
[me] ... Perhaps if I could figure out how to grab the dmesg output from initramfs environment, I could then compare the amd64 kernel output to the 686-bigmem kernel output... :-/ [martin f krafft] Append 'break=bottom debug' to the kernel line and at the shell do something like mount -o remount,rw /root cp /dev/.initramfs/initramfs.debug /root/root/initramfs-debug.foo mount -o remount,ro /root and then find the file in /root once the system booted. ... No luck. No /root mounted so cannot remount it. [http://wiki.debian.org/InitramfsDebug] If that does not work, use a USB stick: plug it in, observe the kernel output, mkdir /mnt, mount the device node there, and write to the flash drive. Remember to umount before pulling out the stick. No luck. I plugged in a USB stick and now the screen and keyboard are frozen. Tony -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
On Wed, May 20, 2009 at 8:48 AM, Tony Godshall t...@of.net wrote: [me] ... Perhaps if I could figure out how to grab the dmesg output from initramfs environment, I could then compare the amd64 kernel output to the 686-bigmem kernel output... :-/ [martin f krafft] Append 'break=bottom debug' to the kernel line and at the shell do something like ... [http://wiki.debian.org/InitramfsDebug] If that does not work, use a USB stick: plug it in, observe the kernel output, mkdir /mnt, mount the device node there, and write to the flash drive. Remember to umount before pulling out the stick. [me] No luck. I plugged in a USB stick and now the screen and keyboard are frozen. Reboot with USB stick plugged in: now I get a long pause immediately after md: raid1 personality registered for level 1 I look in dmesg for a usb-storage device: nothing. I look for /dev/sd[a-z]*: nothing So I can't mount the memory stick to capture dmesg output and I cant put it to the hard drive. -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
also sprach Tony Godshall t...@of.net [2009.05.12.2003 +0200]: Yes, I see that it's optional, and actually rather pointless in my case since I'm booting off the RAID partition, unless grub reads mdadm.conf . But grub only reads /boot, not /etc, right? /etc would not be available until /etc/fstab is processed. The point is that mdadm.conf is copied into the initramfs and is thus available at boot time before the root filesystem is available. Now that I have a better idea of what's going on during the boot process, I googled and found this: http://wiki.debian.org/InitramfsDebug Note the change history. ;) Wish I'd found it earlier. I could have submitted a much better initial report. By the way, Martin, sometimes it's good to give people a little more why with the do this, do that. Or point them to a good wiki or faq. Bug reporters don't necessarily choose to be ignorant and a word to the wise-guy may save a bit of flame. ;-) Yes, I am aware. And sometimes it is necessary to first poke around a bit to find out which direction the actual cause lies. It just takes too much time and is potentially confusing to explain the background for each case. Once the solution is found, I always give more information, for the poster, to recap myself and find possible holes, and for posterity. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems a farmer is a man outstanding in his field. digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
also sprach Tony Godshall t...@of.net [2009.05.11.2058 +0200]: They are *not*. That would seem to be the nub of the problem. No base partitions, thus no RAID. Good, thanks, that's progress. Might be good for md to report that that a little better (see screenshot). Oh, duh, I moved /etc/mdadm/mdadm.conf out of the way. So it doesn't even know I have a RAID until it autodetects it, right? Oh, wait, in this initramfs environment there is an /etc/mdadm/mdadm.conf, and it shows UUID and the 4-way RAID1. What, so the /etc/mdadm/mdadm.conf inside the initrd is not from the kernel package but was built locally? Didn't realize that. It's copied from the main system when the initramfs is created, unless it's faulty or doesn't represent the system or hasn't been checked since the 2.5.3 upgrade. In the initramfs, if there is a config file, it's used. If there's not a config file, mdadm scans all partitions and assembles them all (like /sbin/mdadm-startall). Thus, if you remove it in the initramfs, you basically tell the system that you want it to scan, rather than search for the specific UUID in the file. Perhaps if I could figure out how to grab the dmesg output from initramfs environment, I could then compare the amd64 kernel output to the 686-bigmem kernel output... :-/ Append 'break=bottom debug' to the kernel line and at the shell do something like mount -o remount,rw /root cp /dev/.initramfs/initramfs.debug /root/root/initramfs-debug.foo mount -o remount,ro /root and then find the file in /root once the system booted. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems review of a chemistry paper: paper should be greatly reduced or completely oxidized. -- frank vastola digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
On Tue, May 12, 2009 at 9:11 AM, martin f krafft madd...@debian.org wrote: also sprach Tony Godshall t...@of.net [2009.05.11.2058 +0200]: They are *not*. That would seem to be the nub of the problem. No base partitions, thus no RAID. Good, thanks, that's progress. Might be good for md to report that that a little better (see screenshot). Oh, duh, I moved /etc/mdadm/mdadm.conf out of the way. So it doesn't even know I have a RAID until it autodetects it, right? Oh, wait, in this initramfs environment there is an /etc/mdadm/mdadm.conf, and it shows UUID and the 4-way RAID1. What, so the /etc/mdadm/mdadm.conf inside the initrd is not from the kernel package but was built locally? Didn't realize that. It's copied from the main system when the initramfs is created, unless it's faulty or doesn't represent the system or hasn't been checked since the 2.5.3 upgrade. In the initramfs, if there is a config file, it's used. If there's not a config file, mdadm scans all partitions and assembles them all (like /sbin/mdadm-startall). Yes, I see that it's optional, and actually rather pointless in my case since I'm booting off the RAID partition, unless grub reads mdadm.conf . But grub only reads /boot, not /etc, right? /etc would not be available until /etc/fstab is processed. Thus, if you remove it in the initramfs, you basically tell the system that you want it to scan, rather than search for the specific UUID in the file. Perhaps if I could figure out how to grab the dmesg output from initramfs environment, I could then compare the amd64 kernel output to the 686-bigmem kernel output... :-/ Append 'break=bottom debug' to the kernel line and at the shell do something like mount -o remount,rw /root cp /dev/.initramfs/initramfs.debug /root/root/initramfs-debug.foo mount -o remount,ro /root and then find the file in /root once the system booted. Thanks! I'll try this on Thursday. Now that I have a better idea of what's going on during the boot process, I googled and found this: http://wiki.debian.org/InitramfsDebug Wish I'd found it earlier. I could have submitted a much better initial report. By the way, Martin, sometimes it's good to give people a little more why with the do this, do that. Or point them to a good wiki or faq. Bug reporters don't necessarily choose to be ignorant and a word to the wise-guy may save a bit of flame. ;-) Best Regards. Tony -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
also sprach Tony Godshall t...@of.net [2009.05.11.1819 +0200]: retitle 526525 amd64 kernel cannot find bnx2 PCI device base address Um. BNX2 is the network card? WTF does it have to do with being able to mount and boot off RAID in 64-bit mode only? I don't know, but your attitude does not make me want to help you further. http://www.chiark.greenend.org.uk/~sgtatham/bugs.html -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems sobald man über niveau spricht ist man längst darüber hinweg. -- thomas krafft digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
On Sat, May 9, 2009 at 12:35 AM, martin f krafft madd...@debian.org wrote: retitle 526525 amd64 kernel cannot find bnx2 PCI device base address Um. BNX2 is the network card? WTF does it have to do with being able to mount and boot off RAID in 64-bit mode only? also sprach Tony Godshall t...@of.net [2009.05.09.0117 +0200]: If you cannot boot, append break=mount to the kernel line, and at the initramfs prompt, type rm /etc/mdadm/mdadm.conf /scripts/local-top/mdadm ctrl-d and then fix the initramfs. I'm not interested in deleting mdadm.conf or taking any other steps that might break the existing functionality. I considered it a necessary step in my analysis, but if you prefer to do things your way, it's your system. Note that I would have never proposed anything that made permanent changes without adequate warning. rm /etc/mdadm.conf ? Maybe mv. Anyhow, I'm giving more info below and am open to suggestions on how to acquire more. I'm not reporting this bug because I must have an amd64 kernel- like I said, the 686 and 686bigmem kernels are working. I initiated this bug to help get the amd64 version of the kernel (or mdadm?) fixed. I'm interested in steps that will help fix the packages, not manually work around its flaws. Then please provide all the necessary infos. mdadm works perfectly fine with amd64 kernels. I think your problem is that the kernel doesn't initialise the drives you're using properly, so mdadm doesn't find them when trying to assemble. You will have to make sure the kernel sees your drives. From what you've allowed me to see, I can conclude that this is not a RAID problem. Please find below my mdadm.conf. I assume the dmesg output would be useful but I'm not sure how to capture that in the initramfs environment. Let me know what else comprises the necessary infos I have failed to provide. # cat /etc/mdadm/mdadm.conf # mdadm.conf # # Please refer to mdadm.conf(5) for information about this file. # # by default, scan all partitions (/proc/partitions) for MD superblocks. # alternatively, specify devices to scan, using wildcards if desired. DEVICE partitions # auto-create devices with Debian standard permissions CREATE owner=root group=disk mode=0660 auto=yes # automatically tag new arrays as belonging to the local system HOMEHOST system # instruct the monitoring daemon where to send mail alerts MAILADDR root # definitions of existing MD arrays ARRAY /dev/md0 level=raid1 num-devices=4 UUID=1cdfc35d:237af2b8:58db9480:16165906 # This file was auto-generated on Mon, 27 Apr 2009 02:47:01 -0700 # by mkconf $Id$ Best Regards. Please keep in touch. This is unedited. P-) -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduck http://vcs-pkg.org `- Debian - when you have better things to do than fixing systems fashions have done more harm than revolutions. -- victor hugo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkoFMkEACgkQIgvIgzMMSnUk5ACfcRDawcJVFhpm2RqdxehK64Mv +10An3TllsHOk1io8ho4e8nW4CxlUGZL =jHa4 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
also sprach Tony Godshall t...@of.net [2009.05.11.1843 +0200]: I filed the report because I want to see Debian work great on all configurations, with all CPUs, with all RAID configurations, off the bat, without tweaking. And I'm trying to do what small part I can. With the limited access to the equipment I have. As I said before, this is not a RAID problem. RAID works no different on amd64 than it does on i386. I'm trying to help, and you tell me to delete config files, you don't bother to read key parts of my report, and you talk about my attitude when I notice a bad rename. I told you to delete a file in an initrd image copied to RAM, because I suspected your UUIDs to have gotten out of sync. Which part of your report didn't I read? What bad rename are you talking about? Please find attached screenshots of boot with /etc/mdadm/mdadm.conf removed out of the way. No screenshot attached. Also, note that I didn't ask you to remove the file from the disk, but I asked you to remove the file from the command line you see when initramfs fails to mount the rootfs. Sorry if that wasn't clear. If you want to get an idea of what relevant information is, please run /usr/share/bug/mdadm/script 31 as root and post the output. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems life moves pretty fast. if you don't stop and look around once in a while, you could miss it. -- ferris bueller digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
Did I say I was looking for help? As I said before, I am fine running with a 32 bit kernel. I filed the report because I want to see Debian work great on all configurations, with all CPUs, with all RAID configurations, off the bat, without tweaking. And I'm trying to do what small part I can. With the limited access to the equipment I have. I'm trying to help, and you tell me to delete config files, you don't bother to read key parts of my report, and you talk about my attitude when I notice a bad rename. My attitude? Wow. Look in the mirror. Anyhow, back to work. I'd appreciate any assistance anyone, Martin or others, can provide toward getting the amd64 kernel working well on machines like the Dell T610. Please find attached screenshots of boot with /etc/mdadm/mdadm.conf removed out of the way. Also, here's output of lspci -v, in case it helps (booted under 686smp kernel, not the problematic amd64 kernel) # lspci -v 00:00.0 Host bridge: Intel Corporation QuickPath Architecture I/O Hub to ESI Port (rev 13) Subsystem: Dell Device 0237 Flags: fast devsel, IRQ 15 Capabilities: [60] Message Signalled Interrupts: Mask+ 64bit- Queue=0/1 Enable- Capabilities: [90] Express Root Port (Slot-), MSI 00 Capabilities: [e0] Power Management version 3 Capabilities: [100] Advanced Error Reporting ? Capabilities: [150] Access Controls ? Capabilities: [160] Vendor Specific Information ? 00:01.0 PCI bridge: Intel Corporation QuickPath Architecture I/O Hub PCI Express Root Port 1 (rev 13) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 Memory behind bridge: da00-ddff Capabilities: [40] Subsystem: Dell Device 0237 Capabilities: [60] Message Signalled Interrupts: Mask+ 64bit- Queue=0/1 Enable+ Capabilities: [90] Express Root Port (Slot-), MSI 00 Capabilities: [e0] Power Management version 3 Capabilities: [100] Advanced Error Reporting ? Capabilities: [150] Access Controls ? Capabilities: [160] Vendor Specific Information ? Kernel driver in use: pcieport-driver Kernel modules: shpchp 00:03.0 PCI bridge: Intel Corporation QuickPath Architecture I/O Hub PCI Express Root Port 3 (rev 13) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 Capabilities: [40] Subsystem: Dell Device 0237 Capabilities: [60] Message Signalled Interrupts: Mask+ 64bit- Queue=0/1 Enable+ Capabilities: [90] Express Root Port (Slot+), MSI 00 Capabilities: [e0] Power Management version 3 Capabilities: [100] Advanced Error Reporting ? Capabilities: [150] Access Controls ? Capabilities: [160] Vendor Specific Information ? Kernel driver in use: pcieport-driver Kernel modules: shpchp 00:04.0 PCI bridge: Intel Corporation QuickPath Architecture I/O Hub PCI Express Root Port 4 (rev 13) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=04, subordinate=04, sec-latency=0 Capabilities: [40] Subsystem: Dell Device 0237 Capabilities: [60] Message Signalled Interrupts: Mask+ 64bit- Queue=0/1 Enable+ Capabilities: [90] Express Root Port (Slot+), MSI 00 Capabilities: [e0] Power Management version 3 Capabilities: [100] Advanced Error Reporting ? Capabilities: [150] Access Controls ? Kernel driver in use: pcieport-driver Kernel modules: shpchp 00:05.0 PCI bridge: Intel Corporation QuickPath Architecture I/O Hub PCI Express Root Port 5 (rev 13) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=05, subordinate=06, sec-latency=0 I/O behind bridge: e000-efff Memory behind bridge: df10-df2f Capabilities: [40] Subsystem: Dell Device 0237 Capabilities: [60] Message Signalled Interrupts: Mask+ 64bit- Queue=0/1 Enable+ Capabilities: [90] Express Root Port (Slot+), MSI 00 Capabilities: [e0] Power Management version 3 Capabilities: [100] Advanced Error Reporting ? Capabilities: [150] Access Controls ? Kernel driver in use: pcieport-driver Kernel modules: shpchp 00:07.0 PCI bridge: Intel Corporation QuickPath Architecture I/O Hub PCI Express Root Port 7 (rev 13) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0 Bus: primary=00, secondary=07, subordinate=07, sec-latency=0 Capabilities: [40] Subsystem: Dell Device 0237 Capabilities: [60] Message Signalled Interrupts: Mask+ 64bit- Queue=0/1 Enable+ Capabilities: [90] Express Root Port (Slot+), MSI 00 Capabilities: [e0] Power Management version 3
Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
On Mon, May 11, 2009 at 9:55 AM, martin f krafft madd...@debian.org wrote: also sprach Tony Godshall t...@of.net [2009.05.11.1843 +0200]: I filed the report because I want to see Debian work great on all configurations, with all CPUs, with all RAID configurations, off the bat, without tweaking. And I'm trying to do what small part I can. With the limited access to the equipment I have. As I said before, this is not a RAID problem. RAID works no different on amd64 than it does on i386. Fine. It's not a RAID issue. Did I argue otherwise? I'm trying to help, and you tell me to delete config files, you don't bother to read key parts of my report, and you talk about my attitude when I notice a bad rename. I told you to delete a file in an initrd image copied to RAM, because I suspected your UUIDs to have gotten out of sync. I understand now. Which part of your report didn't I read? The bit about where I made it clear I didn't care that much if it worked for me but rather that I was reporting to make Debian better. I.e. I'm not asking you to help me, I'm trying to help Debian and Linux. What bad rename are you talking about? The bug as a networking (bnx2) bug. That's the point where you apparently just read WTF? and, whoop, flamethrower on, attitude! Please find attached screenshots of boot with /etc/mdadm/mdadm.conf removed out of the way. No screenshot attached. Yeah, :-/ Check the followup email sent about 60 seconds later. Also, note that I didn't ask you to remove the file from the disk, but I asked you to remove the file from the command line you see when initramfs fails to mount the rootfs. Sorry if that wasn't clear. I understand now. If you want to get an idea of what relevant information is, please run /usr/share/bug/mdadm/script 31 as root and post the output. Well, like you say, it's not a RAID issue, so I don't see how it's relevant. But OK, here goes... # cat t --- mount output /dev/md0 on / type ext3 (rw,noatime,errors=remount-ro) tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755) proc on /proc type proc (rw,noexec,nosuid,nodev) sysfs on /sys type sysfs (rw,noexec,nosuid,nodev) procbususb on /proc/bus/usb type usbfs (rw) udev on /dev type tmpfs (rw,mode=0755) tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev) devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620) --- mdadm.conf no mdadm.conf file. --- /proc/mdstat: Personalities : [raid1] md0 : active raid1 sda2[0] sdd2[3] sdc2[2] sdb2[1] 291009344 blocks [4/4] [] unused devices: none --- /proc/partitions: major minor #blocks name 8 0 292968750 sda 8 11951866 sda1 8 2 291009442 sda2 816 292968750 sdb 8171951866 sdb1 818 291009442 sdb2 832 292968750 sdc 8331951866 sdc1 834 291009442 sdc2 848 292968750 sdd 8491951866 sdd1 850 291009442 sdd2 9 0 291009344 md0 --- initrd.img-2.6.26-2-686-bigmem: 30579 blocks sbin/mdadm etc/mdadm etc/mdadm/mdadm.conf lib/modules/2.6.26-2-686-bigmem/kernel/drivers/md/raid10.ko lib/modules/2.6.26-2-686-bigmem/kernel/drivers/md/multipath.ko lib/modules/2.6.26-2-686-bigmem/kernel/drivers/md/raid456.ko lib/modules/2.6.26-2-686-bigmem/kernel/drivers/md/md-mod.ko lib/modules/2.6.26-2-686-bigmem/kernel/drivers/md/raid0.ko lib/modules/2.6.26-2-686-bigmem/kernel/drivers/md/raid1.ko lib/modules/2.6.26-2-686-bigmem/kernel/drivers/md/linear.ko scripts/local-top/mdadm --- /proc/modules: dm_mod 46952 0 - Live 0xf8a0b000 raid1 18784 1 - Live 0xf89c8000 md_mod 67804 2 raid1, Live 0xf89d8000 --- /var/log/syslog: --- volume detail: /dev/sda2: Magic : a92b4efc Version : 00.90.00 UUID : 1cdfc35d:237af2b8:58db9480:16165906 Creation Time : Mon Apr 20 16:42:49 2009 Raid Level : raid1 Used Dev Size : 291009344 (277.53 GiB 297.99 GB) Array Size : 291009344 (277.53 GiB 297.99 GB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 0 Update Time : Mon May 11 10:11:19 2009 State : active Active Devices : 4 Working Devices : 4 Failed Devices : 0 Spare Devices : 0 Checksum : fdc5cbbe - correct Events : 15 Number Major Minor RaidDevice State this 0 820 active sync /dev/sda2 0 0 820 active sync /dev/sda2 1 1 8 181 active sync /dev/sdb2 2 2 8 342 active sync /dev/sdc2 3 3 8 503 active sync /dev/sdd2 -- /dev/sdb2: Magic : a92b4efc Version : 00.90.00 UUID : 1cdfc35d:237af2b8:58db9480:16165906 Creation Time : Mon Apr 20 16:42:49 2009 Raid Level : raid1 Used Dev Size : 291009344 (277.53 GiB 297.99 GB) Array Size : 291009344 (277.53 GiB 297.99 GB) Raid Devices : 4 Total Devices : 4 Preferred Minor : 0 Update Time : Mon May 11 10:11:19 2009
Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
... Sorry. We got off on a bad start. I'll review your stuff tomorrow and then let's start afresh. OK By the time you get dumped into the busybox prompt during initramfs time, are /dev/sd[abcd] present? They are *not*. That would seem to be the nub of the problem. No base partitions, thus no RAID. Good, thanks, that's progress. Might be good for md to report that that a little better (see screenshot). Oh, duh, I moved /etc/mdadm/mdadm.conf out of the way. So it doesn't even know I have a RAID until it autodetects it, right? Oh, wait, in this initramfs environment there is an /etc/mdadm/mdadm.conf, and it shows UUID and the 4-way RAID1. What, so the /etc/mdadm/mdadm.conf inside the initrd is not from the kernel package but was built locally? Didn't realize that. Perhaps if I could figure out how to grab the dmesg output from initramfs environment, I could then compare the amd64 kernel output to the 686-bigmem kernel output... :-/ -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526525: a problem with mptbase or bnx2 (was: Bug#526525: Kernel linux-image-2.6.26-2-amd64 does not see) root RAID device /dev/md0
retitle 526525 amd64 kernel cannot find bnx2 PCI device base address thanks also sprach Tony Godshall t...@of.net [2009.05.09.0117 +0200]: If you cannot boot, append break=mount to the kernel line, and at the initramfs prompt, type rm /etc/mdadm/mdadm.conf /scripts/local-top/mdadm ctrl-d and then fix the initramfs. I'm not interested in deleting mdadm.conf or taking any other steps that might break the existing functionality. I considered it a necessary step in my analysis, but if you prefer to do things your way, it's your system. Note that I would have never proposed anything that made permanent changes without adequate warning. I'm not reporting this bug because I must have an amd64 kernel- like I said, the 686 and 686bigmem kernels are working. I initiated this bug to help get the amd64 version of the kernel (or mdadm?) fixed. I'm interested in steps that will help fix the packages, not manually work around its flaws. Then please provide all the necessary infos. mdadm works perfectly fine with amd64 kernels. I think your problem is that the kernel doesn't initialise the drives you're using properly, so mdadm doesn't find them when trying to assemble. You will have to make sure the kernel sees your drives. From what you've allowed me to see, I can conclude that this is not a RAID problem. -- .''`. martin f. krafft madd...@d.o Related projects: : :' : proud Debian developer http://debiansystem.info `. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org `- Debian - when you have better things to do than fixing systems fashions have done more harm than revolutions. -- victor hugo digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/)
