Re: Upgrade to 2.6.32-5-amd64 failing miserably
also sprach lrhorer lrho...@satx.rr.com [2011.02.02.2057 +0100]: [4.228353] ata4.04: hard resetting link [4.564319] ata4.04: SATA link down (SStatus 0 SControl 320) [4.564375] ata4.05: hard resetting link [4.900300] ata4.05: SATA link up 1.5 Gbps (SStatus 113 SControl 320) […] [4.965365] ata4: EH complete This does not look like a happy SATA controller or disk. Similarly: [ 23.324019] ata7: softreset failed (timeout) [ 33.340017] ata7: softreset failed (timeout) [ 68.364019] ata7: softreset failed (timeout) [ 68.364053] ata7: limiting SATA link speed to 1.5 Gbps [ 73.388016] ata7: softreset failed (timeout) [ 73.388049] ata7: reset failed, giving up But this might not be a problem. [ 74.143154] md: array md3 already has disks! I really need to see initramfs debug output, i.e. the shell traces when you pass the debug option on the kernel boot line and then obtain the file from /dev/.initramfs or whatever the location was according to the wiki; I am offline right now and cannot check. Also, what version of mdadm are you using? Which package? Debian Squeeze. Both the mdadm binary in the 2.6.32-5 and in the /sbin/ directory of the root array report 3.1.2, which is the version supported in the distro. Squeeze has had 3.1.4-something for several months. I suggest you upgrade. -- .''`. martin f. krafft madduck@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 uʍop ǝpısdn sı ɹoʇıuoɯ ɹnoʎ digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: Upgrade to 2.6.32-5-amd64 failing miserably
martin f krafft wrote: also sprach lrhorer lrho...@satx.rr.com [2011.02.02.2057 +0100]: [4.228353] ata4.04: hard resetting link [4.564319] ata4.04: SATA link down (SStatus 0 SControl 320) [4.564375] ata4.05: hard resetting link [4.900300] ata4.05: SATA link up 1.5 Gbps (SStatus 113 SControl [320) […] [4.965365] ata4: EH complete This does not look like a happy SATA controller or disk. I have two of those controllers on two different systems. They both produce the same reports in dmesg and neither produces any errors when running. I regularly transfer to and from them at over 800 Mbps without a belch. It's moot in any case, because this is a SATA controller, and the two boot disks are IDE: [0.807649] ata8: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xff00 irq 14 [1.022462] ata8.00: ATA-7: ST3500641A, 3.AAE, max UDMA/100 [1.022464] ata8.00: 976773168 sectors, multi 16: LBA48 [1.065826] ata8.01: ATA-7: ST3500641A, 3.AAE, max UDMA/100 [1.065830] ata8.01: 976773168 sectors, multi 16: LBA48 [1.065847] ata8.00: limited to UDMA/33 due to 40-wire cable [1.065849] ata8.01: limited to UDMA/33 due to 40-wire cable [1.113673] ata8.00: configured for UDMA/33 [1.165339] ata8.01: configured for UDMA/33 Similarly: [ 23.324019] ata7: softreset failed (timeout) [ 33.340017] ata7: softreset failed (timeout) [ 68.364019] ata7: softreset failed (timeout) [ 68.364053] ata7: limiting SATA link speed to 1.5 Gbps [ 73.388016] ata7: softreset failed (timeout) [ 73.388049] ata7: reset failed, giving up But this might not be a problem. That's just an external SATA docking station with no hard drive inserted. [ 74.143154] md: array md3 already has disks! I really need to see initramfs debug output, i.e. the shell traces when you pass the debug option on the kernel boot line and then obtain the file from /dev/.initramfs or whatever the location was according to the wiki; I am offline right now and cannot check. Also, what version of mdadm are you using? Which package? Debian Squeeze. Both the mdadm binary in the 2.6.32-5 and in the /sbin/ directory of the root array report 3.1.2, which is the version supported in the distro. Squeeze has had 3.1.4-something for several months. I suggest you upgrade. Bingo! That did it. I don't know what the system did not like about 3.1.2, but now booting under the old kernel brings up md0 properly, and booting under the new kernel works. I take it you no longer want to see the shell traces? Thanks for all the help! -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/dnudncqie7yadnfqnz2dnuvz5tedn...@giganews.com
Re: Upgrade to 2.6.32-5-amd64 failing miserably
martin f krafft wrote: also sprach lrhorer lrho...@satx.rr.com [2011.02.01.2123 +0100]: far too quickly to be seen, but then an error pops up concerning an address space collision of some PCI device. Then it shows three errors for RAID devices md1. md2, and md3, saying they are already in use. This looks like a hardware problem, causing mdadm to fail to assemble. I guess I did not make myself clear. The systems boots perfectly, and continues to do so, under 2.6.32-3-amd64. Since the arrays assemble and run without error under 2.6.32-3-amd64, then there is no way enough members of the array could be bad to prevent them from assembling under 2.6.32.3-5-amd64. Not only that, but GRUB would not even come up, since /boot is /dev/md1, and all three arrays are assembled from the same two dirves. 'Bottom line, md1, md2, and md3 are just fine. Immediately thereafter the system shows errors concerning the RAID targets being already in use, after which point the system complains it can't mount / (md2), /dev, /sys, or /proc (in that order) because the sources do not exist (if /dev/md2 does not exist, how can it be busy?). Thereafter, of course, it fails to find init, since / is not mounted. It then tries to run BusyBox, but Busybox complains: /bin/sh: can't access tty; job control turned off This is normal. Don't worry about that. Instead, try to assemble the arrays manually. And provide me with a lot more information, e.g. How could I assemble the arrays manually when the system won't boot? They don't need to be assembled manually under 2.6.32-3-amd64, because they assemble and boot perfectly well automatically in that release. ls -l /dev/md* /dev/[sh]d* brw-rw 1 root disk 3, 0 Feb 2 03:23 /dev/hda brw-rw 1 root disk 3, 1 Feb 2 03:23 /dev/hda1 brw-rw 1 root disk 3, 2 Feb 2 03:23 /dev/hda2 brw-rw 1 root disk 3, 3 Feb 2 03:23 /dev/hda3 brw-rw 1 root disk 3, 64 Feb 2 03:23 /dev/hdb brw-rw 1 root disk 3, 65 Feb 2 03:23 /dev/hdb1 brw-rw 1 root disk 3, 66 Feb 2 03:23 /dev/hdb2 brw-rw 1 root disk 3, 67 Feb 2 03:23 /dev/hdb3 brw-rw 1 root disk 9, 0 Feb 2 03:22 /dev/md0 brw-rw 1 root disk 9, 1 Feb 2 03:22 /dev/md1 brw-rw 1 root disk 9, 2 Feb 2 03:22 /dev/md2 brw-rw 1 root disk 9, 3 Feb 2 03:22 /dev/md3 brw-rw 1 root disk 8, 0 Feb 2 03:23 /dev/sda brw-rw 1 root disk 8, 16 Feb 2 03:23 /dev/sdb brw-rw 1 root disk 8, 32 Feb 2 03:23 /dev/sdc brw-rw 1 root disk 8, 48 Feb 2 03:23 /dev/sdd brw-rw 1 root disk 8, 64 Feb 2 03:23 /dev/sde brw-rw 1 root disk 8, 80 Feb 2 03:23 /dev/sdf brw-rw 1 root disk 8, 96 Feb 2 03:23 /dev/sdg brw-rw 1 root disk 8, 112 Feb 2 03:23 /dev/sdh brw-rw 1 root disk 8, 128 Feb 2 03:23 /dev/sdi brw-rw 1 root disk 8, 144 Feb 2 03:23 /dev/sdj I don't see the point of this, at all. There is nothing to guarantee the drive targets will be the same in the new kernel, or for that matter from one boot to the next in the old kernel. cat /proc/mdstat Personalities : [raid1] [raid6] [raid5] [raid4] md0 : inactive sdj[9](S) 1465137560 blocks super 1.2 md3 : active (auto-read-only) raid1 hda3[0] hdb3[1] 204796548 blocks super 1.2 [2/2] [UU] bitmap: 0/196 pages [0KB], 512KB chunk md2 : active raid1 hda2[2] hdb2[1] 277442414 blocks super 1.2 [2/2] [UU] bitmap: 5/265 pages [20KB], 512KB chunk md1 : active raid1 hda1[0] hdb1[1] 6144704 blocks [2/2] [UU] bitmap: 0/1 pages [0KB], 65536KB chunk mdadm -Es ARRAY /dev/md1 UUID=4cde286c:0687556a:4d9996dd:dd23e701 ARRAY /dev/md/2 metadata=1.2 UUID=d45ff663:9e53774c:6fcf9968:21692025 name=Backup:2 ARRAY /dev/md/3 metadata=1.2 UUID=51d22c47:10f58974:0b27ef04:5609d357 name=Backup:3 ARRAY /dev/md/0 metadata=1.2 UUID=431244d6:45d9635a:e88b3de5:92f30255 name=Backup:0 The arrays are fine. This is not an issue with any of the arrays themselves. dmesg See next message. It would really help if you could also enable initramfs debugging (http://wiki.debian.org/InitramfsDebug) and provide us with the output file. Well, this may be getting a bit closer, but still no cigar. Setting the break=premount kernel parameter causes the kernel to halt booting and load the BusyBox executable, but since there is still no access to the tty, the system is once again locked at that point. I need something which will allow the me to inspect things - or at least obtain an output that can be saved - during the boot process. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/v5gdneecxi3yuttqnz2dnuvz5tcdn...@giganews.com
Re: Upgrade to 2.6.32-5-amd64 failing miserably
also sprach lrhorer lrho...@satx.rr.com [2011.02.02.1044 +0100]: How could I assemble the arrays manually when the system won't boot? At the busybox command line. The command output you provided is from the 2.6.32-3-amd64 kernel. I need you to provide me with this output after trying to boot the 2.6.32-5-amd64 kernel. Since it fails to assemble the arrays, it will not be able to mount the root filesystem. Hence it will drop you into a shell. The message /bin/sh: can't access tty; job control turned off just says that there is no real tty. But busybox should still start and let you type commands. At this stage you can gather all the information, store them to media (see Saving debug information on http://wiki.debian.org/InitramfsDebug), and then either assemble the arrays by hand and let the boot continue, or reboot and publish the gathered data from 2.6.32-3-amd64. -- .''`. martin f. krafft madduck@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 the wonderful thing about standards is that there are so many to choose from. -- grace hopper digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: Upgrade to 2.6.32-5-amd64 failing miserably
martin f krafft wrote: also sprach lrhorer lrho...@satx.rr.com [2011.02.02.1044 +0100]: How could I assemble the arrays manually when the system won't boot? At the busybox command line. The command output you provided is from the 2.6.32-3-amd64 kernel. I need you to provide me with this output after trying to boot the 2.6.32-5-amd64 kernel. Since it fails to assemble the arrays, it will not be able to mount the root filesystem. Hence it will drop you into a shell. The message /bin/sh: can't access tty; job control turned off just says that there is no real tty. But busybox should still start and let you type commands. No, that's the whole point. It locks up. It doesn't just launch the BusyBox shell, awaiting a command. It doesn't respond to the keyboard. I thought I made that clear when I said, ...hangs completely. If that weren't the case, I could have investigated further myself. Without a responding system, though, and no way to save logs, I'm stuck. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/wagdna1-uvfcf9tqnz2dnuvz5r2dn...@giganews.com
Re: Upgrade to 2.6.32-5-amd64 failing miserably
also sprach lrhorer lrho...@satx.rr.com [2011.02.02.1748 +0100]: No, that's the whole point. It locks up. It doesn't just launch the BusyBox shell, awaiting a command. It doesn't respond to the keyboard. So you likely do not have the required USB modules for the keyboard in the initramfs. I suggest that you recreate the initramfs after changing MODULES=most in /etc/initramfs/mkinitramfs.conf I thought I made that clear when I said, ...hangs completely. If that weren't the case, I could have investigated further myself. Without a responding system, though, and no way to save logs, I'm stuck. Fair enough, although I doubt that it actually hangs. It just doesn't know how to deal with your keyboard. -- .''`. martin f. krafft madduck@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 without music, life would be a mistake. - friedrich nietzsche digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: Upgrade to 2.6.32-5-amd64 failing miserably
martin f krafft wrote: also sprach lrhorer lrho...@satx.rr.com [2011.02.02.1748 +0100]: No, that's the whole point. It locks up. It doesn't just launch the BusyBox shell, awaiting a command. It doesn't respond to the keyboard. So you likely do not have the required USB modules for the keyboard in the initramfs. I suggest that you recreate the initramfs after changing MODULES=most in /etc/initramfs/mkinitramfs.conf Ah! Thanks. That worked. Well, it got the console working. Now to find the problem... I thought I made that clear when I said, ...hangs completely. If that weren't the case, I could have investigated further myself. Without a responding system, though, and no way to save logs, I'm stuck. Fair enough, although I doubt that it actually hangs. It just doesn't know how to deal with your keyboard. I rather suspected that might be the case. Taking a quick look at the /dev directory, the drive targets have changed from /hdX to /sdX, and are now way at the end of the list, rather than a and b. Now that really shouldn't give mdadm any grief, but I think it is. Mdstat and dmadm -D both show all the arrays inactive, but if I try to assemble them, it says they are all in use. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/vf-dnrwi1polpntqnz2dnuvz5okdn...@giganews.com
Re: Upgrade to 2.6.32-5-amd64 failing miserably
also sprach lrhorer lrho...@satx.rr.com [2011.02.02.1923 +0100]: I rather suspected that might be the case. Taking a quick look at the /dev directory, the drive targets have changed from /hdX to /sdX, and are now way at the end of the list, rather than a and b. Now that really shouldn't give mdadm any grief, but I think it is. Should not. Show me your mdadm.conf! Mdstat and dmadm -D both show all the arrays inactive, but if I try to assemble them, it says they are all in use. How do you assemble them? And what does /proc/mdstat contain at this point. Also, show ls -l /dev/md* /dev/sd* Thanks, -- .''`. martin f. krafft madduck@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 there are two groups of people in the world: those who believe that the world can be divided into two groups of people, and those who don't. digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: Upgrade to 2.6.32-5-amd64 failing miserably
martin f krafft wrote: also sprach lrhorer lrho...@satx.rr.com [2011.02.02.1923 +0100]: I rather suspected that might be the case. Taking a quick look at the /dev directory, the drive targets have changed from /hdX to /sdX, and are now way at the end of the list, rather than a and b. Now that really shouldn't give mdadm any grief, but I think it is. Should not. Show me your mdadm.conf! 'Very straightforward: DEVICE partitions HOMEHOST system ARRAY /dev/md0 level=raid6 num-devices=10 metadata=01.2 name=Backup:0 UUID=431244d6:45d9635a:e88b3de5:92f30255 ARRAY /dev/md1 level=raid1 num-devices=2 metadata=0.90 UUID=4cde286c:0687556a:4d9996dd:dd23e701 ARRAY /dev/md2 level=raid1 num-devices=2 metadata=01.2 name=Backup:2 UUID=d45ff663:9e53774c:6fcf9968:21692025 ARRAY /dev/md3 level=raid1 num-devices=2 metadata=01.2 name=Backup:3 UUID=51d22c47:10f58974:0b27ef04:5609d357 Mdstat and dmadm -D both show all the arrays inactive, but if I try to assemble them, it says they are all in use. How do you assemble them? I have to stop them (mdadm -S /dev/mdX), at which point assembly works via `mdadm --assemble --scan`, or of course I can specify the array to assemble. And what does /proc/mdstat contain at this point. Before I stop and re-start the arrays, all four show inactive. After I manually assemble the arrays, they all show active (auto-read-only). Also, show ls -l /dev/md* /dev/sd* Something is also wrong with this busybox's implementation of `more`, so it's hard to see all of any sufficiently verbose output. Suffice to say the block devices (md0 - 3, sda - k, and sdl1 -3 plus sdm1 - 3) are all there. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/vf-dnrsi1pnckdtqnz2dnuvz5okdn...@giganews.com
Re: Upgrade to 2.6.32-5-amd64 failing miserably
Here is the output of dmesg under the new kernel: [4.228353] ata4.04: hard resetting link [4.564319] ata4.04: SATA link down (SStatus 0 SControl 320) [4.564375] ata4.05: hard resetting link [4.900300] ata4.05: SATA link up 1.5 Gbps (SStatus 113 SControl 320) [4.939162] ata4.00: ATA-8: WDC WD15EADS-00R6B0, 01.00A01, max UDMA/133 [4.939164] ata4.00: 2930277168 sectors, multi 0: LBA48 NCQ (depth 31/32) [4.943192] ata4.00: configured for UDMA/100 [4.946435] ata4.01: ATA-8: WDC WD15EADS-00R6B0, 01.00A01, max UDMA/133 [4.946438] ata4.01: 2930277168 sectors, multi 0: LBA48 NCQ (depth 31/32) [4.950727] ata4.01: configured for UDMA/100 [4.955783] ata4.02: ATA-8: WDC WD15EADS-00R6B0, 01.00A01, max UDMA/133 [4.955785] ata4.02: 2930277168 sectors, multi 0: LBA48 NCQ (depth 31/32) [4.961792] ata4.02: configured for UDMA/100 [4.963501] ata4.03: ATA-8: WDC WD15EADS-00P8B0, 01.00A01, max UDMA/133 [4.963503] ata4.03: 2930277168 sectors, multi 0: LBA48 NCQ (depth 31/32) [4.965305] ata4.03: configured for UDMA/100 [4.965365] ata4: EH complete [4.965449] scsi 3:0:0:0: Direct-Access ATA WDC WD15EADS-00R 01.0 PQ: 0 ANSI: 5 [4.965585] scsi 3:1:0:0: Direct-Access ATA WDC WD15EADS-00R 01.0 PQ: 0 ANSI: 5 [4.965707] scsi 3:2:0:0: Direct-Access ATA WDC WD15EADS-00R 01.0 PQ: 0 ANSI: 5 [4.965832] scsi 3:3:0:0: Direct-Access ATA WDC WD15EADS-00P 01.0 PQ: 0 ANSI: 5 [6.380157] usb-storage: device scan complete [6.380626] scsi 13:0:0:0: Direct-Access SanDisk SanDisk Cruzer 8.02 PQ: 0 ANSI: 0 CCS [6.380996] scsi 13:0:0:1: CD-ROMSanDisk SanDisk Cruzer 8.02 PQ: 0 ANSI: 0 [7.076030] ata5: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [7.076258] ata5.15: Port Multiplier 1.1, 0x1095:0x3726 r23, 6 ports, feat 0x1/0x9 [7.092219] ata5.00: hard resetting link [7.428322] ata5.00: SATA link up 3.0 Gbps (SStatus 123 SControl 320) [7.428352] ata5.01: hard resetting link [7.764293] ata5.01: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [7.764320] ata5.02: hard resetting link [8.100323] ata5.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [8.100353] ata5.03: hard resetting link [8.436319] ata5.03: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [8.436348] ata5.04: hard resetting link [8.772318] ata5.04: SATA link down (SStatus 0 SControl 320) [8.772374] ata5.05: hard resetting link [9.108293] ata5.05: SATA link up 1.5 Gbps (SStatus 113 SControl 320) [9.110465] ata5.00: ATA-8: WDC WD15EARS-00Z5B1, 80.00A80, max UDMA/133 [9.110468] ata5.00: 2930277168 sectors, multi 0: LBA48 NCQ (depth 31/32) [9.113055] ata5.00: configured for UDMA/100 [9.115434] ata5.01: ATA-8: WDC WD15EARS-00Z5B1, 80.00A80, max UDMA/133 [9.115436] ata5.01: 2930277168 sectors, multi 0: LBA48 NCQ (depth 31/32) [9.117420] ata5.01: configured for UDMA/100 [9.11] ata5.02: ATA-8: WDC WD15EARS-00Z5B1, 80.00A80, max UDMA/133 [9.120001] ata5.02: 2930277168 sectors, multi 0: LBA48 NCQ (depth 31/32) [9.121969] ata5.02: configured for UDMA/100 [9.124597] ata5.03: ATA-8: WDC WD15EADS-00P8B0, 01.00A01, max UDMA/133 [9.124600] ata5.03: 2930277168 sectors, multi 0: LBA48 NCQ (depth 31/32) [9.127144] ata5.03: configured for UDMA/100 [9.127204] ata5: EH complete [9.127291] scsi 4:0:0:0: Direct-Access ATA WDC WD15EARS-00Z 80.0 PQ: 0 ANSI: 5 [9.127469] scsi 4:1:0:0: Direct-Access ATA WDC WD15EARS-00Z 80.0 PQ: 0 ANSI: 5 [9.127593] scsi 4:2:0:0: Direct-Access ATA WDC WD15EARS-00Z 80.0 PQ: 0 ANSI: 5 [9.127705] scsi 4:3:0:0: Direct-Access ATA WDC WD15EADS-00P 01.0 PQ: 0 ANSI: 5 [ 11.252029] ata6: SATA link up 3.0 Gbps (SStatus 123 SControl 0) [ 11.252255] ata6.15: Port Multiplier 1.1, 0x1095:0x3726 r23, 6 ports, feat 0x1/0x9 [ 11.268197] ata6.00: hard resetting link [ 11.604322] ata6.00: SATA link up 3.0 Gbps (SStatus 123 SControl 320) [ 11.604353] ata6.01: hard resetting link [ 11.940321] ata6.01: SATA link down (SStatus 0 SControl 320) [ 11.940378] ata6.02: hard resetting link [ 12.276293] ata6.02: SATA link up 3.0 Gbps (SStatus 123 SControl 300) [ 12.276320] ata6.03: hard resetting link [ 12.612321] ata6.03: SATA link down (SStatus 0 SControl 320) [ 12.612377] ata6.04: hard resetting link [ 12.948321] ata6.04: SATA link down (SStatus 0 SControl 320) [ 12.948378] ata6.05: hard resetting link [ 13.284318] ata6.05: SATA link up 1.5 Gbps (SStatus 113 SControl 320) [ 13.287633] ata6.00: ATA-8: WDC WD15EADS-00P8B0, 01.00A01, max UDMA/133 [ 13.287635] ata6.00: 2930277168 sectors, multi 0: LBA48 NCQ (depth 31/32) [ 13.290246] ata6.00: configured for UDMA/100 [ 13.292122] ata6.02: ATA-8: WDC WD15EARS-00Z5B1, 80.00A80, max UDMA/133 [ 13.292124] ata6.02: 2930277168 sectors, multi 0: LBA48 NCQ (depth 31/32) [ 13.294114] ata6.02: configured for
Re: Upgrade to 2.6.32-5-amd64 failing miserably
also sprach lrhorer lrho...@satx.rr.com [2011.02.02.2047 +0100]: ARRAY /dev/md0 level=raid6 num-devices=10 metadata=01.2 name=Backup:0 UUID=431244d6:45d9635a:e88b3de5:92f30255 What's metadata=01.2. I suggest you remove the 0, except for this one line: ARRAY /dev/md1 level=raid1 num-devices=2 metadata=0.90 UUID=4cde286c:0687556a:4d9996dd:dd23e701 And what does /proc/mdstat contain at this point. Before I stop and re-start the arrays, all four show inactive. Are they degraded? Also, judging from your dmesg output, you *do* have hardware problems. Also, what version of mdadm are you using? Which package? -- .''`. martin f. krafft madduck@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 ... (ethik und ästhetik sind eins.) -- wittgenstein digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
Re: Upgrade to 2.6.32-5-amd64 failing miserably
martin f krafft wrote: also sprach lrhorer lrho...@satx.rr.com [2011.02.02.2047 +0100]: ARRAY /dev/md0 level=raid6 num-devices=10 metadata=01.2 name=Backup:0 UUID=431244d6:45d9635a:e88b3de5:92f30255 What's metadata=01.2. I suggest you remove the 0, except for this one line: I'll give it a shot, although it shouldn't matter. Note I didn't create the line. Mdadm did. I suppose there could be a version incompatibility between the two initrds, but there shouldn't be. Both report the same version of mdadm. Besides, if it were a problem, why do they assemble at all? How is it I can stop and then re-assemble the arrays with no problems? (Not to mention, how is it it works under 2.6.32-5?) ARRAY /dev/md1 level=raid1 num-devices=2 metadata=0.90 UUID=4cde286c:0687556a:4d9996dd:dd23e701 I definitely know this won't matter, since md1 is not required once the initrd is loaded. Md1 is the boot array, containing GRUB, the kernel, and of course the initrd. It's not used once GRUB has done its work, the kernel is live, and the RAM Disk is operational. Md2 is the critical array, at this point, and its failure to mount is what is causing the boot to fail. And what does /proc/mdstat contain at this point. Before I stop and re-start the arrays, all four show inactive. Are they degraded? Nope. 100% clean, both when inactive and when active. No drives faulty or removed. The arrays and the file systems are both pristine. Why md is assembling the arrays but not activating them is the question. Also, judging from your dmesg output, you *do* have hardware problems. Where? I'm not seeing anything related to md or anything which would cause the arrays not to start. Also, what version of mdadm are you using? Which package? Debian Squeeze. Both the mdadm binary in the 2.6.32-5 and in the /sbin/ directory of the root array report 3.1.2, which is the version supported in the distro. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/vf-dnrai1pnom9fqnz2dnuvz5okdn...@giganews.com
Re: Upgrade to 2.6.32-5-amd64 failing miserably
There's another, possibly very significant oddity. Right now, when the old kernel boots, it exhibits exactly the same symptoms for /dev/md0, but not for the other arrays, the only obvious difference being /dev/md0 is comprised entirely of disks whose udev names are /dev/sdX, while the other arrays are built entirely from members whose names are /dev/hdXY. In the new kernel, all the drive names are /dev/sdX. For some reason, it is trying to assemble all the members twice, the difference being the arrays assembled from PATA targets are being stopped in the old kernel before the second attempt to assemble the array, but not the new: Dmesg | grep md from the old kernel: [0.00] Command line: BOOT_IMAGE=/vmlinuz-2.6.32-3-amd64 root=/dev/md2 ro quiet [0.00] Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.32-3-amd64 root=/dev/md2 ro quiet [2.411210] md: raid1 personality registered for level 1 [2.940328] md: raid6 personality registered for level 6 [2.940331] md: raid5 personality registered for level 5 [2.940332] md: raid4 personality registered for level 4 [2.948514] md: md1 stopped. [2.951701] md: bindhdb1 [2.951933] md: bindhda1 [2.953206] raid1: raid set md1 active with 2 out of 2 mirrors [2.957738] md1: bitmap initialized from disk: read 1/1 pages, set 0 bits [2.957741] created bitmap (1 pages) for device md1 [3.000642] md1: detected capacity change from 0 to 6292176896 [3.001942] md1: unknown partition table snip Compare that with the new kernel: [0.00] Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.32-5-amd64 root=/dev/md2 ro quiet [0.748091] usb usb1: Manufacturer: Linux 2.6.32-5-amd64 ehci_hcd [0.748547] ata1: SATA max UDMA/133 port i16@0xec00 bmdma 0xe400 irq 20 [0.748551] ata2: SATA max UDMA/133 port i16@0xe880 bmdma 0xe408 irq 20 [0.748553] ata3: PATA max UDMA/133 port i16@0xe800 bmdma 0xe410 irq 20 [0.806045] usb usb2: Manufacturer: Linux 2.6.32-5-amd64 ohci_hcd [0.807649] ata8: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0xff00 irq 14 [0.807652] ata9: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0xff08 irq 15 [0.820043] usb usb3: Manufacturer: Linux 2.6.32-5-amd64 ehci_hcd [0.882041] usb usb4: Manufacturer: Linux 2.6.32-5-amd64 ohci_hcd [0.938057] usb usb5: Manufacturer: Linux 2.6.32-5-amd64 ohci_hcd [0.994029] usb usb6: Manufacturer: Linux 2.6.32-5-amd64 ohci_hcd [1.050029] usb usb7: Manufacturer: Linux 2.6.32-5-amd64 ohci_hcd [ 16.140763] md: bindsdk1 [ 16.150006] md: bindsdl3 [ 16.170380] md: bindsdl2 [ 16.199653] md: array md1 already has disks! [ 16.225273] md: bindsdi [ 16.349657] md: raid1 personality registered for level 1 snip -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/vf-dnrgi1pmuh9fqnz2dnuvz5okdn...@giganews.com
Upgrade to 2.6.32-5-amd64 failing miserably
I have been attempting to upgrade a Debian Squeeze Linux box from 2.6.32-3-amd64 to 2.6.32-5-amd64, but the upgrade is a non-starter. GRUB2 comes up just fine, but when I select the new kernel version, a number of announcements flash by too fast to seen. I am not 100% certain, but I believe the initrd starts to load OK. Some text flies by far too quickly to be seen, but then an error pops up concerning an address space collision of some PCI device. Then it shows three errors for RAID devices md1. md2, and md3, saying they are already in use. Immediately thereafter the system shows errors concerning the RAID targets being already in use, after which point the system complains it can't mount / (md2), /dev, /sys, or /proc (in that order) because the sources do not exist (if /dev/md2 does not exist, how can it be busy?). Thereafter, of course, it fails to find init, since / is not mounted. It then tries to run BusyBox, but Busybox complains: /bin/sh: can't access tty; job control turned off After that, it attempts to put up an initramfs prompt, but of course with no tty access, it just hangs completely. Not surprisingly, recovery mode doesn't boot, either. It gives a bit more detail in the output, but nothing illuminating. The old kernel (2.6.32-3-amd64) boots just fine. Obviously there is a problem in the initramfs, probably with mdadm, but what? What should I try to manipulate in the initrd so I can find out what is failing? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/uoidnyrcaohf9txqnz2dnuvz5qedn...@giganews.com
Re: Upgrade to 2.6.32-5-amd64 failing miserably
--- On Tue, 2/1/11, lrhorer lrho...@satx.rr.com wrote: Obviously there is a problem in the initramfs, probably with mdadm, but what? What should I try to manipulate in the initrd so I can find out what is failing? When I was running mdadm, I'd usually rebuild initramfs manually after a kernel upgrade. That would include all the necessary drivers into the initrd image. Make sure you backup your working /boot/initrd.img, then run # update-initramfs -ut -k 2.6.32-5-amd64 HTH -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/733349.34962...@web45806.mail.sp1.yahoo.com
Re: Upgrade to 2.6.32-5-amd64 failing miserably
S D wrote: --- On Tue, 2/1/11, lrhorer lrho...@satx.rr.com wrote: Obviously there is a problem in the initramfs, probably with mdadm, but what? What should I try to manipulate in the initrd so I can find out what is failing? When I was running mdadm, I'd usually rebuild initramfs manually after a kernel upgrade. That would include all the necessary drivers into the initrd image. Make sure you backup your working /boot/initrd.img, then run # update-initramfs -ut -k 2.6.32-5-amd64 HTH Thanks. I had already tried that, more than once. Just for giggles, I tried again. No joy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/uoidnyxcaoge4nxqnz2dnuvz5qedn...@giganews.com
Re: Upgrade to 2.6.32-5-amd64 failing miserably
also sprach lrhorer lrho...@satx.rr.com [2011.02.01.2123 +0100]: far too quickly to be seen, but then an error pops up concerning an address space collision of some PCI device. Then it shows three errors for RAID devices md1. md2, and md3, saying they are already in use. This looks like a hardware problem, causing mdadm to fail to assemble. Immediately thereafter the system shows errors concerning the RAID targets being already in use, after which point the system complains it can't mount / (md2), /dev, /sys, or /proc (in that order) because the sources do not exist (if /dev/md2 does not exist, how can it be busy?). Thereafter, of course, it fails to find init, since / is not mounted. It then tries to run BusyBox, but Busybox complains: /bin/sh: can't access tty; job control turned off This is normal. Don't worry about that. Instead, try to assemble the arrays manually. And provide me with a lot more information, e.g. ls -l /dev/md* /dev/[sh]d* cat /proc/mdstat mdadm -Es dmesg It would really help if you could also enable initramfs debugging (http://wiki.debian.org/InitramfsDebug) and provide us with the output file. -- .''`. martin f. krafft madduck@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 the mind of the thoroughly well-informed man is a dreadful thing. it is like a bric-à-brac shop, all monsters and dust, with everything priced above its proper value. -- oscar wilde digital_signature_gpg.asc Description: Digital signature (see http://martin-krafft.net/gpg/sig-policy/999bbcc4/current)
