Forum Debian Users Gang

U mnie jest wszystko w normie: xD

#  ls -alh /boot/initrd.img-*
-rw-r--r-- 1 root root 47M 2024-07-17 06:15:28 /boot/initrd.img-6.10.0-amd64
-rw-r--r-- 1 root root 43M 2024-07-11 00:12:37 /boot/initrd.img-6.9.8-amd64

#  dpkg -l | grep firmware
ii  firmware-atheros                            20240610-1                                           all          Binary firmware for Qualcomm Atheros wireless cards
ii  firmware-intel-graphics                     20240610-1                                           all          Binary firmware for Intel iGPUs and IPUs
ii  firmware-iwlwifi                            20240610-1                                           all          Binary firmware for Intel Wireless cards
ii  firmware-linux-free                         20240610-1                                           all          Binary firmware for various drivers in the Linux kernel
ii  firmware-misc-nonfree                       20240610-1                                           all          Binary firmware for various drivers in the Linux kernel
ii  firmware-realtek                            20240610-1                                           all          Binary firmware for Realtek wired/Wi-Fi/BT adapters
ii  intel-microcode                             3.20240531.1+nmu1                                    amd64        Processor microcode firmware for Intel CPUs
ii  ipxe-qemu                                   1.0.0+git-20190125.36a4c85-5.1                       all          PXE boot firmware - ROM images for qemu

Wypakuj sobie ten initrd i zobacz co tam aż tyle zajmuje:

# unmkinitramfs /boot/initrd.img-6.10.0-amd64 /tmp/obraz

U mnie po wypakowaniu zajmuje 167 MiB, z czego cache pod politykę apparmor 80 MiB, a firmware 46 MiB, Więc w zasadzie to co jest potrzebne do podniesienia mojego systemu zajmuje około 40 MiB, ale ja tam mam jeszcze szyfrowanie i lvm. Więc bez tych wszystkich niestandardowych rzeczy to by ten initrd zajmował może z 10-20 MiB (niespakowany) ale to jest przy budowaniu własnego kernela ze wszystkimi niezbędnymi modułami wkompilowanymi bezpośrednio w jądro. Same kernele zajmują:

#  ls -alh /boot/vmlinuz-*
-rw-r--r-- 1 root root 14M 2024-07-16 20:13:30 /boot/vmlinuz-6.10.0-amd64
-rw-r--r-- 1 root root 14M 2024-07-09 12:47:46 /boot/vmlinuz-6.9.8-amd64

Także nie są jakoś rozrośnięte. xD

Ostatnio edytowany przez morfik (2024-07-21 10:27:38)

Dzieki @morfik.

Miałem wcześniejsze podejrzenia, że to ten nowy pakiet 'firmware-nvidia-graphics' tak narozrabiał.
PC ma kartę NVidia, ale Trixie chodzi na sterowniku 'nouveau'. Z pakietów NVidia nie mam nic zainstalowane.

Ale po kolei.

Skopiowałem plik initrd.img do /tmp i rozpakowałem poleceniem:

# unmkinitramfs initrd.img-6.10-amd64 obraz/

Następnie korzystając z 'ncdu' odkryłem:
1. Rozpakowany initrd.img to dwa katalogi:
main 492,6 MiB oraz early 7,6 MiB
2. W 'main/usr/lib/' katalog firmware to 267,0 MiB oraz modules 190,0MiB, plus nieistotna reszta.
3. W 'modules' jest jeden katalog 6.10-amd64 – czyli moduły jądra. Niech tak będzie.
4. Natomiast w 'firmware' jest mój podejrzany – katalog 'nvidia'  254,0 MiB, z swoimi podkatalogami 'ga102, ga107, etc.', także 'tu102, tu104, tu106'.
W podkatalogach 'ga' jest 36,3 MiB plik 'gsp-535.113.01.bin' . W podkatalogach 'tu{102|104|107}'  trochę mniejszy – 22,7 MiB.
Karta która jest w PC to 'tu116', ale dla niej nie ma pliku 'gsp-535.113.01.bin' (prawidłowo: jest, ale o zerowej wielkości).

Dziwne, bo usuwałem pakiet 'firmware-nvidia-graphics' ale nie powodowało to zmianę pliku  initrd.img-6.10-amd64.
Ostatecznie zainstalowałem ten pakiet ponownie.

Spróbuję teraz znów odinstalować pakiet 'firmware-nvidia-graphics' i wykonać ręcznie 'update-initramfs -u -k all'.
Zobaczę co się stanie.

A propos.
Mam włączony Secure Boot i zauważyłem, że za każdym razem gdy Trixie (zainstalowany na przenośnym USB) wykonuje 'update-initramfs', to po jego wyłączeniu, wyjęciu USB nie można uruchomić komputera, Pojawia się

Verifying shim SBAT data failed: Security Policy Violation
Something has gone seroiusly wrong: SBAT self-check failed: Security Policy Violation

Po kilku sekundach od wyświetlenia tego napisu komputer się wyłącza. Z biedą można ten napis sfotografować.
Jedyne co można zrobić, to po włączeniu nacisnąć klawisz 'Del' aby wejść do BIOS/UEFI i wyłączyć Secure Boot.

Porady z sieci typu 'mokutil --set-sbat-policy delete' w moim przypadku nie działają.

Jedyne co pomaga przywrócić Secure Boot, to uruchomić Trixie z USB (oczywiście bez SB) i przeinstalować cztery pakiety shim (shim-helpers-amd64-signed, shim-signed, shim-signed-common, shim-unsigned). Ponownie uruchomić PC, klawisz 'Del' i włączenie SB. Wtedy Debian Bookworm z dysku w PC uruchamia się poprawnie.

Pakiety 'shim' na Trixie mam z sida – może dlatego te komplikacje.

Pozdrawiam

Ostatnio edytowany przez zl23 (2024-07-21 19:35:50)

zl23 napisał(-a):

Pakiety 'shim' na Trixie mam z sida – może dlatego te komplikacje.

Być może właśnie dlatego, bo wersjami to shim się sporo różni. Bo jakiś czas temu był niesamowity burdel z shim na linux (BootHole) i zaczęli pracować nad rozwiązaniami innymi niż dodawanie hash'y/kluczy do bazy dbx, bo te hash'e, które trzeba było dodać do bazy za sprawą BootHole zajmowały 1/3 całej bazy. xD I wypracowali coś co się nazywa SBAT (UEFI Secure Boot Advanced Targeting). Ten komunikat Verifying shim SBAT data failed: Security Policy Violation. Something has gone seroiusly wrong: SBAT self-check failed: Security Policy Violation. może być tego efektem. Więc jeśli chcesz mieć Secure Boot  to wszystkie pakiety, które w tym procesie biorą udział (shim, grub, kernel, i co tam jeszcze jest) dobrze mieć z konkretnej galężi, w przeciwnym razie ryzykujesz takie właśnie problemy. Jak coś to zobacz co tam siedzi w tej bazie:

#  mokutil --list-sbat-revocations

Co do samego problemu z firmware, to obrazy initrd trzeba regenerować. Jeśli usunięcie danego pakietu nie wymusi automatycznego wygenerowania obrazu initrd, to trzeba to zrobić samemu. xD Ta flaga -u  w update-initramfs odpowiada tylko za aktualizację tego obrazu initrd, którego kernel jest aktualnie załadowany. Dlatego przy takich większych przeróbkach zawsze używaj -k all.

Ten komunikat 'W: Possible missing firmware /lib/firmware/nvidia/'. jest efektem próbkowania sprzętu w celu ustalenia, które moduły są potrzebne do poprawnego działania sprzętu — mają robić za wskazówkę, by wiedzieć mniej więcej jakie pakiety doinstalować i wtedy jeśli dany plik istnieje, to zostanie automatycznie wrzucony do obrazu initrd, co zwykle rozwiązuje problemy ze sprzętem. Możesz także sobie zrobić skrypt initramfs i usunąć/dodać cokolwiek chcesz z obrazu przy jego generowaniu, przykładowo, ja mam np. takie skrypty.

Tu mam skrypt od brakującego firmware, bo coś na ręcznie budowanych kernelach (ze wszystkimi modułami wkopilowanymi w jądro), debian ma problemy z kopiowaniem firmware (nie potrafi tego robić) i konkretne pliki firmware trzeba kopiować ręcznie. xD

# cat /etc/initramfs-tools/hooks/fix_missing_firmware
#!/bin/sh

set -e

PREREQ=""
prereqs()
{
   echo "$PREREQ"
}

case $1 in
prereqs)
   prereqs
   exit 0
   ;;
esac

[ -r /usr/share/initramfs-tools/hook-functions ] || exit 0
. /usr/share/initramfs-tools/hook-functions

echo -n "Copying missing firmware files... "

#cp -a /lib/firmware/ ${DESTDIR}/lib/

[ ! -d "${DESTDIR}/lib/firmware/" ] && mkdir -p ${DESTDIR}/lib/firmware/
[ ! -d "${DESTDIR}/lib/firmware/brcm/" ] && mkdir -p ${DESTDIR}/lib/firmware/brcm/
[ ! -d "${DESTDIR}/lib/firmware/i915/" ] && mkdir -p ${DESTDIR}/lib/firmware/i915/

cp /lib/firmware/i915/adlp_guc_*.bin ${DESTDIR}/lib/firmware/i915/
cp /lib/firmware/iwlwifi-6000g2a-6.ucode ${DESTDIR}/lib/firmware/
cp /lib/firmware/brcm/BCM20702A1-0a5c-21e6.hcd ${DESTDIR}/lib/firmware/brcm/
cp /lib/firmware/regulatory.db-debian ${DESTDIR}/lib/firmware/regulatory.db
cp /lib/firmware/regulatory.db.p7s-debian ${DESTDIR}/lib/firmware/regulatory.db.p7s

echo "done."

exit 0

Tu od apparmor

# cat /etc/initramfs-tools/hooks/apparmor
#!/bin/sh

set -e

PREREQ=""
prereqs()
{
   echo "$PREREQ"
}

case $1 in
prereqs)
   prereqs
   exit 0
   ;;
esac

[ -r /usr/share/initramfs-tools/hook-functions ] || exit 0
. /usr/share/initramfs-tools/hook-functions

copy_exec /sbin/apparmor_parser /sbin

# Copy Apparmor config
mkdir -p $DESTDIR/etc/apparmor/
cp -a /etc/apparmor/ $DESTDIR/etc/
mkdir -p $DESTDIR/usr/share/apparmor-features/
cp -a /usr/share/apparmor-features/features $DESTDIR/usr/share/apparmor-features/
mkdir -p $DESTDIR/etc/apparmor.d/
cp -a /etc/apparmor.d/ $DESTDIR/etc/
mkdir -p $DESTDIR/var/cache/apparmor/
cp -a /var/cache/apparmor/ $DESTDIR/var/cache/

for i in $(ls /etc/apparmor.d/disable/); do rm $DESTDIR/etc/apparmor.d/$i ;done
rm -R $DESTDIR/etc/apparmor.d/disable/

To takie przykładowe skrypty, żebyś miał miej więcej rozeznanie w tym jak przy ich pomocy można sobie zmieniać zawartość obrazu initrd.

morfik napisał:

Jak coś to zobacz co tam siedzi w tej bazie:
#  mokutil --list-sbat-revocations

Używałem tego polecenia, ale nie za bardzo rozumiem tego co wypisuje.

Poniższa treść powinna być nowym wątkiem, ale niech już będzie.
Ostrzeżenie: poniższy tekst może się wydawać nudnym.

Teraz do rzeczy.
Mamy cztery przenośne pamięci USB.
Na trzech są zainstalowane systemy Linux Mint 21.3, ten nieszczęsny Trixie z pakietami shim z sida i OpenSuse Tumbleweed.
Czwarty to Ventoy m.in. z Debian Trixie Live z dn. 2024-07-22.
W komputerze na dysku SSD (zwanym dalej twardym) jest zainstalowany Bookworm bez żadnych pakietów z backport.

Secure Boot (dalej: SB) włączone.

1.
Uruchamiam Minta.

# dpkg -l | grep shim
ii  shim-signed                                1.51.3+15.7-0ubuntu1                       amd64        Secure Boot chain-loading bootloader (Microsoft-signed binary)

# mokutil --list-sbat-revocations
sbat,1,2022052400
grub,2

2.
Uruchamiam tego nieszczęsnego Trixi z sidowymi pakietami i nic nie aktualizuję, ani nie instaluję.
Tylko wypisanie komend.

# dpkg -l | grep shim
ii  shim-helpers-amd64-signed             1+15.8+1                             amd64        boot loader to chain-load signed boot loaders (signed by Debian)
ii  shim-signed:amd64                     1.44+15.8-1                          amd64        Secure Boot chain-loading bootloader (Microsoft-signed binary)
ii  shim-signed-common                    1.44+15.8-1                          all          Secure Boot chain-loading bootloader (common helper scripts)
ii  shim-unsigned:amd64                   15.8-1                               amd64        boot loader to chain-load signed boot loaders under Secure Boot

# mokutil --list-sbat-revocations
sbat,1,2024010900
shim,4
grub,3
grub.debian,4

3.
Teraz uruchamiam Bookworm z dysku twardego i... figa z makiem – SB popsuty.
Widzę: "Veryfing shim SBAT data failed: Security Policy Violation ..." i po ok. 3 sekundach komputer sam się wyłącza.

Samo tylko uruchomienie Trixie z jego shimo-sidowymi pakietami "popsuło komputer".

4.
Wyłączam SB i po uruchomieniu Bookworm z dysku twardego aktualizuję pakiety shim (Bookworm) myśląc, że go przechytrzę.

# mokutil --sb-state
SecureBoot disabled

# dpkg -l | grep shim
ii  shim-helpers-amd64-signed               1+15.7+1                            amd64        boot loader to chain-load signed boot loaders (signed by Debian)
ii  shim-signed:amd64                       1.39+15.7-1                         amd64        Secure Boot chain-loading bootloader (Microsoft-signed binary)
ii  shim-signed-common                      1.39+15.7-1                         all          Secure Boot chain-loading bootloader (common helper scripts)
ii  shim-unsigned                           15.7-1                              amd64        boot loader to chain-load signed boot loaders under Secure Boot

# mokutil --list-sbat-revocations
sbat,1,2024010900
shim,4
grub,3
grub.debian,4

5.
Włączam SB – i znów figa z makiem i widzę ten czarujący napis, a po nim pstryk.

Wniosek:
Pakiety shim należy aktualizować na systemie który to zepsuł – w moim przypadku na Trixie z USB.

Ciekawe co by było jakbym ten pendrive zgubił?
Jak przywrócić wtedy uruchamianie z Secure Boot?
Ponowna aktualizacja biosa?
A może Trixie Live i aktualizacja pakietów shim do sid?

Co tam takiego w tym UEFI ten sidowy shim zasiał?

6.
Wyłaczam SB.
Uruchamiam Trixie z USB, aktualizuję pakiety shim.
Przyglądam się informacji:
"No DKMS packages installed: not changing Secure Boot validation state."
która okazuje się niegroźna (dziwne – dkms jest zainstalowany).

Tym razem:

# mokutil --list-sbat-revocations
sbat,1,2021030218

7.
Włączam SB.
Uruchamiam Bookworm z dysku twardego.
Działa poprawnie.

Ale tym razem:

# mokutil --list-sbat-revocations
sbat,1,2022052400
grub,2

8.
OpenSuse.
Shim w wersji 15.4-7.2.

# mokutil --list-sbat-revocations
sbat,1,2022052400
grub,2

9.
Trixie Live z 20240722 na Ventoy.

root@debian:/home/user# mokutil --sb-state
bash: mokutil: command not found

root@debian:/home/user# dpkg -l | grep shim

Po zainstalowaniu 'mokutil':

root@debian:/home/user# mokutil --sb-state
This system doesn't support Secure Boot

root@debian:/home/user# mokutil --list-sbat-revocations
This system doesn't support Secure Boot

Wynika to chyba z innego sposobu rozruchu na systemie Live.

Aktualne są więc kwestie z pkt. 5:

Pakiety shim należy aktualizować na systemie który to zepsuł – w moim przypadku na Trixie z USB.

Ciekawe co by było jakbym ten pendrive zgubił?
Jak przywrócić wtedy uruchamianie z Secure Boot?
Ponowna aktualizacja biosa?
A może Trixie Live i aktualizacja pakietów shim do sid?

Co tam takiego w tym UEFI ten sidowy shim zasiał?

W moim przypadku polecenie:
# mokutil --set-sbat-policy <latest/previous/delete>
nie działa.

Pozdrawiam

PS.
Dziekuję za skrypty.
Wypróbuję je.

morfik napisał(-a):

Pakos napisał(-a):

to samo pare dni temu rozkminialem i na razie zatrzymalem sie na ustawieniu

Kod:

grep MODULES /etc/initramfs-tools/initramfs.conf
# MODULES: [ most | netboot | dep | list ]
MODULES=dep

by default jest most, ale spadek jest przeogromny

Kod:

ls -ltrh /boot/initrd.img-6.9.*
-rw-r--r-- 1 root root 231M Jul 18 19:04 /boot/initrd.img-6.9.7-amd64
-rw-r--r-- 1 root root  27M Jul 18 19:26 /boot/initrd.img-6.9.9-amd64

ps. chyba jest cos na rzeczy skoro nawet juz apt bombarduje info ze malo mu miejsca ;)

Kod:

Warning: More space needed in /boot than available: 369 MB > 148 MB, installation may fail

Myślałem, że domyślnie jest dep, bo ja zawsze przestawiałem tutaj na most. xD

no ja tez wtedy bym se prawie dal reke uciac a jednak nie, sprawdzalem na kilku maszynach o roznym wieku i wszedzie byl most :D