mdadm: sending ioctl 1261 to a partition!

Fórumok

Sziasztok,

nem találtam még ezzel kapcsolatos témát, így feldobom...
[ 2.393899] md: md0 stopped.
[ 2.393932] mdadm: sending ioctl 1261 to a partition!
[ 2.393936] mdadm: sending ioctl 1261 to a partition!
[ 2.394947] mdadm: sending ioctl 1261 to a partition!
[ 2.394951] mdadm: sending ioctl 1261 to a partition!
[ 2.395854] mdadm: sending ioctl 1261 to a partition!
[ 2.395859] mdadm: sending ioctl 1261 to a partition!
[ 2.429153] md: bind
[ 2.436479] md: bind
[ 2.438105] raid1: raid set md0 active with 2 out of 2 mirrors
[ 2.438145] md0: detected capacity change from 0 to 9998877696
[ 2.439333] md0: unknown partition table
[ 2.458485] mdadm: sending ioctl 1261 to a partition!
[ 2.458490] mdadm: sending ioctl 1261 to a partition!

- Debian 6.0.4 (minden az elérhető legfrissebb)
- Linux version 2.6.32-5-amd64 (Debian 2.6.32-41) (ben@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Jan 16 16:22:28 UTC 2012
- mdadm 3.1.4-1+8efb9d1+squeeze1
- md0 : active raid1 sda2[0] sdb2[1]
9764529 blocks super 1.2 [2/2] [UU]

- HP Microserver N40L
- 2x ST2000DL003-9VT166 (firmware: CC3C)

Arra jutottam hogy ez egy kernelben lévő bug, de létezik hogy még nem lett javítva január óta? Van olyan akinek sikerült megoldást találnia ezekre a hibákra? Köszi!

Hozzászólások

+1, mármint nálam is van ez a hiba ~1 hónapja.
HP Microserver N36L

Én is kerestem rá és ugyanerre jutottam, hogy kernel bug .
Tehát várom a folytatást, hátha van valakinek valami tippje.

Kiegészítés:
Ha pld. nyomok egy ilyet : hddtemp /dev/sd[abc]1 akkor szintén:

[2994844.355019] hddtemp: sending ioctl 2285 to a partition!
[2994844.355025] hddtemp: sending ioctl 2285 to a partition!
[2994844.357315] hddtemp: sending ioctl 2285 to a partition!
[2994844.357320] hddtemp: sending ioctl 2285 to a partition!
[2994844.357363] hddtemp: sending ioctl 2285 to a partition!
[2994844.357366] hddtemp: sending ioctl 2285 to a partition!
[2994844.357835] hddtemp: sending ioctl 2285 to a partition!
[2994844.357841] hddtemp: sending ioctl 2285 to a partition!
[2994844.359136] hddtemp: sending ioctl 31f to a partition!
[2994844.359142] hddtemp: sending ioctl 31f to a partition!
[2994844.359392] hddtemp: sending ioctl 2285 to a partition!
[2994844.359398] hddtemp: sending ioctl 2285 to a partition!
[2994844.359619] hddtemp: sending ioctl 2285 to a partition!
[2994844.359625] hddtemp: sending ioctl 2285 to a partition!
[2994844.411205] hddtemp: sending ioctl 31f to a partition!
[2994844.411211] hddtemp: sending ioctl 31f to a partition!
[2994844.411295] hddtemp: sending ioctl 2285 to a partition!
[2994844.411299] hddtemp: sending ioctl 2285 to a partition!
[2994844.494396] hddtemp: sending ioctl 2285 to a partition!
[2994844.494402] hddtemp: sending ioctl 2285 to a partition!
[2994844.500545] hddtemp: sending ioctl 31f to a partition!
[2994844.500551] hddtemp: sending ioctl 31f to a partition!
[2994844.500630] hddtemp: sending ioctl 2285 to a partition!
[2994844.500633] hddtemp: sending ioctl 2285 to a partition!
[2994844.582253] hddtemp: sending ioctl 2285 to a partition!
[2994844.582259] hddtemp: sending ioctl 2285 to a partition!

nálam is bejött - bár intel rack szerveren. amit eddig találtam, azon leírások azt mondják, ez akkor van (leginkább) ha a /boot is LVM-en van (mondjuk a / -ben). Nálatok így van?

Arról egyébként van valakinek infója hogy milyen prioritással kezelendő ez a bug? Azért nem javítják mert semmi jelentősége nincsen, vagy mert nincs rendes patch rá? Senkinek nem volt emiatt semmi gondja? Google dobott egy olyan találatot ahol egy Fedora ezekkel a hibákkal fagyott.

Nekem az utolsó rendszerem ahol még volt softraid az egy Lenny (ott nem volt semmi probléma), Squeeze-ben volt olyan kernel aminél még nem jelentkeztek a hibák?

Igen, a január közepe előtti kernelekkel + mdadm -mel még jó volt.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=656899:

Nálam is előjött, a rendszerdiszk nincs RAID-ben, viszont LVM ott is van.

$ cat /proc/version
Linux version 2.6.32-5-openvz-amd64 (Debian 2.6.32-41) (ben@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Jan 16 17:49:19 UTC 2012

$ dpkg --list | grep mdadm
ii  mdadm                                      3.2.2-1~bpo60+2                     tool to administer Linux MD arrays (software RAID)

Nekem ugyanez a felallas van (N40L, 2x1TB Samsung raid1-ben, openmediavault amd64 ugyanezzel a kernellel) de nincs ilyen hibauzenetem a dmesg-ben. Meg a hddtemp-es dolgot is feltelepitettem es kiprobaltam (bar az omv valahogy meri, mert a webes feluleten kint van a homerseklet), de igy se jelentkezett. Biosfrissites nem oldana meg (bar en se frissitettem :)?

Kipróbáltam az OpenMediaVault-ot, annyi a különbség hogy amivel telepíti az nem a legújabb kernel, ellenben updatenél már lehúzza azt ami a legfrissebb a Squeeze-ben.

OpenMediaVault:
Linux version 2.6.32-5-amd64 (Debian 2.6.32-38) (ben@decadent.org
.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Oct 3 03:59:20 UTC 2011

Squeeze (latest):
Linux version 2.6.32-5-amd64 (Debian 2.6.32-41) (ben@decadent.org.uk) (gcc version 4.3.5 (Debian 4.3.5-4) ) #1 SMP Mon Jan 16 16:22:28 UTC 2012

nálam is tele van a log vele, de hibát nem tapasztalok. ismerősnél az openoffice fájlok válnak csak olvashatóvá. raid1-ek mindenhol, 39-es kernelnél kezdte alighanem. márc. 5.-i az első előfordulása a meglevő logokban.

Ubuntu 10.04.4 LTS
$ uname -srvm
Linux 2.6.32-40-generic-pae #87-Ubuntu SMP Mon Mar 5 21:44:34 UTC 2012 i686
$ mdadm --version
mdadm - v2.6.7.1 - 15th October 2008

CVE-2011-4127

Igen, erről van szó. A debian backport ideje (kivonat), fentről lefelé időrendben:


linux-2.6 (2.6.32-39squeeze1) stable-security; urgency=high
  * Restrict ioctl forwarding on partitions and logical volumes (CVE-2011-4127)
 -- dann frazier <dannf@debian.org>  Mon, 09 Jan 2012 21:17:41 +0100

linux-2.6 (2.6.32-41) stable; urgency=low
  * Refine the fix for CVE-2011-4127, based on mainline Linux:
    - Do not restrict processes that have CAP_SYS_RAWIO
    - Log a warning when an ioctl is forbidden (with rate-limiting,
      and excluding CDROM_GET_CAPABILITY)
    - Fix the ide-floppy and ub drivers
    - Fix the ub driver properly (not included in Debian configurations)
 -- Ben Hutchings <ben@decadent.org.uk>  Sun, 15 Jan 2012 03:37:31 +0000

Hm, nem tudom mennyire van összefüggés, de hasonlót tapasztaltam szintén egy HP MicroServer N40L-nel éppen ma.

Egy kis teszt rendszer lett volna, 3 darab winyóval, ebből kettő raid1ben.

Elsőnek csak jöttek az üzenetek, pedig a 2darab raid1 winyó még benne sem volt a gépben.

2-3 napig ment a szerkezet, 1 darab 1 terás winyó + 2 darab 2T -s raid1ben, semmi extrázás nem került rá, mint LVM vagy ilyesmi.

Sima raid1es mdadm setup.

Ma pedig látom, hogy kihullot az sdc nevezetű winyó a raid1 tömbböl. Dmesg szerint elsőnek IO errorokkal találkozott, majd addig addig próbálta kapcsolgatni a vezérlő a sata winyót, míg dobott egy kernel panicot. Ki is került az sdc mint olyan a raid1 tömbből. Bár érdekes, mert nem az egész gép pánikolt el, csak az egyik drv.

Ma nem volt időm vele foglalkozni, majd holnap megnézem mi volt a konkrét ok.

Csak noteszként írtam le, nem tudom van-e köze a fent említett mdadm üzenetekhez, de mivel ezen a gépen is jöttek ilyen üzenetek, akár az is elképzelhető :/

Felmerült kérdések:

- A HP Microserver SATA vezérlője döglött-e meg ?
- Esetleg a 3.2-es kernelben van valami bug ehhez a chipset/drv-hez ?
- Esetleg az mdadm / kernelben izéltek el valamit nagyon ?
- Esetleg a winyó pattant el valamitől mint olyan? (bár most lett kibontva 3 napja...) SMART okés volt.

Na majd holnap :)

selfnote:

SDC mint olyan fizikailag tönkrement (illetve tönkre fog). SMART szerint sok reallocated sector count és egyéb finomságok.

Viszont extra kérdésnek, valaki magyarázza el nekem, hogy lesz egy winyó kiesése után az md0 raidből md127 .... wtf ? :/

Nem tudom honnan szedte elő ezt az md127 -es számot, de azzal húzta fel 1 winyóval az "új" raidet. WTFx2, miért is húz fel új raidet ? És hogy lett ez pont 127 -es számú ?

mdadm.confban ennyi van:


ARRAY /dev/md/0 metadata=1.2 name=sv2:0 UUID=b03e9b94:8ef2b754:a471c293:779fc0fc

Na most ebből:
1. hogy lesz md_127_ ???
2. miért lesz ebből automatikusan új MD* device ?
3. miért nem tudja lekezelni a rendszer 1 darab winyó kiesését és maradni md0-án fél lábbal ?

Amúgy egy Ubuntu 12.04*BETA (tudom, hogy még nem jött ki, stb, stb, de ez a rendszer csak tesztrendszer)
kernel: 3.2.0-20 x86_64

-krix-

A fenti config ezt most kezdte el produkálni:

Apr 16 18:21:19 mail kernel: [273710.328110] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Apr 16 18:21:19 mail kernel: [273710.328118] ata4.00: link online but device misclassifed

Apr 16 18:21:24 mail kernel: [273715.328570] ata4.00: qc timeout (cmd 0xec)
Apr 16 18:21:24 mail kernel: [273715.328582] ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
Apr 16 18:21:24 mail kernel: [273715.328587] ata4.00: revalidation failed (errno=-5)
Apr 16 18:21:24 mail kernel: [273715.328598] ata4: hard resetting link

Apr 16 18:22:15 mail kernel: [273766.376124] ata4.00: qc timeout (cmd 0xec)
Apr 16 18:22:15 mail kernel: [273766.376136] ata4.00: failed to IDENTIFY (I/O error, err_mask=0x4)
Apr 16 18:22:15 mail kernel: [273766.376141] ata4.00: revalidation failed (errno=-5)
Apr 16 18:22:15 mail kernel: [273766.376150] ata4.00: disabled
Apr 16 18:22:15 mail kernel: [273766.376168] ata4: hard resetting link
Apr 16 18:22:21 mail kernel: [273771.900070] ata4: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
Apr 16 18:22:21 mail kernel: [273771.900078] ata4.00: link online but device misclassifed
Apr 16 18:22:21 mail kernel: [273771.900095] ata4: EH complete
Apr 16 18:22:21 mail kernel: [273771.900129] sd 3:0:0:0: [sdb] Unhandled error code
Apr 16 18:22:21 mail kernel: [273771.900132] sd 3:0:0:0: [sdb] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Apr 16 18:22:21 mail kernel: [273771.900136] sd 3:0:0:0: [sdb] CDB: Write(10): 2a 00 01 2a 0d bf 00 00 02 00
Apr 16 18:22:21 mail kernel: [273771.900146] end_request: I/O error, dev sdb, sector 19533247
Apr 16 18:22:21 mail kernel: [273771.900159] end_request: I/O error, dev sdb, sector 19533247
Apr 16 18:22:21 mail kernel: [273771.900169] md: super_written gets error=-5, uptodate=0
Apr 16 18:22:21 mail kernel: [273771.900174] raid1: Disk failure on sdb3, disabling device.
Apr 16 18:22:21 mail kernel: [273771.900175] raid1: Operation continuing on 1 devices.

Van tippetek hogy mi lehet a nyűgje?

hmmm. Érdekes. Bár "látszólag" rendben.

7 Seek_Error_Rate 0x000f 073 060 030 Pre-fail Always - 23509709

Bár Seagate, azoknál mindig voltak érdekes SeekError rate-ek.

Kábel csatlakozások jók? Tápot is illene esetleg bemérni. Egy-két ingadozástól simán lehet I/O error.

Milyen vezérlőn lógnak ?

Továbbra is dobja nekem ezt a hibát.
Ráadásul most már ioctl 800c0910 is felbukkan. :-(

Ne viccelj mar, gondolod, hogy mdadm-szintu hiba csak egyes fajlok RO-va valasat eredmenyezi? Ezer es egy mas oka lehetett a jelensegnek.

Megegyszer: az mdadm a mukodese soran device-okat scannel, vizsgal. Ennek soran nem nezi, hogy teljes eszkozrol vagy particiorol van-e szo, bizonyos ioctl hivasokat (pl. 1261) kuld neki. A fentebb jelzett security fix ezt kuszoboli ki, illetve logolja. Ha "normalis" eszkozod van, semmiben nem befolyasolja a mukodest.

A 1261-es ioctl-nek nem neztem utana, nem volt idom leszedni es kibogaraszni a kernelforrasbol, bocs.

--
Fedora, RHEL, CentOS, virtualizáció, SELinux: http://sys-admin.hu

Nekem is detto ezt irja + meg a realtek halokartyaval is szivok + meg tele van szorva valamivel a log de azt most probalom kiszurni hogy mi lehet.
Egyszerre ennyi gondom meg nem volt vele...

Szerk.: Most monitoroztam a raid tomboket es egybol logolta: mdadm: sending ioctl 1261 to a partition!

Hi!

Tudja valaki, hogy mdadm-nak hogy lehet esetleg a log level-t lejebb venni? Vagy esetleg megkérni, hogy ne a syslogot használja?

Fut nálam egy kis script, ami 5 percenként lekéri az mdadm állapotát, és kidobja egy php-ba. Na most a syslog csak ezzel van teli.

mdadm konfigjában nem találtam semmit róla.

Köszönöm!

udv
letix

-----------------------------------------
Linux alapparancsok, kezdőknek