OK, po tym, jak trochę szperałem wokoło, znalazłem sposób, aby pozbyć się tego problemu, przynajmniej tymczasowo, jest to dość proste, ale nie mam konfiguracji systemu z btrfs, więc nie mogę potwierdzić tej poprawki.
skomentuj lub usuń ten wiersz:
if [ -n ${have_grubenv} ]; then save_env recordfail; fi
lub
if [ -n "\${have_grubenv}" ]; then if [ -z "\${boot_once}" ]; then save_env \
recordfail; fi; fi
w tym pliku
/etc/grub.d/00_header
następnie uruchomić
update-grub
powodem tego, że nie edytujesz /boot/grub/grub.cfg
bezpośrednio, jest to, że będzie nadpisywane za każdym razem, gdy grub jest aktualizowany, w takim przypadku będziesz musiał „ponownie zrobić” poprawkę, jeśli zwykłe pakiety gruba zostaną zaktualizowane.
To jest błąd w starterze, jeśli chcesz dodać sobie błąd # 736743
Cytując Colina Watsona z raportu o błędzie
Jest to w rzeczywistości mylący komunikat o błędzie: dzieje się tak, że implementacja btrfs GRUB-a nie implementuje interfejsu przechwytującego odczyt plików do zwracania list bloków do wywołania kodu. Napisałem na grub-devel o tym, a opiekun nadrzędny zwrócił uwagę, że nawet poza problemami z wieloma urządzeniami, pisanie do btrfs z GRUB-a jest zasadniczo ryzykowne, ponieważ:
ten sam blok może być używany przez wiele migawek, każde drzewo, które korzysta z danego bloku, będzie zawierało sumę kontrolną itd. rekurencyjnie
Jednak btrfs rezerwuje miejsce na początku dla modułu ładującego. Ta przestrzeń jest czymś więcej niż GRUB musi się osadzić, więc możemy użyć 1 KB dla bloku środowiska.
W każdym razie nie jest to nowy problem, który powstał podczas korzystania z podwoluminów, ani nie uniemożliwia rozruchu (pojawia się fałszywy monit „Naciśnij dowolny klawisz, aby kontynuować”, ale jeśli go zignorujesz, i tak się uruchomi). Przejście na listę życzeń.
Mam nadzieję że to pomoże