Átmenetileg visszavonták az Ubuntu 17.10 letöltési linkjeit BIOS korrupciós hiba miatt

Címkék

Jelenleg még mindig nem elérhetők az Ubuntu 17.10 letöltési linkjei, mert egyes Lenovo (és más) laptop felhasználók arról számoltak be, hogy telepítés után gépük BIOS-a korrupttá vált. Az érintett gépeken egyebek mellett nem lehet elmenteni a megváltoztatott BIOS beállításokat, illetve nem lehet USB-ről bootolni. A bug nyomon követhető itt. Részletek itt.

Hozzászólások

Mintha csak az Apple keze lenne a dologban, ök szoktak hasonló bug-okkal elöállni.
Erre szokott az lenni a válasz, hogy használj LTS-t, csak az a baj ezzel, hogy akkor ki fog bétatesztelni?
Aki meg tesztel persze ne lepödjön meg azon, ha a rendszere nem úgy müködik, ahogyan szeretné.

Ilyenkor bukik meg az elmélet, hogy a linuxhoz tudni kell HW-t venni.

Az megbocsáthatatlan, ha egy szoftver tönkreteszi a vasat.

--
robyboy

Főleg, ha kevered a szezont a fazonnal. A "hardvert venni tudni kell" nem erre vonatkozik, hanem támogatottságra.

Nyilvánvaló, hogy megengedhetetlen, hogy egy szoftver tönkretegyen egy hardvert. A problémát inkább ott látom, hogy OS telepítés sosem végződhetne ilyen hibával. Az a hardver, amit egy installerrel ilyen szinten haza lehet vágni, az eleve szarul tervezett valami.

A szánalom az, hogy az Apple a saját vasán képes ezt a mutatványt előadni. Amit elve ő gyárt(at).

--
trey @ gépház

Vagy 15 éve az egyik Linux terjesztés (talán Mandrake???) az egyik LG CD-író firmwaret vágta haza.
Érdekes módon semmi mást csak azt! Na erre hogy lehetett volna felkészülni?
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Az LG CD-író firmware-ét kellett volna úgy megírni, hogy ilyen ne fordulhasson elő.

Több dolog egyezőségét kell ilyenkor vizsgálni, pl.:
- formátum
- lemezcímke
- teljes fáljnév
- a fájl megfelelő helyén egyedi karaktersorozat, amolyan fejléc jelleggel, ami csak arra az egy típusra jellemző
- a firmware mérete
- CRC
stb.

Ha minden stimmel, csak akkor hihetné el a CD-író, hogy ebben az állományban az ő firmware-ének frissítéséhez szükséges dolgok vannak.

A feltételeknek megfelelő dolgokat véletlenül elég nehéz lenne előállítani.

Vegyük már észre, hogy a firmware-ek egyik sajátossága, hogy írhatók. Régen még védték öket hardveres jumperekkel az írástól, és igen, az volt az egyetlen és jó védelem. Aztán ezt felszámolták, mert megspóroltak vele egy csomó gyártási költséget.

Szofver oldalról meg a jelszavas levédés lehetne opció, ha valaki frissíteni akar, kérjen jelszót, ami változtatható lenne házilag.

Nem tudom amúgy, ha a bios le van védve jelszóval, akkor is lehet frissíteni? Sosem próbáltam.

--
robyboy

Szerintem ne "régen"-ezzünk. Itt a laptopom idevágó BIOS-beállítása (jaaaj, trey-nek nem romlott el a gépe, mik vannak):

https://flic.kr/p/D5cqy4

Be van állítva, hogy End-User ne tudjon BIOS-t flash-elni jelszó ismerete nélkül. Ha ennek ellenére egy telepítő vagy op. rendszer képes összebaszni a BIOS-t, az igenis a gyártó hibája.

A többi maszatolás, ahogy lentebb megjegyezték (csak rosszul).

--
trey @ gépház

Ez ok, ezen kívül pedig:

Ránéztem az Ubuntu oldalára. A certified hardware-knél csupán a két támogatott LTS verzió választható opció:

https://certification.ubuntu.com/desktop/

Szóval aki nem LTS-t használ, az ne reklamáljon, még akkor sem, ha a gyártó hibájából vágja szét a gépet a szoftver.

--
robyboy

Èn semmit. Amúgy pár száz eszközt támogat a két LTS verzió mindösszesen, ami eléggé sovány felhozatal szerintem, ahhoz mindenképpen, hogy a desktop piacon komolyan labdába rúgjanak.

Bármennyire is szar a Windows, eljutottunk oda, hogy sokkal jobban támogatja a különféle hardvereket. Nem volt ez mindig így, még a 90-es években a Linux ezen a fronton jobban teljesített.

--
robyboy

1,A linux lehet, hogy igen, de ubuntu nem volt. Most te egy disztrót veszel alapul, ez így hibás megállapítás.
2, A windows támogatását ne feszegessük. Messze van az még attól is, hogy beszéljünk róla, bár némi javulás valóban történt...

üdv: pomm

A 852-es kídlap telepötúsa sikeresen befejezádétt

Nem volt ez mindig így, még a 90-es években a Linux ezen a fronton jobban teljesített.

El tudom képzelni, mikor még a kilencvenes évek vége felé is felhasználói ráhatás kellett egy elterjedt videokártya vagy épp egy sima PS/2 egér ~működésre bírására... A Linux disztróban a driverek konfigurálására ugyanannyi idő elment, mint Windowsnál a hardverhez mellékelt driver telepítésére. A különbség annyi volt, hogy Windowson általában működött is a cucc, míg Linuxnál már annak is örült az ember, ha működésre utaló jeleket látott.

:)

Vegyük már észre, hogy én sem állítottam azt, hogy egy firmware ne legyen írható a felhasználó által, pusztán azt mondom, hogy az írási folyamat csak bizonyos feltételek teljesülése esetén történhessen meg. Ha egy LG-író firmware-e egy akármilyen lemez akármilyen tartalmának beolvasásakor "véletlenül" felülíródik, akkor ott komoly problémák vannak a fejlesztői oldalon.

Erdemes viszont Linus mantrajat is elhozni -- 'we don't break userland'. Tehat ha valami eddig mukodott a felhasznaloi oldalon, es egy alacsonyabb szintu komponens valtoztatasa azt megtori, akkor hiaba 'fixaltak egy bugot' az adott komponensben, ez nem jo erv arra, hogy miert doglik meg az userland.

----------------------
while (!sleep) sheep++;

Annyi volt az eredeti történet, hogy az LG CD-ROM-ok az opcionális ATAPI FLUSH_CACHE parancs helyett ugyanarra a parancskódra implementált UPLOAD_FIRMWARE funkciót hajtották végre. A linux fejlesztőknek annyi róható fel, hogy hatékonyabb kódot szerettek volna írni. Ha a gyártó 'hülye', akkor arra valóban nem lehet felkészülni.

https://www.theregister.co.uk/2003/10/29/mandrake_linux_ate_my_cd/

április 1 van trej? nem úgy volt hogy a linxuéknál nincsenek hibák?

az nem nagy probléma, hogyha a linux anyagi károkat okoz, mert legalább ingyen volt!

ha viszont az apple fun-ból berak egy featuret (amit nem kötelező használni...) a telefonjaiba (amiket nem kötelező megvenni...) akkor trey már az istenhez is imádkozva szarozza le napi 50x a márkát.

objektív látásmód ftw!

Teglásított BIOS a Buguntuban.

Thnx Intel!

Nekem a Lenovo G50-45 -ön szerencsére nem jött ez a probléma. Ne is jöjjön :)
A disztró-hopperkodásból kifolyólag sem :) De ki az a ...... aki Buguntut tesz a gépére? Milyen kezdő az?? :D ;)

---
Amíg a test renyhe, az elme dolgozik...

Van az a helyzet, amikor az Ubuntu megfelelő. Nekem most ér véget egy 2-3 hónapos fix projektem, ahova külső gépet nem tudtam bevinni, viszont a belsőre telepíthettem. Mivel Linuxon szeretek dolgozni, ezért felcsaptam rá egy Ubuntut. Arra nem akartam energiát befektetni hogy a kedvencemet felrakjam és customizáljam (Arch). Egyébként a fő munkagépem sok éve az. Pénteken a projekt végén letörlöm, oszt jónapot.

--
debian,libreelec,openmediavault,ubuntu,windows,arch,lineageOS
zbook/elitebook/rpi3/nexus5_hammerhead

Amióta Gnome 3-ra visszaálltak, már telepítettem egyet és teljesen jól fut. A BIOS-"korrupció" nekem inkább AMT-vel basz*kodó hülyegyerekeket feltételez, sem mint az Ubuntu-t magát. (Max. kezükbe adja a "drótot" hozzá.)

Sokak által várt trollkodás:

A hiba csak a Mészáros és Mészáros Kft. által gyártott lapkákat érinti.

Sajnos, ezt még senki sem erősítette meg..

Az már egy elég nagy probléma, hogy az Ubuntuba ilyen kód egyáltalán bekerülhet. Azonban hibák mindenütt előfordulnak, csak hatalmas blamázs.

Az viszont gondolkodásra ad okot és nálam mostantól kilövi a rendszer használatát, ahogy a problémához álltak hozzá (hülyének nézik az embert):
"ez nem az Ubuntu hibája"
"a Lenovo-t kérdezd"
aztán mikor előjöttek más laptopokon is
"a BIOS szállítójának hibája"
sőt kiderült, hogy ezt már nyáron jelezték nekik, de lezárták a kérdést, SŐT ki is törölték még a nyomát is, mert kényelmetlen volt
https://launchpadlibrarian.net/349959106/askubuntubiosissues.png

Tipikus: you're holding it wrong

Szerk
Most már egy vicc az egész, komolyan mondom ilyen embereknek miért adnak írási jogot bárhova:
"I think we are off on the wrong track. This is fundamentally a CVE against Insyde Software BIOS and possibly other vendors. Any attacker with kernel mode access could do the same thing, regardless of Linux install."
Tudja mi az a CVE egyáltalán? Kernel módban le is nullázhatod a BIOS-t. Ezt is jelentse már! Az összes hozzászólást le kellene menteni és mehetne egy IT kabaréba.

Ez a hiba nagyon gáz, de néhány dolgot hadd jegyezzek meg:

"ez nem az Ubuntu hibája"

Ha a mainline kernelben benne van a hibás kód, akkor ez _nem csak_ az Ubuntu hibája.

"sőt kiderült, hogy ezt már nyáron jelezték nekik, de lezárták a kérdést, SŐT ki is törölték még a nyomát is, mert kényelmetlen volt"

Nem "nekik". Az askubuntu nem bugtracker, egy közösségileg egyengetett kérdezz-felelek fórum, a Stack Exchange része, nem sok köze van az Ubuntu-hoz (a témáján kívül). Az, hogy miért törölték egy fórumról, az jó kérdés. Az, hogy ha buot akart bejelenteni az Ubuntu-nak, akkor rossz helyre jelezte, az biztos.

--
trey @ gépház

“Ha a mainline kernelben benne van a hibás kód, akkor ez _nem csak_ az Ubuntu hibája.”

Hasonlattal elve, ha a szakacs megfozi a romlott hust, es te beteg leszel, az sem a szakacs hibaja, mert romlottan kapta mar? :)
---------------------------------------------------
Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

Nagyon jók az ilyen semmilyen kommentek. Ha én veszem a fáradságot, hogy normálisan válaszolok, akkor elvárnám, hogy akivel beszélgetek, szintén vegye a fáradságot, hogy kifejti a véleményét.

Ha szeretnél valami érdemi érvet letenni az asztalra, nyugodtan tedd meg.

--
trey @ gépház

ott a launchpados link a képen, az hivatalos. Mindegy, ezt Márkék csúnyán elszabták, hogy nem néztek utána.
Nem kell jópofizni a zintellel, keményen rájuk kell borítani a bilit ha elkúrnak valamit.
Van elég pénzük, vegyenek fel több debuggert. Ez érvényes az applere is.

--
GPLv3-as hozzászólás.

Ne legyél már ennyire hülye... "Edited 13 hours ago"

Ott a link:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147/

November 23-án hozták létre. Az Ubuntu 17.10 októberben jelent meg.

Az illető 13 órával ezelőtt szépen beleszerkesztette egy 4 hónappal ezelőtti kommentbe.

--
trey @ gépház

haha és tényleg, a júliusi kommentbe betette a novemberi linket a kis geci.

Akkor ezt le is zárhatjuk, tényleg nem jó helyen jelezte a srác a problémát. Márkék meg elmehetnek a picsába, hogy azt a posztot nem vették komolyan. Aki lezárta azt a topicot, mint offtopic az is elmehet a picsába.

Szóval sokan elmehetnek a picsába ezzel a buggal kapcsolatban. Úgyhogy én is elindultam, szevasztok...

--
GPLv3-as hozzászólás.

Még egyszer megjegyezném, hogy az Ask Ubuntu-nak semmi köze a hivatalos bugtracker-hez (Launchpad). Az egy community support fórum, ami kap (anyagi) segítséget néha a Canonical-tól (a téma miatt), de egyrészt user-driven, másrészt nem nem bugracker. Az üzemeltetője a Stack Exchange Network.

Hibakövetésre és megoldásra teljesen alkalmatlan felület és ebből kifolyólag a Canonical/Ubuntu fejlesztők valószínűleg nem is követik.

Kb. mintha én egy iOS hibát a meszmac.com-ra jelentenék be, aztán csodálkoznék, ha nem történik semmi.

--
trey @ gépház

Kevered a dolgokat szerintem. Amikor te azt látod a Twitter-en, hogy ott hibákat jelentenek be, akkor azokat általában rég jelezték már az érintett cégek felé.

Főként biztonsági hibákat jelentenek ott be, de ha megnézed a disclosure timeline-ját egy-egy hibának, akkor azt láthatod, hogy a felelős közlés miatt azt akkor már rég jelezték a gyártónak.

Egy-egy ellenpéldából felesleges messzemenő következtetéseket levonni. Minden Ubuntu kiadás release notes-ében ott a megjegyzés és a link, hogy HOVA KELL bejelenteni a hibát:

https://help.ubuntu.com/community/ReportingBugs

Első lépés, hogy készíts egy Launchpad accountot. Kifejezettek ki van emelve, hogy ha nem bugot akarsz bejelenteni, hanem támogatást akarsz kérni, akkor menj a mindenféle support csatornára - Ask Ubuntu, IRC csatorna stb.

Még egyszer: a bugreport és a support kérése nem ugyanaz. Hibát bejelenteni a megfelelő módon és helyen kell. Úgy lesz hibajegye, úgy kerül a megfelelő team-hez, úgy tud a fejlesztőcsapat további infókat kérni, úgy tudják kiadásokhoz rendelni, úgy tudnak súlyossági besorolás alá tenni és minden egyebet úgy tudnak vele megcsinálni, amit egy bugtracker-ben lehet, de nem lehet egy fórumon.

Egyébként aki a napi munkája során használ bugtracker-t, az tudja mi a különbség mondjuk egy vBulletin meg egy Mantis közt.

Akinek nincs fogalma, az nézzen utána. Nem hiszem, hogy neked mesélnem kéne neked ezeket, szerintem egyszerűen csak trollkodsz.

--
trey @ gépház

Szerintem a bugreport igy nez ki:
1. felmesz egy support csatornara (pl. ask ubuntu), es leirod a problemad, hogy masnal is jelentkezik-e, vagy user error.
2. amennyiben masnal is megvan a hiba, akkor bugreport.

A gond akkor van, hogyha az egyes pontot bezarjak offtopik miatt (itt ez tortent), vagy a 2-es pontig senki se jut el.
DE, mivel ez egy eleg kritikus hiba, igy a 2-es pontot nem csak az eredeti kerdezo teheti meg. Veheti mas is a faradtsagot, hogy bejelenti.

A twitterre visszaterve, rengeteg apple ios es macos hibarol irtal te magad,
amit kizarolag a twitteren jelentettek be eloszor.

Volt valami mexikoi sofor, aki bruteforce kitalalta, hogyan kell belepni iphoneba, vagy egy eve. Sztem az is twitter-only volt.
Most volt, hogy a jelszo mezo nincs fokuszban, es kiposztolta slack-re, sztem az is twitter-only volt.
Es akkor mintha te magad mondtad volna, hogy mit var az apple, amikor nincs normalis hibabejelento rendszere.

Osszefoglalva: Szerintem hibas hozzaallas az, hogyha tudsz az esetrol,
csak azert nem foglalkozol vele (barmilyen kritikus is),
mert nem pontosan ugy jelentettek be, ahogy elvarod.

De ez csak az en velemenyem.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Én 2006 óta a Launchpad-et használom a bugok kezelésére:

https://bugs.launchpad.net/~gmicsko

Nekem bevált!

Útbaigazítottalak, ha ezután is tartod magad a rögeszméidhez, akkor magadra vess. Világosan le van írva a bugreport menete. Véleményed persze lehet ettől. Végül is mindenki úgy baszik ki magával, ahogy akar.

PS: én bug bounty programról írtam, ami megint más, kevered a dolgokat újra.

--
trey @ gépház

jaj latom. Kemeny egy bugra van workaround 14.04-bol a masik bugreport "elhalt".

Ha mar tanacsokat osztogatsz, en is adok egyet, hatha a jovoben tenyleg bugot akarsz javittatni: kernel.org. Oda kell a bugot bejelenteni.
De elotte ki kell jarni a szamarletrat, stackoverflow-n rakerdezni,
tuti nem te vagy a hulye, es amikor 100%, akkor ott bejelented.

De ott azert vigyazni kell, mert magas lovon ulnek az illetok, igy vagy elso korben tokeletes a bugreport, vagy pedig megy a fikazas az erdemi dolog helyett.

En javitattam mar igy suspend bugot, videokartya bugot, miegyebet.

Persze ugy szopatod magad a launchpaddal, ahogy jonak latod.
De ubuntueknal komoly javitasra ne szamits. Max csomagolasi hibak.

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1734147/comments/1…

Inkább tűnik ez szerencsétlen egybeesésnek, mint hibának.

Ha elolvassátok az első leírást ami a fenti linken található, kiderül belőle:

Not all manufacturers protect the SPI serial flash, mainly because it allows upgrading the BIOS image directly from an OS.

The intel-spi driver makes it possible to read and write the SPI serial flash, if certain protection bits are not set and locked. If it finds any of them set, the whole MTD device is made read-only to prevent partial overwrites. By default the driver exposes SPI serial flash contents as read-only but it can be changed from kernel command line, passing "intel-spi.writeable=1".

Szóval két dolog lehetséges szerintem:
- Ubuntu-ék / Kernel fejlesztők gondoltak egy merészet és defaultba beállították, hogy legyen csak writeable a flash :) (ez akkor Ubuntu / Kernel bug)
- vagy az érintett gyártó implementációja gáz, mert olyan területekre történik írás egy operációs rendszer telepítése során (nem BIOS frissítés, mert az Ubuntu ilyet asszem azért alapból installkor nem csinál ...) ahova nem lenne szabad

Én a másodiknak adok nagyobb esélyt, de simán lehet az első is.

Biztonsági szempontból nem tűnik jó ötletnek mezei op.rendszerből BIOS frissítgetni, ennyi erővel egy kártevő is dönthet úgy, hogy ideje másik BIOS-t betölteni, mondjuk olyat ami titkosítja a disket és bitcoinért cserébe visszaállít ... hm? :)

A cdírós firmware-es történet meg egyenesen hajmeresztő ... a cd (minden) olvasása közben a driver mintát keres és ha valami hasonlít egy cd firmware-re akkor azt benyalja és onnantól "ujj a torkon ..." ahogy Drex mondaná.

szerk: ez mondjuk gyanús :)

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git…

author Bin Meng 2017-09-11 02:41:53 -0700
committer Greg Kroah-Hartman 2017-11-30 08:40:55 +0000
spi-nor: intel-spi: Fix broken software sequencing codes
commit 9d63f17661e25fd28714dac94bdebc4ff5b75f09 upstream.

There are two bugs in current intel_spi_sw_cycle():

- The 'data byte count' field should be the number of bytes
transferred minus 1
- SSFSTS_CTL is the offset from ispi->sregs, not ispi->base

Azt azért látni kell, hogy évek óta frissíthetö a firmware így-úgy-amúgy, op.rendszer alól. Ez egy feature. Régebben még volt opció a bios-ban, ma már talán még az sincs. Ha nem lenne írható a firmware, akkor nem lehetne frissíteni.

Ami meg egy kapcsolóval állítható, az tulajdonképpen nem védelem.

Szóval továbbra is fenntartom, hogy a kód a hibás és nem a hardver, ugyanúgy, mint egy vírusnál is. Mondhatjuk úgy is, hogy egy vírus sem csinálhatta volna ezt szebben.

De persze egyszerübb mindent a gyártókra fogni...

Ami igazi védelem volt, az a jumper-es megoldás még az öskorban, de ugye ez meg nem felhasználóbarát.

--
robyboy

ha az apple csinálta volna, már lenne erről szavazás, 4000 fika komment, trey 5 imát írt volna már istenhez hogy szűnjön meg a cég.

ha ubuntuék akkor pedig a hardver gyártó a hibás és amúgy is meg van magyarázva hogy ez amúgy miért jó és miért nem baj. :)

szerencsére az itteni ubuntu userek (vér-fanok) nem elvakultak mint az állat. :)

Hali

Az egyébként valóban gáz, hogy nem a hiba jellege, hanem az eredete (gyártója) határozza meg sok esetben hogy ki hogyan ítéli meg a hibát magát.

Én személy szerint nem azt nézem, hogy Apple v Ubuntu, hanem a hibát magát és talán a hozzászólásomból sem süt az elfogultság (pláne, hogy azért mindjárt egy kernelbug-ra utaló idézetet tettem bele), az meg hogy leírtam a véleményem, szerintem még nem szentségtörés.

Személy szerint jobban zavar a HUP-on, hogy egyre inkább mobil platfom ketrecharcos klub, de hát ez van, a világ a mobil irányába megy el. Néhány éve még az számított "ejha" érzésnek, hogy de régen fordítottam kernelt, lassan meg az, hogy de régen használtam nem mobil alkalmazást arra, hogy levelet küldjek vagy olvassak, netem megnézzek valamit.

Összegezve jobb lenne több tény, szakmai tartalom és kevesebb szubjektív felhang, mert az ugye ízlés dolga az pedig: "De gustibus non est disputandum."

... most megyek és meg is írom a Jézuskának, hogy ezt kérem karácsonyra! :)

Semmi kétség, hogy helyes az érvelésed.

De anno futottam bele olyan bug-ba (ACPI asszem) amikor a BIOS olyan memória területet mutatott az operációs rendszer által módosíthatónak amit nem lett volna szabad és az is hasonló hibajelenségekhez vezetett. (Google -> ACPI BIOS Warning (bug))

Szóval persze, hogy szoftver hiba, de lehet, hogy olyan hiba amihez két dolog kell: egy hibás BIOS és egy hibás oprendszer, melyek ha nem találkoznak az életben nem jön elő a hiba. (Ahogy valószínűleg ebben az esetben is valami hasonló lehetett, mivel nem minden eszközön jött elő a hiba, de azokon ahol előjött ott is csak az Ubuntu ezen változata hozta elő a hibát)

És innentől mehet a mutogatás, hogy ki a hibás, az aki olyan címet ad át szabadként amit nem az vagy az aki nem ellenőrzi valahogy hogy tényleg szabad azon a címen mókolni? (mondjuk, hogy hogyan lehet ilyet ellenőrizni azt spec nem tudom :))

Persze simán lehet, hogy nem ez van, de majd kiderül és akkor nem kell találgatni.

Gondolom arra is van ötleted, hogy hogyan tesztelje le az összes támogatott hardveren a disztribútor az összes változást egyik release-ről a másikra. Sehogy nem tudja nyilvánvalóan, ezért van az alpha, bétateszt időszak.

Tetszik vagy sem, ha a gyártó (Lenovo) hivatalosan nem támogatja az Ubuntu ezen verióját azokon a gépeken, a hw gyártó nem fogja elvégezni ezt a tesztet. Ha nincs teszt, nincs "certified" plecsni. Ha nincs, akkor nincs hol reklamálni. Ezt te, aki ebben az iparban dolgozott, pontosan tudod.

Tetszik vagy nem, itt a felhasználókra marad a bétateszt (nem mintha a fizetős op. rendszerknél ez már nem így lenne).

Ha a megfelelő helyen és időben bejelentik a hibát, "release critical" bug lehetett volna.

Kérdés, hogy ez megtörtént-e. Ha igen és nem történt érdemi reagálás, akkor egyértelmű a felelős.

--
trey @ gépház

Nem kell a gyártókra semmit sem fogni, egyértelmű, hogy az ő hibájuk :)

Egyszerűen nem szabadna a hardvernek tönkretehetőnek lenni szoftverből, mert nem csak hibák, hanem szándékosság is létezik. Ráadásul könnyen megoldható lenne hardverből, hogy ilyenkor ne legyen gond. Páran meg is oldják. Szóval nem lehetetlen. Inenntől aki mégsem oldja meg... nos, nehéz őket nem hibáztatni, ha az opció adott.

Van nálunk egy érintett Lenovo laptop, ahol az első dolgom volt kipróbálni ezt az ötletet: sajnos nem oldja meg a problémát. Annyi változott, hogy a BIOS-ba már be lehet lépni, de a változtatások továbbra se mentődnek el, és az USB-ről bootolás továbbra is teljesen halott ügy.

Kíváncsian várom, mi lesz a vége...

Nyár végén visszatértem a debianra ubunturól, mert untam az upgradek után, hogy sokszor popup hegyeket kaptam olyan hibákról,amik előtte nem léteztek. Természetesen ez ha alkalmanként történik, teljesen elfogadható, de idegesítően vált rendszeresége és szerencsére szeptemberben repült az ubuntu. Lenovom (yoga500) van, bár nincs listán, de nem is szeretném :)
Amúgy mindegy hogy hol jelezték, az azért érdekes, hogy ez senkinek nem szúrt szemet vagy, hogy pontosabban fogalmazzak, senki nem akarta ezt észrevenni.

üdv: pomm

A 852-es kídlap telepötúsa sikeresen befejezádétt

Valaki, akit érdekelt annyira a téma, hogy elolvasta, mondja már meg, hogy hogyan tud egy (akármilyen) OS telepítés BIOS korrupciót okozni!

Feltételezem nem része a telepítésnek, hogy valami random image-dzsel elkezdi felülírni a BIOS-t.
Eddig akármit telepítettem, az valamilyen háttértárra (pl. hdd, sdd, sd kártya) firkált, a BIOS meg nem törődött ezzel.

Itt van leírva a - feltehetően helyes - következtetés:

https://github.com/torvalds/linux/commit/d9018976cdb6eefc62a7ba79a405f6…

Úgy tűnik, hogy a Lenovo Thinkpad Yoga (és esetleg más gépek) BIOS-a ellenőrzi az SPI-NOR írásvédelmi bit állapotát és ha az írás/olvasás állapotba van billentve, akkor feltételezi, hogy a BIOS beállítások megváltoztak a következő reboot során. Ebben az esetben, valami ismeretlen okból visszaállítja a BIOS beállításokat az alapértelmezett értékekre.

A kernelfejlesztők ezt a bitet valószínűleg alapértelmezetten r/w-re állították (pl. hogy lehessen BIOS-t update-elni az op. rendszer alól). A következő rebootkor bekövetkezett a fenti állapot. Az user hiába állította be a BIOS-t, a rendszer elindulása után a kernel újra bebillentette a flag-et és az egész kezdődött elölről.

Az user pedig annyit észlelt, hogy hiába állítja a BIOS-t be, azt "nem lehet elmenteni". El lehetett feltehetően, csak a következő reboot-kor a BIOS elbaszta újra, lásd eleje.

A megoldás az, hogy a drivert ki kell szedni (mondjuk blacklistre tenni) és utána csinálni reboot-ot kétszer.

Ha a fenti feltételezés helyes, akkor semmi sem firkált a BIOS-ba, egyszerűen csak szar a BIOS.

--
trey @ gépház

Ha tippelnem kellene, akkor valamilyen bug(ok) miatt az UEFI boot beállításakor az Ubuntu installer olyan területre ír ahova nem lenne szabad.
(vagy azért van mert a BIOS olyan címet ad át amit nem lenne szabad írni, vagy azért mert bugos az Ubuntu installere, és az sem kizárt, hogy ez a kettő együtt :))

Ahogy nézem, itt mindenkinek jár a tockos:
- normális vason legalább CRC-t ellenőriznek,
- ha valamit nem írok, akkor nem kérek rá írási jogot. A kernelnek illene abból kiindulnia, hogy akár részlegesen megtörhetik/van benne hiba. Ne legyen annyira könnyű dolga a támadónak/usernek BIOS-t írni. A BIOS-t állítsuk akkor írhatóra, ha ténylegesen írni akarjuk. (Valljuk be egy gép életének elhanyagolható része az, hogy BIOS-t írunk.)
--
https://naszta.hu