Zawiesza się bootowanie z USB

[pavbaranov]

Obraz live (na 99,99%), zajmujący 600 coś mega, wrzuciłem na dysk zewnętrzny USB i z tego teraz próbuję odpalić.

Ok. Mam rozumieć: liveiso przekopiowałem na zewnętrzny dysk USB? Da się i z czegoś takiego wystartować system, ale w takim razie:
- jakiego programu rozruchowego dla tego zewnętrznego dysku używasz?
- jak go przygotowałeś? (podaj konfigurację)
- nadałeś temu dyskowi flagę boot?
Innymi słowy: zamiast od Ciebie wyciągać lepiej napisz co robisz krok po kroku i jak od chwili ściągnięcia obrazu ISO do chwili, w której próbujesz komputer z dysku (obojętne co to jest) z tym obrazem wystartować.

[micdnj]

Panowie, (jak wnioskuję po nickach)

Jeden obraz wart jest więcej niż 1000 słów. Poniżej katalog dropbox z filmami pokazującymi w jaki sposób wgrywam obraz na zewnętrzny dysk HDD przez USB, z którego później bootuję system (GPT wybrane przykładowo).
https://www.dropbox.com/sh/g697akz14fudxdh/AABqhFeYRWVYJLar21cyPq0Ja?dl=0

Drugi z filmów pokazuje jak z dysku bootuje mi się stary komputer, a od 1:21 jak nowy. Nie wiem, czy będę w stanie odpowiedzieć na jakieś pytania których nie można wywnioskować z tych filmów.
MD5 mojego obrazu:
? md5sum.exe archlinux-2019.11.01-x86_64.iso
d466c5512dd717ca2d0eca3e23d2de7b *archlinux-2019.11.01-x86_64.iso

Inna sprawa - jak dobrze jesteś obeznany z linuksem? Arch nie jest dystrybucją dla nowicjuszy i on nie ma swojego instalatora. Obraz liveiso uruchamia się i wszystko potem trzeba zrobić ręcznie, posiłkując się podręcznikiem instalacji. Alternatywą jest np. anarchy linux, który jest po prostu instalatorem Archa

Instalowałem już archa na poprzednim kompie, doszedłem do wersji konsolowej. Ale przy problemach z X-ami trochę  mi się odechciało:) Zainstalowałem Anarchy i tak docelowo zamierzam. Problem bootowania chciałem pokazać na podstawowym środowisku.

Dobrałeś właściwą architekturę dla Twojego komputera?

Jeśli są inne możliwości wyboru niż 32/64 bitowe, to nie wiem, nie znam się. Arch jest tylko na wersję 64 bitową z tego co się zorientowałem.

i czy on pozwala na uruchomienie systemu z live usb. Podobno są już takie wynalazki od Billa Gatesa, które to blokują.

FreeDos z live usb uruchamia się.

Jeśli czujesz się na siłach - i masz takie możliwości - to możesz rozważyć instalację w trybie netboot:

Poczytam, rozważę.

A mógłbym prosić jeszcze o wyjaśnienie? Co to jest intel-ucode i jak to ma się do live iso? To się tam wgrywa? I tak w przypadku każdego producenta sprzętu trzeba robić? Jest jakiś firmware BIOSu i nie-BIOSu? Update który ostatnio robiłem z poziomu BIOS, przeze mnie i potocznie nazywany updatem BIOSu, to był właśnie update firmware BIOS czy czegoś innego?

Wielkie dzięki za takie zaangażowanie w pomoc:)

[EDIT]
Jak piszę bzdury poniżej, to poprawiajcie.
Spróbowałem dodać netboot w wersji UEFI do tego zewnętrznego dysku, korzystając z Archa na starym kompie. Przy wywołaniu komendy efibootmgr otrzymuję komunikat "EFI variables are not supported on this system".

[pavbaranov]

Jeszcze gdyby te filmiki jakoś czytelne były i choćby choć trochę ostre... Jeśli już coś takiego robisz, to przygotuj je jakimś programem do rejestracji pulpitu, a nie kręć komórką.
I nie - filmiki nie są w żaden sposób lepsze, albowiem ciężko potem się do nich odnosić i uzgodnić o co chodzi. Stopklatkami się mamy posługiwać?
Linux mocno nie lubi być przygotowywany w inny sposób niż to osoby przygotowujące obraz sobie wymyśliły. Zwykle jest to opisane na stronie jak to zrobić. Zrób zatem w sposób przewidziany w danej dystrybucji, w tym jeśli to jest wypalane rufusem, to należy w nim użyć opcji odpowiadającej poleceniu dd i dopiero z tak przygotowanego dysku wystartuj (uwaga: średnio opłaca się do tego używać zewnętrznego dysku, lepiej coś zdecydowanie tańszego).

Ucode to tzw. mikrokod dostarczany przez producenta czegoś; w tym przypadku przez Intela dla określonego CPU i GPU: https://www.archlinux.org/packages/extra/any/intel-ucode/ i https://wiki.archlinux.org/index.php/Microcode

[TataPingu]

A mógłbym prosić jeszcze o wyjaśnienie? Co to jest intel-ucode i jak to ma się do live iso? To się tam wgrywa? I tak w przypadku każdego producenta sprzętu trzeba robić? Jest jakiś firmware BIOSu i nie-BIOSu? Update który ostatnio robiłem z poziomu BIOS, przeze mnie i potocznie nazywany updatem BIOSu, to był właśnie update firmware BIOS czy czegoś innego?

To bardzo szeroki temat, na pewno w kilku zdaniach nie da się tego wyjaśnić...
Poniżej masz kilka materiałów na temat tego szajsu UEFI:

Kod [Zaznacz] Rozwiń

http://www.uefi.org/sites/default/files/resources/Brian_Richardson_Intel_Final.pdf

Kod [Zaznacz] Rozwiń

http://www.uefi.org/sites/default/files/resources/UPFS11_P4_UEFI_GOP_AMD.pdf

Kod [Zaznacz] Rozwiń

https://www.anandtech.com/show/12068/intel-to-remove-bios-support-from-uefi-by-2020

Kod [Zaznacz] Rozwiń

https://www.guru3d.com/news-story/intel-halts-certain-uefi-bios-class-level-2-compatibility-modes-in-2020.html

Zresztą, w którymś miejscu tu na forum pisałem już na ten temat...

Jedno jest pewne, w starych (tzw. "Legacy-BIOS"), nie było żadnego problemu z update biosu.
BIOS to był czip w postaci EPROM, a później tzw flash, osadzony na płycie. Zadaniem jego było jedynie udostępnić wszystkie interfejsy podczas startu sprzętu.
Oczywiście, było tam oprogramowanie (assembler), ale "dostęp" do niego był właściwie zamknięty.
OK, sprzęty są coraz bardziej skomplikowane, więc, aby dobrze "chodziły" trzeba by było "rozbudować" oprogramowanie BIOSu. Taką "przejściówką" były/są tzw. "sterowniki". BIOS udostępniał interfejs sprzętu, a sterownik go "uzupełniał" (pełna funkcjonalność).

Z biegiem czasu (i rozwojem branży), zaczęto tworzyć tzw. firmware. Właściwie to nic innego, jak wcześniejszy assembler w czipie plus sterownik.
Obecnie, producenci hardware tworzą firmware praktycznie do każdego swojego produktu.

Nie byłoby w tym nic złego, tylko...
- co poniektórym "umyśliło się", że byłoby fajnie ich firmware zdalnie updateować...
No i w ten sposób narobiono "dziur" (proszę wziąść pod uwagę wcześniejsze legacy - te były "z zewnątrz" zupełnie niedostępne)

Oczywiście spółka "Win-Tel i inni (NSA itp)" dostrzegli w tym sposób na dojście (zdalne) do sprzętu. Ze względów "bezpieczeństwa", wymyślono UEFI i zaczęto manipulować/preparować BIOSy ("firmware")...

A dlaczego rozpisuję się tak o tym ?
Ano dlatego, by w końcu dojść do odpowiedzi na Twoje pytania...
- jak widzisz, co Ty updatowałeś, nie jesteśmy w stanie odpowiedzieć...

W dzisziejszych sprzętach, szczególnie w tak przygotowanych, jak HP o którego pytasz (sprzęt + OS), firmware składać się może z większej części modułów...
Szczególnie niepewne są zmiany (update) firmware w których M$ zintegrował kody swoich kluczy do swojego badziewia...
- klucz powiązany jest częściowo z numerami (ale którymi !?) pewnych komponentów hardware (jakich, procesor, matheboard !?)

W takim przypadku, po update, klucz "znika" i okazuje się, że na tym sprzęcie nie zainstalujesz już legalnie kupionej wersji windowsa...

A co tam jeszcze inni pointegrowali (HP, Intel), to jedynie producent sprzętu jest w stanie odpowiedzieć...

To tak tylko, dla rozwagi, jeśli chodzi o najnowsze sprzęty i update...

[micdnj]

No niestety, sprzęt do nagrywania mam jaki mam. Na przyszłość zostanę przy tradycyjnych mediach:)

Podsumowując (przy założeniu że poprawnie robię LiveUSB):
1. Kwestia może być firmware'u. Problem może sam się rozwiązać przy którymś update BIOS lub nowej wersji Linuxa
2. Mogę wrzucić problem w świat, może ktoś jeszcze się z czymś takim spotkał i rozwiązał w inny sposób niż update firmware
3. Na moim sprzęcie nigdy nie będzie działać Linux, i wtedy:
  - odpuścić sobie Linuxa, albo
  - wymienić ten sprzęt na np. Fujitsu, czego bym nie chciał robić

[pavbaranov]

No właśnie... przy okazji: jak przygotowujesz tego liveusb?
Z innej pary kaloszy - rozumiem, że na tym komputerze masz jakiś system. Spróbuj postawić tam VB, ściągnąć dowolny VDI np. stąd: https://www.osboxes.org/virtualbox-images/ i odpalić. Może do czegoś nas to zbliży.

EDIT:
Jeszcze jedna myśl. Czy masz dostęp do jakiegokolwiek komputera, na którym chodzi dowolny linux? Jeśli tak (lub nie, ale o tym za chwilę), to wracamy do początku:
1. Ściągnij dowolne liveiso.
2. Przy włożonym pendrive wykonaj:

Kod [Zaznacz] Rozwiń

sudo dd if=/ścieżka/do/liveiso of=/dev/sdX bs=4M && sync
gdzie X to jest litera, a...z pod którą komputer widzi Ci pendrive; przy jednym dysku winna to być litera b, a zatem sdb.
3. Z tak przygotowanego systemu wystartuj HP.
Jeśli nie masz, a masz Windows, to użyj narzędzia np. https://www.balena.io/etcher/ lub - bo chyba używasz rufus - wybierz w nim ów drugi sposób tworzenia liveusb (nie mam Windows, nie używam Rufus, wiem jedynie, że coś takiego tam występuje, a zatem sprawdź opcje, ewentualnie gdzieś dopytaj; chodzi o to, by Rufus wykonał kopiowanie liveiso w sposób analogiczny do polecenia dd w linux).

W sumie możesz również sprawdzić nie tylko Ubuntu (Twojego HP nie ma na liście "certyfikowanego" sprzętu przez Canonical) i Archa, ale spróbować nawet - mimo że wcześniejsze - Anarchy. Dodatkowo - z mojego doświadczenia wynika, że dość dobrze komputery HP "porozumiewały się" z RHEL/CentOS ew. Fedora oraz SUSE (SLED/S, OpenSUSE). Może wypróbuj również je? Jeśli problem nie leży po stronie nieszczęsnego BIOSu HP (i ewentualnej konieczności jego aktualizacji), to jeśli żadna opcja się nie uda, to albo zrób remaster ISO Archa z najnowszym intel-ucode, albo poczekaj jeszcze kilka dni na wydanie grudniowe obrazu Archa, bo tam już ono będzie.

Rozumiem również, że żadne sztuczki typu noacpi, nomodeset itp. itd. przekazywane kernelowi podczas startu z tego liveiso nie udają się. Próbowałeś w ogóle?

[ciubaka]

Kolega pisze że ma W10. To niech kolega ściągnie program Rufus, obraz Fedory 31 w wersji podstawowej, czyli niestety Gnome. I wypali na penie Rufusem tą Fedorę. I spróbuje uruchomić z pena, a jak pójdzie to zainstalować. Skoro Paweł pisze, że Fedora się lubi z HP to wie co pisze. A wersja 31 jest świeżutka, sprzed dwóch tygodni, nic nowszego raczej nie będzie dla tej maszyny. I instaluje się łatwo, i powinna do W10 też prosto się doinstalować. I w sumie to przyjazny system, jak już się ogarnie jej narowy i przyzwyczai do zasobożerności RAM. Ale dla tego komputera to nie będzie problem :-)

[pavbaranov]

@ciubaka - Fedora to nie tylko GNOME. Ma swoich kilka spinów.

[micdnj]

Wczoraj próbowałem z Fedorą i też nic. Ale spróbuję jeszcze raz, instalując komendą dd pod linuxem i opiszę proces. Jak by co to mam też cygwina zainstalowanego, gdzie też jest komenda dd.

Rozumiem również, że żadne sztuczki typu noacpi, nomodeset itp. itd. przekazywane kernelowi podczas startu z tego liveiso nie udają się. Próbowałeś w ogóle?

Musiałem wstawić acpi=off, bo inaczej błąd (typowy z tego co widzę) związany z ACPI się pojawiał. Próbowałem jeszcze inne parametry wylistowane w wątku związanym z tym błędem i tylko ten powodował jego usunięcie. Nomodeset i innych sztuczek nie znam i nie stosowałem.

[ciubaka]

ale spiny to wersje społecznościowe oparte o oryginał fedory i sam wiesz, że lepiej spróbować gnome, bo na nim fedora ma wszystko, a na spinach już niekoniecznie
moja fedora mate jest taka jaka jest i tyle :-)
więc testowo niech postawi wersję główną lepiej, potem sobie zmieni jak zechce
nie podziałało - znaczy kupa :-(

[pavbaranov]

@micdnj - Ok, bo już nie łapię. To, co opisujesz jest z acpi=off, czy nie? Z acpi=off udało Ci się odpalić?

[micdnj]

Pierwszym problemem jaki napotkałem był błąd jak z tego wątku:
https://www.linuxquestions.org/questions/bodhi-92/acpi-error-%5Bcapb%5D-namespace-lookup-failure-ae-already-exists-when-attempting-to-install-bohdi-on-asus-aspire-one-zg5-4175659775/


Po wpisaniu acpi=off błąd zniknął, ale bootowanie się wiesza (w przypadku Archa). W przypadku innych niektórych linuxów pojawia się komunikat Kernel Panic i bootowanie się wiesza.

Wszystkie próby które opisuję są z acpi=off.

Zainstalowałem na VB Archa spod linka którego wskazałeś i działa.

[EDIT]
Ale mam taki komunikat podczas bootowania:
systemd-modules-load.service        loaded failed failed    Load Kernel Modules

[robson75]

Zauważyłem że wersje Anarchy od 1.0.7 do 1.0.8 podczas bootowania mają taki oto błąd

Kod [Zaznacz] Rozwiń

failed systemd-boot-system-token.service
Jest to związane z UEFI.
Ale wersja 1.0.6 tego błędu nie ma.

[pavbaranov]

Ok, spróbuj zatem wywalić to acpi=off ze startowych i zamiast niego ustawić którąś ze zmiennych z tego poradnika: https://wiki.archlinux.org/index.php/DSDT. Jeśli sama nie pomoże, to wypróbuj również z tym acpi=off. Spośród DSDT próbuj różnych.

@robson75 - Czy to o czym piszesz jest jakoś związane z problemem @micdnj?

[robson75]

@pavbaranov Zasugerowałem się tym wpisem przez autora.

Ale mam taki komunikat podczas bootowania:
systemd-modules-load.service        loaded failed failed    Load Kernel Modules