Mount-Probleme mit Stable-Kernel in Zusammenhang mit 3ware-Raid?
Hallo, ich habe ein kleines Problem. Ich habe mir bei Hetzner einen DS3000 mit 3ware-Raid-Controller angemietet. Darauf betreibe ich OpenVZ. Nun habe ich dabei ein Problem. Ich benutze auf dem Host Debian Etch und die OpenVZ-Kernel und Tools von http://debian.systs.org (vielen Dank dafür!). Das hat auf anderer Hardware auch immer gut funktioniert. Nun habe ich das System eingerichtet und auf der Platte SDA (kommt vom 3ware-Controller (8006-2LP)) 3 Partitionen (sda1 Swap, sda2 /, sda3 /data - sda2/3 als ext3) angelegt und mounte diese entsprechend per fstab. Das hat mit dem von Hetzner gelieferten Kernel (2.6.18-3-686-bigmem) auch super funktioniert. Nun habe ich den OpenVZ Stable-Kernel (kernel-2.6.9-023stab040.1-ovz) installiert und rebootet. Das System ist mit dem Stable-Kernel hochgefahren doch zu meinem erstaunen war nur / also /dev/sda2 gemountet. Also habe ich versucht die Partitionen händisch nachzumounten. serv3:~# mount /data mount: special device /dev/sda3 does not exist OK, interessant das sda2 geht aber sda3 nicht - also weiter versucht serv3:~# fdisk /dev/sda Unable to open /dev/sda Interessant oder? Er hat von sda gestartet! Hier eine Ausgabe von den gemounteten Portitionen: /dev/sda2 ext3 3,0G 877M 2,0G 31% / tmpfs tmpfs 503M 0 503M 0% /lib/init/rw tmpfs tmpfs 503M 0 503M 0% /dev/shm serv3:~# cat /proc/partitions major minor #blocks name 8 0 156289880 sda 8 1 2096451 sda1 8 2 3148740 sda2 8 3 151043130 sda3 Wieso kennt mein fdisk und mount die Platte/Partitionen nicht? fstab: --- proc /proc proc defaults 0 0 none /dev/pts devpts gid=5,mode=620 0 0 /dev/sda1 none swap sw 0 0 /dev/sda2 / ext3 defaults 0 0 /dev/sda3 /data ext3 defaults 0 0 --- Im Syslog listet er mir beim Boot auch brav alle Partitionen: Feb 27 22:59:11 serv3 kernel: SCSI device sda: 312579760 512-byte hdwr sectors (160041 MB) Feb 27 22:59:11 serv3 kernel: SCSI device sda: drive cache: write back Feb 27 22:59:11 serv3 kernel: SCSI device sda: 312579760 512-byte hdwr sectors (160041 MB) Feb 27 22:59:11 serv3 kernel: SCSI device sda: drive cache: write back Feb 27 22:59:11 serv3 kernel: sda: sda1 sda2 sda3 lsmod mit kernel-2.6.9-023stab040.1-ovz von http://debian.systs.org/: --- Module Size Used by i2c_core 19776 0 vznetdev 13984 1 vzethdev 7980 0 vzrst 165640 0 iptable_nat 26936 1 vzrst vzcpt 131384 0 ip_conntrack 45972 3 vzrst,iptable_nat,vzcpt vzdquota 53264 0 [permanent] vzmon 48284 4 vznetdev,vzethdev,vzrst,vzcpt vzdev 3328 4 vznetdev,vzethdev,vzdquota,vzmon af_packet 22024 0 ipt_length 1664 0 ipt_ttl 1792 0 ipt_tcpmss 2176 0 ipt_TCPMSS 3904 0 iptable_mangle 4448 0 iptable_filter 4416 0 ipt_multiport 1952 0 ipt_limit 2816 0 ipt_tos 1568 0 ipt_REJECT 6016 0 ip_tables 22352 11 iptable_nat,ipt_length,ipt_ttl,ipt_tcpmss,ipt_TCPMSS,iptable _mangle,iptable _filter,ipt_multiport,ipt_limit,ipt_tos,ipt_REJECT thermal 11176 0 fan 2948 0 button 4816 0 processor 11068 1 thermal ac 3332 0 battery 7812 0 8139cp 21184 0 8139too 26528 0 mii 4480 2 8139cp,8139too loop 15016 0 --- grub --- title Debian GNU/Linux, kernel 2.6.9-023stab040.1-ovz root (hd0,1) kernel /boot/vmlinuz-2.6.9-023stab040.1-ovz root=/dev/sda2 ro savedefault title Debian GNU/Linux, kernel 2.6.9-023stab040.1-ovz (single-user mode) root (hd0,1) kernel /boot/vmlinuz-2.6.9-023stab040.1-ovz root=/dev/sda2 ro single savedefault title Debian GNU/Linux, kernel 2.6.18-3-686-bigmem root (hd0,1) kernel /boot/vmlinuz-2.6.18-3-686-bigmem root=/dev/sda2 ro initrd /boot/initrd.img-2.6.18-3-686-bigmem savedefault title Debian GNU/Linux, kernel 2.6.18-3-686-bigmem (single-user mode) root (hd0,1) kernel /boot/vmlinuz-2.6.18-3-686-bigmem root=/dev/sda2 ro single initrd /boot/initrd.img-2.6.18-3-686-bigmem savedefault --- Weiter interessant ist übrigens, dass ich den Server mit 2.6.18-028test015.1+40-ovz betreiben kann. Hier mountet er auch alles korrekt. Nur irgendwie habe ich ein schlechtes Gefühl mit einem Test-Kernel auf einem Produktivsystem. Ich bin jedenfalls mit meinem Latein am Ende und würde mich über Hilfe freuen. Vielen Dank MeTRiX
Re: Mount-Probleme mit Stable-Kernel in Zusammenhang mit 3ware-Raid?
Hi Metrix, > [...] OpenVZ-Kernel und Tools von http://debian.systs.org (vielen Dank dafür!). [...] Bitte! Sind die dev-Nodes für sda in /dev vorhanden ?
Hi Thorsten muss ich mal in einer Nacht und Nebelaktion ausprobieren. Da das Ding mehr oder weniger Produktiv mit dem Test-Kernel nun läuft. Was wäre denn, wenn die DEV nicht da wären? Einfach anlegen wäre zu einfach denke ich Das wäre nicht gut, wenn ich jetzt den Kernel switche MeTRiX
Hi Metrix, kannst anlegen, ich denke das Problem liegt bei udev, du hast ein Debian etch System bootest aber einen Kernel kleiner 2.6.16. Ich würde dir bald eh zum 2.6.18er raten, der wird bald stable (ist im git schon als stable getagged) und persönlich setze ich schon bei meinen Systemen den 2.6.18er ein, und die laufen alle stabil.
dann würde es sich ja fast anbieten noch ein paar Tage zu warten Der 2.6.18-028test015.1+40-ovz lief jetzt eine Woche lang problemlos. Hatte dann am Sonntag auf 2.6.18 028test018.1 geupdatet. Doch der ist mir heute morgen um 4 Uhr mit einem Kernel oops stehen geblieben Also wieder zurück auf den 2.6.18-028test015.1+40-ovz.
> Hatte dann am Sonntag auf 2.6.18 028test018.1 geupdatet. Doch der ist mir heute morgen um 4 Uhr mit einem Kernel oops stehen geblieben. Hast Du den "oops" noch in deinen Logs verzeichnet und kannst den bitte hier mal posten, danke!
aber sicher doch Mar 12 04:07:04 serv3 kernel: BUG: unable to handle kernel NULL pointer dereference at virtual address 00000000 Mar 12 04:07:04 serv3 kernel: printing eip: Mar 12 04:07:04 serv3 kernel: c016e590 Mar 12 04:07:04 serv3 kernel: *pde = 00000000 Mar 12 04:07:04 serv3 kernel: Oops: 0002 [#1] Mar 12 04:07:04 serv3 kernel: Modules linked in: simfs vznetdev vzethdev vzrst vzcpt vzdquota vzmon vzdev af_packet xt_length ipt_ttl xt_tcpmss ipt_TCPMSS xt_ limit ipt_tos xt_state xt_multiport xt_tcpudp ipt_REJECT iptable_mangle iptable_nat ip_nat ip_conntrack iptable_filter ip_tables x_tables tun loop i2c_viapro i2c_core shpchp ehci_hcd uhci_hcd usbcore 8139too 8139cp mii thermal processor fan xfs Mar 12 04:07:04 serv3 kernel: CPU: 0, VCPU: 0.0 Mar 12 04:07:04 serv3 kernel: EIP: 0060:[<c016e590>] Not tainted VLI Mar 12 04:07:04 serv3 kernel: EFLAGS: 00010246 (2.6.18-028test018.1+40-openvz #1) Mar 12 04:07:04 serv3 kernel: EIP is at remove_inode_buffers+0x30/0x60 Mar 12 04:07:04 serv3 kernel: eax: cb267afc ebx: cb267ad4 ecx: cb267af8 edx: 00000000 Mar 12 04:07:04 serv3 kernel: esi: cb267cfc edi: 99cb566a ebp: 0000d0f6 esp: dff30ec0 Mar 12 04:07:04 serv3 kernel: ds: 007b es: 007b ss: 0068 Mar 12 04:07:04 serv3 kernel: Process kswapd0 (pid: 156, veid: 0, ti=dff30000 task=dfc45280 task.ti=dff30000) Mar 12 04:07:04 serv3 kernel: Stack: cb267c24 cb267c24 00000080 c01866a1 cb267c24 2a2f79d0 0000d0e5 00000000 Mar 12 04:07:04 serv3 kernel: 0000000d 0000000d cb26a114 cb271864 000175d4 0000009a dfffeda0 000000d0 Mar 12 04:07:04 serv3 kernel: c0153860 00000080 000000d0 00000000 0000001f 00000000 00000064 00000080 Mar 12 04:07:04 serv3 kernel: Call Trace: Mar 12 04:07:04 serv3 kernel: [<c01866a1>] shrink_icache_memory+0x251/0x2e0 Mar 12 04:07:04 serv3 kernel: [<c0153860>] shrink_slab+0x120/0x180 Mar 12 04:07:04 serv3 kernel: [<c0153cb6>] kswapd+0x336/0x440 Mar 12 04:07:04 serv3 kernel: [<c01327e0>] autoremove_wake_function+0x0/0x60 Mar 12 04:07:04 serv3 kernel: [<c0153980>] kswapd+0x0/0x440 Mar 12 04:07:04 serv3 kernel: [<c013253d>] kthread+0xfd/0x110 Mar 12 04:07:04 serv3 kernel: [<c0132440>] kthread+0x0/0x110 Mar 12 04:07:04 serv3 kernel: [<c0101005>] kernel_thread_helper+0x5/0x10 Mar 12 04:07:04 serv3 kernel: Code: 8b 5c 24 10 89 1c 24 e8 7f d5 ff ff 85 c0 74 3c 8b 83 d8 00 00 00 8d b3 d8 00 00 00 39 c6 75 1c eb 2a 8d 43 28 8b 4b 28 8b 50 04 <89> 0a 89 43 28 89 51 04 89 40 04 8b 06 39 c6 74 10 8d 58 d8 8b Mar 12 04:07:04 serv3 kernel: EIP: [<c016e590>] remove_inode_buffers+0x30/0x60 SS:ESP 0068:dff30ec0
Poste diesen Kernel - oops bitte auch nach http://bugzilla.openvz.org
hmm, wenn mein Englisch nicht so beschissen wäre ...
nun wird es schwierig http://bugzilla.openvz.org/show_bug.cgi?id=496
Hi Thorsten, ich hoffe ich darf dich noch mal belästigen Der 2.6.18-028test015er Kernel ist heute auch nach einen Tag mit einem Oops (siehe Bugzilla 496) stehen geblieben. Dabei lief dieser ja eine Woche problemlos. Ich würde fast vermuten, dass es mit dem libc-Update zutun hat, was mir Etch am Wochenende untergeschoben hat. Ist das möglich? Was ist deine Empfehlung? Doch den Host auf Sarge packen und dann den 2.6.18er-Test-Kernel? Ich muss das Ding jedenfalls irgendwie halbwegs stable bekommen Oder lässt sich auch Ubuntu 6.06 Server von deinen Paketen überzeugen?
Hi Metrix, > ich hoffe ich darf dich noch mal belästigen klar ... Ich hab diesen Beitrag mit dem Kernel oops geteilt, geht dann hier weiter: (-> http://forum.openvz.org/index.php?t=msg&th=2165&star t=0& ) Hat sich das ursprüngliche Problem mit dem mounten mittlerweile lösen lassen ?
ich bin der Sache mit dem Mount gar nicht mehr nachgegangen und warte auf aktuelle Stable-Pakete von dir http://www.heise.de/newsticker/meldung/86787 Kann man eigentlich ausschließen, dass mein Oops durch den Netfilter-Bug kommt?