Tisztelt nagyérdemű!
Az alábbi dologba keveredtem bele:
Volt/van egy(pár) OEL5.9-es (tikaga?) oracle redhat szerver, amik multipath-on kapják némely diszkjüket.
Eddig minden jól működött, Oracle RAC ASM-es diszkjeit kapta. És aki implementálta a rc.local-ből adta ki a jogokat a multipath-olt eszközökön a megefelelő (nem root) usernek.
Aztán egyszer csak puff nem működött...Azaz a device létrejött a /dev/mapper/ alatt de a jogok nem kerültek beállításra rajta.
Amit láttam, hogy boot után a multipath-olt diskek csaj jelenős 4-5 perc késéssel jelennek meg, amikorra a rc.local már lefutott.
A probléma multipath nem kellően dokumentált uid group parmétereivel orvoslódott, szerencsére az Oracle cluster stack ezt túléli.
Amit viszont megtaláltam, hogy a multipath betöltéskor pillanatra felvillan a unable to load libaio.so üzenet.
Azt is sikerült kiderítenem, hogy ezek a /usr/lib(64)-ben "laknak" de nálam a /usr külön filesys így a boot folyamat ezen részében nincs fenn.
Nos ezek szerint ez design hiba? vagy mi?
Persze a libaio-s libek átmásolva a /lib(64)-be a boot megvárja a mpath-olt diszkeket ...
Ilyet láttatok?
Mit lehet tenni?
Üdv. TamsA
- 4600 megtekintés
Hozzászólások
Hasonlot tapasztaltam, teljesen mas temakorben, centos-nel, az initramfs-t /initrd/ kellett ujragyartani, ugy, hogy a lib bekeruljon. Azota leszoktam a /usr kolrakasatol, az fc18 ota meg mar ajanlott is, keveset akar az emberfia szivni.
- A hozzászóláshoz be kell jelentkezni
Csak ezt nem értem miért került ki onnan ... ha benne volt valaha ..
de a hiba már a bootnak annak a szakaszában jön amikor a root read onlyban van fenn.
Ha átadod a tudásod neked attól még nem lesz kevesebb belőle..
- A hozzászóláshoz be kell jelentkezni