Fórumok
Sziasztok!
Ha VM-ben fut CentOS 6-od, készülj rá, hogy a 2.6.32-696.16.1.el6.x86_64 kernel nem fog elindulni. Más gépen nem néztem.
Az egyik megbízható, még jó kernel: 2.6.32-696.16.1.el6.x86_64
Pont ebbe futottam bele:
https://forums.aws.amazon.com/thread.jspa?messageID=823105&tstart=0
Van, akinek megy ez a kernel VM-ben?
Köszi.
Hozzászólások
uname -a
Linux hogymi 2.6.32-696.18.7.el6.x86_64 #1 SMP Thu Jan 4 17:31:22 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
nálam 2.6.32-696.18.7.el6.x86_64 települt és megy
igaz nem awsen hanem VMware alatt fut
Rosszul másoltam be a téma címbe, és nem tudom átírni, tehát:
2.6.32-696.18.7.el6.x86_64 ami NEM MEGY, és
2.6.32-696.16.1.el6.x86_64 ami JÓ.
Tehát nálad akkor nem jelentkezett a probléma.
Sakk-matt,
KaTT :)
+1
centos 7-es VM vmware alatt:
uname -a
Linux ... 3.10.0-693.11.6.el7.x86_64 #1 SMP Thu Jan 4 01:06:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
centos 6-os VM vmware alatt:
uname -a
Linux ... 2.6.32-696.18.7.el6.x86_64 #1 SMP Thu Jan 4 17:31:22 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Többet is frissítettem, mindegyik szépen elindult.
vmware alatt nincs gond, KVM alatt is jó.
Ugyanigy jartam penteken, Xen-alapu VPS-em halt el.
--
L
Szintén, 2.6.32-696.18.7 nem jó. Viszont valamit nagyon elkúrhattak, mert CloudLinux 6 és 7 se indult el a legutolsó kernellel Xen alatt.
Szintén, 2.6.32-696.18.7 nem jó. Viszont valamit nagyon elkúrhattak, mert CloudLinux 6 és 7 se indult el a legutolsó kernellel Xen alatt.
Hozzáértő, felelős javítás, Red Hat módra.
Pont egy olyan, staibilitás szempontjából kritikus LTS disztrónál, mint a CentOS 6.
Teged ki kerdezett? Nyilvanvaloan fogalmad sincs, mirol van szo.
--
L
Ez egy fórum, ahol szólásszabadság van és bárki hozzászólhat. Nem kell kérdezned ahhoz, hogy elmondjam a véleményem.
Témánál maradva tehát: Többről van szó annál, minthogy CentOS 6 alá kiadtak egy kernelt, amit lusták voltak VM környezetben tesztelni?
Bőven.
Akkor kíváncsian várom a fejleményeket.
Amit Xen (unsupported) környezetre nem validáltak. Nagyon nem mindegy.
Microsoftnak sem sikerült első nekifutásra, jópár Windows 10-es rendszer lebénult a kiadott frissítéstől. (Egyébként nem az első eset, hamar munka ritkán jó).
Nehezebb jól peccselni, főleg gyorsan, mint kritizálni, ha valami félremegy.
A legnagyobb kritika pedig a CPU gyártókat illeti, akik ezt valójában jól elbaltázták.
--
robyboy
A Windows 10-ek ennél sokkal jelentéktelenebb frissítésektől is lebénultak már. Szarból épített várra nehéz új szintet ráépíteni úgy, hogy ne dőljön össze.
Ha adsz ezermilliárd dollárt (amennyi perpill a Microsoft mögött van), megpeccselem neked. Ha nekem nem megy, segítséget kérek itt, úgyis annyi megélhetési mérnök úr hemzseg erre felé, hogy biztos akad, aki szívesen dolgozik majd nekem. Ha ez után se sikerül stabil patch-et produkálnom, akkor csatlakozom az általad képviselt, szoftvermultiékat mosdató véleményvonalhoz, sőt, azt is megfogadom, hogy önként visszavonulok és többet nem írok a HUP-ra. Kipróbáljuk?
Örülök, hogy ebben legalább egyetértünk.
Nem hiszem, hogy Microsoftéknál a programozók lennének a legjobban megfizetve, főleg nem annyival, amennyi a cég "mögött" van. Mondjuk a magyar bérekhez képest biztosan ég és föld. Egyébként szerintem itt semmi másról nincs szó, csak kapkodásról, rövid határidőkről, ami magában hordozza a hibalehetőséget, illetve a megfelelő tesztelés hiányát. A biztonság mindenek előtt ugyebár.
--
robyboy
Nem hiszem, hogy létezik elfogadható kifogás egy pénzzel ilyen mértékben teletömött cég esetében. Persze, ha a befektetők nem fejőstehénnek használnák, akkor lehet, hogy a produktív, értelmes dolgokra is jutna pénz marketinghadjáratok, FUD kampányok (XP), fájlkezelőbe bújtatott reklámok, Cortana, telemetriás idealizmusok és a jelenlegi, elbaszott, szélsőségesen idealista termékpolitika és arrogáns üzletpolitika helyett.
Ez igaz, de ez az üzletpolitika, illetve amúgy "üzlet" nélkül is (politika), most ugyanígy müködik minden szinten a világon. Ha nem így müködne, nem lenne éhinség a földön, és már kolonizálhatnánk más bolygókat is, hogy az emberiség túlélését biztosítsuk az eljövendö évszázadokra is.
De a profit a legfontosabb, a vagyon, a minél több ZS, mert az az élet értelme. Meg is fogom újra nézni a Nagy Likvidátort Denni de Vito-val, az zseniális. A kapitalista mogul életfilozófiája: "aki a legtöbbet gyüjt, az nyer!" (pont, mint egy videojátékban).
--
robyboy
Jó, de legalább ez egy régi kernel, még a Posready XP-dnél is régebbi, nem ilyen gigamegabloat, mint a mostani 4.14 és 4.15. Ezek még kernelek voltak, betonstabil, gyorsan rajzoljakiaGDI-t, meg van benne dinoszauruszok elleni védelem, ha véletlenül hátba támadna egy, miközben ezt használod.
Persze ahogy nézem, a 2.6.32-696.18-ba bekerült a KTPI, biztos ez zavar be a VM-nek. Ezek szerint a 3.x-be, meg a 4.9-be is belelapátolják, nem hagyják őket sebezhetően.
„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum
Az zavar be, hogy egy multimilliárd dolláros cég (Red Hat) képtelen volt egy értelmes, stabil, jól tesztelt megoldást készíteni, mielőtt kiadott egy kernelfrissítést. Ez azt is jól megmutatja, hogy nincsenek berendezkedve arra, hogy valamennyi, az iparban™ használt scenario-t leteszteljenek, csupán élvezik, ahogy jó zsírosra híznak a nem az alkalmazásukban álló, FOSS fejlesztők ingyenmunkáján.
Itt sehol sem latok RHEL-re utalo hibajelzest, CentOSrol van szo. Amugy a Red Hat mar nem tamogat Xent.
--
L
Értsd akkor ugyanezt a CentOS csapatára, multimilliárd nélkül.
A CentOS már a 6-os verzióban is gyakorlatilag egy "unbranded" RHEL6 volt - úgyhogy a Xen nem támogatott ott is érvényes.
Xen DomU-ként ugyanez áll fenn, bár ahogy tudom a Xen-t nemnagyon szeretik mert KVM/VMWare vonalon mennek.
Az xl dmesg -be ez jön (attól tekintsük el, hogy stable-4.9 git át került fel, ugyanis nincs még dom0 patch:
(XEN) Freed 460kB init memory
(XEN) d3v0 Unhandled page fault fault/trap [#14, ec=0000]
(XEN) Pagetable walk from ffffffffff400000:
(XEN) L4[0x1ff] = 00000002dd891067 0000000000001a91
(XEN) L3[0x1ff] = 00000002dd892067 0000000000001a92
(XEN) L2[0x1fa] = 0000000000000000 ffffffffffffffff
(XEN) domain_crash_sync called from entry.S: fault at ffff82d0803489c8 entry.o#create_bounce_frame+0x135/0x14d
(XEN) Domain 3 (vcpu#0) crashed on cpu#5:
(XEN) ----[ Xen-4.9.1-pre x86_64 debug=n Not tainted ]----
(XEN) CPU: 5
(XEN) RIP: e033:[]
(XEN) RFLAGS: 0000000000000212 EM: 1 CONTEXT: pv guest (d3v0)
(XEN) rax: 0000000000000000 rbx: ffffffffff400000 rcx: 0000000000000004
(XEN) rdx: 0000000000000010 rsi: ffffffffff400000 rdi: ffffffff81a03e68
(XEN) rbp: ffffffff81a03e48 rsp: ffffffff81a03e00 r8: 0000000000000000
(XEN) r9: 0000000000007ff0 r10: 0000000000000000 r11: 0000000000000000
(XEN) r12: ffffffff81a03e58 r13: ffffffffff400000 r14: ffffffffff410000
(XEN) r15: ffffffff81a03e68 cr0: 000000008005003b cr4: 00000000000406e0
(XEN) cr3: 00000002dd88e000 cr2: ffffffffff400000
(XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e02b cs: e033
(XEN) Guest stack trace from rsp=ffffffff81a03e00:
(XEN) 0000000000000004 0000000000000000 0000000000000000 ffffffff812b7872
(XEN) 000000010000e030 0000000000010012 ffffffff81a03e48 000000000000e02b
(XEN) ffffffff812b7869 ffffffff81a03eb8 ffffffff81c80153 0000000000000000
(XEN) 0000000000000000 ffffffff81a03e98 ffffffff81c872a0 0000000000000000
(XEN) 8497c6cdded0758e ffffffffffffffff ffffffff81c872a0 0000000000000000
(XEN) ffffffff81a03f80 ffffffffffffffff 0000000000000000 ffffffff81a03f68
(XEN) ffffffff81c45605 0000000000000010 ffffffff81c872a0 0000000000000000
(XEN) 0000000000000000 ffffffffffffffff 0000000000000000 ffffffff81a03f08
(XEN) ffffffff8107e0ee ffffffff81a03f68 ffffffff8154b0cd 0000000000000010
(XEN) ffffffff81a03f78 ffffffff81a03f38 8497c6cdded0758e ffffffff81a03f58
(XEN) ffffffff81c872a0 0000000000000000 0000000000000000 ffffffffffffffff
(XEN) 0000000000000000 ffffffff81a03fa8 ffffffff81c3fdda 8497c6cdded0758e
(XEN) ffffffff81c8a820 000000000204aa24 0000000000000000 0000000000000000
(XEN) 0000000000000000 ffffffff81a03fc8 ffffffff81c3f33a ffffffff81c34640
(XEN) ffffffff85332000 ffffffff81a03ff8 ffffffff81c4309c 9e98220317898175
(XEN) 00600f12000c0800 0000000000000000 0000000000000000 0000000000000000
(XEN) ffffffff84b2f000 ffffffff84b30000 ffffffff84b31000 ffffffff84b32000
(XEN) ffffffff84b33000 ffffffff84b34000 ffffffff84b35000 ffffffff84b36000
(XEN) ffffffff84b37000 ffffffff84b38000 ffffffff84b39000 ffffffff84b3a000
(XEN) ffffffff84b3b000 ffffffff84b3c000 ffffffff84b3d000 ffffffff84b3e000
Én ugy tudom, hogy csak a PV modban futo VM-eket erinti. Legálábbis xenservernél tuti, gondolom sima xennél is hasonló a helyzet. Szóval lehet érdemes addig valamilyen HVM módban indítani.
Fedora 26, Thinkpad x220
Nem szeretnék HVM módot egy Linuxnak Linuxon, mire van akkor a PV? :) Egyébként szerintem a particiók miatt eleve nem is indulna csak úgy simán, mert nincs MBR meg semmi, csak egy LV és azon az fs.
Talán mert a PVHVM jobb teljesítményt tud adni mint a PV mód.
Fedora 26, Thinkpad x220
PV még abban az időben volt tényező, amikor a virtualizációt támogató feature-ök még hiányoztak a CPU-kból. Szerintem manapság a Xen által is a HVM preferált.
Kérdés hogy hypervisor (xen) patchelve van-e már.
Fedora 26, Thinkpad x220
Lefrissült nálam is, VMWare alatt hibátlan.
Xen + HVM módban sincsen gond.
Fedora 26, Thinkpad x220
Feliratkozok.