Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!

Ogłoszenie

Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.

#1  2024-07-20 20:28:41

  zl23 - Użytkownik

zl23
Użytkownik
Zarejestrowany: 2016-09-02

Partycja /boot/ – 512 MiB to już za mało?

Takie drobne spostrzeżenie podczas eksperymentów z sidem.

Debian Trixie zainstalowany na pamięci USB przeznaczony do różnych testów.
Aktualizacja jądra do 6.9.9 – plik initrd.img-6.9.9-amd64 ma normalną wielkość – ok. 65 MiB.

Ponieważ w sid ukazał się nowy firmware – 20240610, to postanowiłem go zaktualizować.
(Teraz z  firmware-misc-nonfree wyodrębniono: firmware-intel-graphics, firmware-intel-misc, firmware-mediatek,  firmware-nvidia-graphics. Wg: https://packages.debian.org/sid/firmware-misc-nonfree).

Kiedy mi się to zainstalowało to plik initrd.img-6.9.9-amd64 urósł do 233,9 MiB.
Prawie czterokrotnie!

Ponieważ w experimental pojawiło się jądro 6.10 to postanowiłem zobaczyć czy initrd.img będzie też taki wielki.
Po zainstalowaniu jądra 6.10 plik initrd.img-6.10-amd64 ma wielkość 234,3 MiB.

To chyba tak już będzie.

I to byłoby na tyle..
Pozdrawiam.

Offline

 

#2  2024-07-20 21:18:33

  Jacekalex - Podobno człowiek...;)

Jacekalex
Podobno człowiek...;)
Skąd: /dev/random
Zarejestrowany: 2008-01-07

Re: Partycja /boot/ – 512 MiB to już za mało?

U mnie boot  ma w tej chwili:

Kod:

# root ~> du -shm /boot
62    /boot

W środku w tej chwili są dwa kernele:

Kod:

# root ~> ls -ld /boot/*
-rw------- 1 root root   204633 07-12 04:55 /boot/config-6.6.39-g1
-rw-r--r-- 1 root root   204611 07-19 23:33 /boot/config-6.6.41-g1
drwxr-xr-x 3 root root      512 1970-01-01  /boot/efi
-rw-r--r-- 1 root root    24576 07-14 16:20 /boot/microcode.cpio
lrwxrwxrwx 1 root root       17 07-19 23:33 /boot/stable -> vmlinuz-6.6.41-g1
-rw------- 1 root root  8919129 07-12 04:55 /boot/System.map-6.6.39-g1
-rw-r--r-- 1 root root  8920976 07-19 23:33 /boot/System.map-6.6.41-g1
lrwxrwxrwx 1 root root       17 07-19 23:33 /boot/vmlinuz -> vmlinuz-6.6.41-g1
-rw------- 1 root root 19191808 07-12 04:56 /boot/vmlinuz-6.6.39-g1
-rw-r--r-- 1 root root 19200000 07-19 23:33 /boot/vmlinuz-6.6.41-g1
lrwxrwxrwx 1 root root       17 07-12 04:55 /boot/vmlinuz.old -> vmlinuz-6.6.39-g1

Zazwyczaj są trzy, ale Linux-6.9.7 wyleciał parę dni temu.

Tylko żeby mieć lekkie kernele, to trzeba je budować samemu, wtedy w initramfs nie masz sterowników do wszystkiego, co było produkowane przez ostatnie 20 lat.

Pozdro

Ostatnio edytowany przez Jacekalex (2024-07-20 23:11:15)


W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem  para bellum  ;)       |       Pozdrawiam :)

Offline

 

#3  2024-07-21 09:45:35

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Partycja /boot/ – 512 MiB to już za mało?

U mnie jest wszystko w normie: xD

Kod:

#  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:

Kod:

# 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ą:

Kod:

#  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)

Offline

 

#4  2024-07-21 15:11:45

  mati75 - Psuj

mati75
Psuj
Skąd: masz ten towar?
Zarejestrowany: 2010-03-14

Re: Partycja /boot/ – 512 MiB to już za mało?

Nawet na dystrybucji bazującej na debianie z kernelem z ubuntu czyli proxmox 3 zainstalowane wersje zajmują 220MB. 512 MB to aż nadto jak się pilnuje zainstalowanych wersji. Debian to co prawda to nie srubuntu które wypuszcza 2137 wersji kernela w ciągu miesiąca i automatyczne aktualizacje zapychają dyski bo się stare wersje nie czyszczą.

Co do samej zajętości partycji alpine linux z zainstalowanym xfce i innym softem zajmuje trochę ponad 800MB:

Kod:

alpine:~# df -h
Filesystem                Size      Used Available Use% Mounted on
devtmpfs                 10.0M         0     10.0M   0% /dev
shm                     987.7M         0    987.7M   0% /dev/shm
/dev/sda3                 7.0G    789.8M      5.9G  12% /
tmpfs                   395.1M    396.0K    394.7M   0% /run
/dev/sda1               271.1M     33.9M    218.2M  13% /boot

https://l0calh0st.pl/obrazki/userbar.png

Offline

 

#5  2024-07-21 19:34:01

  zl23 - Użytkownik

zl23
Użytkownik
Zarejestrowany: 2016-09-02

Re: Partycja /boot/ – 512 MiB to już za mało?

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:

Kod:

# 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)

Offline

 

#6  2024-07-21 20:10:31

  zl23 - Użytkownik

zl23
Użytkownik
Zarejestrowany: 2016-09-02

Re: Partycja /boot/ – 512 MiB to już za mało?

Cd.
Uruchomiony Trixie z przenośnego USB.
PC z kartą Nvidia 'tu116'.

Samo odinstalowanie:

Kod:

# apt purge firmware-nvidia-graphics

nie zmniejsza wielkości jądra.

Trzeba ręcznie wykonać '# update-initramfs -u' (bez '-k all' aby zobaczyć co będzie z poprzednim jadrem).

Po wykonaniu ww. polecenia poprzednie jądro 6.9.9 ma nadal 234 MiB, ale najnowsze 6.10 zmniejszyło się do 65 MiB.
Co znaczy, że  'gsp-535.113.01.bin' nadal jest w initrd.img-6.9.9, ale w initrd.img-6.10-amd64 już go nie ma
Gdyby dać opcje '-k all' poprzednie jądro też byłoby mniejsze.

Podczas wykonywania się 'update-initramfs'  na ekranie cały czas ukazywały się informacje: 'W: Possible missing firmware /lib/firmware/nvidia/'.

Podsumowanie
Przed operacją usuwania firmware-nvidia-graphics i update-initamfs:

Kod:

# ls -al /boot/initrd.img-6.10-amd64 
-rw-r--r-- 1 root root 245705314 07-21 14:33 /boot/initrd.img-6.10-amd64

i po operacji:

Kod:

# ls -al /boot/initrd.img-6.10-amd64 
-rw-r--r-- 1 root root 67941989 07-21 19:43 /boot/initrd.img-6.10-amd64

Wnioski z tego takie:
1.
Od teraz (pakiet 'firmware-nvidia-graphics' wszedł do Trixie 21 lipca br.) podczas 'update-initamfs' na komputerach z kartami NVidia jądro będzie ładowało do 'initrd.img' 254 MiB firmware niezależnie od tego czy ktoś go potrzebuje czy nie.
2.
Chyba lepszym rozwiązaniem jest w takim przypadku instalacja sterowników firmowych NVidia (plik *run) – tam nie ma takich cudów.
3.
Natomiast kto chce pozostać na sterowniku nouveau ten powinien pakiet 'firmware-nvidia-graphics' zablokować (# apt-mark hold firmware-nvidia-graphics) i pogodzić się z widokiem komunikatów 'W: Possible missing firmware /lib/firmware/nvidia/' podczas aktualizacji jadra.

Pozdrawiam.

Postscriptum.
Ponieważ wykonywałem 'update-initramfs' to postanowiłem zaraz też zrobić reinstall pakietów shim (SB włączone).
Ale po ponownym uruchomieniu PC, wyjeciu USB z Trixie znów ujrzałem ten napis: 'Verifying shim SBAT data failed: Security Policy Violation ...'.
Stąd mała poprawka:
Reinstalacji pakietów shim dokonujemy po wyłączeniu SB, gdyż przy załączonym SB to nie zadziała.
Wersje pakietów shim, które reinstaluję  to: 15.8-1 i 1.44+15.8-1

Ostatnio edytowany przez zl23 (2024-07-21 20:31:06)

Offline

 

#7  2024-07-22 11:49:49

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Partycja /boot/ – 512 MiB to już za mało?

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:

Kod:

#  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

Kod:

# 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

Kod:

# 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.

Offline

 

#8  2024-07-22 18:26:54

  Pakos - Członek DUG

Pakos
Członek DUG
Zarejestrowany: 2007-06-12
Serwis

Re: Partycja /boot/ – 512 MiB to już za mało?

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

Ostatnio edytowany przez Pakos (2024-07-22 18:35:52)

Offline

 

#9  2024-07-23 08:18:12

  zl23 - Użytkownik

zl23
Użytkownik
Zarejestrowany: 2016-09-02

Re: Partycja /boot/ – 512 MiB to już za mało?


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.

Kod:

# 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.

Kod:

# 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ę.

Kod:

# 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:

Kod:

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

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

Ale tym razem:

Kod:

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

8.
OpenSuse.
Shim w wersji 15.4-7.2.

Kod:

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

9.
Trixie Live z 20240722 na Ventoy.

Kod:

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

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

Po zainstalowaniu 'mokutil':

Kod:

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.

Offline

 

#10  2024-07-23 10:46:26

  morfik - Cenzor wirtualnego świata

morfik
Cenzor wirtualnego świata
Skąd: ze WSI
Zarejestrowany: 2011-09-15
Serwis

Re: Partycja /boot/ – 512 MiB to już za mało?

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

@zl23, w sumie to do przeczytania masz to:

https://en.opensuse.org/openSUSE:UEFI#Reset_SBAT_st … ld_Leap_image
https://github.com/rhboot/shim/blob/main/SBAT.md
https://wiki.archlinux.org/title/Unified_Extensible … ure_Boot#shim

To co zwraca mokutil --list-sbat-revocations np.

Kod:

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

To wersie oprogramowania, poniżej których tego oprogramowania się nie da uruchomić jeśli SB jest włączony, czyli jeśli shim będzie w twoim systemie miał 3, to system się nie uruchomi, podobnie jak grub będzie miał 2 albo grub.debian 3. Każda kompromitacja shim/grub będzie skutkować podbijaniem tych wersji w przyszłości, tak by starszych wersji shim/grub nie szło uruchomić na systemach z SB bez potrzeby dodawania miliona hash'y do bazy dbx, która prędzej czy później się i tak zapełni.

Możesz sobie zobaczyć jakie wersje mają te binarki:

Kod:

 #  objdump -j .sbat -s /usr/lib/shim/shimx64.efi.signed

/usr/lib/shim/shimx64.efi.signed:     file format pei-x86-64

Contents of section .sbat:
 d3000 73626174 2c312c53 42415420 56657273  sbat,1,SBAT Vers
 d3010 696f6e2c 73626174 2c312c68 74747073  ion,sbat,1,https
 d3020 3a2f2f67 69746875 622e636f 6d2f7268  ://github.com/rh
 d3030 626f6f74 2f736869 6d2f626c 6f622f6d  boot/shim/blob/m
 d3040 61696e2f 53424154 2e6d640a 7368696d  ain/SBAT.md.shim
 d3050 2c342c55 45464920 7368696d 2c736869  ,4,UEFI shim,shi
 d3060 6d2c312c 68747470 733a2f2f 67697468  m,1,https://gith
 d3070 75622e63 6f6d2f72 68626f6f 742f7368  ub.com/rhboot/sh
 d3080 696d0a73 68696d2e 64656269 616e2c31  im.shim.debian,1
 d3090 2c446562 69616e2c 7368696d 2c31352e  ,Debian,shim,15.
 d30a0 382c6874 7470733a 2f2f7472 61636b65  8,https://tracke
 d30b0 722e6465 6269616e 2e6f7267 2f706b67  r.debian.org/pkg
 d30c0 2f736869 6d0a                        /shim.

Czyli;

Kod:

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md.
shim,4,UEFI shim,shim,1,https://github.com/rhboot/shim.shim.
debian,1,Debian,shim,15.8,https://tracker.debian.org/pkg/shim.

Czyli ten shim ma wersje 4. Więc jeśli mokutil --list-sbat-revocations zwraca shim,4, to się uruchomi.

Jeśli ta binarka miała coś w stylu:

Kod:

#  objdump -j .sbat -s  /efi/EFI/refind/shimx64.efi.signed

/efi/EFI/refind/shimx64.efi.signed:     file format pei-x86-64

objdump: section '.sbat' mentioned in a -j option, but not found in any input file

To taki shim się w SB nie uruchomi.

Musiałbyś zobaczyć jak wyglądają te metadane w binarkach na twoich systemach bo to w nich jest problem.

Generalnie to po tym BootHole to niezłe zamieszanie jest i przeszło ono obok mnie niezauważone, bo ja mam własne klucze EFI i sam sobie wszystko podpisuje, więc cokolwiek niepodpisane się u mnie nie uruchomi, szkoda tylko, że obraz initrd/initramfs nie jest w żaden sposób zabezpieczony. xD

Ostatnio edytowany przez morfik (2024-07-23 10:50:08)

Offline

 

#11  2024-07-24 10:23:42

  Pakos - Członek DUG

Pakos
Członek DUG
Zarejestrowany: 2007-06-12
Serwis

Re: Partycja /boot/ – 512 MiB to już za mało?

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

Offline

 

Stopka forum

Powered by PunBB
© Copyright 2002–2005 Rickard Andersson
Możesz wyłączyć AdBlock — tu nie ma reklam ;-)