Solaris - /dev/fd - boot failure

Sun Solaris, SunOS

A par hete felrakott Solaris 10 u7 a kovetkezovel orvendeztetett meg 4 nap kikapcsolt allapot utan:


[user] /export/home/user $ tail /var/svc/log/system-filesystem-usr:default.log
...
[ Aug 19 15:36:17 Executing stop method (null) ]
[ Aug 24 09:34:17 Enabled. ]
[ Aug 24 09:34:21 Executing start method ("/lib/svc/method/fs-usr") ]
ERROR: /sbin/mount /dev/fd failed, err=2
mount: fd is not this fstype.
[ Aug 24 09:34:35 Method "start" exited with status 95 ]

Valoban benne volt /dev/fd a vfstab-ban, a kerdes csak az, mikor, mitol es miert kerult bele. Ez single userbe kenyszeritette a rendszert.


#device device mount FS fsck mount mount
#to mount to fsck point type pass at boot options
#
# fd - /dev/fd fd - no -

Lehetseges am az is, hogy az ext2/3 mounthoz felrakott OpenSolaris/Belenix-es FSWfsmisc turt bele, de nem tartom valoszinunek.

( zwei | 2009. 08. 24., h – 11:49 )

Az oprendszer telepítésekor került bele, mint mindig. Ez teljesen normális.
Csak az nem értem, hogy mit akart vele bootkor, mert (amint ez látható is) a vfstab-ban nem is úgy van benne, hogy bootkor mountolnia kellene.

hö...meg wtf...

szerk.: Én azért megnézném , hogy mit rakott fel az a csomag, mert valami el lehet benne cseszve. Tippek: vagy valami script hibásan dolgozza fel a vfstab-ot benne, vagy valami smf dolog (szarul) függ fd-től.

( juhasztibi | 2010. 03. 29., h – 13:40 )

Sziasztok,

nem akartam új topicot indítani a témának. Talán itt is helyén lesz.
A problémám a következő lenne. Van egy vmware fájlom ami egy solaris 10. Ezt átkonvertálom ESX serverre.
Amikor elindítom a saját gépemen vmware player-el akkor rendesen működik.
Ha az esx szerveren akarom elindítani akkor ezeket az üzeneteket kapom:

Cannot mount root /pci@0,0/pci-ide@7,1/ide@0/cmdk@0,0:a fstype ufs

panic[cpu0]/thread=fec20160: vfs_mountroot: cannot mount root

fec38274 genunix:vfs_mountroot+61 (fe8000000, 1010750, )
fec38274 genunix:main+8b ()

skipping system dump - no dump device configured
rebooting...

Lenne valami ötletetek?

Az alap vmware-en ide-n van a vinyó a esx pedig scsi-n keresi. Lehet ez a hiba oka? Ha igen akkor hol kell átkonfigolni ezt a dolgot? Boot menü?

Köszönöm!

üdv,
T.

on all of them solvable

Pontosan az történik, amit ír: nem tudja mountolni a /-t mert a más "virtuális vason" a bootpath, nem ugyanott van.
(szerk: igen az ide-scsi a probléma oka)
Indítsd a failsafe módot, majd ott megkérdezi, hogy a talált - elvileg megtalálja - Solaris 10-et mountolja-e read-write-ban az /a-ra.
Ezután /a/boot/solaris/bootenv.rc-ben át kell írni a path-ot a korrekt elérési útra.
Ezt a "mount" megmondja.

Ezután még nem biztos, hogy elindul a gép, de egy lépéssel közelebb vagy.
Szólj, hogy mi van, a hw-csere-procedúra többi része kicsit több odafigyelést igényel... :)

<-------
You can't grep on dead trees.

nem egyértelmű mit kell átírni. Ez van benne:

setprop ata-dma-enabled 1
setprop atapi-cd-dma-enabled 1
setprop ttyb-rts-dtr-off false
setprop ttyb-ignore-cd true
setprop ttya-rts-dtr-off false
setprop ttya-ignore-cd true
setprop ttyb-mode 9600,8,n,1,-
setprop ttya-mode 9600,8,n,1,-
setprop lba-access-ok 1
setprop prealloc-chunk-size 0x2000
setprop keyboard-layout "Unknow"

fel kell vennem egy új property-t?
Az pedig a mount listában szereplő / on / randisk:a read/write/setuid/devices/dev=1180001 legyen? Mondjuk itt van még sok más is, sajnos nem tudom kimásolni ide.

találtam egy ilyet:

# uname -a
SunOS ganymede 5.10 Generic_127128-11 i86pc i386 i86pc
# grep -v "^#" /boot/solaris/bootenv.rc

setprop ata-dma-enabled '1'
setprop atapi-cd-dma-enabled '0'
setprop ttyb-rts-dtr-off 'false'
setprop ttyb-ignore-cd 'true'
setprop ttya-rts-dtr-off 'false'
setprop ttya-ignore-cd 'true'
setprop ttyb-mode '9600,8,n,1,-'
setprop ttya-mode '9600,8,n,1,-'
setprop lba-access-ok '1'
setprop prealloc-chunk-size '0x2000'
setprop bootpath '/[EMAIL PROTECTED],0/pci1022,[EMAIL PROTECTED]/pci17c2,[EMAIL
PROTECTED]/[EMAIL PROTECTED],0:a'
setprop keyboard-layout 'US-English'
setprop console 'ttya'

http://www.mail-archive.com/opensolaris-discuss@opensolaris.org/msg3548…

on all of them solvable

A bootpath-ot, ha jól emlékszek (*), failsafe módban a mount parancs kimenete megmondja, azt kell keresni, ahol /a-val kezdődik. ( (*) mintha ilyenkor a /devicesből szedné... de nem 100%)
(Ugye failsafe alatt a /-t /a alá mountolja, HA KÉRED. De megkérdezi, hogy kéred-e :))

Ha úgy nem, akkor a format megmondja, hogy mit kell oda írni (ld. lentebb). A /a-t tartalmazó disknél szólni fog, hogy "mounted partitions found", meg azt is, hogy hova vannak mountolva.
Arra FIGYELJ, hogy a /a/boot/solaris/bootenv.rc-t szerkeszd failsafe-ben!!

Ezután init 6-ra automatikusan kéne, hogy updatelje a boot archive-ot, és reboot után OK minden.

HA nem, akkor - mint már mondtam - picit bonyolultabb a helyzet, a thread-ben, amit idéztél, Jürgen Keil (nagy guru!!) szépen leírja/összefoglalja a teendőket.

Ez az egyik gépünk: 


/$format
Searching for disks...done


AVAILABLE DISK SELECTIONS:
       0. c1t0d0 <DEFAULT cyl 8921 alt 2 hd 255 sec 63>
          /pci@5,0/pci1022,7450@4/pci108e,534d@4/sd@0,0
       1. c1t1d0 <DEFAULT cyl 8933 alt 2 hd 255 sec 63>
          /pci@5,0/pci1022,7450@4/pci108e,534d@4/sd@1,0
Specify disk (enter its number): 0
selecting c1t0d0
[disk formatted]
Warning: Current Disk has mounted partitions.
/dev/dsk/c1t0d0s0 is currently mounted on /sxde. Please see umount(1M).
/dev/dsk/c1t0d0s1 is currently used by swap. Please see swap(1M).
/dev/dsk/c1t0d0s3 is currently mounted on /. Please see umount(1M).
/dev/dsk/c1t0d0s7 is currently mounted on /export/home. Please see umount(1M).


$more /boot/solaris/bootenv.rc
#
# Copyright 2007 Sun Microsystems, Inc.  All rights reserved.
# Use is subject to license terms.
#

#ident  "@(#)bootenv.rc 1.33    07/03/03 SMI"
#
#       bootenv.rc -- boot "environment variables"
#
setprop ata-dma-enabled 1
setprop atapi-cd-dma-enabled 0
setprop ttyb-rts-dtr-off false
setprop ttyb-ignore-cd true
setprop ttya-rts-dtr-off false
setprop ttya-ignore-cd true
setprop ttyb-mode 9600,8,n,1,-
setprop ttya-mode 9600,8,n,1,-
setprop lba-access-ok 1
setprop prealloc-chunk-size 0x2000
setprop bootpath /pci@5,0/pci1022,7450@4/pci108e,534d@4/sd@0,0:d
setprop keyboard-layout 'US-English'
setprop console 'text'

<-------
You can't grep on dead trees.

nekem a format parancsra:

no disks found!

a (*)-ra pedig:

boot: not found

Ez nem túl megnyugtató. :(

az ls -l /dev/rdsk ilyet ad vissza:

/pci@0,0/pci-ide@7,1/ide@1/sd@0,0:m, raw
/pci@0,0/pci-ide@7,1/ide@1/sd@0,0:o, raw
/pci@0,0/pci-ide@7,1/ide@1/sd@0,0:p, raw
/pci@0,0/pci-ide@7,1/ide@1/sd@0,0:c, raw
.
.
.

mountolni kellene előtte a meghajtót?

on all of them solvable

(*): arra gondoltam, hogy normál esetben a /dev/dsk/cX(tY)dZsW formában kapja a mount parancs a paraméterét, az /etc/vfstab-ból. Ezek a /dev -ben található bejegyzések a /devices hosszabb/bonyolultabb tree-jének a linkjei tkp. a fenti gépen pl: 

$ls -la /dev/dsk/c1t0d0s0
lrwxrwxrwx   1 root     root          60 szept. 30  2009 /dev/dsk/c1t0d0s0 -> ../../devices/pci@5,0/pci1022,7450@4/pci108e,534d@4/sd@0,0:a

failsafe módban pedig a /devices -ben található bejegyzésből mountolja a /-t (illetve a boot archive-ben található bootenv.rc-beli bootpath alapján, ami ugye a /devices tree root eszközre mutató bejegyzése) és nem a vfstab-on keresztül, a /dev -ből. Erre gondoltam, hogy talán, mintha, de nem biztos.
--> a /devices -ben "boot" stringet nem fogsz találni ;)

A format parancs ha nem talál disk-et, akkor az nem jó. Root vagy? - ez akkor érdekes, ha nem init 1-ben, vagy failsafe-ben vagy. Ha nem rootként akarod futtatni, akkor azt írja, hogy: 

$format
Searching for disks...done
No permission (or no disks found)!

Egyáltalán failsafe-ben indítod a (virtuális)gépet?
Most hirtelen több ötletem nincs.
Ha failsafe-ben indítasz, akkor nyomj egy
devfsadm -v -r /a -t
VAGY előtte egy
devfsadm -s -v -r /a
(ez utóbbi esetben nem csinál semmit, csak megmutatja ,mit csinálNA, ha megcsinálná a devlinkeket)

Ezután a format mit mutat? (Nem kell restart)
<-------
You can't grep on dead trees.

az ls -l /dev/rdsk ilyet ad vissza:

/pci@0,0/pci-ide@7,1/ide@1/sd@0,0:m, raw
/pci@0,0/pci-ide@7,1/ide@1/sd@0,0:o, raw
/pci@0,0/pci-ide@7,1/ide@1/sd@0,0:p, raw
/pci@0,0/pci-ide@7,1/ide@1/sd@0,0:c, raw

ezek nem scsi device-ok. azt mondtad, hogy azon van a boot diszk.
ez csak úgy lehet, hogy az image-ben annak a virtuális gépbe beszimulált scsi kártyának nincs drivere, ezért a rajta lógó diszket nem is látja.

ezt orbitális szopás lesz megcsinálni.

lehetőségek:
- átvarázslod a vmware-t, hogy ide-n szimulálja már be azt a nyomorult boot diszket.
- visszaviszed egy olyan vmware alá, ahol még bootol, felrakod rá a scsi driverét a másik vmware scsi kártyájának, visszahozod, és hátha több szerencséd lesz.
- letöltesz egy os install iso-t, bebootolod a vm-ben, ha rajta van a scsi kártya drivere az install cd-n, akkor felmountolod a /a-ra a boot diszket, pkgadd -R /a-val felrakod a package-t, módosítod a /a/etc/vfstab-ot, a /a/boot/akármi/bootenv.rc-t, bootadm update-archive -R /a, aztán reménykedsz, hogy jobb lesz.
- ha nincs rajta az os install iso-n a driver, na akkor a fentiek kiegészítve annyival, hogy az install iso-ra bootolva konfigurálsz magadnak netet (ifconfig), és nfs-en keresztül rávarázslod a driver package-et a /tmp-be, onnan felrakod.

közben továbbgondoltam a dolgot.

a boot archive-ba elvileg csak azok a driverek vannak berakva, amik a boot diszkhez kellenek. ott nyilván nem lesz bent az új scsi driver, még ha magán az os-en fent is van.

a boot archive arra való, hogy bebootoljon a gép a korábbi boot diszkről, arra nem való, hogy egy tök más drivert igénylő gépen is be tudjál bootolni.

szóval nem lehet megúszni az install iso használatát, ha marad a virtuális scsi kártya.

Köszi a hozzászólást, ez tényleg szívás. Akkor az lenne a legtisztább, hogy azon a gépen csinálok egy új vmware fájlt amin az esx szerver is van. Húú ez tényleg szívás, már így is egy csomó időm ráment.
A boot archive-ot nem lehet módosítani?

on all of them solvable

Szia,

igazából semmi gond nincs vele. Csak egy elhamarkodott gondolat volt, hiszen nyílván ha az ide discről bootolok be akkor bajosabb lenne maga alatt kivágni a fát. :)
De akkor sem úszom meg az esx-be való betöltést, mert sajnos az esx egy távoli gépen van, ráadásul egy másik domainben, szóval még az sem megy, hogy hálózatról bootoltassam be.
De holnap reggel megcsinálom.
Viszont még annyi kérdésem lenne, hogy ha bebootoltam akkor hogyan tudom belőni a scsi drivert?

?:

http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?lang=en&c…

gondoltam ezt még belinkelem:

http://wotho.ethz.ch/ESX_solaris/Install_Solaris_on_ESX.html

on all of them solvable

A diszk nevét a format paranccsal meg tudod keresni.
felmountolod a diszket, utána:
bootadm update-archive -fR /mnt

A vfstab-ot ellenőrizni kell, változott -e ahoz képest a rootdev.
Ha igen, akkor módosítani, és egy umount után még egy rekonfigurációs reboot is kell. (reboot -- -r)

Végül az lett, hogy az esx-en csináltam egy új solarist. Így már megy. Most megint a hálózattal vannak gondjaim...
Viszont lenne még egy kérdésem.

Szeretnék egy fájlt felmásolni a virtuális gépre. Az architectúra kb a következő.

Van a gépem-> innen bejutok egy treminálba->innen el tudom érni ip címen az esx-et->itt elindítom a solaris virtuális gépemet.

Teljes jogom csak a gépemen van, az elsőn a listában. Elképzelésem sincs egyenlőre, hogyan tudnék egy fájlt eljuttatni a virtuális gépre. Internet elérhetőség nincs, le van tiltva.

mondjuk pár ötletem van:

-a hálózat többi elemét tudom pingelni(kivéve azt a teminált ahonnan az esx-et indítom), így talán át tudom juttatni valahogy a fájlt
-> az első terminálta tudok fájlokat másolni, szóval kezdhettem volna onnan is a felsorolást.

- samba...
->nagyon kevés ismeretem van ezen a területen

- készítek egy iso-t és felmountolom a terminálon majd a vmware-be kiválasztom meghajtónak (ja, nem tudom felmountolni mert nincs jogom telepíteni semmit... vagy tudtok olyan alkalmazást amit fel tudnék esetleg tenni admin jogok nélkül is, vagy van windowson is lehetőség mountolni mondjuk parancssorból?)

üdv,
T.

on all of them solvable

A gyártónál, mint OS-ek alatt ;)
vmware-ben nem vagyok otthon, de hirtelen ez jutott eszembe :)
Gyorsan megnézve pár linket (mondom: gyorsan; mennem kell) nem teljesen reménytelen a szitu.
soxerencsét, holnap jövök

szerk: zwei megeleőzőtt; igaza lehet, nem ismerem ezt a rendszert (esxi)
<-------
You can't grep on dead trees.

Sracok, nekem van otletem:
- egyszeruen atkonvertalja a vmdk image-t ugy, hogy scsi tipusu legyen (ezen belul is lsilogic, ha minden igaz, ez kell a solaris ala).
Mindenki ezerrel felejti el, hogy a vmware azert nagyjabol konzekvens, tobbe-kevesbe ugyanazokat a hardvereket emulalja le. Tehat, ha visszaalakitja scsi diskke, akkor mar megvan a jo disk, utana mar csak azt kell eltalalni, pontosan melyik scsi eszkozon logott a disk.

A konvertalas menete:
- leszed egy vmware workstation-t es felrakja
- lemasolja a disk fajlait a esxi szerverrol valahogy (scp a baratunk)
- vmware-vdiskmanager -r -t 0 -a lsilogic sourcedisk.vmdk destinationdisk.vmdk

Ennek elvben mukosznie kell. Egyebkent erdemesebb a diskeket 2GB-onkent vagdosni azert, mert igy a konfig ilyen esetekben vi-jal szerkesztheto :-)
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Tenyleg nem bantasibol, de itt is szabad uj topicot nyitni mindennek, es a tied nagyon nem vag a temaba, mert mas a hibauzenet (es a hiba is valoszinuleg). Olyan zavaro, amikor egy topicon belul ket-harom kerdes is van, foleg ugy, hogy nem altalanos a topiccim.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.