megamap
megamap copied to clipboard
Uninitialized value $linux
Use of uninitialized value $linux in concatenation (.) or string at ./megamap line 84. 0 ?
This is output for me from megamap.
Not sure if this will help:
root@kali:~/megamap/megamap# megaclisas-status
-- Controller information --
-- ID | H/W Model | RAM | Temp | BBU | Firmware
c0 | PERC H800 Adapter | 512MB | N/A | Good | FW: 12.10.6-0001
-- Array information --
-- ID | Type | Size | Strpsz | Flags | DskCache | Status | OS Path | InProgress
c0u0 | RAID-10 | 7276G | 64 KB | ADRA,WB | Default | Optimal | /dev/sda | None
-- Disk information --
-- ID | Type | Drive Model | Size | Status | Speed | Temp | Slot ID | LSI Device ID
c0u0s0p0 | HDD | SEAGATE ST4000NM0023 GS0DZ1Z44GB3 | 3.637 TB | Online, Spun Up | 6.0Gb/s | 34C | [13:0] | 12
c0u0s0p1 | HDD | SEAGATE ST4000NM0023 GS0DZ1Z44JCA | 3.637 TB | Online, Spun Up | 6.0Gb/s | 36C | [13:1] | 11
c0u0s1p0 | HDD | SEAGATE ST4000NM0023 GS0DZ1Z43ZCY | 3.637 TB | Online, Spun Up | 6.0Gb/s | 35C | [13:2] | 9
c0u0s1p1 | HDD | SEAGATE ST4000NM0023 GS0DZ1Z44H2Y | 3.637 TB | Online, Spun Up | 6.0Gb/s | 33C | [13:3] | 10
-- Unconfigured Disk information --
-- ID | Type | Drive Model | Size | Status | Speed | Temp | Slot ID | LSI Device ID
c0uXpY | HDD | SEAGATE ST4000NM0023 GS10S1Z1KZM7 | 3.637 TB | Unconfigured(good), Spun Up | 6.0Gb/s | 35C | [13:4] | 14
c0uXpY | HDD | SEAGATE ST4000NM0023 GS10S1Z1KX7M | 3.637 TB | Unconfigured(good), Spun Up | 6.0Gb/s | 34C | [13:5] | 15
c0uXpY | HDD | SEAGATE ST4000NM0023 GS10S1Z1KZB1 | 3.637 TB | Unconfigured(good), Spun Up | 6.0Gb/s | 33C | [13:6] | 16
c0uXpY | HDD | SEAGATE ST4000NM0023 GS10S1Z1L05Y | 3.637 TB | Unconfigured(good), Spun Up | 6.0Gb/s | 31C | [13:7] | 17
What OS distro and release are you on?
Can you paste in the output from megacli -pdlist -a0 | egrep 'Slot|^SAS'
?
I'm running Debian stable (8.3).
root@kali:~/ansible-playbooks# megacli -pdlist -a0 | egrep 'Slot|^SAS' Slot Number: 0 SAS Address(0): 0x5000c50058a04111 SAS Address(1): 0x5000c50058a04112 Slot Number: 1 SAS Address(0): 0x5000c500589fc059 SAS Address(1): 0x5000c500589fc05a Slot Number: 2 SAS Address(0): 0x5000c50058a01631 SAS Address(1): 0x5000c50058a01632 Slot Number: 3 SAS Address(0): 0x5000c50058a01571 SAS Address(1): 0x5000c50058a01572 Slot Number: 4 SAS Address(0): 0x5000c5008f8b12b9 SAS Address(1): 0x5000c5008f8b12ba Slot Number: 5 SAS Address(0): 0x5000c5008f8d1115 SAS Address(1): 0x5000c5008f8d1116 Slot Number: 6 SAS Address(0): 0x5000c5008f8b8335 SAS Address(1): 0x5000c5008f8b8336 Slot Number: 7 SAS Address(0): 0x5000c5008f8a75b5 SAS Address(1): 0x5000c5008f8a75b6
That helped me isolate the problem. (It was a bit of a head scratcher because I used the same variable name twice, but that's fixed now.) What is the output of ls -l /dev/disk/by-id | grep -v part
?
I'm guessing the /dev/disk/by-id
directory is gone or I haven't looked at a large enough range of UUID's. I've added a patch to master to avoid the message you got. If we get any output from the ls
above then I should be able to tweak the range code so the unmatched drive can be found.
On Wed, Mar 16, 2016 at 10:02 AM, Christopher Hicks < [email protected]> wrote:
ls -l /dev/disk/by-id | grep -v part
root@kali:~/megamap/megamap# ls -l /dev/disk/by-id | grep -v part
total 0
lrwxrwxrwx 1 root root 9 Jul 5 2015 ata-PLDS_DVD-ROM_DS-8D3SH_202160315125 -> ../../sr0
lrwxrwxrwx 1 root root 9 Jul 5 2015 ata-ST1000NM0033-9ZM173_Z1W3MMY5 -> ../../sdb
lrwxrwxrwx 1 root root 10 Jul 5 2015 dm-name-CSVolGroup1-extrel -> ../../dm-6
lrwxrwxrwx 1 root root 10 Jul 5 2015 dm-name-CSVolGroup1-faculty -> ../../dm-2
lrwxrwxrwx 1 root root 10 Jul 5 2015 dm-name-CSVolGroup1-grads -> ../../dm-3
lrwxrwxrwx 1 root root 10 Jul 5 2015 dm-name-CSVolGroup1-shared -> ../../dm-5
lrwxrwxrwx 1 root root 10 Jul 5 2015 dm-name-CSVolGroup1-site -> ../../dm-7
lrwxrwxrwx 1 root root 10 Jul 5 2015 dm-name-CSVolGroup1-wexport -> ../../dm-4
lrwxrwxrwx 1 root root 10 Jul 5 2015 dm-name-kali-root -> ../../dm-0
lrwxrwxrwx 1 root root 10 Jul 5 2015 dm-name-kali-swap_1 -> ../../dm-1
lrwxrwxrwx 1 root root 10 Jul 5 2015 dm-uuid-LVM-0PrXDn2yrwvJSWyxXB7RpbFIlfb0NAhI0nuTc56TKswLcceMjaEBdYWJc1c8B0tj -> ../../dm-6
lrwxrwxrwx 1 root root 10 Jul 5 2015 dm-uuid-LVM-0PrXDn2yrwvJSWyxXB7RpbFIlfb0NAhI9AMxAMrd01bdl9eetj2FBW9ivXVTVRar -> ../../dm-7
lrwxrwxrwx 1 root root 10 Jul 5 2015 dm-uuid-LVM-0PrXDn2yrwvJSWyxXB7RpbFIlfb0NAhIKiQuXGkLv5hvdqcsz1cPPWNNXgYKei7d -> ../../dm-2
lrwxrwxrwx 1 root root 10 Jul 5 2015 dm-uuid-LVM-0PrXDn2yrwvJSWyxXB7RpbFIlfb0NAhILc17IuvdPmWCmeE5LROW8JLaYIO78IkR -> ../../dm-3
lrwxrwxrwx 1 root root 10 Jul 5 2015 dm-uuid-LVM-0PrXDn2yrwvJSWyxXB7RpbFIlfb0NAhIwXgLnX3LeZ22Z74LsgzcreMF1GoYZKOi -> ../../dm-4
lrwxrwxrwx 1 root root 10 Jul 5 2015 dm-uuid-LVM-0PrXDn2yrwvJSWyxXB7RpbFIlfb0NAhIXd1Jmv370y1Jqz1TgoLNYOV12SaAK6vQ -> ../../dm-5
lrwxrwxrwx 1 root root 10 Jul 5 2015 dm-uuid-LVM-F6NSjs0xFN6XAeoo235R32uW7crj0I4i22i7lwdoPZTfpuR2pQ1nHLqMwxxEmdQb -> ../../dm-0
lrwxrwxrwx 1 root root 10 Jul 5 2015 dm-uuid-LVM-F6NSjs0xFN6XAeoo235R32uW7crj0I4iBu9WBn4btFlr3YmSwQJrTfMfxXszl91g -> ../../dm-1
lrwxrwxrwx 1 root root 10 Mar 16 06:00 lvm-pv-uuid-693BCo-zuEn-NGj8-KZw4-OhXc-6Vfh-vboPVq -> ../../sda1
lrwxrwxrwx 1 root root 10 Jul 5 2015 lvm-pv-uuid-w6Rajo-87fd-Jpdl-VvMM-NdfC-QR0Q-bTDgB5 -> ../../sdc5
lrwxrwxrwx 1 root root 9 Jul 5 2015 scsi-3600508e000000000557c8d0363dc8f0c -> ../../sdc
lrwxrwxrwx 1 root root 9 Mar 16 06:00 scsi-36c81f660d62f3b001b62c92d09ac8fc6 -> ../../sda
lrwxrwxrwx 1 root root 9 Jul 5 2015 wwn-0x5000c5007abd9c20 -> ../../sdb
lrwxrwxrwx 1 root root 9 Jul 5 2015 wwn-0x600508e000000000557c8d0363dc8f0c -> ../../sdc
lrwxrwxrwx 1 root root 9 Mar 16 06:00 wwn-0x6c81f660d62f3b001b62c92d09ac8fc6 -> ../../sda
pulled your changes:
root@kali:~/megamap/megamap# ./megamap
0 ? ???
1 ? ???
2 ? ???
3 ? ???
4 ? ???
5 ? ???
6 ? ???
7 ? ???
So, some progress. Hope this helps. Let me know if you need more.
David-
Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe. -- Albert Einstein Visit my web page at: http://david.bandel.us/
That helps. I'm slammed this week, but I will dig in more when I get a chance.
@chicks-net any luck with this? otherwise I may need to step in :)
@bwitt I'd be happy for someone to shine a light on this. I've been meaning to turn David's files into debugging files but I haven't gotten that far yet. In glancing at the output just now it looks like sdb
has the only WWN that is in the right range but it is nowhere close to the megacl
i WWN's so I'm stumped as of now. There's some chance that the kernel or LSI have changed something that breaks my matching trick.
David: what kernel version are you on?
That script David mentioned does work for my RAID setup (shows the linux device) but not the JBOD ones: https://github.com/eLvErDe/hwraid/blob/master/wrapper-scripts/megaclisas-status
Hi all, sorry for reviving this, but I'm seeing the same thing on a fully updated jessie, running kernel 3.16.36-1+deb8u2 Let me know if you need more details. Edit: I just noticed another difference: my "ls -l /dev/disk/by-id | grep -v part" has mappings for both scsi-hash, and wwwn-0xhash, so it might not be the same thing.. If you conclude it's a separate issue, I can open another ticket? Thanks, camypaj
Howdy camypaj,
It does seem like a fresh issue would be good for this. Please include the output from:
-
megacli -pdlist -a0 | egrep 'Slot|^SAS'
-
ls -l /dev/disk/by-id
-
uname -a
-
lsb_release -a
The newly included script megatrouble
will give you all of this in a format ready to paste into an issue.