Умер диск в lpar из под Vios. Что делать?

[TemplarУчастник]

Господа, если я правильно понимаю у меня умер hdisk0?

lpar боевой!

Файловая система в зеркале, работает из под dual vios.
Какой порядок действий по замене диска? подскажите пожалуйста.

Все команды в lpar. В errpt на vios ошибок нет.

bash-3.00# lspv
hdisk0 000520ffffda3ac2 rootvg active
hdisk2 000520fffef457fc rootvg active

bash-3.00# lsdev -Cc disk
hdisk0 Available Virtual SCSI Disk Drive
hdisk1 Defined Virtual SCSI Disk Drive
hdisk2 Available Virtual SCSI Disk Drive

bash-3.00# lsvg -l rootvg
rootvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
hd5 boot 1 2 2 closed/stale N/A
hd6 paging 4 8 2 open/syncd N/A
hd8 jfs2log 1 2 2 open/stale N/A
hd4 jfs2 2 4 2 open/stale /
hd2 jfs2 103 206 2 open/stale /usr
hd9var jfs2 4 8 2 open/stale /var
hd3 jfs2 80 160 2 open/stale /tmp
hd1 jfs2 1 2 2 open/stale /home
hd10opt jfs2 16 32 2 open/stale /opt

bash-3.00# lscfg -v | grep disk
hdisk2 U9133.55A.655DC9H-V3-C4-T1-L820000000000 Virtual SCSI Disk Drive
hdisk0 U9133.55A.655DC9H-V3-C3-T1-L810000000000 Virtual SCSI Disk Drive

bash-3.00# bootlist -m normal -o
hdisk0
hdisk2 blv=hd5

bash-3.00# bosboot -ad /dev/hdisk2

0301-108 /usr/lib/boot/bin/mkboot_chrp: Unable to read file blocks. Return code: -1

0301-158 bosboot: mkboot failed to create bootimage.

0301-165 bosboot: WARNING! bosboot failed – do not attempt to boot device.

bash-3.00# errpt
IDENTIFIER TIMESTAMP T C RESOURCE_NAME DESCRIPTION
EAA3D429 0127113017 U S LVDD PHYSICAL PARTITION MARKED STALE

[TemplarУчастник]

Прошу прощения на одном из виосов тоже все плохо:
#errpt
ksh:Invalid file system control data detected

# lspv
ksh: Invalid file system control data detected
hdisk2 000520fffae529a7 rootvg active
hdisk3 000520ffd402eff6 rootvg active

# lsvg -l rootvg
ksh: Invalid file system control data detected
0516-070 : LVM system call found an unaccountable
internal error.

Как правильно заменить сломавшийся диск?

[MichaelУчастник]

1. Проверить наличие гарантии/техподдержки на сервер.

2.1. Если техподдержка есть, то открыть заявку в IBM и следовать инструкциям.

2.2. Если же техподдержки нет, то…

[sdudnikУчастник]

Похоже виосу поплохело. Если два виоса правильно настроены, и диск в лпаре отвалилися именно со сбойного виоса, то можно попробовать перегрузить его, чтобы fsck прошла. Странно, что на виосе нет никаких дисков, которые должны быть примаплены к лпаре. Или они отвалились, или лпаре отданы логические тома из rootvg виоса, что маловероятно.

 

на лпаре нужно определить, был ли hdisk1 в rootvg

lsvg -p rootvg

и определить какие диски живы

lquerypv -h /dev/hdiskX, где  X это номер диска

 

 

[TemplarУчастник]

Сервер 2006 года, гарантии никакой нет(

Что-то мне страшно перезагружать lpar. Все началось с того что мне нужно было немного расширить раздел opt и вот что он выдал:
bash-3.00# chfs -a size=5G /opt/
lquerypv: Warning, physical volume hdisk0 is excluded since it may be
either missing or removed.
0516-404 allocp: This system cannot fulfill the allocation request.
There are not enough free partitions or not enough physical volumes
to keep strictness and satisfy allocation requests. The command
should be retried with different allocation characteristics.
0516-1734 extendlv: Warning, savebase failed. Please manually run ‘savebase’ before rebooting.

Диск hdisk1 не в rootvg

bash-3.00# lsvg -p rootvg
rootvg:
PV_NAME PV STATE TOTAL PPs FREE PPs FREE DISTRIBUTION
hdisk2 active 279 67 11..00..00..00..56
hdisk0 missing 279 67 11..00..00..00..56

bash-3.00# lquerypv -h /dev/hdisk0
bash-3.00# lquerypv -h /dev/hdisk1
bash-3.00# lquerypv -h /dev/hdisk2
00000000 C9C2D4C1 00000000 00000000 00000000 |…………….|
00000010 00000000 00000000 00000000 00000000 |…………….|
00000020 00000000 00000000 00000000 00000000 |…………….|
00000030 00000000 00000000 00000000 00000000 |…………….|
00000040 00000000 00000000 00000000 00000000 |…………….|
00000050 00000000 00000000 00000000 00000000 |…………….|
00000060 00000000 00000000 00000000 00000000 |…………….|
00000070 00000000 00000000 00000000 00000000 |…………….|
00000080 000520FF FEF457FC 00000000 00000000 |.. …W………|
00000090 00000000 00000000 00000000 00000000 |…………….|
000000A0 00000000 00000000 00000000 00000000 |…………….|
000000B0 00000000 00000000 00000000 00000000 |…………….|
000000C0 00000000 00000000 00000000 00000000 |…………….|
000000D0 00000000 00000000 00000000 00000000 |…………….|
000000E0 00000000 00000000 00000000 00000000 |…………….|
000000F0 00000000 00000000 00000000 00000000 |…………….|

Такой диск на замену у меня в наличии есть…

[sdudnikУчастник]

Имел ввиду перегружать не лпару, а виос. Опасения понятные, ибо если некорректо настроена отказоустойчивость, то лпара отвалиться.

Судя по выводу отвалился hdisk0  на лпаре. Нужно убедиться с какого виоса он примаплен.

можете прислать lspv с рабочего виоса? и вывод lsmap -all

Еще нужен номер сбойно лпары, можно посмотреть из HMC.

 

[TemplarУчастник]

Lpar ID 3

$ lsmap -all
SVSA Physloc Client Partition ID
————— ——————————————– ——————
vhost0 U9133.55A.655DC9H-V2-C5 0x00000003

VTD vtopt0
Status Available
LUN 0x8100000000000000
Backing device cd0
Physloc U787B.001.DNWG06Z-P4-D2

VTD vtscsi0
Status Available
LUN 0x8200000000000000
Backing device dnsrootvg
Physloc

SVSA Physloc Client Partition ID
————— ——————————————– ——————
vhost1 U9133.55A.655DC9H-V2-C6 0x00000004

VTD vtscsi1
Status Available
LUN 0x8100000000000000
Backing device nimrootvg
Physloc

SVSA Physloc Client Partition ID
————— ——————————————– ——————
vhost2 U9133.55A.655DC9H-V2-C7 0x00000000

VTD vtscsi2
Status Available
LUN 0x8100000000000000
Backing device monrootvg
Physloc

$ lspv
NAME PVID VG STATUS
hdisk0 000520ffdacd05b9 rootvg active
hdisk1 000520fffb00f594 rootvg active

[sdudnikУчастник]

Еще вывод lsvg -lv rootvg с рабочего виоса

 

[TemplarУчастник]

$ lsvg -lv rootvg
rootvg:
LV NAME TYPE LPs PPs PVs LV STATE MOUNT POINT
hd5 boot 1 1 1 closed/syncd N/A
hd6 paging 4 4 1 open/syncd N/A
paging00 paging 8 8 1 open/syncd N/A
hd8 jfs2log 1 1 1 open/syncd N/A
hd4 jfs2 4 4 1 open/syncd /
hd2 jfs2 30 30 1 open/syncd /usr
hd9var jfs2 5 5 1 open/syncd /var
hd3 jfs2 18 18 1 open/syncd /tmp
hd1 jfs2 80 80 1 open/syncd /home
hd10opt jfs2 14 14 1 open/syncd /opt
lg_dumplv sysdump 8 8 1 open/syncd N/A
hd11admin jfs2 1 1 1 open/syncd /admin
livedump jfs2 2 2 1 open/syncd /var/adm/ras/livedump
dnsrootvg jfs 280 280 1 open/syncd N/A
nimrootvg jfs 280 280 1 open/syncd N/A
monrootvg jfs 280 280 2 open/syncd N/A

[sdudnikУчастник]

Получается следующая ситуация –  у каждого виоса по два диска, они НЕ в зеркале  ( это можно также проверить командой lslv -m hd4) и на них расположен rootvg виосов. Также в rootvg расположены логические тома

<span style=”color: #5a5a5a; font-family: Verdana, Geneva, sans-serif; font-size: 12px;”>dnsrootvg jfs 280 280 1 open/syncd N/A</span><br style=”color: #5a5a5a; font-family: Verdana, Geneva, sans-serif; font-size: 12px;” /><span style=”color: #5a5a5a; font-family: Verdana, Geneva, sans-serif; font-size: 12px;”>nimrootvg jfs 280 280 1 open/syncd N/A</span><br style=”color: #5a5a5a; font-family: Verdana, Geneva, sans-serif; font-size: 12px;” /><span style=”color: #5a5a5a; font-family: Verdana, Geneva, sans-serif; font-size: 12px;”>monrootvg jfs 280 280 2 open/syncd N/A</span>

они с каждого виоса презентованы лпарам, и на лпаре собраны в зеркале. Так что нужно проверить и остальные лпары, на них скорее всего та же проблема.

Из плохих новостей – похоже что диск вылетел на виосе, а так как на нем не было зеркало (похоже, что отказоустойчивость сделали с помощью двух виосов, но пожалели диски, чтобы сделать зеркало на каждом и защитить их от сбоя), данные на одном виосе потеряны.  Скорее всего потребуется замена диска и переустановка сбойного виоса. В данный момент желательно проверить как устроена сеть, если используется shared ethernet adapter, то убедиться что активный адаптер сейчас у живого виоса ( для этого найти имя адаптера в lsdev -virtual на живом виосе, затем entstat -d имя-адаптера). Так же нужно посмотреть евенты в HMC,   там должны быть ошибки, если проблема хардварная.

 

[ДмитрийУчастник]

Небольшой оффтоп про физическую замену диска: диски, к счастью, самые обыкновенные. Можно купить для x86, максимум, придётся салазки поменять.

Вот только в прошлый раз я такое делал, когда IBM ещё выпускал диски под x86. Понятно, что внутри это Wd или ещё что-то, но прошивка была IBM овская.

[sdudnikУчастник]

В прошивке как раз и дело. Скорее всего с другой прошивкой не заведется.

[TemplarУчастник]

Диск родной PN 03N6347 на замену у меня есть.

SEA используется. Адаптер активный (вывод писать не буду, он очень большой) кол-во Packets меняется…

Eventы в HMC, к сожалению, удалил – видимо проблема давняя, просто обнаружил только сейчас…

Какая последовательность действий по восстановлению?
Если я правильно понимаю, то мне нужно сначала разломать зеркало на Lpar (а точнее на трех lpar):
unmirrorvg rootvg hdisk0
reducevg rootvg hdisk0
bosboot -a -d /dev/hdisk02
bootlist -m normal hdisk2

Не понятно, что дальше?
Можно ли как-то без переустановки vios решить проблему? даже сбойный vios долго, но грузится!
Может как-то вставить новый диск загрузиться с диска vios и восстановить битые lv?

[ДмитрийУчастник]

2) ремонт VIOS

Судя по lsvg -lv rootvg, смотрим на строки
dnsrootvg jfs 280 280 1 open/syncd N/A
nimrootvg jfs 280 280 1 open/syncd N/A
monrootvg jfs 280 280 2 open/syncd N/A
предполагая здравый смысл при установке VIOS,
а также зная, что он всё-таки работает и даже грузится,
можем предположить, что Вам повезло:
VIOS установлен на работающем диске, а LV для клиентов как-то разбросаны (monrootvg точно поплохело).
Чтобы узнать точно, нужно посмотреть
lspv -lv hdisk0
lspv -lv hdisk1
чтобы точно в этом убедиться.
Если ВСЕ остальные LV, кроме этих трёх, ЦЕЛИКОМ на хорошем диске, то переустанавливать VIOS не надо. Ну, разве что, /tmp и /home, если на битом диске, то, наверное, можно их переделать.

Если это предположение верно, то надо будет
разобрать виртуальные устройства (rmvdev -dev dnsrootvg и т.д.),
убрать диск из VG (reducevg rootvg битый_диск);
удалить устройство (rmdev -dev битый_диск);
заменить на новый
найти (cfgdev)
а вот дальше я бы сделал на нём отдельную VG для клиентов, а не включал в rootvg. Это правильнее. Гораздо правильнее.  Ещё правильнее включить его в riootvg и сделать зеркало, а клиентам диски пробрасывать с СХД (или найти ещё внутренние диски). Но, если со свободным местом совсем плохо, то придётся включать его в rootvg…
С этим разберёмся потом, надо понять, сколько места есть, сколько нужно, и тогда уже решить, как им распорядиться.
ну и, конечно, потом придётся заново создать LV для клиентов, создать виртуальные устройства, а в AIX-ах – пересоздать зеркало rootvg.

 

[ДмитрийУчастник]

1) ремонт AIX
Если я правильно понимаю, то мне нужно сначала разломать зеркало на Lpar (а точнее на трех lpar):
unmirrorvg rootvg hdisk0
reducevg rootvg hdisk0
bosboot -a -d /dev/hdisk02
bootlist -m normal hdisk2

да, всё правильно, только не “разломать” (уже разломано), а удалить 😉
небольшие дополнения: reducevg rootvg hdisk0 может не пройти, а ругаться на dump device
надо его временно отключить:
sysdumpdev -l (запоминаете имя primary dump device)
sysdumpdev -p /dev/sysdumpnull (временно отключаете)
после ремонта: sysdumpdev -p старое_имя
bootlist -m service hdisk2 тоже надо сделать

команда bosboot может не пройти, обычно лечится командой savebase (без параметров) и опять bosboot.

После того, как сбойный диск убрали из rootvg, можете смело его удалять из ОС
rmdev -dl сбойный_диск.

Повторяем это на всех затронутых AIX-ах (предварительно проверив и убедившись, что они требуют ремонта),
и переходим к ремонту VIOS.

[TemplarУчастник]

На рабочем VIOS:
bash-4.3# lspv -l hdisk0
hdisk0:
LV NAME LPs PPs DISTRIBUTION MOUNT POINT
dnsrootvg 280 280 109..15..30..109..17 N/A
hd11admin 1 1 00..00..01..00..00 /admin
livedump 2 2 00..02..00..00..00 /var/adm/ras/livedum
p
monrootvg 14 14 00..00..00..00..14 N/A
hd9var 5 5 00..00..05..00..00 /var
hd3 18 18 00..00..18..00..00 /tmp
hd1 80 80 00..80..00..00..00 /home
hd10opt 14 14 00..00..14..00..00 /opt
paging00 8 8 00..00..08..00..00 N/A
hd8 1 1 00..00..01..00..00 N/A
lg_dumplv 8 8 00..08..00..00..00 N/A
hd4 4 4 00..00..02..00..02 /
hd2 30 30 00..00..30..00..00 /usr
hd5 1 1 01..00..00..00..00 N/A
hd6 4 4 00..04..00..00..00 N/A

bash-4.3# lspv -l hdisk1
hdisk1:
LV NAME LPs PPs DISTRIBUTION MOUNT POINT
nimrootvg 280 280 00..109..109..62..00 N/A
monrootvg 266 266 110..00..00..47..109 N/A

На сбойном VIOS:
# lspv
ksh: Invalid file system control data detected
hdisk2 000520fffae529a7 rootvg active
hdisk3 000520ffd402eff6 rootvg active

# lspv -l hdisk2
ksh: Invalid file system control data detected
0516-070 : LVM system call found an unaccountable
internal error.

# lspv -l hdisk3
ksh: Invalid file system control data detected
0516-070 : LVM system call found an unaccountable
internal error.

[TemplarУчастник]

Еще глупый вопрос, не могу разобраться… в данном сервере у меня всего 4 диска, нет СХД. Как мне узнать location code сбойного диска?

Рабочий VIOS
# lsdev -Cc disk -F ‘name location physloc’
hdisk0 02-08-00-3,0 U787B.001.DNWG06Z-P1-C3-T1-L3-L0
hdisk1 02-08-00-4,0 U787B.001.DNWG06Z-P1-C3-T1-L4-L0

Сбойный VIOS#
#lsdev -Cc disk -F ‘name location physloc’
ksh: Invalid file system control data detected
hdisk0 00-08-00-3,0 U787B.001.DNWG06Z-P1-C3-A3
hdisk1 00-08-00-4,0 U787B.001.DNWG06Z-P1-C3-A4
hdisk2 03-08-00-5,0 U787B.001.DNWG06Z-P1-T14-L5-L0
hdisk3 03-08-00-8,0 U787B.001.DNWG06Z-P1-T14-L8-L0

HMC:
hscroot@hmc1:~> lshwres -m 9133-55A-SRV -r virtualio –rsubtype scsi –level lpar –filter “lpar_ids=3” -F slot_num,remote_lpar_id,remote_slot_num
4,2,5
3,1,5

Я бы предположил, что сбойный диск находится в слоте 5…? Но такого нет http://puu.sh/tGAYP/bf617b29ba.png

[ГригорийУчастник]

согласно этому https://www.ibm.com/support/knowledgecenter/en/POWER5/iphau_p5/loc550.htm

Рабочий VIOS
# lsdev -Cc disk -F ‘name location physloc’
hdisk0 02-08-00-3,0 U787B.001.DNWG06Z-P1-C3-T1-L3-L0 – U<em class=”ph i”>n-P2-D4
hdisk1 02-08-00-4,0 U787B.001.DNWG06Z-P1-C3-T1-L4-L0 – U<em class=”ph i”>n-P2-D3

Сбойный VIOS#
#lsdev -Cc disk -F ‘name location physloc’
ksh: Invalid file system control data detected
hdisk0 00-08-00-3,0 U787B.001.DNWG06Z-P1-C3-A3
hdisk1 00-08-00-4,0 U787B.001.DNWG06Z-P1-C3-A4
hdisk2 03-08-00-5,0 U787B.001.DNWG06Z-P1-T14-L5-L0 – U<em class=”ph i”>n-P2-D2
hdisk3 03-08-00-8,0 U787B.001.DNWG06Z-P1-T14-L8-L0 –  U<em class=”ph i”>n-P2-D1

Т.е. lsdev выдает логические коды, а с помощью документации определяем физические коды и ищем на вашей диаграмме. Что такое Un-C3-A3 и Un-C3-A4 – не знаю.

Если предположение о пятом слоте взялось из вывода lshwres, то это не правильно, так как это виртуальные адаптеры раздела с id=3.

[TemplarУчастник]

Спасибо!
Из вывода lspv -lv hdiskX (выше) видно на каких дисках лежат логические тома для клиентов на vios1. А как можно узнать какой из двух дисков вылетел (P2-D1 или P2-D2) на vios2? Уже кучу всего перепробовал в т.ч. lquerypv, lqueryvg, readvgda.
LVMу совсем плохо.

Сбойный vios:
# lslv -m dnsrootvg
ksh: Invalid file system control data detected
0516-070 : LVM system call found an unaccountable
internal error.

# lspv hdisk2
ksh: Invalid file system control data detected
0516-070 : LVM system call found an unaccountable
internal error.
PHYSICAL VOLUME: hdisk2 VOLUME GROUP: rootvg
PV IDENTIFIER: 000520fffae529a7 VG IDENTIFIER 000520ff0000d6000000011f4b434d8c
PV STATE: ???????
STALE PARTITIONS: ??????? ALLOCATABLE: ???????
PP SIZE: ??????? LOGICAL VOLUMES: ???????
TOTAL PPs: ??????? VG DESCRIPTORS: ???????
FREE PPs: ??????? HOT SPARE: ???????
USED PPs: ??????? MAX REQUEST: 256 kilobytes
FREE DISTRIBUTION: ???????
USED DISTRIBUTION: ???????
MIRROR POOL: ???????
# lspv hdisk3
ksh: Invalid file system control data detected
0516-070 : LVM system call found an unaccountable
internal error.
PHYSICAL VOLUME: hdisk3 VOLUME GROUP: rootvg
PV IDENTIFIER: 000520ffd402eff6 VG IDENTIFIER 000520ff0000d6000000011f4b434d8c
PV STATE: ???????
STALE PARTITIONS: ??????? ALLOCATABLE: ???????
PP SIZE: ??????? LOGICAL VOLUMES: ???????
TOTAL PPs: ??????? VG DESCRIPTORS: ???????
FREE PPs: ??????? HOT SPARE: ???????
USED PPs: ??????? MAX REQUEST: 256 kilobytes
FREE DISTRIBUTION: ???????
USED DISTRIBUTION: ???????
MIRROR POOL: ???????

[ГригорийУчастник]

а в rootvg есть свободное место? на сбойном vios-е? и errpt бы глянуть…

[TemplarУчастник]

Ничего не показывает

# lsvg rootvg
ksh: Invalid file system control data detected
0516-070 : LVM system call found an unaccountable
internal error.
# errpt
ksh: Invalid file system control data detected
#

[ГригорийУчастник]

Конец рабочего дня, виноват, я не rootvg имел ввиду, а / – корневую файловую систему. Если и errpt не работает, то мне кажется не в LVM дело. Может просто нет места в /, /var или в /tmp, и команды просто с ODM работать не могут нормально.

[TemplarУчастник]

Вы правы. Места нет в /
# df -g
ksh: Invalid file system control data detected
Filesystem GB blocks Free %Used Iused %Iused Mounted on
/dev/hd4 0.25 0.00 100% 2789 88% /
/dev/hd2 3.75 0.81 79% 82230 28% /usr
/dev/hd9var 0.62 0.41 34% 4457 5% /var
/dev/hd3 2.25 2.24 1% 105 1% /tmp
/dev/hd1 10.00 9.97 1% 75 1% /home
/proc – – – – – /proc
/dev/hd10opt 1.75 0.84 52% 10399 5% /opt
/dev/hd11admin 0.12 0.12 1% 5 1% /admin
/dev/livedump 0.25 0.25 1% 4 1% /var/adm/ras/livedump

Но получается какой-то “замкнутый круг”…
# chfs -a size=+10M /
ksh: Invalid file system control data detected
0516-070 /usr/sbin/lquerylv: LVM system call found an unaccountable
internal error.
chfs: Cannot get volume group partition size.

Удалить я даже не знаю что от туда можно… никаких логов нет.
du -sg /* при поиске выдает ряд I/O error

[ДмитрийУчастник]

Да, засада полная.
Ещё и в / место закончилось.
В “нормальной” ситуации я бы предложил отрезать место у /home и добавить его /
но здесь, со сбойным диском, это, наверное, не пройдёт.

Под рукой у меня VIOSа нет сейчас, посмотрите сами в корневом каталоге, вероятно, там есть core и/или какие-нибудь текстовые логи.
core можно смело удалять, логи, если боитесь, то перенести в /home.
Пока корневую ф.с. не почистить, толку не будет.

Интересный случай 🙂
Здесь проще всего посоветовать проверить, что с одним VIOS-ом всё работает, да и переставить сбойный. Но это не интересно 🙂

[ГригорийУчастник]

Если расчистка корня не поможет, то возможно дело не только в переполнении, есть вероятность что и файловая система побилась. Тогда без перезагрузки не обойтись, мне кажется. На этапе загрузки должна отработать fsck по файловым системам у которых check=true в /etc/filesystems. Если /etc/filesystems тоже попортился, то вот сюда https://www-01.ibm.com/support/docview.wss?uid=isg3T1000131 .

fsck – без ключа -y будет спрашивать разрешение на внесение исправлений, так что следите за консолью во время загрузки.

Как минимизировать простой для клиентов? Если они еще держатся на плаву, то может им третий vios как-то подсунуть удастся? или на первый переключить?

[TemplarУчастник]

Дмитрий писал(а):

Здесь проще всего посоветовать проверить, что с одним VIOS-ом всё работает, да и переставить сбойный. Но это не интересно

Можно и такой вариант, но нужно как-то определить какой именно диск сдох (P2-D1 или P2-D2).
Может это можно сделать по индикации?

Григорий писал(а):

Если /etc/filesystems тоже попортился, то вот сюда https://www-01.ibm.com/support/docview.wss?uid=isg3T1000131 .

Что-то мне подсказывает, что так и будет….

В общем, ситуация такая.
Вот содержимое /
# ls -la .
ksh: Invalid file system control data detected
total 208
drwxr-xr-x 17 root system 4096 Dec 8 18:10 .
drwxr-xr-x 17 root system 4096 Dec 8 18:10 ..
-rw——- 1 root system 94 Feb 6 2009 .sh_history
drwxr-xr-x 4 root system 256 Feb 6 2009 admin
drwxr-x— 2 root audit 256 Oct 8 2008 audit
lrwxrwxrwx 1 bin bin 8 Feb 6 2009 bin -> /usr/bin
-rw-r–r– 1 root system 5133 Jun 6 2007 bosinst.data
drwxrwxr-x 5 root system 8192 Jan 30 20:13 dev
drwxr-xr-x 34 root system 20480 Jul 30 2013 etc
drwxr-xr-x 6 bin bin 256 Jan 31 12:00 home
-rw-r–r– 1 root system 13794 Oct 5 2009 image.data
lrwxrwxrwx 1 bin bin 8 Feb 6 2009 lib -> /usr/lib
drwx—— 2 root system 256 Oct 8 2008 lost+found
drwxr-xr-x 163 bin bin 12288 Mar 12 2009 lpp
-rw-r–r– 1 root staff 0 Dec 8 17:51 lvmt.log
drwxr-xr-x 2 bin bin 256 Oct 8 2008 mnt
drwxr-xr-x 15 root system 4096 Feb 6 2009 opt
-rwxr-xr-x 1 root system 602 Jun 6 2007 post_install
dr-xr-xr-x 1 root system 0 Jan 31 12:09 proc
-rw-r–r– 1 root system 0 Jun 6 2007 save_bosinst.data_file
drwxr-xr-x 3 bin bin 256 Feb 6 2009 sbin
-rw-r–r– 1 root system 751 Feb 6 2009 smit.script
-rw-r–r– 1 root system 1186 Feb 6 2009 smit.transaction
drwxrwxr-x 2 root system 256 Feb 6 2009 tftpboot
drwxrwxrwt 10 bin bin 4096 Jun 13 2015 tmp
lrwxrwxrwx 1 bin bin 5 Feb 6 2009 u -> /home
lrwxrwxrwx 1 root system 21 Feb 6 2009 unix -> /usr/lib/boot/unix_64
drwxr-xr-x 43 bin bin 4096 Feb 6 2009 usr
drwxr-xr-x 30 bin bin 4096 Feb 6 2009 var

Не знаю, что отсюда можно удалить, да и не удалит он видимо ничего
# rm /lvmt.log
ksh: Invalid file system control data detected
rm: /lvmt.log not removed.
Invalid file system control data detected

Тогда пробую перезагрузить сбойный vios?) С одним вроде должен работать

[TemplarУчастник]

Перезагрузил, Lpar работает нормально.

Сбойный vios повис с кодом 0552: IPL vary-on failed
До fsck не дошел.

Что посоветуете? грузиться с диска и по этой процедуре https://www-01.ibm.com/support/docview.wss?uid=isg3T1000131
??

[ГригорийУчастник]

если 552, то лучше по этой http://www-01.ibm.com/support/docview.wss?uid=isg3T1000132 , хотя разница не большая. Да и на форуме у нас тут был случай https://aixportal.ru/forums/topic/ipl-vary-on-failed/ …  так это ж ваш пост!

 

[ДмитрийУчастник]

1) у вас сохранилась инфа, через какие ethernet-порты настроены SEA-bridge?
Это когда VIOS всё-таки переставите, их придётся пересоздавать.
с дисками проще.

2) если по п.1 OK, то, может, не ходить дальше по краю, а переставить VIOS?

3) какой диск сбойный?
Для начала: его всё-равно менять и новый диск есть. Значит, вынимаем все старые, вставляем только новый, ставим на него VIOS и потом подсовываем ему диски на изучение.
Чтобы не перепутать, что вынимать: у вас, судя по листингу, всего 6 дисков.
2 в “хорошем” VIOS, 4 в “плохом”. Правильно?
Непонятно только, почему не одинаково…
В “хорошем” VIOS из-под root запускаем diag, идём в 3-й пункт меню (diagnostic procedures?), там где-то есть пункт Identification. Или disk routines -> identify disk.
Он зажигает моргающий светодиод на диске, иногда плохо видимый.
Можно запускать на работающем диске.
“Поморгав” хорошими дисками, вычисляем остальные.
Если по дискам предположение верное, то в одной половине корзины 2 диска, в другой – 4.

Если по дискам всё не так, как я описал:
Где-то я смутно помню, что в p5 была возможность поставить “совсем внутренние”, не hot-swap диски.
У вас сервер <span class=”keyword”>9133-55A? В каких слотах установлены диски, что установлено в PCI-адаптеры?
</span>

 

[TemplarУчастник]

Дмитрий писал(а):

1) у вас сохранилась инфа, через какие ethernet-порты настроены SEA-bridge?
Это когда VIOS всё-таки переставите, их придётся пересоздавать.
с дисками проще.

Не сохранилась. Я лишь могу предположить, что конфигурация такая же как на рабочем vios

$ lsmap -all -net
SVEA Physloc
—— ——————————————–
ent2 U9133.55A.655DC9H-V2-C2-T1

SEA NO SHARED ETHERNET ADAPTER FOUND

SVEA Physloc
—— ——————————————–
ent3 U9133.55A.655DC9H-V2-C3-T1

SEA ent6
Backing device ent5
Status Available
Physloc

SVEA Physloc
—— ——————————————–
ent4 U9133.55A.655DC9H-V2-C4-T1

SEA NO SHARED ETHERNET ADAPTER FOUND

Дмитрий писал(а):

2) если по п.1 OK, то, может, не ходить дальше по краю, а переставить VIOS?

Да, я уже готов переставить

Дмитрий писал(а):

У вас сервер <span class=»keyword»>9133-55A?

Да

Дмитрий писал(а):

В каких слотах установлены диски, что установлено в PCI-адаптеры?

Диски установлены с слотах P2-D1, P2-D2 Сбойный vios и P2-D3, P2-D4 рабочий vios. Должно быть не 6 а 4 диска
Вот вывод по PCI

$ lsdev | grep PCI
ent0 Available 2-Port 10/100/1000 Base-TX PCI-X Adapter (14108902)
ent1 Available 2-Port 10/100/1000 Base-TX PCI-X Adapter (14108902)
pci0 Available PCI Bus
pci1 Available PCI Bus
pci2 Available PCI Bus
pci3 Available PCI Bus
pci4 Available PCI Bus
pci5 Available PCI Bus
sa0 Available 2-Port Asynchronous EIA-232 PCI Adapter
scsi0 Available PCI-X Dual Channel Ultra320 SCSI Adapter bus
scsi1 Available PCI-X Dual Channel Ultra320 SCSI Adapter bus
sisscsia0 Available PCI-XDDR Dual Channel Ultra320 SCSI Adapter

Я сегодня туда поеду и все глазами посмотрю

[TemplarУчастник]

Спасибо за подробные инструкции и помощь!

Что сделано:
– приехал на место, удалил из lparов диск со сбойного vios (прошло нормально, без sysdumpdev, chpv -c hdiskX только надо было сделать еще)
– вытащил из сервера все диски, вставил 1 новый и установил на него vios (правда не нашел той же версии и теперь viosы разных версий (2.2.4 и 2.1.0), но думаю это ничего страшного)

Что интересно: дисков (которые hot-swap) оказалось все-таки 4 и находились они в слотах P2-D1, P2-D2 (сбойный vios) и P3-D3, P3-D4 (рабочий vios) (а локейшн коды показывали, что находятся в слотах P2-D3, P2-D4) и остается загадкой, что такое P1-C3-A3 и P1-C3-A4….

– возникла проблема с определением сбойного диска:
1. вставил два старых диска зашел в diag=>Task Selection=>c идентификацией там только пункт Identify and Attention Indicators, но я так понял он просто подсвечивает слоты и не проверяет диски. (оба диска поморгали оранжевым)
2. сделал cfgmgr, оба диска определились. Зашел в diag=>Diagnostic Routines=> Problem Determination и выбрал их проверить – он написал все ок и предложил что-то типа Certification (который должен был занять много времени и я его не стал делать)

Все делал со свежеустановленного vios.

Вопрос с определением битого диска пока остается открытым….

[ДмитрийУчастник]

С разными версиями должно работать, но второй виос лучше обновить.

Старые available devices: AIX (VIOS) видит то, что есть, и не видит того, чего нет (простите за философию).

Но если физически отключить или вытащить устройство, то его статус в ОС не поменяется, оно останется available. До перезагрузки. После перезагрузки оно станет defined. Вы писали, что перезагрузки VIOS и после этого диски были available. Значит, они были. Ну или виосу совсем уже плохо было и он бредил… Вообще мне эти локейшн коды очень напоминают внутренние диски или scsi-полку.

Как найти битый диск: certification хорошая процедура. В качестве альтернативы создайте на диске vg, lv, FS. Смонтируйте и посмотрите, что получится. Может получиться, тогда надо заполнить диск данными. Сертификация правильнее 😀

А identify только светит лампочками, верно. Это очень удобно при замене устройств. Я так понимаю, что у вас нет туда удаленного доступа?

[TemplarУчастник]

Дмитрий писал(а):

Вы писали, что перезагрузки VIOS и после этого диски были available.

Не совсем так. Я установил новый vios, вставил диски и они нашлись в lspv после cfgmgr. Статус наверное defined у них был

Дмитрий писал(а):

Я так понимаю, что у вас нет туда удаленного доступа?

Доступ есть.

Я диски (старые) вытащил. Тогда завтра поеду, вставлю их сделаю cfgmgr и поочередно certification, если пройдет то посоздаю на них больших файлов. Надеюсь это поможет определить битый. Отпишусь

[TemplarУчастник]

Поочередно вставил диски и после cfgmgr сделал certify. Не на одном из дисков он не нашел ни битых секторов ни каких-либо других ошибок (в отчете все по 0). Сделал на каждом из дисков по VG, LV, файловой системе, смонтировал, попробовал расширить FS, сделал большой файл вот таким образом “dd if=/dev/zero of=/test1/test.dat bs=8192 count=20000”, еще раз расширил FS.
В общем оба диска работают. Что еще посоветуете?

В HMC загорелся Attention LED на этом виосе, но в eventах ничего нет.
Еще когда вставил диск в слот P2-D1 в diage показал ошибку: SCSI bus problem: cables, terminators or other SCSI devices (DISK_ERR3), но после того как диск переткнул она ушла.

[ДмитрийУчастник]

Вот оно как… Это мы что, не то чинили? Смеяться и плакать, плакать и смеяться…
Сертификации дисков я доверяю, errpt тоже. а реальному чтению-записи файлов ещё больше.

Что это: сбой контроллера, контактов с слоте?

Зато у вас теперь свежий, хороший VIOS, и диск лишний появился. можно всё аккуратно настроить.
И проблему, так или иначе, но устранили.

[TemplarУчастник]

В серверной несколько лет назад сверлили кирпичную стену, не выключая сервера. Думаю скорее всего на контакты пыль попала. Спасибо всем ОГРОМНОЕ за помощь!

Буду настраивать на следующей неделе

[ГригорийУчастник]

Так вам не удалось после перезагрузки  и “0552: IPL vary-on failed” починить файловые системы?

[TemplarУчастник]

Григорий писал(а):

Так вам не удалось после перезагрузки  и «0552: IPL vary-on failed» починить фай

Я решил не чинить, предполагая, что какой-то диск мертвый просто переустановил vios на новый диск

[Кирилл ТерентьевУчастник]

походу ничего уже не сделаешь..интересно как все разрешилось..

[ДмитрийУчастник]

Здравствуйте, Владимир!

Templar написал: “Я решил не чинить, предполагая, что какой-то диск мертвый просто переустановил vios на новый диск”.

С точки зрения исследователя – жаль. С точки зрения практики часто выбирают самый быстрый (сейчас), хотя, может быть, и не самый оптимальный путь. И это часто справедливо.

[Автор]

Сообщения