martin f krafft wrote:
> also sprach lrhorer [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 SCon
also sprach lrhorer [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]
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 oth
martin f krafft wrote:
> also sprach lrhorer [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 sho
also sprach lrhorer [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
> U
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]
martin f krafft wrote:
> also sprach lrhorer [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 real
also sprach lrhorer [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 gr
martin f krafft wrote:
> also sprach lrhorer [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 f
also sprach lrhorer [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 th
martin f krafft wrote:
> also sprach lrhorer [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 wit
also sprach lrhorer [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-
martin f krafft wrote:
> also sprach lrhorer [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.
>
> Thi
also sprach lrhorer [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, c
S D wrote:
> --- On Tue, 2/1/11, lrhorer 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 a
--- On Tue, 2/1/11, lrhorer 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. T
16 matches
Mail list logo
