Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - jauznevimco

Stran: [1] 2 3 ... 11
1
Software / Re:Bootování iPXE s aktivním Secure Bootem
« kdy: 29. 11. 2025, 13:02:11 »
mozna to je zrejmy ale vis ze audit mode dela presne tohle a ty bys cekal asi deployed mode? (nastaveni secure bootu)
Nene, ja to zkousel na desce od MSI - a UEFI od MSIcka bylo toho casu defaultne nastaveno tak, spoustelo i veci nepodepsane.
V novejsich BIOSech (2023+) pridali menu Image Execution Policy, kde clovek muze menit Always Execute vs Deny Execute nepodepsanych veci, avsak tahle moje deska mela posledni BIOS vyrazne starsi.

Krasny haluze, co clovek obcas potka. :-)

https://us.msi.com/blog/statement-on-secure-boot


Oba stroje jsou schopne nabootovat fedoru s nfsroot pomoci dhcp -> tftp/shim ->tftp/grub -> tftp/vmlinuz+initrd -> dhcp -> nfsroot
Dekuji prevelice za detailni info! Tohle zni jako dobra zprava. V tydnu to prubnu.


Takze si myslim, ze ten podepsanej ipxe od toho broadcomu muze spoustet pouze veci podepsane broadcomem.
A to fedora kernel asi neni.
Z toho, co jsem se docetl, je pro Linux se Secure Bootem typicky potreba:
[v mem pripade navic] podepsany ipxe (ten od Broadcomu je podepsany od Microsoft Windows UEFI Driver Publisher) => ten dokaze natahnout podepsany shim (rovnez podepsany od Microsoft Windows UEFI Driver Publisher, tj. pokud masina nabootuje podepsany ipxe, nutne musi umet nabootovat i tento shim) => podepsany grub (podepsany od Debian Secure Boot Signer 2022 - grub2) => vmlinuz (podepsany od Debian Secure Boot Signer 2022 - linux).


Cili MS-podepsany shim zajistuje podporu/"znalost" tech debianich podpisu v dalsich fazich.

A nakolik je shim podepsany, jeho chovani je takove, ze hleda grubx64.efi v "aktualnim umisteni" (a s HTTP delat neumi), takze bez obezlicky v podobe TFTP prave pro shim a grub se nehnu.


Proti tomu pokus o boot primo grubu nebo vmlinuz selze, protoze defaultni klice pro Secure Boot neznaji Debiani podpisy.


Takhle mi to nejak dava smysl a odpovida to i vysledkum tohodle pokusu.


Jeste jednou dekuji.

2
Software / Re:Bootování iPXE s aktivním Secure Bootem
« kdy: 26. 11. 2025, 08:16:39 »
Tak jo, rozbehnout boot do Linuxu z iPXE mi slo, diky za doplneni...

Narazil jsem ale na celkem vtipny zadrhel. A sice, ze vsechen "uspech", co jsem mel s domnele zaplym SecureBootem, jsem testoval na zeleze, ktery ma SB implemetaci docista zprasenou a bez problemu spousti i veci nepodepsane.  :o


Cili patrne se bez shimu a grubu neobejdu, pricemz je to vzhledem k pouzite podepsane ipxe binarce trosku past, nakolik tato binarka nezna prikaz shim...


A pokud natahnu shimx64.efi jako kernel, tak si zacne zit trosku svym zivotem - a at tam zadam cokoliv, zacina sahat po TFTP a zkousi hledat grubx64.efi


Samo, muzu delat tak, jak si shim piskne, tj. dodat grubx64.efi a jeho config na TFTP, ale nevadilo by mi se bez toho obejit.


Grok mi dal celkem zajimave znejici workaround v podobe natroubeni vseho potrebneho (grub, vmlinuz, initrd) do virtualniho disku (wimboot), procez by se tento mohl natahnout lokalne a nezkouset sahat do TFTP.

No nic, prubnu to.

3
Videl jsem na vlastni bulvy totez.

Heslo zarucene spravne / vyresetovane. Psane na on-screen klabosnici, heslo zobrazene pred odeslanim - ano, je spravne, akorat, ze neni.

Prihlasi se jinej user a zkusi "run as" user puvodni .... heslo to sezere na prvni dobrou.

OK, nahradni user se odhlasi a ten problematickej se zkusi prihlasit znovu... ne.

Vlastne uz nevim, co bylo reseni. Snad zadani kompletne celyho prihlaseni pres kolonku Other user.

Strasna haluz. Takze ne, nehrabe vam... deje se to.

4
Bazar / Re:Prodám monitor 43" 3840×1200 100 Hz
« kdy: 16. 11. 2025, 14:52:40 »
Anekdoticky...

Dell 2007FP, rv 2007? ... loni odeslo podsviceni. Vymenen za QHD 27 ultrasharp za bratru 4-5k, kdy byl jeste ctvrtrok v zaruce.
NEC 200NX, rv 2007?, koupen cca 2011 za vcelku smesny peniz... spokojene si dudla dodnes


V kanclu mame 400+ prevazne levnych Lenovo ThinkVision (6-bit IPS, 22-24"), za osm let klekly dva, o mrtvych (sub)pixelech nevim z jedinyho z nich...


Co to safra kupujete, ze to nic nevydrzi?  :o

5
Software / Re:Bootování iPXE s aktivním Secure Bootem
« kdy: 27. 10. 2025, 15:20:18 »
Mountnout v diskless Linuxu rootfs z NFS... to už přece není záležitost bootloaderu (iPXE), ale distra. Může to udělat kernel rovnou, nebo to udělá něco v initrd.

Pro natahnuti kernelu a initramdisku v iPXE funguje krasne HTTP, tak bych pouzil to. Samotny rootfs uz mountuje kernel, takze tam NFS klidne muze zustat.
Jeee... no jasne, tak moc jsem se soustredil na to, ze podepsany iPXE NFS neumi, takze s NFS "radsi nepocitat nikde" NFS sem, NFS tam, az mi v tom tenhleten fakt uplne zapadnul...


Samo, kernel a initrd taham pres http. Na problemy jsem narazel v pripade, kdy mel kernel dal natahnout rootfs z filesystem.squashfs pres http - tehdy ani nedochazelo k pokusum o natahnuti adresy z DHCP.
Coz, kdyz na to koukam, dava docela smysl, pac image, co jsem zkousel, sice umi squashfs a nfs, ale neumi httpfs...


Diky za nakopnuti!

6
Software / Bootování iPXE s aktivním Secure Bootem
« kdy: 25. 10. 2025, 21:28:30 »
Dobry vecer,


donedavna jsem mel funkcni postarsi live Ubuntu, ktere slo bootovat z EFI a fungovalo mi to i z iPXE (za predpokladu vypnuteho Secure Bootu a iPXE zkompilovaneho s podporou NFS, aby slo nejak sahat na rootfs).

Par let jsem to nesledoval a koukam, ze najednou existuje iPXE i s podporou Secure Bootu - avsak, aby to MS podepsal, musela byt vyrazena podpora NFS.
https://knowledge.broadcom.com/external/article/280113/updated-64bit-ipxeefi-ipxe-v1211-binarie.html

V podstate staci jen dodat iPXE menu na adrese:
http://[Boot-Server-IP]:4433/Altiris/iPXE/GetPxeScript.aspx


A krasne to funguje treba s wimbootem pro boot do jakychkoliv winblowsich WIM, nebo treba pro memtest, potud super.


Kdyz uz se v tom babram, rad bych tam rozbehnul treba nejaky aktualni live distro (celkem jedno, jake - hlavne, at to umi sahat na aktualni zelezo... treba zivy Ubuntu nebo Debian jsou fpoho), pricemz rootfs bych natahoval pres http.
A idealne tak, aby to dokazalo schroustat i s tim slavnym Secure Bootem.


Zatim jsem ale nenatrefil na spolehlivej zpusob, jak toho docilit.



Tento postup je 9 let stary a jakkoliv mi fungoval s tim prehistorickym Ubuntu, na aktualnim live image to vzdy ztroskota na nemoznostni natahnout rootfs.
https://github.com/live-httpboot/ubuntu-live-httpboot



Plus jeste se vlastne nabizi tema... jak je to s tim Secure Bootem samotnym?

Bez problemu muzu udelat treba tohle:
kernel http://server.home.arpa:8081/debian/vmlinuz
initrd http://server.home.arpa:8081/debian/initrd.img
plus prislusne imgargs (nichz jsem jeste neodhalil spravnou kombinaci)

A kernel zacne bootovat, iPXE nevrati zadny "Exec file error" jako v pripade, kdy by kernel nebyl podepsany.



Nicmene, v ruznych clancich tykajicich se Secure Bootu a Linuxu jsem zahlednul ruzne zminky o bootovani ve smyslu:
EFI > shim (podepsany, vytahly z toho distra) > grub (totez) > kernel ...


Mozna na to jdu teda uplne spatne a z iPXE bych mel tahat toliko shim a grub a boot parametry pro natahnuti rootfs z http resit az pres grub?


Vim, ze existuje netboot.xyz, ale to stavi vsechno na nepodepsanem iPXE a k jejich (upravenym?) live imagum se mi nepodarilo dohledat...


Zkousel nekdo neco takovyho?



Diky.

7
Hardware / Re:Ochrana koženky
« kdy: 22. 09. 2025, 21:46:50 »
Preventivni ochranu kozenky jsem neresil, po jejich doziti jsem provedl nahradu nausniku aftermatker materialem pokrytym nejakou latkou - narozdil od kozenky to celkem i luftuje, takze v tom pres leto nejsou usi uplne zapareny.
Vlastne skoda, ze to s tou latkovinou vyrobce nedodaval rovnou, komfort je o parnik jinde.

Cili doporucuju se spis mrknout po aftermarket dilech (vc. ebay), na velkym mnozstvi (tuplem v kategorii nejakych lepsich) sluchatek to urcite bude k sehnani.

8
Vlastne jeste nez se dostanu k veci, zminim jednu vec.
Primo tady MS uvadi, ze pokud jsou wokna uz aktivovany (klicem / z HW) a uzivatel se prihlasi do MS uctu (nebo si jej vytvori), stane se klic soucasti jeho MS uctu a skrze tento MS ucet bude mozno reaktivovat i na jinem zeleze (treba po vymene klekle desky za jinou v ramci reklamace), technicky vzato tedy i na pripadne VM...
https://support.microsoft.com/en-us/windows/activate-windows-c39005d4-95ee-b91e-b399-2820fda32227


To jen, kdybyste chteli zkusit snazsi cestu naservirovanou primo z MS :-)




To by bolo OK, ale momentalne nemam programator na dump biosu a neviem ci by sa mi do toho chcelo.
To neni vubec potreba, vse potrebne si vytahnes pres dmidecode a /sys/firmware/acpi/tables/
 

V mem pripade bylo potreba tohle:

Kód: [Vybrat]
dmidecode | grep -A8 'System Information' > ~/gigabyte_sysinfo.txtobsah zhruba takovy (klicove udaje pro aktivaci: Serial number a UUID):
Kód: [Vybrat]
System Information
        Manufacturer: Wortmann_AG
        Product Name: TERRA_PC
        Version: Default string
        Serial Number: yololololo
        UUID: yaddayadda
        Wake-up Type: Power Switch
        SKU Number: Default string
        Family: Default string

Jako dalsi nutny obsah, ktery bylo potreba te VM podstrcit, bylo tohle:
Kód: [Vybrat]
cat /sys/firmware/acpi/tables/SLIC > ~/gigabyte_slic_table

Naopak navzdory ocekavanim (vzdyt to prece obsahuje samotnej klic) nebylo potreba tohle:
Kód: [Vybrat]
cat /sys/firmware/acpi/tables/MSDM > ~/gigabyte_MSDMobsah zhruba takovy:
Kód: [Vybrat]
MSDMU7WORTMAWORTMANN     AMI blablabla-windows-product-key


Jak jsem uvadel v predchozim postu, potrebne soubory se muzou lisit v zavislosti na konkretni desce a OEM. Na vlastni bulvy jsem videl treba i desku, kde se mnou ciste nainstalovane Windows zcela neomylne aktivovaly "digitalni licenci", aniz bych vubec dokazal Product Key v SLIC najit... proste tam nebyl, ale vsechno koser, i na fakture.



V XML virtualky to pak vypada nasledne:

Vytvorit sekci sysinfo a precpat tam data z dmidecode:
Kód: [Vybrat]
  <sysinfo type="smbios">
    <system>
      <entry name="manufacturer">Wortmann_AG</entry>
      <entry name="product">TERRA_PC</entry>
      <entry name="version">Default string</entry>
      <entry name="serial">yololololo</entry>
      <entry name="uuid">yaddayadda</entry>
    </system>
    <baseBoard>
      <entry name="version">Default string</entry>
      <entry name="serial">yololololo</entry>
    </baseBoard>
  </sysinfo>


+

nutno doplnit ACPI tabulku a odkazat na SMBIOS data v sekci OS:

Kód: [Vybrat]
  <os firmware="efi">
    <type arch="x86_64" machine="pc-q35-8.2">hvm</type>
    <firmware>
      <feature enabled="yes" name="enrolled-keys"/>
      <feature enabled="yes" name="secure-boot"/>
    </firmware>
    <loader readonly="yes" secure="yes" type="pflash">/usr/share/OVMF/OVMF_CODE_4M.ms.fd</loader>
    <nvram template="/usr/share/OVMF/OVMF_VARS_4M.ms.fd">/var/lib/libvirt/qemu/nvram/win10_VARS.fd</nvram>
    <acpi>
      <table type="slic">/var/lib/libvirt/images/gigabyte_MSDM</table>
    </acpi>
    <boot dev="hd"/>
    <smbios mode="sysinfo"/>
  </os>

9
Licenci na winblows HW do KVM pres libvirt jsem uspesne dostal.

Univerzalni postup neexistuje, zalezi na konkretni implementaci v te ci one desce (treba u Dellich masin mi nefungovalo to, co slape na OEM desce od Gigabyte).

Michal Smucr ma v principu spravny postup.

Je potreba vycucnout SMBIOS, ACPI a to do KVM propasovat.
Nenechte se vsak zmast vytahnutim seriovyho cisla, to nakonec v mem pripade ani nebylo potrebne, pac probehla digitalni aktivace dle toho SMBIOS a ACPI otisku...

Vecer zkusim dodat primo nastaveni, jaky soubory a kam jsem do KVM musel nacpat.

10
IMO se tu plete vic veci dohromady a dotaz smeruje asi primarne k HTTP bootu samotnemu (co je preferovana varianta treba na Dellich notasech z doby tak 3 roky zpatky a novejsich).



Obecne v principu je to tak, jak pisou panove vejs...
V ramci DHCP requestu se resi, co poslat za boot file, melo by to byt nejak takto - vycucnuto z dnsmasq konfiguraku a okomentovano:

Kód: [Vybrat]
#legacy-BIOS PXE boot >> pro tuhle Arch se bootujici klient nasmeruje na TFTP boot-file name odpovidajici te architekture, prikladmo undionly.kpxe jako bootloader
PXEClient:Arch:00000

#UEFI x86 >> tady se posle jako odpoved .efi binarka z prislusneho tftp boot-file, ovsem zkompilovana pro 32-bit (v praxi se vyskytuje jen u nejakych prehistorickych obskurnich notasu a netbooku s 64-bit Atomem, ktery ovsem maji jen 32-bit UEFI)
PXEClient:Arch:00007

#UEFI x64 >> dnes nejcastejsi varianta, ocekava se 64-bit .efi binarka, opet z tftp boot-file
PXEClient:Arch:00009

#http boot x86-64 EFI >> a tentyz soubor lze poskytnout i z http boot file...
HTTPClientArch:00016


ad embed iPXE skriptu primo do binarky - drive to byla temer nutnost, aktualni verze iPXE automaticky saha po souboru "autoexec.ipxe" v root tftp slozce, takze pakarna odpada. :-)

Schvalne k tomu jeste neco malo dohledavam a koukam, ze iPXE uz konecne existuje i v SecureBoot-signed variante... sice ficurove osekane (treba neumi NFS boot), ale k sehnani to je...
https://hannan.au/posts/pxe/

11
Software / Re:Sdílená grafika s video výstupy pod VM
« kdy: 07. 09. 2025, 12:19:49 »
Ano, myslel jsem to tak, ze 3D akceleraci by stale zajistovala nVidia, u niz rozumim, ze nejaky rozparcelovani mezi VM guests je mozne (? - neco takoveho jsem zkousel jen s Inteli GPU pres MDEV a ackoliv to fungovalo, vykon byl zcela zoufaly, treba to je u nV zmaknuto lepe), pricemz onen DisplayLink by zajistoval ciste ten obrazovej vystup.


Obdobny postup uvazuju pro Davinci Resolve - grafiky se spoustou VRAM jsou drahe, takze uvazuju nejakou vypocetni nVidii bez vystupu a tyto suplovat prave DisplayLinkem (nebo RDP ... prekvapive to wokenni RDP pres domaci LAN je vyborne pouzitelne, obcas je videt naznak komprese, ale vse pekne plynule).
Na funkci to nema vliv, pokud neco potrebuje vyuzit CUDA/OpenCL, ma tu moznost.

12
Software / Re:Sdílená grafika s video výstupy pod VM
« kdy: 06. 09. 2025, 14:50:26 »
A co obezlicka skrze DisplayLink?


USB passthrough nejake DisplayLinkove dokiny do kazde z prislusnych VM a jedem, zcela nezavisle na tom, co nVidia umozni...? Pripadne, z pohledu KVM "cistejsi" reseni je PCI passthrough celyho USBckovyho radice do VM, pokud jich teda deska nabizi dostatek.


Omezeni - dopad na vykon (vysoka rezie), za nekterych okolnosti potencialne viditelne znamky komprese. Treba aspon nejaky scenar by to pokryt mohlo?

13
Hardware / Re:Odkoupení firemního notebooku Dell
« kdy: 02. 09. 2025, 21:14:44 »
Firma by měla postupovat s péčí řádného hospodáře. Takže by to měla prodávat za stejnou cenu, za jakou to vykoupí bazár. Pokud se to má prodat zaměstnacnům za méně, tak to musí někdo rozhodnout a nést za to odpovědnost před majitelem.
Mejme varku par desitek notasu k vyrazeni... nekde je nejaka ta kosmetika, ruzny stupne opotrebeni baterky/disku/..., nekdy nkde nefunguje port a kdesi cosi.
Individualni cenu pro kazdej kus a dohadovani se o par stovek jednim nebo druhym smerem nikdo resit nebude, proste se to na tu varku nak zprumeruje a nazdar.

Slysel jsem od ucetni, ze spravne by se melo prodavat za "cenu obvyklou", prave i s ohledem na stav a opotrebeni, ale v praxi, tuplem pokud prodej zeleza neni primarni cinnosti zamestnavatele, to nikdo prilis nehroti - tuplem pokud je jasne, ze to zelezo uz nikdo pro pracovni ucely neuzije.

No a kde tu "cenu obvyklou" vlastne vzit?
Ceny na bazosi / ebay jsou ceny, kolik by za to clovek rad dostal; ovsem jestli to za tu cenu i nekdo koupi? :-) Cili kdyz uz, je treba vychazet treba z ukoncenych aukci na ebay / leboncoin, kde se clovek dostane k cislum, ktera jsou trosku bliz k realite.

Takze se vezme nejaka bezna prodejni cena, k tomu nejaka bulharska konstanta podle stari zeleza a vetsinou to vyjde treba do 5kKc bez dane.


Jinak stran prodeje a zaruky - coby koupe normalniho second hand zbozi je i odkoupeni notasu od zamestnavatele kryto pulrocni zarukou, ze zakona...
Ze to treba u nas nikdy nikdo neresil, protoze zakoupeno za pakatel, je vec druha.

14
Distribuce / Re:System Recue (CD) oprava NTFS
« kdy: 01. 09. 2025, 18:28:28 »
Záloha dd resp. ddrescue  ma napadla, akurát ten nenahraditeľný CAD SW je viazaný na sériové číslo disku a  motherboardu a už ju nejde reaktivovať

Todle jsem nedavno resil.
Vubec bych se nevazal na konkretni zelezo a nafejkoval to vse v KVM. Jde tam zfejkovat SN disku, desky (SMBIOS), povedlo se mi i vytahnout ACPI tabulky, aby prosla aktivace Winblows (klic na desce, na zeleze bezi tux, ve VM Win).


Pokud by tedy mely selhat vice ci mene koser postupy pro boot woken primo na tom zeleze, resil bych workaround prave takto.

Variantne treba pod tucnakem udelat VM Win7 za pouziti toho vytvoreneho image... nevytvaret novej VHD, ale zkusit boot z toho image. Vetsinou se mi takovej pokus chytnul, samo za pouziti emulovanyho zeleza a ne pres virtio...

15
Hardware / Re:128 GB Ram v notebooku framework?
« kdy: 06. 08. 2025, 08:17:31 »
hlavni vyhoda, ps integrovani grafika je na urovni cca 4060 mobilni nVidia  ;)
Mobilni integrovana grafika v prociku s max power limitem 35 W (coz je ovsem pro CPU i IGP soucasne) ma odpovidat mobilni RTX 4060, kterazto ma v normalnich noteboocich TDP limit ciste pro grafiku nekde kolem 100-115 W?

Rad bych to videl na vlastni bulvy. Fskutecnosti to vsak povazuji za zcela vyloucene.

Stran: [1] 2 3 ... 11