CentOS 6 + Spectre and Meltdown patch: 2.6.32-696.16.1.el6.x86_64 nem megy

Red Hat, Fedora, CentOS

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.

( pepelopez | 2018. 01. 07., v – 15:41 )

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

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

( lberes (nem ellenőrzött) | 2018. 01. 07., v – 16:05 )

Ugyanigy jartam penteken, Xen-alapu VPS-em halt el.

--
L

( hajbazer v | 2018. 01. 07., v – 16:12 )

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?

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?

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

Microsoftnak sem sikerült első nekifutásra, jópár Windows 10-es rendszer lebénult a kiadott frissítéstől.

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.

Nehezebb jól peccselni, főleg gyorsan, mint kritizálni, ha valami félremegy.

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?

A legnagyobb kritika pedig a CPU gyártókat illeti, akik ezt valójában jól elbaltázták.

Ö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.

( andrej_ v | 2018. 01. 07., v – 18:27 )

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

( _ventura_ v | 2018. 01. 07., v – 18:27 )

Kérdés hogy hypervisor (xen) patchelve van-e már.

Fedora 26, Thinkpad x220

( ibenny v | 2018. 01. 07., v – 20:27 )

Lefrissült nálam is, VMWare alatt hibátlan.

( _ventura_ v | 2018. 01. 07., v – 20:59 )

Xen + HVM módban sincsen gond.

Fedora 26, Thinkpad x220