mdadm: sending ioctl 1261 to a partition!

 ( gdudas | 2012. március 23., péntek - 10:22 )

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ás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

+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!

Neked milyen kernel / mdadm?

mdadm
3.1.4-1+8efb9d1+squeeze1
kernel
2.6.32-5-686

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?

Nálam a rendszer független diszken van, nincs raidben . Ez egy szoftveres RAID1 2db. 500GB diszkkel /mnt be mountolva.

Én először azt hittem a GPT miatt van, de egy kolléga megerősítette hogy olyan rendszernél is jelen van ahol nincs GPT.
Így néz ki a disk:
Number Start End Size File system Name Flags
1 17.4kB 1018kB 1000kB bios_grub
2 1018kB 10.0GB 10.0GB raid
[...]

Nincs LVM.

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?

Nalam is irkal ilyet az egyik gep (Debian 6.0.4, vanilla kernel 2.6.32.57), de hibatlanul mukodik.

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)

A linkelt bugreportban 3.2-es kernellel van a baj, de a topic inditoban 2.6.32-es kernel van, illetve az mdadm-ed is ujabb a hivatalosnal (=3.1.4-1+8efb9d1+squeeze1)

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

Kipróbálgattam visszafelé a kerneleket, és igazad van. Debian esetén ennél a verziónál kezdi: linux-image-2.6.32-5-amd64_2.6.32-39_amd64.deb

Ez a legutolsó verzió ahol még nem jelentkezett a hiba: linux-image-2.6.32-5-amd64_2.6.32-38_amd64.deb

a kernel logon kívűl más is jelentkezik mint "hiba" ?

Nálam semmi, de én mondjuk még csak most futottam bele a hibába.

Amiota ujrainditottam az uj kernellel, mar nalam is jelentkezik az uzenet a syslogban, de szerencsere hibat eddig meg nem produkalt. Setupert lasd a fentebbi hozzaszolast.

Volt egy ilyen problema: http://rwmj.wordpress.com/2011/12/22/cve-2011-4127-privilege-escalation-from-qemu-kvm-guests/

Erre jott ki a fix januarban, ha jol emlekszem. Ha ilyet latsz a logokban, akkor valamely app olyat csinal, amit neki nem kellene.

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

Hmm, na jó de akkor mit csinál az mdadm amit neki nem kéne? :) (vagy fent van hddtemp, sőt grub-bal is láttam már ezt az errort)

Pl: http://www.spinics.net/lists/raid/msg37753.html

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

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   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   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?

vezérlő hiba ?

smartctl mit mond a winyóra ?

Nem tudott vele semmit kezdeni, mintha kb kirántottam volna a disket. Kértem rá egy consolet, toltam neki egy rebootot, a vinyót a BIOS már nem is látta. Pár hetet bírnának ezek a diskek? Na meg nem disk hibára utaltak a bejegyzések.

Akkor nézd meg a diszket egy másik gépben. Ott mit mond :) Ha ott sem látja, akkor jah, ennyit bírnak.

Nekem egy vadiúj bontatlan WD 2TB-os hdd döglött meg ~3 nap használat után. Nagyon intenzív használat .. raid1 syncelt.

:(

Annyi változott hogy kikapcs-bekapcs után még is látja a disket, itt a két disk smartctl kimenete:
sda: http://pastebin.com/6438ddcK
sdb: http://pastebin.com/4wDZUR8t (elvileg ezt dobta ki a tömbből)

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 ?

Meg nem mondom mi van a MicroServerben... :) alaplapi vezérlő.

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

Nekem is megy mind a ketto fujitsu szerveren, de latszolag semmi gondot nem okoz. RAID1 harom winyobol.

Mar leirtuk egy csomoan fent, hogy ez mindossze warning, teljesen artalmatlan.

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

openoffice fájlok váltak csak olvashatóvá, gondolom ami meg volt nyitva.

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

ezt értem, de más hibát nem találtam amikor ez előjött.

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