A Microsoft Secure boot miatt a régebbi gépeken a fenti dátumtól nem fog működni a linux. (Illetve a Windows sem.) Mit tehetünk?

@"vé"#p686370 Szia! Messze még a negyedik hó első napja! Értem én, hogy uborkaszezon van, de szerintem ez az információ hápog, szóval nagy valószínüséggel kacsa. Mit tehetünk? Te például megoszthatod velünk, honnan ez az információ és hogy pontosan mit jelent a régebbi gépeken.

@"vé"#p686370 Pl. tájékozódhatunk.

@"csuhas32"#p686371 Innen: https://pcforum.hu/hirek/29624/linux-secure-boot-tanusitvany-lejarat-2025-szeptember

@"vé"#p686373 A szövegértelmezés sokkal hasznosabb lenne mint a pánikkeltés. A cikkben, mely amúgy helyesírási hibákat tartalmaz, tehát komoly forrásnak szerintem amúgy se vehető, az én olvasatomban egyáltalán nem ezt írják.

@"vé"#p686377 Amit leírt. Ha senki sem tesz semmit, akkor a Secure Boot nem engedi elindulni a lejárt aláírású szoftvereket, ugyanúgy mint eddig is pl az aláírással nem rendelkező szoftvereknél (linux változatok többsége). Megoldások: a SB letiltható UEFI-ben, a hardver gyártója frissítésben kiadhatja az új kulcsokat, az OS gyártója kiadhatja frissítésben a kulcsokat (ez az általános), linux rendszernél a user is aláírhat bármit MOK segítségével, amit csak jónak lát. Szóval aki olyan linuxot használ, ami nem volt aláírva, az már eddig is tiltotta a SB-t, aki aláírtat használt az rendszeresen frissítse.

@"vé"#p686377 A cikk címében ez a szó szerepel: „válhat**NAK**” aztán, ha tovább olvasol, akkor „... vagy valamiért egy, az említett dátumnál régebbi Linuxot használnak, belefuthat**NAK** a szóban forgó indítási problémába.” A cikk mindkét idézett részben feltételes módot használ, te viszont kijelentő módban hánytad ide a mondatodat, ami megítélésem szerint jelentős csúsztatást eredményez. Megállapíthatóan a témaindító mondatod mindkét fele téves. I. Ha nem vagy istentelenül béna, akkor simán fog működni az Ubuntu ami (még ha titkoltan is :-) ), de egy Linux disztribúció. – Eleve csak az említett dátumnál régebbi Linuxokat érintheti a probléma, ami ugye élből nagyon leszűkíti a kört, hiszen javarészt naprakész rendszereket használunk, azok már rendelkeznek a módosított kulccsal. – Másrészt ha ez nincs, akkor még a cikk szerint is lehet frissíteni a gépek firmware-t. – Ha erre sincs lehetőség vagy valamiért nem történt meg, akkor ki lehet kapcsolni a Secure Boot-ot (amit azonban a cikk szerzője biztonsági okokra hivatkozva nem ajánl). II. Windowsról pedig egyáltalán nincs is benne szó, bár az engem nem is érint, ezt te költötted oda. Ahogy az a cikk alatti jelenleg utolsó hozzászólásban is olvasható, akik Linuxot használnak, azoknál már most is nagyon sok esetben ki van kapcsolva a Secure Boot (aztán mégse történt semmi), szóval a legtöbb felhasználó esetén ennek az egésznek nulla jelentősége lesz, észre sem fogja venni. Javaslom neked, hogy máskor használd az „Ebben a cikkben meglátásom szerint az szerepel, hogy” formulát és egyből jelöld is meg a forrást, úgy a mondandód tartalmától függetlenül a közlendőd rendben lesz! Mert így, hogy tényként kijelentesz valamit, amit aztán egyáltalán nem tudsz alátámasztani... :-(

A dologhoz figyelembe veendő az a gyakorlati megfigyelésen alapuló tapasztalat, hogy - a pcforumon írt linuxos cikkeket nem szabad komolyan venni - Sting linuxos írásait nem szabad komolyan venni.

@"csuhas32"#p686379 Köszönöm a kioktatást! :(

@"vé"#p686381 Pedig minden szava igaz.

Szeptember 11 és kész?

csuhas32

vé -a Windows 11-et a Rufus általi telepítővel raktam fel és ugye minden ki volt pipálva. Így aztán nem figyeli az sb-ét.

Fentebb írta már neked windowsos szakértőnk, hogy a Windowsok automatikusan megkapják a Secure Boot-tal kapcsolatos frissítést (a Secure Boot Microsoft találmány). Nem számít, hogy hogyan tetted fel a Windowst, ha fent van és frissül, akkor a probléma nem érintheti.

A Debianod meg friss és frissül. Szóval azt se.
Ennyi az egész.

Kutyó

Alveus irónia? 🙂

Nem irónia, hanem egy adott diagnosztikai módszer alkalmazása.
Nagy bizonyosságú módszer a puding tesztelésére a megevése.
Édesapám azt mondta, a gondolkozás nehéz, fárasztó dolog, de megéri.

csuhas32

Kutyó Nyugalom. Amit @Alveus írt, azt viccnek, iróniának szánta, csak nekem nem volt elég agyam hozzá, hogy felfogjam és jól megválaszoltam. :-D
Ennyi.

Kutyó

csuhas32 Igen, ez IS lehetséges.

Alveus

Igen, viccnek szántam, direkt nem tettem bele semmi hangulatjelet, csak nem az vette komolyan, akire számítottam 😁 Na, de én befejeztem az offot 🙂 olvasgatok szépen csendben tovább

a mester

Alveus van-e erről a hírről nemzetközi oldalon is valami. Jelentem, nem találtam semmit.

Sting "cikke" a tomshardware oldalt jelöli meg forrásnak. És igen, ott is ezt írja a "szakértő".

tenkes

a mester Elolvastam amit találtam a témáról. Ami megerősített abban, hogy az MS álláspontja hagyományosan ködös és folyamatosan változik, különösen a határidők előtt.
Szóval valahogyan mégis minden szokott működni.

csuhas32

Most települt a Debian 13-ra shim-signed és shim-signed-common frissítés. :-)

Csak a végét mutatom, szerintem elég az is most:

Setting up shim-signed:amd64 (1.47+15.8-1) ...
Installing for x86_64-efi platform.
Installation finished. No error reported.
No DKMS packages installed: not changing Secure Boot validation state.
Setting up dirmngr (2.4.7-21+b3) ...
Setting up gpg-wks-server (2.4.7-21+b3) ...
Setting up bind9-dnsutils (1:9.20.11-4) ...
Setting up gpg-wks-client (2.4.7-21+b3) ...
Processing triggers for man-db (2.13.1-1) ...
Processing triggers for debianutils (5.23.1) ...
Processing triggers for initramfs-tools (0.148.3) ...
update-initramfs: Generating /boot/initrd.img-6.12.38+deb13-amd64
I: The initramfs will attempt to resume from /dev/sdb3
I: (UUID=994e5c49-4d71-4140-8653-530cd84332a7)
I: Set the RESUME variable to override this.
Processing triggers for libc-bin (2.41-11) ...
csuhas@ThinkCentre:~$

« Előző oldal