Могу ли я безопасно очищать подписанные ядра EFI? (в качестве альтернативы, я могу избавиться от неподписанных ядер?)

Question 1

Можно ли безопасно удалить и удалить пакеты linux-signed* из моей установки Ubuntu 16.10 (yakkety)?

Причина, по которой я рассматриваю это, заключается в том, что мой BIOS UEFI не использует безопасную загрузку, и мой загрузочный раздел составляет всего 200 Мбайт (~ 210 МБ). У меня есть шифрование на остальных разделах, и я действительно не хочу изменять их размер, чтобы развернуть загрузочный раздел.

К сожалению, 200 MiB просто слишком малы, чтобы держать 3 ядра. Текущие ядра достигают примерно 61 Мбайт каждый (это включает в себя бинарные файлы abi, config, initrd, map, plus и unsigned kernel). Добавление в grub, memtest и таблицу разделов делает его примерно до 198, что, по-видимому, недостаточно свободного места для apt для обновления ядра. Я обычно держу только 2 ядра (текущий + последний), но, очевидно, мне нужно пространство для третьего в процессе обновления. Если бы у меня не было подписанных ядер (7.2 MiB каждый), я был бы в порядке.

На сегодняшний день у меня установлены версии 41, 45 и 46 ядра 4.8.0.

Изменит ли моя система следующее:

apt-get purge linux-signed*
grub-mkconfig -o /boot/grub/grub.cfg

(вторая строка добавлена после комментария ubfan1, см. ниже)

Я считаю, что он должен удалить следующие пакеты ядра и запретить установку новых подписанных ядер:

linux-signed-generic
linux-signed-image-4.8.0-41-generic
linux-signed-image-4.8.0-45-generic
linux-signed-image-4.8.0-46-generic
linux-signed-image-generic

У меня есть все обычные (неподписанные) версии этих пакетов.

В качестве побочного вопроса кто-нибудь знает, почему файл unicode.pf2 (2.3 MiB) появляется как в /boot/grub, так и /boot/grub/fonts? Я различал файлы, и они были точно такими же. Я предполагаю, что это шрифт, используемый в меню grub, но почему он появляется дважды в одном разделе?

Спасибо!

добавил информацию для комментария ubfan1

Ядра .efi.signed появляются в каждом пункт меню в /boot/grub/grub.cfg. Я знаю, что моя прошивка uefi (я думаю, что биос уже не самый правильный термин) не использует безопасную загрузку, но файлы конфигурации grub, похоже, думают, что это так. Очевидно, моя система загружает подписанные ядра просто отлично, так что, возможно, я могу очистить беззнаковые ядра вместо этого?

Я выкопал /etc/grub.d/10_linux, чтобы найти, откуда эти строки, и нашел следующий код:

if test -d /sys/firmware/efi && test -e "${linux}.efi.signed"; then
    sed "s/^/$submenu_indentation/" << EOF
    linux   ${rel_dirname}/${basename}.efi.signed
      root=${linux_root_device_thisversion} ro ${args}
EOF
  else
    sed "s/^/$submenu_indentation/" << EOF
    linux   ${rel_dirname}/${basename}
      root=${linux_root_device_thisversion} ro ${args}
EOF
  fi

Я не эксперт по bash, но я думаю, что следую этому в псевдокоде

if /sys/firmware/efi AND /boot/vmlinuz-x.x.x-xx.efi.signed exist
  echo linux vmlinuz-x.x-xx-generic.efi.signed to /boot/grub/grub.cfg
else
  echo linux vmlinuz-x.x.x-xx-generic to /boot/grub/grub.cfg

, поэтому, если я очищаю подписанные пакеты ядра, заново запустите grub-mkconfig , он должен поместить регулярные беззнаковые ядра в grub.cfg, правильно?

Question 2

Спасибо за всю помощь и ссылки. Я провел несколько часов в эти выходные и проверил следующие

Короткие ответы

Да, вы можете очистить все пакеты linux-signed*, но вам нужно установить linux-generic, если вы хотите, чтобы автоматические обновления ядра продолжали нормально функционировать. Вся конфигурация grub, kernel и initramfs обрабатывается автоматически. Скрипты установки ядра действительно обрабатывают все без каких-либо проблем. [F1] Да, вы можете избавиться от беззнаковых ядер без каких-либо вредных эффектов, но они будут продолжать возвращаться после обновлений ядра. Это невозможно решить, управляя пакетами, но его легко исправить с помощью короткого сценария.

#!/bin/sh
#
# user script: 
/etc/kernel/postinst.d/zzz-remove-unsigned-kernel
#
# after a new signed kernel image is installed, this script removes
# the unsigned image
#
if [ -e "$2.efi.signed" ]; then
    echo "/etc/kernel/postinst.d/zzz-remove-unsigned-kernel: removing $2"
    rm "$2";
fi

Более длинные ответы

В первом случае решение действительно прост. Он работает в значительной степени, как вы предполагали на первый взгляд. Тем не менее, я узнал некоторые полезные сведения о структуре пакета ubuntu для ядер. Я хотел быть уверенным, что я понял побочные эффекты или последствия, но мне также нравится видеть, как все построено. Как примечание, я использую общее ядро, но просто меняю generic на lowlatency или virtual, если это ваша вещь. Кроме того, все здесь основано на 16.10 (яккеты). Вот иерархия пакетов ядра:

linux-signed-generic - мета-пакет, что означает, что он не содержит никакого кода. В нем есть список зависимостей, который всегда содержит полную установку новейшего обновления ядра. «Завершить» означает все заголовки ядра, образ ядра, (отдельную) подпись изображения и дополнительные модули ядра для почти каждого устройства, которое может поддерживать ubuntu. linux-generic - это еще один мета-пакет, содержащий все те же реальные пакеты, за исключением сигнатуры изображения. Фактическое изображение ядра содержится только в пакете linux-image-x.x.x-yy. Пакет linux-signed-image-x.x.x-yy просто содержит отдельную подпись, а скрипт сборки прикрепляет этот сиг к /boot/vmlinuz-x.x.x.yy-generic и создает /boot/vmlinuz-x.x.x.yy-generic.efi.signed. Сценарий не очищает неподписанное изображение. Пакеты ядра имеют специальные скрипты в /etc/kernel, которые изменяют поведение apt autoremove по умолчанию. Обычно удаление linux-signed-generic будет указывать на все последующие пакеты для autoremoval, но этого не происходит для пакетов ядра до тех пор, пока не появятся две новые версии той же версии.

Во втором случае (попытка сохранить только подписанный образ ядра), по-видимому, нет последствий для удаления /boot/vmlinuz-x.x.x.yy-generic после завершения установки. Оба изображения ядра точно совпадают, за исключением сигнатуры, и они имеют все одинаковые модули и файлы конфигурации. Однако, как только обновленное ядро будет установлено, оно останется за неподписанным изображением. К счастью, при запуске скрипта выполнялись легкие перехваты при каждом новом ядре. Любые скрипты из /etc/kernel/postinst.d выполняются с помощью run-parts с двумя аргументами $1 - это версия ядра, а $2 - полный путь изображения (т. Е. [F21])

Единственная незначительная оговорка заключается в том, что удаление неподписанного изображения должно выполняться после завершения обновления grub grub.cfg. Если /boot/vmlinuz-x.x.x-yy-generic.efi.signed существует, grub добавляет это изображение к grub.cfg и игнорирует неподписанное изображение. Тем не менее, должно быть где-то в процессе, который все еще ожидает изображение без знака, потому что grub не может правильно настроить без него. Сценарий, который инициирует конфигурацию grub, - /etc/kernel/postinst.d/zz-update-grub. Я назвал свой скрипт zzz-remove-unsigned-kernel так, чтобы run-parts выполнил его после завершения всего остального.

EDIT: Я использовал этот скрипт сейчас с несколькими обновлениями сборки ядра, и все работает нормально. Я использую вариант 2 выше (удаление беззнаковых ядер). Я собираюсь отметить это как правильный ответ.

Question 3

Question 4

Спасибо за всю помощь и ссылки. Я провел несколько часов в эти выходные и проверил следующие

Короткие ответы

Да, вы можете очистить все пакеты linux-signed*, но вам нужно установить linux-generic, если вы хотите, чтобы автоматические обновления ядра продолжали нормально функционировать. Вся конфигурация grub, kernel и initramfs обрабатывается автоматически. Скрипты установки ядра действительно обрабатывают все без каких-либо проблем. [F1] Да, вы можете избавиться от беззнаковых ядер без каких-либо вредных эффектов, но они будут продолжать возвращаться после обновлений ядра. Это невозможно решить, управляя пакетами, но его легко исправить с помощью короткого сценария.

#!/bin/sh
#
# user script: 
/etc/kernel/postinst.d/zzz-remove-unsigned-kernel
#
# after a new signed kernel image is installed, this script removes
# the unsigned image
#
if [ -e "$2.efi.signed" ]; then
    echo "/etc/kernel/postinst.d/zzz-remove-unsigned-kernel: removing $2"
    rm "$2";
fi

Более длинные ответы

В первом случае решение действительно прост. Он работает в значительной степени, как вы предполагали на первый взгляд. Тем не менее, я узнал некоторые полезные сведения о структуре пакета ubuntu для ядер. Я хотел быть уверенным, что я понял побочные эффекты или последствия, но мне также нравится видеть, как все построено. Как примечание, я использую общее ядро, но просто меняю generic на lowlatency или virtual, если это ваша вещь. Кроме того, все здесь основано на 16.10 (яккеты). Вот иерархия пакетов ядра:

linux-signed-generic - мета-пакет, что означает, что он не содержит никакого кода. В нем есть список зависимостей, который всегда содержит полную установку новейшего обновления ядра. «Завершить» означает все заголовки ядра, образ ядра, (отдельную) подпись изображения и дополнительные модули ядра для почти каждого устройства, которое может поддерживать ubuntu. linux-generic - это еще один мета-пакет, содержащий все те же реальные пакеты, за исключением сигнатуры изображения. Фактическое изображение ядра содержится только в пакете linux-image-x.x.x-yy. Пакет linux-signed-image-x.x.x-yy просто содержит отдельную подпись, а скрипт сборки прикрепляет этот сиг к /boot/vmlinuz-x.x.x.yy-generic и создает /boot/vmlinuz-x.x.x.yy-generic.efi.signed. Сценарий не очищает неподписанное изображение. Пакеты ядра имеют специальные скрипты в /etc/kernel, которые изменяют поведение apt autoremove по умолчанию. Обычно удаление linux-signed-generic будет указывать на все последующие пакеты для autoremoval, но этого не происходит для пакетов ядра до тех пор, пока не появятся две новые версии той же версии.

Во втором случае (попытка сохранить только подписанный образ ядра), по-видимому, нет последствий для удаления /boot/vmlinuz-x.x.x.yy-generic после завершения установки. Оба изображения ядра точно совпадают, за исключением сигнатуры, и они имеют все одинаковые модули и файлы конфигурации. Однако, как только обновленное ядро будет установлено, оно останется за неподписанным изображением. К счастью, при запуске скрипта выполнялись легкие перехваты при каждом новом ядре. Любые скрипты из /etc/kernel/postinst.d выполняются с помощью run-parts с двумя аргументами $1 - это версия ядра, а $2 - полный путь изображения (т. Е. [F21])

Единственная незначительная оговорка заключается в том, что удаление неподписанного изображения должно выполняться после завершения обновления grub grub.cfg. Если /boot/vmlinuz-x.x.x-yy-generic.efi.signed существует, grub добавляет это изображение к grub.cfg и игнорирует неподписанное изображение. Тем не менее, должно быть где-то в процессе, который все еще ожидает изображение без знака, потому что grub не может правильно настроить без него. Сценарий, который инициирует конфигурацию grub, - /etc/kernel/postinst.d/zz-update-grub. Я назвал свой скрипт zzz-remove-unsigned-kernel так, чтобы run-parts выполнил его после завершения всего остального.

EDIT: Я использовал этот скрипт сейчас с несколькими обновлениями сборки ядра, и все работает нормально. Я использую вариант 2 выше (удаление беззнаковых ядер). Я собираюсь отметить это как правильный ответ.

Question 5

Спасибо за всю помощь и ссылки. Я провел несколько часов в эти выходные и проверил следующие

Короткие ответы

Да, вы можете очистить все пакеты linux-signed*, но вам нужно установить linux-generic, если вы хотите, чтобы автоматические обновления ядра продолжали нормально функционировать. Вся конфигурация grub, kernel и initramfs обрабатывается автоматически. Скрипты установки ядра действительно обрабатывают все без каких-либо проблем. [F1] Да, вы можете избавиться от беззнаковых ядер без каких-либо вредных эффектов, но они будут продолжать возвращаться после обновлений ядра. Это невозможно решить, управляя пакетами, но его легко исправить с помощью короткого сценария.

#!/bin/sh
#
# user script: 
/etc/kernel/postinst.d/zzz-remove-unsigned-kernel
#
# after a new signed kernel image is installed, this script removes
# the unsigned image
#
if [ -e "$2.efi.signed" ]; then
    echo "/etc/kernel/postinst.d/zzz-remove-unsigned-kernel: removing $2"
    rm "$2";
fi

Более длинные ответы

В первом случае решение действительно прост. Он работает в значительной степени, как вы предполагали на первый взгляд. Тем не менее, я узнал некоторые полезные сведения о структуре пакета ubuntu для ядер. Я хотел быть уверенным, что я понял побочные эффекты или последствия, но мне также нравится видеть, как все построено. Как примечание, я использую общее ядро, но просто меняю generic на lowlatency или virtual, если это ваша вещь. Кроме того, все здесь основано на 16.10 (яккеты). Вот иерархия пакетов ядра:

linux-signed-generic - мета-пакет, что означает, что он не содержит никакого кода. В нем есть список зависимостей, который всегда содержит полную установку новейшего обновления ядра. «Завершить» означает все заголовки ядра, образ ядра, (отдельную) подпись изображения и дополнительные модули ядра для почти каждого устройства, которое может поддерживать ubuntu. linux-generic - это еще один мета-пакет, содержащий все те же реальные пакеты, за исключением сигнатуры изображения. Фактическое изображение ядра содержится только в пакете linux-image-x.x.x-yy. Пакет linux-signed-image-x.x.x-yy просто содержит отдельную подпись, а скрипт сборки прикрепляет этот сиг к /boot/vmlinuz-x.x.x.yy-generic и создает /boot/vmlinuz-x.x.x.yy-generic.efi.signed. Сценарий не очищает неподписанное изображение. Пакеты ядра имеют специальные скрипты в /etc/kernel, которые изменяют поведение apt autoremove по умолчанию. Обычно удаление linux-signed-generic будет указывать на все последующие пакеты для autoremoval, но этого не происходит для пакетов ядра до тех пор, пока не появятся две новые версии той же версии.

Во втором случае (попытка сохранить только подписанный образ ядра), по-видимому, нет последствий для удаления /boot/vmlinuz-x.x.x.yy-generic после завершения установки. Оба изображения ядра точно совпадают, за исключением сигнатуры, и они имеют все одинаковые модули и файлы конфигурации. Однако, как только обновленное ядро будет установлено, оно останется за неподписанным изображением. К счастью, при запуске скрипта выполнялись легкие перехваты при каждом новом ядре. Любые скрипты из /etc/kernel/postinst.d выполняются с помощью run-parts с двумя аргументами $1 - это версия ядра, а $2 - полный путь изображения (т. Е. [F21])

Единственная незначительная оговорка заключается в том, что удаление неподписанного изображения должно выполняться после завершения обновления grub grub.cfg. Если /boot/vmlinuz-x.x.x-yy-generic.efi.signed существует, grub добавляет это изображение к grub.cfg и игнорирует неподписанное изображение. Тем не менее, должно быть где-то в процессе, который все еще ожидает изображение без знака, потому что grub не может правильно настроить без него. Сценарий, который инициирует конфигурацию grub, - /etc/kernel/postinst.d/zz-update-grub. Я назвал свой скрипт zzz-remove-unsigned-kernel так, чтобы run-parts выполнил его после завершения всего остального.

EDIT: Я использовал этот скрипт сейчас с несколькими обновлениями сборки ядра, и все работает нормально. Я использую вариант 2 выше (удаление беззнаковых ядер). Я собираюсь отметить это как правильный ответ.

Question 6

Спасибо за всю помощь и ссылки. Я провел несколько часов в эти выходные и проверил следующие

Короткие ответы

Да, вы можете очистить все пакеты linux-signed*, но вам нужно установить linux-generic, если вы хотите, чтобы автоматические обновления ядра продолжали нормально функционировать. Вся конфигурация grub, kernel и initramfs обрабатывается автоматически. Скрипты установки ядра действительно обрабатывают все без каких-либо проблем. [F1] Да, вы можете избавиться от беззнаковых ядер без каких-либо вредных эффектов, но они будут продолжать возвращаться после обновлений ядра. Это невозможно решить, управляя пакетами, но его легко исправить с помощью короткого сценария.

#!/bin/sh
#
# user script: 
/etc/kernel/postinst.d/zzz-remove-unsigned-kernel
#
# after a new signed kernel image is installed, this script removes
# the unsigned image
#
if [ -e "$2.efi.signed" ]; then
    echo "/etc/kernel/postinst.d/zzz-remove-unsigned-kernel: removing $2"
    rm "$2";
fi

Более длинные ответы

В первом случае решение действительно прост. Он работает в значительной степени, как вы предполагали на первый взгляд. Тем не менее, я узнал некоторые полезные сведения о структуре пакета ubuntu для ядер. Я хотел быть уверенным, что я понял побочные эффекты или последствия, но мне также нравится видеть, как все построено. Как примечание, я использую общее ядро, но просто меняю generic на lowlatency или virtual, если это ваша вещь. Кроме того, все здесь основано на 16.10 (яккеты). Вот иерархия пакетов ядра:

linux-signed-generic - мета-пакет, что означает, что он не содержит никакого кода. В нем есть список зависимостей, который всегда содержит полную установку новейшего обновления ядра. «Завершить» означает все заголовки ядра, образ ядра, (отдельную) подпись изображения и дополнительные модули ядра для почти каждого устройства, которое может поддерживать ubuntu. linux-generic - это еще один мета-пакет, содержащий все те же реальные пакеты, за исключением сигнатуры изображения. Фактическое изображение ядра содержится только в пакете linux-image-x.x.x-yy. Пакет linux-signed-image-x.x.x-yy просто содержит отдельную подпись, а скрипт сборки прикрепляет этот сиг к /boot/vmlinuz-x.x.x.yy-generic и создает /boot/vmlinuz-x.x.x.yy-generic.efi.signed. Сценарий не очищает неподписанное изображение. Пакеты ядра имеют специальные скрипты в /etc/kernel, которые изменяют поведение apt autoremove по умолчанию. Обычно удаление linux-signed-generic будет указывать на все последующие пакеты для autoremoval, но этого не происходит для пакетов ядра до тех пор, пока не появятся две новые версии той же версии.

Во втором случае (попытка сохранить только подписанный образ ядра), по-видимому, нет последствий для удаления /boot/vmlinuz-x.x.x.yy-generic после завершения установки. Оба изображения ядра точно совпадают, за исключением сигнатуры, и они имеют все одинаковые модули и файлы конфигурации. Однако, как только обновленное ядро будет установлено, оно останется за неподписанным изображением. К счастью, при запуске скрипта выполнялись легкие перехваты при каждом новом ядре. Любые скрипты из /etc/kernel/postinst.d выполняются с помощью run-parts с двумя аргументами $1 - это версия ядра, а $2 - полный путь изображения (т. Е. [F21])

Единственная незначительная оговорка заключается в том, что удаление неподписанного изображения должно выполняться после завершения обновления grub grub.cfg. Если /boot/vmlinuz-x.x.x-yy-generic.efi.signed существует, grub добавляет это изображение к grub.cfg и игнорирует неподписанное изображение. Тем не менее, должно быть где-то в процессе, который все еще ожидает изображение без знака, потому что grub не может правильно настроить без него. Сценарий, который инициирует конфигурацию grub, - /etc/kernel/postinst.d/zz-update-grub. Я назвал свой скрипт zzz-remove-unsigned-kernel так, чтобы run-parts выполнил его после завершения всего остального.

EDIT: Я использовал этот скрипт сейчас с несколькими обновлениями сборки ядра, и все работает нормально. Я использую вариант 2 выше (удаление беззнаковых ядер). Я собираюсь отметить это как правильный ответ.

Question 7

Question 8

Спасибо за всю помощь и ссылки. Я провел несколько часов в эти выходные и проверил следующие

Короткие ответы

Да, вы можете очистить все пакеты linux-signed*, но вам нужно установить linux-generic, если вы хотите, чтобы автоматические обновления ядра продолжали нормально функционировать. Вся конфигурация grub, kernel и initramfs обрабатывается автоматически. Скрипты установки ядра действительно обрабатывают все без каких-либо проблем. [F1] Да, вы можете избавиться от беззнаковых ядер без каких-либо вредных эффектов, но они будут продолжать возвращаться после обновлений ядра. Это невозможно решить, управляя пакетами, но его легко исправить с помощью короткого сценария.

#!/bin/sh
#
# user script: 
/etc/kernel/postinst.d/zzz-remove-unsigned-kernel
#
# after a new signed kernel image is installed, this script removes
# the unsigned image
#
if [ -e "$2.efi.signed" ]; then
    echo "/etc/kernel/postinst.d/zzz-remove-unsigned-kernel: removing $2"
    rm "$2";
fi

Более длинные ответы

В первом случае решение действительно прост. Он работает в значительной степени, как вы предполагали на первый взгляд. Тем не менее, я узнал некоторые полезные сведения о структуре пакета ubuntu для ядер. Я хотел быть уверенным, что я понял побочные эффекты или последствия, но мне также нравится видеть, как все построено. Как примечание, я использую общее ядро, но просто меняю generic на lowlatency или virtual, если это ваша вещь. Кроме того, все здесь основано на 16.10 (яккеты). Вот иерархия пакетов ядра:

linux-signed-generic - мета-пакет, что означает, что он не содержит никакого кода. В нем есть список зависимостей, который всегда содержит полную установку новейшего обновления ядра. «Завершить» означает все заголовки ядра, образ ядра, (отдельную) подпись изображения и дополнительные модули ядра для почти каждого устройства, которое может поддерживать ubuntu. linux-generic - это еще один мета-пакет, содержащий все те же реальные пакеты, за исключением сигнатуры изображения. Фактическое изображение ядра содержится только в пакете linux-image-x.x.x-yy. Пакет linux-signed-image-x.x.x-yy просто содержит отдельную подпись, а скрипт сборки прикрепляет этот сиг к /boot/vmlinuz-x.x.x.yy-generic и создает /boot/vmlinuz-x.x.x.yy-generic.efi.signed. Сценарий не очищает неподписанное изображение. Пакеты ядра имеют специальные скрипты в /etc/kernel, которые изменяют поведение apt autoremove по умолчанию. Обычно удаление linux-signed-generic будет указывать на все последующие пакеты для autoremoval, но этого не происходит для пакетов ядра до тех пор, пока не появятся две новые версии той же версии.

Во втором случае (попытка сохранить только подписанный образ ядра), по-видимому, нет последствий для удаления /boot/vmlinuz-x.x.x.yy-generic после завершения установки. Оба изображения ядра точно совпадают, за исключением сигнатуры, и они имеют все одинаковые модули и файлы конфигурации. Однако, как только обновленное ядро будет установлено, оно останется за неподписанным изображением. К счастью, при запуске скрипта выполнялись легкие перехваты при каждом новом ядре. Любые скрипты из /etc/kernel/postinst.d выполняются с помощью run-parts с двумя аргументами $1 - это версия ядра, а $2 - полный путь изображения (т. Е. [F21])

Единственная незначительная оговорка заключается в том, что удаление неподписанного изображения должно выполняться после завершения обновления grub grub.cfg. Если /boot/vmlinuz-x.x.x-yy-generic.efi.signed существует, grub добавляет это изображение к grub.cfg и игнорирует неподписанное изображение. Тем не менее, должно быть где-то в процессе, который все еще ожидает изображение без знака, потому что grub не может правильно настроить без него. Сценарий, который инициирует конфигурацию grub, - /etc/kernel/postinst.d/zz-update-grub. Я назвал свой скрипт zzz-remove-unsigned-kernel так, чтобы run-parts выполнил его после завершения всего остального.

EDIT: Я использовал этот скрипт сейчас с несколькими обновлениями сборки ядра, и все работает нормально. Я использую вариант 2 выше (удаление беззнаковых ядер). Я собираюсь отметить это как правильный ответ.

Question 9

AFAIK, ядра .efi.signed такие же, как и обычные ядра, за исключением того, что они подписаны с ключом безопасности Canon EFI Secure Boot. Таким образом, если вы не загружаетесь с активной загрузкой, вы можете безопасно удалить ядра .efi.signed. Если я правильно разбираю информацию о пакете, вы должны удалить пакеты linux-signed-image-generic и linux-signed-generic, чтобы предотвратить установку будущих обновлений для подписанных ядер.

Тем не менее, Лучшим решением в долгосрочной перспективе является увеличение размера раздела /boot. Это может быть больно и даже рискованно для ваших данных, особенно если вы используете LVM или программный RAID; однако детали сильно зависят от вашего текущего расположения диска и планов по изменению этого макета по другим причинам. Обратите внимание, что в зависимости от вашего макета может быть предпочтительнее сжать раздел данных с конца и создать более крупный раздел /boot после того, как этот сокращенный раздел данных, чем попытаться сжать раздел данных с самого начала, чтобы сделать пространство для раздела /boot, чтобы оно выросло.

Наконец, если вы достаточно отчаянно хотите освободить несколько мегабайт, которые вы просматриваете дублируемыми файлами в дереве каталогов /boot/grub, вы можете подумать вообще удаляясь от GRUB. Большинство других загрузчиков не требуют столько же файлов в /boot, сколько GRUB. Если вы загружаетесь в режиме EFI, мой собственный менеджер загрузки rEFInd, скорее всего, будет самым простым в установке, и вы можете попробовать его на USB-накопителе или CD-R, чтобы посмотреть, что это такое, прежде чем сбрасывать жесткий диск. Если вы загружаетесь в режиме BIOS, LILO, SYSLINUX и даже GRUB Legacy - это все варианты, но я не имею указателей на инструкции по установке любого из них, небрежно.

Question 10

Ячейки .signed немного больше, поэтому, если вы не используете безопасную загрузку и пытаетесь сэкономить место, используйте unsigned и очистите подписанный. Я тоже думаю, что ваш подход с восстановлением grub будет работать. Если вы должны потерять власть перед восстановлением grub.cfg, вы всегда можете отредактировать старое меню grub и удалить подписанную часть. Конечно, вы можете оставить одну подписанную версию (последнюю) и избавиться от остальных, чтобы убедиться, что все работает так, как ожидалось, а затем повторите это для последнего, не оставив вас без известной загрузочной установки. Что касается файлов unicode.pf2 - они существуют и в моей системе. Вы можете попробовать заменить его ссылкой на другую (с удобным загрузочным носителем, если вам нужно вернуть файл туда, где есть ссылка).

Question 11

AFAIK, ядра .efi.signed такие же, как и обычные ядра, за исключением того, что они подписаны с ключом безопасности Canon EFI Secure Boot. Таким образом, если вы не загружаетесь с активной загрузкой, вы можете безопасно удалить ядра .efi.signed. Если я правильно разбираю информацию о пакете, вы должны удалить пакеты linux-signed-image-generic и linux-signed-generic, чтобы предотвратить установку будущих обновлений для подписанных ядер.

Тем не менее, Лучшим решением в долгосрочной перспективе является увеличение размера раздела /boot. Это может быть больно и даже рискованно для ваших данных, особенно если вы используете LVM или программный RAID; однако детали сильно зависят от вашего текущего расположения диска и планов по изменению этого макета по другим причинам. Обратите внимание, что в зависимости от вашего макета может быть предпочтительнее сжать раздел данных с конца и создать более крупный раздел /boot после того, как этот сокращенный раздел данных, чем попытаться сжать раздел данных с самого начала, чтобы сделать пространство для раздела /boot, чтобы оно выросло.

Наконец, если вы достаточно отчаянно хотите освободить несколько мегабайт, которые вы просматриваете дублируемыми файлами в дереве каталогов /boot/grub, вы можете подумать вообще удаляясь от GRUB. Большинство других загрузчиков не требуют столько же файлов в /boot, сколько GRUB. Если вы загружаетесь в режиме EFI, мой собственный менеджер загрузки rEFInd, скорее всего, будет самым простым в установке, и вы можете попробовать его на USB-накопителе или CD-R, чтобы посмотреть, что это такое, прежде чем сбрасывать жесткий диск. Если вы загружаетесь в режиме BIOS, LILO, SYSLINUX и даже GRUB Legacy - это все варианты, но я не имею указателей на инструкции по установке любого из них, небрежно.

Question 12

Ячейки .signed немного больше, поэтому, если вы не используете безопасную загрузку и пытаетесь сэкономить место, используйте unsigned и очистите подписанный. Я тоже думаю, что ваш подход с восстановлением grub будет работать. Если вы должны потерять власть перед восстановлением grub.cfg, вы всегда можете отредактировать старое меню grub и удалить подписанную часть. Конечно, вы можете оставить одну подписанную версию (последнюю) и избавиться от остальных, чтобы убедиться, что все работает так, как ожидалось, а затем повторите это для последнего, не оставив вас без известной загрузочной установки. Что касается файлов unicode.pf2 - они существуют и в моей системе. Вы можете попробовать заменить его ссылкой на другую (с удобным загрузочным носителем, если вам нужно вернуть файл туда, где есть ссылка).

Question 13

Question 14

AFAIK, ядра .efi.signed такие же, как и обычные ядра, за исключением того, что они подписаны с ключом безопасности Canon EFI Secure Boot. Таким образом, если вы не загружаетесь с активной загрузкой, вы можете безопасно удалить ядра .efi.signed. Если я правильно разбираю информацию о пакете, вы должны удалить пакеты linux-signed-image-generic и linux-signed-generic, чтобы предотвратить установку будущих обновлений для подписанных ядер.

Тем не менее, Лучшим решением в долгосрочной перспективе является увеличение размера раздела /boot. Это может быть больно и даже рискованно для ваших данных, особенно если вы используете LVM или программный RAID; однако детали сильно зависят от вашего текущего расположения диска и планов по изменению этого макета по другим причинам. Обратите внимание, что в зависимости от вашего макета может быть предпочтительнее сжать раздел данных с конца и создать более крупный раздел /boot после того, как этот сокращенный раздел данных, чем попытаться сжать раздел данных с самого начала, чтобы сделать пространство для раздела /boot, чтобы оно выросло.

Наконец, если вы достаточно отчаянно хотите освободить несколько мегабайт, которые вы просматриваете дублируемыми файлами в дереве каталогов /boot/grub, вы можете подумать вообще удаляясь от GRUB. Большинство других загрузчиков не требуют столько же файлов в /boot, сколько GRUB. Если вы загружаетесь в режиме EFI, мой собственный менеджер загрузки rEFInd, скорее всего, будет самым простым в установке, и вы можете попробовать его на USB-накопителе или CD-R, чтобы посмотреть, что это такое, прежде чем сбрасывать жесткий диск. Если вы загружаетесь в режиме BIOS, LILO, SYSLINUX и даже GRUB Legacy - это все варианты, но я не имею указателей на инструкции по установке любого из них, небрежно.

Question 15

Ячейки .signed немного больше, поэтому, если вы не используете безопасную загрузку и пытаетесь сэкономить место, используйте unsigned и очистите подписанный. Я тоже думаю, что ваш подход с восстановлением grub будет работать. Если вы должны потерять власть перед восстановлением grub.cfg, вы всегда можете отредактировать старое меню grub и удалить подписанную часть. Конечно, вы можете оставить одну подписанную версию (последнюю) и избавиться от остальных, чтобы убедиться, что все работает так, как ожидалось, а затем повторите это для последнего, не оставив вас без известной загрузочной установки. Что касается файлов unicode.pf2 - они существуют и в моей системе. Вы можете попробовать заменить его ссылкой на другую (с удобным загрузочным носителем, если вам нужно вернуть файл туда, где есть ссылка).

Question 16

AFAIK, ядра .efi.signed такие же, как и обычные ядра, за исключением того, что они подписаны с ключом безопасности Canon EFI Secure Boot. Таким образом, если вы не загружаетесь с активной загрузкой, вы можете безопасно удалить ядра .efi.signed. Если я правильно разбираю информацию о пакете, вы должны удалить пакеты linux-signed-image-generic и linux-signed-generic, чтобы предотвратить установку будущих обновлений для подписанных ядер.

Тем не менее, Лучшим решением в долгосрочной перспективе является увеличение размера раздела /boot. Это может быть больно и даже рискованно для ваших данных, особенно если вы используете LVM или программный RAID; однако детали сильно зависят от вашего текущего расположения диска и планов по изменению этого макета по другим причинам. Обратите внимание, что в зависимости от вашего макета может быть предпочтительнее сжать раздел данных с конца и создать более крупный раздел /boot после того, как этот сокращенный раздел данных, чем попытаться сжать раздел данных с самого начала, чтобы сделать пространство для раздела /boot, чтобы оно выросло.

Наконец, если вы достаточно отчаянно хотите освободить несколько мегабайт, которые вы просматриваете дублируемыми файлами в дереве каталогов /boot/grub, вы можете подумать вообще удаляясь от GRUB. Большинство других загрузчиков не требуют столько же файлов в /boot, сколько GRUB. Если вы загружаетесь в режиме EFI, мой собственный менеджер загрузки rEFInd, скорее всего, будет самым простым в установке, и вы можете попробовать его на USB-накопителе или CD-R, чтобы посмотреть, что это такое, прежде чем сбрасывать жесткий диск. Если вы загружаетесь в режиме BIOS, LILO, SYSLINUX и даже GRUB Legacy - это все варианты, но я не имею указателей на инструкции по установке любого из них, небрежно.

Question 17

Ячейки .signed немного больше, поэтому, если вы не используете безопасную загрузку и пытаетесь сэкономить место, используйте unsigned и очистите подписанный. Я тоже думаю, что ваш подход с восстановлением grub будет работать. Если вы должны потерять власть перед восстановлением grub.cfg, вы всегда можете отредактировать старое меню grub и удалить подписанную часть. Конечно, вы можете оставить одну подписанную версию (последнюю) и избавиться от остальных, чтобы убедиться, что все работает так, как ожидалось, а затем повторите это для последнего, не оставив вас без известной загрузочной установки. Что касается файлов unicode.pf2 - они существуют и в моей системе. Вы можете попробовать заменить его ссылкой на другую (с удобным загрузочным носителем, если вам нужно вернуть файл туда, где есть ссылка).

Question 18

AFAIK, ядра .efi.signed такие же, как и обычные ядра, за исключением того, что они подписаны с ключом безопасности Canon EFI Secure Boot. Таким образом, если вы не загружаетесь с активной загрузкой, вы можете безопасно удалить ядра .efi.signed. Если я правильно разбираю информацию о пакете, вы должны удалить пакеты linux-signed-image-generic и linux-signed-generic, чтобы предотвратить установку будущих обновлений для подписанных ядер.

Тем не менее, Лучшим решением в долгосрочной перспективе является увеличение размера раздела /boot. Это может быть больно и даже рискованно для ваших данных, особенно если вы используете LVM или программный RAID; однако детали сильно зависят от вашего текущего расположения диска и планов по изменению этого макета по другим причинам. Обратите внимание, что в зависимости от вашего макета может быть предпочтительнее сжать раздел данных с конца и создать более крупный раздел /boot после того, как этот сокращенный раздел данных, чем попытаться сжать раздел данных с самого начала, чтобы сделать пространство для раздела /boot, чтобы оно выросло.

Наконец, если вы достаточно отчаянно хотите освободить несколько мегабайт, которые вы просматриваете дублируемыми файлами в дереве каталогов /boot/grub, вы можете подумать вообще удаляясь от GRUB. Большинство других загрузчиков не требуют столько же файлов в /boot, сколько GRUB. Если вы загружаетесь в режиме EFI, мой собственный менеджер загрузки rEFInd, скорее всего, будет самым простым в установке, и вы можете попробовать его на USB-накопителе или CD-R, чтобы посмотреть, что это такое, прежде чем сбрасывать жесткий диск. Если вы загружаетесь в режиме BIOS, LILO, SYSLINUX и даже GRUB Legacy - это все варианты, но я не имею указателей на инструкции по установке любого из них, небрежно.

Question 19

Question 20

Ячейки .signed немного больше, поэтому, если вы не используете безопасную загрузку и пытаетесь сэкономить место, используйте unsigned и очистите подписанный. Я тоже думаю, что ваш подход с восстановлением grub будет работать. Если вы должны потерять власть перед восстановлением grub.cfg, вы всегда можете отредактировать старое меню grub и удалить подписанную часть. Конечно, вы можете оставить одну подписанную версию (последнюю) и избавиться от остальных, чтобы убедиться, что все работает так, как ожидалось, а затем повторите это для последнего, не оставив вас без известной загрузочной установки. Что касается файлов unicode.pf2 - они существуют и в моей системе. Вы можете попробовать заменить его ссылкой на другую (с удобным загрузочным носителем, если вам нужно вернуть файл туда, где есть ссылка).

derHugo · Accepted Answer · 22 May 2018 в 23:56

Спасибо за всю помощь и ссылки. Я провел несколько часов в эти выходные и проверил следующие

Короткие ответы

Да, вы можете очистить все пакеты linux-signed*, но вам нужно установить linux-generic, если вы хотите, чтобы автоматические обновления ядра продолжали нормально функционировать. Вся конфигурация grub, kernel и initramfs обрабатывается автоматически. Скрипты установки ядра действительно обрабатывают все без каких-либо проблем. [F1] Да, вы можете избавиться от беззнаковых ядер без каких-либо вредных эффектов, но они будут продолжать возвращаться после обновлений ядра. Это невозможно решить, управляя пакетами, но его легко исправить с помощью короткого сценария.

#!/bin/sh
#
# user script: 
/etc/kernel/postinst.d/zzz-remove-unsigned-kernel
#
# after a new signed kernel image is installed, this script removes
# the unsigned image
#
if [ -e "$2.efi.signed" ]; then
    echo "/etc/kernel/postinst.d/zzz-remove-unsigned-kernel: removing $2"
    rm "$2";
fi

Более длинные ответы

В первом случае решение действительно прост. Он работает в значительной степени, как вы предполагали на первый взгляд. Тем не менее, я узнал некоторые полезные сведения о структуре пакета ubuntu для ядер. Я хотел быть уверенным, что я понял побочные эффекты или последствия, но мне также нравится видеть, как все построено. Как примечание, я использую общее ядро, но просто меняю generic на lowlatency или virtual, если это ваша вещь. Кроме того, все здесь основано на 16.10 (яккеты). Вот иерархия пакетов ядра:

linux-signed-generic - мета-пакет, что означает, что он не содержит никакого кода. В нем есть список зависимостей, который всегда содержит полную установку новейшего обновления ядра. «Завершить» означает все заголовки ядра, образ ядра, (отдельную) подпись изображения и дополнительные модули ядра для почти каждого устройства, которое может поддерживать ubuntu. linux-generic - это еще один мета-пакет, содержащий все те же реальные пакеты, за исключением сигнатуры изображения. Фактическое изображение ядра содержится только в пакете linux-image-x.x.x-yy. Пакет linux-signed-image-x.x.x-yy просто содержит отдельную подпись, а скрипт сборки прикрепляет этот сиг к /boot/vmlinuz-x.x.x.yy-generic и создает /boot/vmlinuz-x.x.x.yy-generic.efi.signed. Сценарий не очищает неподписанное изображение. Пакеты ядра имеют специальные скрипты в /etc/kernel, которые изменяют поведение apt autoremove по умолчанию. Обычно удаление linux-signed-generic будет указывать на все последующие пакеты для autoremoval, но этого не происходит для пакетов ядра до тех пор, пока не появятся две новые версии той же версии.

Во втором случае (попытка сохранить только подписанный образ ядра), по-видимому, нет последствий для удаления /boot/vmlinuz-x.x.x.yy-generic после завершения установки. Оба изображения ядра точно совпадают, за исключением сигнатуры, и они имеют все одинаковые модули и файлы конфигурации. Однако, как только обновленное ядро будет установлено, оно останется за неподписанным изображением. К счастью, при запуске скрипта выполнялись легкие перехваты при каждом новом ядре. Любые скрипты из /etc/kernel/postinst.d выполняются с помощью run-parts с двумя аргументами $1 - это версия ядра, а $2 - полный путь изображения (т. Е. [F21])

Единственная незначительная оговорка заключается в том, что удаление неподписанного изображения должно выполняться после завершения обновления grub grub.cfg. Если /boot/vmlinuz-x.x.x-yy-generic.efi.signed существует, grub добавляет это изображение к grub.cfg и игнорирует неподписанное изображение. Тем не менее, должно быть где-то в процессе, который все еще ожидает изображение без знака, потому что grub не может правильно настроить без него. Сценарий, который инициирует конфигурацию grub, - /etc/kernel/postinst.d/zz-update-grub. Я назвал свой скрипт zzz-remove-unsigned-kernel так, чтобы run-parts выполнил его после завершения всего остального.

EDIT: Я использовал этот скрипт сейчас с несколькими обновлениями сборки ядра, и все работает нормально. Я использую вариант 2 выше (удаление беззнаковых ядер). Я собираюсь отметить это как правильный ответ.

Нет ли каких-либо жалоб на отсутствие /boot/vmlinuz-x.x.x-yy-generic при удалении linux-image-x.x.x-yy-generic с помощью apt? — jarno, 24 May 2017 в 11:14
@jarno, у меня нет этой проблемы, но я не думаю, что понимаю ваш вопрос. Если вы хотите окончательно избавиться от неподписанных ядер vmlinuz-x.x.x-yy-generic, см. Опцию № 2 выше. Он использует сценарий после установки, а не apt. Как я уже сказал в своем ответе, структура пакета не допускает только подписанные ядра, но после завершения установки беззнаковое ядро больше не ссылается и вы можете безопасно удалить его. Однако, если вы сначала удалите ядро, вернитесь назад и попробуйте удалить пакет ядра с apt, apt, вероятно, будет жаловаться. В этом порядке нет причин делать это. — James Duvall, 24 May 2017 в 18:42
Если вы просто удалите файл vmlinuz, пакет по-прежнему будет установлен в соответствии с dpkg. Если вы позже хотите полностью очистить ненужные ядра, как вы это делаете? — jarno, 25 May 2017 в 13:46
@jarno, когда вы готовы удалить старую версию ядра, apt не жалуется на отсутствующий файл vmlinuz-x.x.x-yy-generic. Удаление пакета работает отлично. Это верно, если вы вручную удалите старые пакеты ядра или просто разрешите apt обрабатывать его автоматически. Сценарии управления ядрами Ubuntu обычно сохраняют 2 старые версии ядра. — James Duvall, 25 May 2017 в 21:20

derHugo · Accepted Answer · 18 July 2018 в 15:27

Спасибо за всю помощь и ссылки. Я провел несколько часов в эти выходные и проверил следующие

Короткие ответы

Да, вы можете очистить все пакеты linux-signed*, но вам нужно установить linux-generic, если вы хотите, чтобы автоматические обновления ядра продолжали нормально функционировать. Вся конфигурация grub, kernel и initramfs обрабатывается автоматически. Скрипты установки ядра действительно обрабатывают все без каких-либо проблем. [F1] Да, вы можете избавиться от беззнаковых ядер без каких-либо вредных эффектов, но они будут продолжать возвращаться после обновлений ядра. Это невозможно решить, управляя пакетами, но его легко исправить с помощью короткого сценария.

#!/bin/sh
#
# user script: 
/etc/kernel/postinst.d/zzz-remove-unsigned-kernel
#
# after a new signed kernel image is installed, this script removes
# the unsigned image
#
if [ -e "$2.efi.signed" ]; then
    echo "/etc/kernel/postinst.d/zzz-remove-unsigned-kernel: removing $2"
    rm "$2";
fi

Более длинные ответы

В первом случае решение действительно прост. Он работает в значительной степени, как вы предполагали на первый взгляд. Тем не менее, я узнал некоторые полезные сведения о структуре пакета ubuntu для ядер. Я хотел быть уверенным, что я понял побочные эффекты или последствия, но мне также нравится видеть, как все построено. Как примечание, я использую общее ядро, но просто меняю generic на lowlatency или virtual, если это ваша вещь. Кроме того, все здесь основано на 16.10 (яккеты). Вот иерархия пакетов ядра:

linux-signed-generic - мета-пакет, что означает, что он не содержит никакого кода. В нем есть список зависимостей, который всегда содержит полную установку новейшего обновления ядра. «Завершить» означает все заголовки ядра, образ ядра, (отдельную) подпись изображения и дополнительные модули ядра для почти каждого устройства, которое может поддерживать ubuntu. linux-generic - это еще один мета-пакет, содержащий все те же реальные пакеты, за исключением сигнатуры изображения. Фактическое изображение ядра содержится только в пакете linux-image-x.x.x-yy. Пакет linux-signed-image-x.x.x-yy просто содержит отдельную подпись, а скрипт сборки прикрепляет этот сиг к /boot/vmlinuz-x.x.x.yy-generic и создает /boot/vmlinuz-x.x.x.yy-generic.efi.signed. Сценарий не очищает неподписанное изображение. Пакеты ядра имеют специальные скрипты в /etc/kernel, которые изменяют поведение apt autoremove по умолчанию. Обычно удаление linux-signed-generic будет указывать на все последующие пакеты для autoremoval, но этого не происходит для пакетов ядра до тех пор, пока не появятся две новые версии той же версии.

Во втором случае (попытка сохранить только подписанный образ ядра), по-видимому, нет последствий для удаления /boot/vmlinuz-x.x.x.yy-generic после завершения установки. Оба изображения ядра точно совпадают, за исключением сигнатуры, и они имеют все одинаковые модули и файлы конфигурации. Однако, как только обновленное ядро будет установлено, оно останется за неподписанным изображением. К счастью, при запуске скрипта выполнялись легкие перехваты при каждом новом ядре. Любые скрипты из /etc/kernel/postinst.d выполняются с помощью run-parts с двумя аргументами $1 - это версия ядра, а $2 - полный путь изображения (т. Е. [F21])

Единственная незначительная оговорка заключается в том, что удаление неподписанного изображения должно выполняться после завершения обновления grub grub.cfg. Если /boot/vmlinuz-x.x.x-yy-generic.efi.signed существует, grub добавляет это изображение к grub.cfg и игнорирует неподписанное изображение. Тем не менее, должно быть где-то в процессе, который все еще ожидает изображение без знака, потому что grub не может правильно настроить без него. Сценарий, который инициирует конфигурацию grub, - /etc/kernel/postinst.d/zz-update-grub. Я назвал свой скрипт zzz-remove-unsigned-kernel так, чтобы run-parts выполнил его после завершения всего остального.

EDIT: Я использовал этот скрипт сейчас с несколькими обновлениями сборки ядра, и все работает нормально. Я использую вариант 2 выше (удаление беззнаковых ядер). Я собираюсь отметить это как правильный ответ.

derHugo · Accepted Answer · 24 July 2018 в 20:38

Спасибо за всю помощь и ссылки. Я провел несколько часов в эти выходные и проверил следующие

Короткие ответы

Да, вы можете очистить все пакеты linux-signed*, но вам нужно установить linux-generic, если вы хотите, чтобы автоматические обновления ядра продолжали нормально функционировать. Вся конфигурация grub, kernel и initramfs обрабатывается автоматически. Скрипты установки ядра действительно обрабатывают все без каких-либо проблем. [F1] Да, вы можете избавиться от беззнаковых ядер без каких-либо вредных эффектов, но они будут продолжать возвращаться после обновлений ядра. Это невозможно решить, управляя пакетами, но его легко исправить с помощью короткого сценария.

#!/bin/sh
#
# user script: 
/etc/kernel/postinst.d/zzz-remove-unsigned-kernel
#
# after a new signed kernel image is installed, this script removes
# the unsigned image
#
if [ -e "$2.efi.signed" ]; then
    echo "/etc/kernel/postinst.d/zzz-remove-unsigned-kernel: removing $2"
    rm "$2";
fi

Более длинные ответы

В первом случае решение действительно прост. Он работает в значительной степени, как вы предполагали на первый взгляд. Тем не менее, я узнал некоторые полезные сведения о структуре пакета ubuntu для ядер. Я хотел быть уверенным, что я понял побочные эффекты или последствия, но мне также нравится видеть, как все построено. Как примечание, я использую общее ядро, но просто меняю generic на lowlatency или virtual, если это ваша вещь. Кроме того, все здесь основано на 16.10 (яккеты). Вот иерархия пакетов ядра:

linux-signed-generic - мета-пакет, что означает, что он не содержит никакого кода. В нем есть список зависимостей, который всегда содержит полную установку новейшего обновления ядра. «Завершить» означает все заголовки ядра, образ ядра, (отдельную) подпись изображения и дополнительные модули ядра для почти каждого устройства, которое может поддерживать ubuntu. linux-generic - это еще один мета-пакет, содержащий все те же реальные пакеты, за исключением сигнатуры изображения. Фактическое изображение ядра содержится только в пакете linux-image-x.x.x-yy. Пакет linux-signed-image-x.x.x-yy просто содержит отдельную подпись, а скрипт сборки прикрепляет этот сиг к /boot/vmlinuz-x.x.x.yy-generic и создает /boot/vmlinuz-x.x.x.yy-generic.efi.signed. Сценарий не очищает неподписанное изображение. Пакеты ядра имеют специальные скрипты в /etc/kernel, которые изменяют поведение apt autoremove по умолчанию. Обычно удаление linux-signed-generic будет указывать на все последующие пакеты для autoremoval, но этого не происходит для пакетов ядра до тех пор, пока не появятся две новые версии той же версии.

Во втором случае (попытка сохранить только подписанный образ ядра), по-видимому, нет последствий для удаления /boot/vmlinuz-x.x.x.yy-generic после завершения установки. Оба изображения ядра точно совпадают, за исключением сигнатуры, и они имеют все одинаковые модули и файлы конфигурации. Однако, как только обновленное ядро будет установлено, оно останется за неподписанным изображением. К счастью, при запуске скрипта выполнялись легкие перехваты при каждом новом ядре. Любые скрипты из /etc/kernel/postinst.d выполняются с помощью run-parts с двумя аргументами $1 - это версия ядра, а $2 - полный путь изображения (т. Е. [F21])

Единственная незначительная оговорка заключается в том, что удаление неподписанного изображения должно выполняться после завершения обновления grub grub.cfg. Если /boot/vmlinuz-x.x.x-yy-generic.efi.signed существует, grub добавляет это изображение к grub.cfg и игнорирует неподписанное изображение. Тем не менее, должно быть где-то в процессе, который все еще ожидает изображение без знака, потому что grub не может правильно настроить без него. Сценарий, который инициирует конфигурацию grub, - /etc/kernel/postinst.d/zz-update-grub. Я назвал свой скрипт zzz-remove-unsigned-kernel так, чтобы run-parts выполнил его после завершения всего остального.

EDIT: Я использовал этот скрипт сейчас с несколькими обновлениями сборки ядра, и все работает нормально. Я использую вариант 2 выше (удаление беззнаковых ядер). Я собираюсь отметить это как правильный ответ.

derHugo · Accepted Answer · 31 July 2018 в 12:33

Спасибо за всю помощь и ссылки. Я провел несколько часов в эти выходные и проверил следующие

Короткие ответы

Да, вы можете очистить все пакеты linux-signed*, но вам нужно установить linux-generic, если вы хотите, чтобы автоматические обновления ядра продолжали нормально функционировать. Вся конфигурация grub, kernel и initramfs обрабатывается автоматически. Скрипты установки ядра действительно обрабатывают все без каких-либо проблем. [F1] Да, вы можете избавиться от беззнаковых ядер без каких-либо вредных эффектов, но они будут продолжать возвращаться после обновлений ядра. Это невозможно решить, управляя пакетами, но его легко исправить с помощью короткого сценария.

#!/bin/sh
#
# user script: 
/etc/kernel/postinst.d/zzz-remove-unsigned-kernel
#
# after a new signed kernel image is installed, this script removes
# the unsigned image
#
if [ -e "$2.efi.signed" ]; then
    echo "/etc/kernel/postinst.d/zzz-remove-unsigned-kernel: removing $2"
    rm "$2";
fi

Более длинные ответы

В первом случае решение действительно прост. Он работает в значительной степени, как вы предполагали на первый взгляд. Тем не менее, я узнал некоторые полезные сведения о структуре пакета ubuntu для ядер. Я хотел быть уверенным, что я понял побочные эффекты или последствия, но мне также нравится видеть, как все построено. Как примечание, я использую общее ядро, но просто меняю generic на lowlatency или virtual, если это ваша вещь. Кроме того, все здесь основано на 16.10 (яккеты). Вот иерархия пакетов ядра:

linux-signed-generic - мета-пакет, что означает, что он не содержит никакого кода. В нем есть список зависимостей, который всегда содержит полную установку новейшего обновления ядра. «Завершить» означает все заголовки ядра, образ ядра, (отдельную) подпись изображения и дополнительные модули ядра для почти каждого устройства, которое может поддерживать ubuntu. linux-generic - это еще один мета-пакет, содержащий все те же реальные пакеты, за исключением сигнатуры изображения. Фактическое изображение ядра содержится только в пакете linux-image-x.x.x-yy. Пакет linux-signed-image-x.x.x-yy просто содержит отдельную подпись, а скрипт сборки прикрепляет этот сиг к /boot/vmlinuz-x.x.x.yy-generic и создает /boot/vmlinuz-x.x.x.yy-generic.efi.signed. Сценарий не очищает неподписанное изображение. Пакеты ядра имеют специальные скрипты в /etc/kernel, которые изменяют поведение apt autoremove по умолчанию. Обычно удаление linux-signed-generic будет указывать на все последующие пакеты для autoremoval, но этого не происходит для пакетов ядра до тех пор, пока не появятся две новые версии той же версии.

Во втором случае (попытка сохранить только подписанный образ ядра), по-видимому, нет последствий для удаления /boot/vmlinuz-x.x.x.yy-generic после завершения установки. Оба изображения ядра точно совпадают, за исключением сигнатуры, и они имеют все одинаковые модули и файлы конфигурации. Однако, как только обновленное ядро будет установлено, оно останется за неподписанным изображением. К счастью, при запуске скрипта выполнялись легкие перехваты при каждом новом ядре. Любые скрипты из /etc/kernel/postinst.d выполняются с помощью run-parts с двумя аргументами $1 - это версия ядра, а $2 - полный путь изображения (т. Е. [F21])

Единственная незначительная оговорка заключается в том, что удаление неподписанного изображения должно выполняться после завершения обновления grub grub.cfg. Если /boot/vmlinuz-x.x.x-yy-generic.efi.signed существует, grub добавляет это изображение к grub.cfg и игнорирует неподписанное изображение. Тем не менее, должно быть где-то в процессе, который все еще ожидает изображение без знака, потому что grub не может правильно настроить без него. Сценарий, который инициирует конфигурацию grub, - /etc/kernel/postinst.d/zz-update-grub. Я назвал свой скрипт zzz-remove-unsigned-kernel так, чтобы run-parts выполнил его после завершения всего остального.

EDIT: Я использовал этот скрипт сейчас с несколькими обновлениями сборки ядра, и все работает нормально. Я использую вариант 2 выше (удаление беззнаковых ядер). Я собираюсь отметить это как правильный ответ.

derHugo · Accepted Answer · 31 July 2018 в 23:40

Спасибо за всю помощь и ссылки. Я провел несколько часов в эти выходные и проверил следующие

Короткие ответы

Да, вы можете очистить все пакеты linux-signed*, но вам нужно установить linux-generic, если вы хотите, чтобы автоматические обновления ядра продолжали нормально функционировать. Вся конфигурация grub, kernel и initramfs обрабатывается автоматически. Скрипты установки ядра действительно обрабатывают все без каких-либо проблем. [F1] Да, вы можете избавиться от беззнаковых ядер без каких-либо вредных эффектов, но они будут продолжать возвращаться после обновлений ядра. Это невозможно решить, управляя пакетами, но его легко исправить с помощью короткого сценария.

#!/bin/sh
#
# user script: 
/etc/kernel/postinst.d/zzz-remove-unsigned-kernel
#
# after a new signed kernel image is installed, this script removes
# the unsigned image
#
if [ -e "$2.efi.signed" ]; then
    echo "/etc/kernel/postinst.d/zzz-remove-unsigned-kernel: removing $2"
    rm "$2";
fi

Более длинные ответы

В первом случае решение действительно прост. Он работает в значительной степени, как вы предполагали на первый взгляд. Тем не менее, я узнал некоторые полезные сведения о структуре пакета ubuntu для ядер. Я хотел быть уверенным, что я понял побочные эффекты или последствия, но мне также нравится видеть, как все построено. Как примечание, я использую общее ядро, но просто меняю generic на lowlatency или virtual, если это ваша вещь. Кроме того, все здесь основано на 16.10 (яккеты). Вот иерархия пакетов ядра:

linux-signed-generic - мета-пакет, что означает, что он не содержит никакого кода. В нем есть список зависимостей, который всегда содержит полную установку новейшего обновления ядра. «Завершить» означает все заголовки ядра, образ ядра, (отдельную) подпись изображения и дополнительные модули ядра для почти каждого устройства, которое может поддерживать ubuntu. linux-generic - это еще один мета-пакет, содержащий все те же реальные пакеты, за исключением сигнатуры изображения. Фактическое изображение ядра содержится только в пакете linux-image-x.x.x-yy. Пакет linux-signed-image-x.x.x-yy просто содержит отдельную подпись, а скрипт сборки прикрепляет этот сиг к /boot/vmlinuz-x.x.x.yy-generic и создает /boot/vmlinuz-x.x.x.yy-generic.efi.signed. Сценарий не очищает неподписанное изображение. Пакеты ядра имеют специальные скрипты в /etc/kernel, которые изменяют поведение apt autoremove по умолчанию. Обычно удаление linux-signed-generic будет указывать на все последующие пакеты для autoremoval, но этого не происходит для пакетов ядра до тех пор, пока не появятся две новые версии той же версии.

Во втором случае (попытка сохранить только подписанный образ ядра), по-видимому, нет последствий для удаления /boot/vmlinuz-x.x.x.yy-generic после завершения установки. Оба изображения ядра точно совпадают, за исключением сигнатуры, и они имеют все одинаковые модули и файлы конфигурации. Однако, как только обновленное ядро будет установлено, оно останется за неподписанным изображением. К счастью, при запуске скрипта выполнялись легкие перехваты при каждом новом ядре. Любые скрипты из /etc/kernel/postinst.d выполняются с помощью run-parts с двумя аргументами $1 - это версия ядра, а $2 - полный путь изображения (т. Е. [F21])

Единственная незначительная оговорка заключается в том, что удаление неподписанного изображения должно выполняться после завершения обновления grub grub.cfg. Если /boot/vmlinuz-x.x.x-yy-generic.efi.signed существует, grub добавляет это изображение к grub.cfg и игнорирует неподписанное изображение. Тем не менее, должно быть где-то в процессе, который все еще ожидает изображение без знака, потому что grub не может правильно настроить без него. Сценарий, который инициирует конфигурацию grub, - /etc/kernel/postinst.d/zz-update-grub. Я назвал свой скрипт zzz-remove-unsigned-kernel так, чтобы run-parts выполнил его после завершения всего остального.

EDIT: Я использовал этот скрипт сейчас с несколькими обновлениями сборки ядра, и все работает нормально. Я использую вариант 2 выше (удаление беззнаковых ядер). Я собираюсь отметить это как правильный ответ.

Rod Smith · Answer 6 · 22 May 2018 в 23:56

AFAIK, ядра .efi.signed такие же, как и обычные ядра, за исключением того, что они подписаны с ключом безопасности Canon EFI Secure Boot. Таким образом, если вы не загружаетесь с активной загрузкой, вы можете безопасно удалить ядра .efi.signed. Если я правильно разбираю информацию о пакете, вы должны удалить пакеты linux-signed-image-generic и linux-signed-generic, чтобы предотвратить установку будущих обновлений для подписанных ядер.

Тем не менее, Лучшим решением в долгосрочной перспективе является увеличение размера раздела /boot. Это может быть больно и даже рискованно для ваших данных, особенно если вы используете LVM или программный RAID; однако детали сильно зависят от вашего текущего расположения диска и планов по изменению этого макета по другим причинам. Обратите внимание, что в зависимости от вашего макета может быть предпочтительнее сжать раздел данных с конца и создать более крупный раздел /boot после того, как этот сокращенный раздел данных, чем попытаться сжать раздел данных с самого начала, чтобы сделать пространство для раздела /boot, чтобы оно выросло.

Наконец, если вы достаточно отчаянно хотите освободить несколько мегабайт, которые вы просматриваете дублируемыми файлами в дереве каталогов /boot/grub, вы можете подумать вообще удаляясь от GRUB. Большинство других загрузчиков не требуют столько же файлов в /boot, сколько GRUB. Если вы загружаетесь в режиме EFI, мой собственный менеджер загрузки rEFInd, скорее всего, будет самым простым в установке, и вы можете попробовать его на USB-накопителе или CD-R, чтобы посмотреть, что это такое, прежде чем сбрасывать жесткий диск. Если вы загружаетесь в режиме BIOS, LILO, SYSLINUX и даже GRUB Legacy - это все варианты, но я не имею указателей на инструкции по установке любого из них, небрежно.

Благодарю. Ваша вся веб-страница на загрузчиках EFI была действительно полезна. Раньше я встречался с этой информацией, но я очень благодарен за то, что прочитал ваш сайт с актуальной информацией в одном месте и хорошо написал. Я обязательно проверю rEFInd. На данный момент grub отвечает моим потребностям, тем более, что я не загружаю двойную загрузку моего текущего ноутбука ... это только Ubuntu (UEFI). — James Duvall, 10 April 2017 в 10:51

ubfan1 · Answer 7 · 22 May 2018 в 23:56

Ячейки .signed немного больше, поэтому, если вы не используете безопасную загрузку и пытаетесь сэкономить место, используйте unsigned и очистите подписанный. Я тоже думаю, что ваш подход с восстановлением grub будет работать. Если вы должны потерять власть перед восстановлением grub.cfg, вы всегда можете отредактировать старое меню grub и удалить подписанную часть. Конечно, вы можете оставить одну подписанную версию (последнюю) и избавиться от остальных, чтобы убедиться, что все работает так, как ожидалось, а затем повторите это для последнего, не оставив вас без известной загрузочной установки. Что касается файлов unicode.pf2 - они существуют и в моей системе. Вы можете попробовать заменить его ссылкой на другую (с удобным загрузочным носителем, если вам нужно вернуть файл туда, где есть ссылка).

файл grub.cfg автоматически генерируется скриптами в / etc / kernel и /etc/grub.d, поэтому я считаю, что редактирование вручную может вызвать проблемы с автоматическим процессом обновления. Я попробовал вашу идею о замене /boot/grub/fonts/unicode.pf2 символической ссылкой, и, похоже, она работает нормально. — James Duvall, 10 April 2017 в 10:55

Rod Smith · Answer 8 · 18 July 2018 в 15:27

AFAIK, ядра .efi.signed такие же, как и обычные ядра, за исключением того, что они подписаны с ключом безопасности Canon EFI Secure Boot. Таким образом, если вы не загружаетесь с активной загрузкой, вы можете безопасно удалить ядра .efi.signed. Если я правильно разбираю информацию о пакете, вы должны удалить пакеты linux-signed-image-generic и linux-signed-generic, чтобы предотвратить установку будущих обновлений для подписанных ядер.

Тем не менее, Лучшим решением в долгосрочной перспективе является увеличение размера раздела /boot. Это может быть больно и даже рискованно для ваших данных, особенно если вы используете LVM или программный RAID; однако детали сильно зависят от вашего текущего расположения диска и планов по изменению этого макета по другим причинам. Обратите внимание, что в зависимости от вашего макета может быть предпочтительнее сжать раздел данных с конца и создать более крупный раздел /boot после того, как этот сокращенный раздел данных, чем попытаться сжать раздел данных с самого начала, чтобы сделать пространство для раздела /boot, чтобы оно выросло.

Наконец, если вы достаточно отчаянно хотите освободить несколько мегабайт, которые вы просматриваете дублируемыми файлами в дереве каталогов /boot/grub, вы можете подумать вообще удаляясь от GRUB. Большинство других загрузчиков не требуют столько же файлов в /boot, сколько GRUB. Если вы загружаетесь в режиме EFI, мой собственный менеджер загрузки rEFInd, скорее всего, будет самым простым в установке, и вы можете попробовать его на USB-накопителе или CD-R, чтобы посмотреть, что это такое, прежде чем сбрасывать жесткий диск. Если вы загружаетесь в режиме BIOS, LILO, SYSLINUX и даже GRUB Legacy - это все варианты, но я не имею указателей на инструкции по установке любого из них, небрежно.

ubfan1 · Answer 9 · 18 July 2018 в 15:27

Ячейки .signed немного больше, поэтому, если вы не используете безопасную загрузку и пытаетесь сэкономить место, используйте unsigned и очистите подписанный. Я тоже думаю, что ваш подход с восстановлением grub будет работать. Если вы должны потерять власть перед восстановлением grub.cfg, вы всегда можете отредактировать старое меню grub и удалить подписанную часть. Конечно, вы можете оставить одну подписанную версию (последнюю) и избавиться от остальных, чтобы убедиться, что все работает так, как ожидалось, а затем повторите это для последнего, не оставив вас без известной загрузочной установки. Что касается файлов unicode.pf2 - они существуют и в моей системе. Вы можете попробовать заменить его ссылкой на другую (с удобным загрузочным носителем, если вам нужно вернуть файл туда, где есть ссылка).

Rod Smith · Answer 10 · 24 July 2018 в 20:38

AFAIK, ядра .efi.signed такие же, как и обычные ядра, за исключением того, что они подписаны с ключом безопасности Canon EFI Secure Boot. Таким образом, если вы не загружаетесь с активной загрузкой, вы можете безопасно удалить ядра .efi.signed. Если я правильно разбираю информацию о пакете, вы должны удалить пакеты linux-signed-image-generic и linux-signed-generic, чтобы предотвратить установку будущих обновлений для подписанных ядер.

Тем не менее, Лучшим решением в долгосрочной перспективе является увеличение размера раздела /boot. Это может быть больно и даже рискованно для ваших данных, особенно если вы используете LVM или программный RAID; однако детали сильно зависят от вашего текущего расположения диска и планов по изменению этого макета по другим причинам. Обратите внимание, что в зависимости от вашего макета может быть предпочтительнее сжать раздел данных с конца и создать более крупный раздел /boot после того, как этот сокращенный раздел данных, чем попытаться сжать раздел данных с самого начала, чтобы сделать пространство для раздела /boot, чтобы оно выросло.

Наконец, если вы достаточно отчаянно хотите освободить несколько мегабайт, которые вы просматриваете дублируемыми файлами в дереве каталогов /boot/grub, вы можете подумать вообще удаляясь от GRUB. Большинство других загрузчиков не требуют столько же файлов в /boot, сколько GRUB. Если вы загружаетесь в режиме EFI, мой собственный менеджер загрузки rEFInd, скорее всего, будет самым простым в установке, и вы можете попробовать его на USB-накопителе или CD-R, чтобы посмотреть, что это такое, прежде чем сбрасывать жесткий диск. Если вы загружаетесь в режиме BIOS, LILO, SYSLINUX и даже GRUB Legacy - это все варианты, но я не имею указателей на инструкции по установке любого из них, небрежно.

Благодарю. Ваша вся веб-страница на загрузчиках EFI была действительно полезна. Раньше я встречался с этой информацией, но я очень благодарен за то, что прочитал ваш сайт с актуальной информацией в одном месте и хорошо написал. Я обязательно проверю rEFInd. На данный момент grub отвечает моим потребностям, тем более, что я не загружаю двойную загрузку моего текущего ноутбука ... это только Ubuntu (UEFI). — James Duvall, 10 April 2017 в 10:51

ubfan1 · Answer 11 · 24 July 2018 в 20:38

Ячейки .signed немного больше, поэтому, если вы не используете безопасную загрузку и пытаетесь сэкономить место, используйте unsigned и очистите подписанный. Я тоже думаю, что ваш подход с восстановлением grub будет работать. Если вы должны потерять власть перед восстановлением grub.cfg, вы всегда можете отредактировать старое меню grub и удалить подписанную часть. Конечно, вы можете оставить одну подписанную версию (последнюю) и избавиться от остальных, чтобы убедиться, что все работает так, как ожидалось, а затем повторите это для последнего, не оставив вас без известной загрузочной установки. Что касается файлов unicode.pf2 - они существуют и в моей системе. Вы можете попробовать заменить его ссылкой на другую (с удобным загрузочным носителем, если вам нужно вернуть файл туда, где есть ссылка).

файл grub.cfg автоматически генерируется скриптами в / etc / kernel и /etc/grub.d, поэтому я считаю, что редактирование вручную может вызвать проблемы с автоматическим процессом обновления. Я попробовал вашу идею о замене /boot/grub/fonts/unicode.pf2 символической ссылкой, и, похоже, она работает нормально. — James Duvall, 10 April 2017 в 10:55

Rod Smith · Answer 12 · 31 July 2018 в 12:33

AFAIK, ядра .efi.signed такие же, как и обычные ядра, за исключением того, что они подписаны с ключом безопасности Canon EFI Secure Boot. Таким образом, если вы не загружаетесь с активной загрузкой, вы можете безопасно удалить ядра .efi.signed. Если я правильно разбираю информацию о пакете, вы должны удалить пакеты linux-signed-image-generic и linux-signed-generic, чтобы предотвратить установку будущих обновлений для подписанных ядер.

Тем не менее, Лучшим решением в долгосрочной перспективе является увеличение размера раздела /boot. Это может быть больно и даже рискованно для ваших данных, особенно если вы используете LVM или программный RAID; однако детали сильно зависят от вашего текущего расположения диска и планов по изменению этого макета по другим причинам. Обратите внимание, что в зависимости от вашего макета может быть предпочтительнее сжать раздел данных с конца и создать более крупный раздел /boot после того, как этот сокращенный раздел данных, чем попытаться сжать раздел данных с самого начала, чтобы сделать пространство для раздела /boot, чтобы оно выросло.

Наконец, если вы достаточно отчаянно хотите освободить несколько мегабайт, которые вы просматриваете дублируемыми файлами в дереве каталогов /boot/grub, вы можете подумать вообще удаляясь от GRUB. Большинство других загрузчиков не требуют столько же файлов в /boot, сколько GRUB. Если вы загружаетесь в режиме EFI, мой собственный менеджер загрузки rEFInd, скорее всего, будет самым простым в установке, и вы можете попробовать его на USB-накопителе или CD-R, чтобы посмотреть, что это такое, прежде чем сбрасывать жесткий диск. Если вы загружаетесь в режиме BIOS, LILO, SYSLINUX и даже GRUB Legacy - это все варианты, но я не имею указателей на инструкции по установке любого из них, небрежно.

Благодарю. Ваша вся веб-страница на загрузчиках EFI была действительно полезна. Раньше я встречался с этой информацией, но я очень благодарен за то, что прочитал ваш сайт с актуальной информацией в одном месте и хорошо написал. Я обязательно проверю rEFInd. На данный момент grub отвечает моим потребностям, тем более, что я не загружаю двойную загрузку моего текущего ноутбука ... это только Ubuntu (UEFI). — James Duvall, 10 April 2017 в 10:51

ubfan1 · Answer 13 · 31 July 2018 в 12:33

Ячейки .signed немного больше, поэтому, если вы не используете безопасную загрузку и пытаетесь сэкономить место, используйте unsigned и очистите подписанный. Я тоже думаю, что ваш подход с восстановлением grub будет работать. Если вы должны потерять власть перед восстановлением grub.cfg, вы всегда можете отредактировать старое меню grub и удалить подписанную часть. Конечно, вы можете оставить одну подписанную версию (последнюю) и избавиться от остальных, чтобы убедиться, что все работает так, как ожидалось, а затем повторите это для последнего, не оставив вас без известной загрузочной установки. Что касается файлов unicode.pf2 - они существуют и в моей системе. Вы можете попробовать заменить его ссылкой на другую (с удобным загрузочным носителем, если вам нужно вернуть файл туда, где есть ссылка).

файл grub.cfg автоматически генерируется скриптами в / etc / kernel и /etc/grub.d, поэтому я считаю, что редактирование вручную может вызвать проблемы с автоматическим процессом обновления. Я попробовал вашу идею о замене /boot/grub/fonts/unicode.pf2 символической ссылкой, и, похоже, она работает нормально. — James Duvall, 10 April 2017 в 10:55

Rod Smith · Answer 14 · 31 July 2018 в 23:40

AFAIK, ядра .efi.signed такие же, как и обычные ядра, за исключением того, что они подписаны с ключом безопасности Canon EFI Secure Boot. Таким образом, если вы не загружаетесь с активной загрузкой, вы можете безопасно удалить ядра .efi.signed. Если я правильно разбираю информацию о пакете, вы должны удалить пакеты linux-signed-image-generic и linux-signed-generic, чтобы предотвратить установку будущих обновлений для подписанных ядер.

Тем не менее, Лучшим решением в долгосрочной перспективе является увеличение размера раздела /boot. Это может быть больно и даже рискованно для ваших данных, особенно если вы используете LVM или программный RAID; однако детали сильно зависят от вашего текущего расположения диска и планов по изменению этого макета по другим причинам. Обратите внимание, что в зависимости от вашего макета может быть предпочтительнее сжать раздел данных с конца и создать более крупный раздел /boot после того, как этот сокращенный раздел данных, чем попытаться сжать раздел данных с самого начала, чтобы сделать пространство для раздела /boot, чтобы оно выросло.

Наконец, если вы достаточно отчаянно хотите освободить несколько мегабайт, которые вы просматриваете дублируемыми файлами в дереве каталогов /boot/grub, вы можете подумать вообще удаляясь от GRUB. Большинство других загрузчиков не требуют столько же файлов в /boot, сколько GRUB. Если вы загружаетесь в режиме EFI, мой собственный менеджер загрузки rEFInd, скорее всего, будет самым простым в установке, и вы можете попробовать его на USB-накопителе или CD-R, чтобы посмотреть, что это такое, прежде чем сбрасывать жесткий диск. Если вы загружаетесь в режиме BIOS, LILO, SYSLINUX и даже GRUB Legacy - это все варианты, но я не имею указателей на инструкции по установке любого из них, небрежно.

Благодарю. Ваша вся веб-страница на загрузчиках EFI была действительно полезна. Раньше я встречался с этой информацией, но я очень благодарен за то, что прочитал ваш сайт с актуальной информацией в одном месте и хорошо написал. Я обязательно проверю rEFInd. На данный момент grub отвечает моим потребностям, тем более, что я не загружаю двойную загрузку моего текущего ноутбука ... это только Ubuntu (UEFI). — James Duvall, 10 April 2017 в 10:51

ubfan1 · Answer 15 · 31 July 2018 в 23:40

Ячейки .signed немного больше, поэтому, если вы не используете безопасную загрузку и пытаетесь сэкономить место, используйте unsigned и очистите подписанный. Я тоже думаю, что ваш подход с восстановлением grub будет работать. Если вы должны потерять власть перед восстановлением grub.cfg, вы всегда можете отредактировать старое меню grub и удалить подписанную часть. Конечно, вы можете оставить одну подписанную версию (последнюю) и избавиться от остальных, чтобы убедиться, что все работает так, как ожидалось, а затем повторите это для последнего, не оставив вас без известной загрузочной установки. Что касается файлов unicode.pf2 - они существуют и в моей системе. Вы можете попробовать заменить его ссылкой на другую (с удобным загрузочным носителем, если вам нужно вернуть файл туда, где есть ссылка).

файл grub.cfg автоматически генерируется скриптами в / etc / kernel и /etc/grub.d, поэтому я считаю, что редактирование вручную может вызвать проблемы с автоматическим процессом обновления. Я попробовал вашу идею о замене /boot/grub/fonts/unicode.pf2 символической ссылкой, и, похоже, она работает нормально. — James Duvall, 10 April 2017 в 10:55

Могу ли я безопасно очищать подписанные ядра EFI? (в качестве альтернативы, я могу избавиться от неподписанных ядер?)

15 ответов

Короткие ответы

Более длинные ответы

Короткие ответы

Более длинные ответы

Короткие ответы

Более длинные ответы

Короткие ответы

Более длинные ответы

Короткие ответы

Более длинные ответы

Другие вопросы по тегам:

Похожие вопросы: