Pan Chalupa by mohl (a snad i měl) uvést, že problém nastává na počítačích HP, a to z toho důvodu, že instalovali počítače s procesory Intel a AMD ze stejného image. Na počítačích pak skončil driver Intelppm.sys, který na počítačích s procesory AMD nemá co dělat. Po instalaci SP to pak dopadne špatně. Ten samý problém způsobili někteří výrobci již v minulosti, kdy došlo ke stejnému problému po XP SP2. Řešením problému je reboot v safe mode, a změna jedné hodnoty v Registry (linuxáci jsou na podobné zásahy dobře zvyklí).
Daleko jednodušší, než napsat objektivní zprávičku, je navážet se od "odladění SP3". Autor by se měl stydět. Naštěstí čtenáři již vědí, že internetová "žurnalistika", natož zprávičky na root.cz, má kvality více než pochybné.
Dejte si přes hubu sám, až třeba budete bootovat do konzole, a a hrabat se v parametrech. Nebo obecně než se budete hrabat v hromadě logů a konfiguráků. OK?
Jakýkoli ovladač má při zavedení zkontrolovat, jestli je ovládané zařízení přítomné, a pokud není, tak se nezavést (případně vypsat nějakou chybu, ale rozhodně ne shodit počítač). Chybu tam udělali vývojáři Microsoftu, že tento test pokazili (před tím service packem nejspíš fungoval správně).
To bohužel není možné vždy zajistit. Sám jistě víte o případech, kdy takovou věc ani teoreticky zjistit nelze.
Faktem zůstává, že instalaci zmršili pánové v HP. Není jobem výrobce OS, aby odpovídal za jakoukoliv kombinaci souborů, kterou někdo jiný namíchá na disk. Nebo myslíte, že ano?
To, že není možné detekovat přítomnost zařízení, platí pro ISA zařízení bez PNP. Např. není možné detekovat přítomnost starého řadiče paralelního portu (bez EPP nebo ECP), protože řadič paralelního portu, ke kterému není nic připojeno, se chová, jako kdyby tam žádný řadič nebyl --- vrací na všech portech 0xff. Podobně je to s řadičem IDE na ISA, ten taky nejde detekovat, pokud k němu není nic připojeno.
Až na tyhle obskurní případy (v dnešních počítačích se ISA stejně nenachází) se zařízení detekovat dají. Např. procesor má na detekci instrukci CPUID. Takže ji lidé z MS zapomněli použít.
"Není jobem výrobce OS, aby odpovídal za jakoukoliv kombinaci souborů, kterou někdo jiný namíchá na disk. Nebo myslíte, že ano?"
Pokud si uživatel vymění v počítači grafickou kartu, zvukovou kartu apod., tak by ovladače starého zařízení určitě měly poznat, že není přítomno, a neměly by shodit systém. S výměnou procesoru je to podobné, až na to, že uživatelé si běžně procesory tak často nevyměňují --- takže se ta chyba projevila jen v tomto konkrétním případě s HP.
Nejspíš by se našly i jiné případy, kdy to spadne (např. pokud uživatel vyjme procesor Intel a strčí tam jiný procesor Intel, který intelppm.sys nepodporuje).
Na prvním místě OS ten driver nenainstaluje, pokud zařízení neexistuje. Na druhém místě u nástroje Sysprep (který se na hromadné instalace používá) je jasně řečeno, že image musí být určen pro cílový typu CPU, jinak je to špatně. Tím je dořešeno, chyba je na straně HP.
Jestli driver způsobí chybu, nebo je required a zároveň odpadne kvůli neexistujícímu HW, to fakt netuším, a ve světle výše uvedeného je to naprosto jedno. Běžnými způsoby by driver nebyl nainstalován. Když jsme u instrukce CPUID, tak tu pánové z MS zjevně použili, viz třeba detekce mechanismu syscallu prováděná při bootu (int 2e nebo sysenter/syscall).
Samozřejmě změnu HW by měl OS poznat, a korektně obsloužit (tak jako Windows obslouží změnu grafické karty - neskončí na command line s chybovou hláškou). Typ CPU (AMD/Intel) ale fakticky měnit nemůžete, a typ HALu (legacy/ACPI) měnit nesmíte.
Jestli by se našly jiné případy, sem s nimi. Já tvrdím, že problém je jednoznačně na straně HP. Instalace byla provedena v rozporu s dokumentací nástroje Sysprep. Společnost HP měla tento problém už u SP2, a nic s tím od té doby neudělali.
Když jsme u toho, pokud si na Linuxu natáhnete kernelový modul pro neexistující HW (ovšem máte jiný HW jemu podobný), a dojde k pádu OS, můžete si za to sám, nebo je to chyba kernelového modulu?