Почему netconsole не ищет маршрут к серверу регистрации?
Если я правильно понимаю, у вас та же проблема, что и у меня, когда я пытался сделать то же самое с Apache2. Вот как его очистить и удалить.
Сначала введите. service --status-all
Чтобы узнать его точное название, просто найдите его в списке.
Далее введите apt-get --purge nameofprogramyouwanttopurge
НЕ ПРОДОЛЖАЙТЕ, пока не прочитаете следующую часть Теперь, когда эта команда инициализируется, она даст вам опцию (y,n), и вы выберете да или нет. Прежде чем выбрать "да" или "нет", полностью прочитайте весь вывод в терминале и убедитесь, что каждый файл, который команда собирается удалить, это то, что вы хотите удалить. Не нажимайте "да", пока не убедитесь, что не удаляются пакеты или зависимости, которые вы не хотите удалять. Не ленитесь и пропустите чтение.
Если вы удовлетворены тем, что все файлы из списка будут очищены, выберите "Да" и переходите к следующему шагу.
После завершения очистки и удаления вы захотите ввести
apt-get upgrade
Ответьте здесь с выводом этой строки, прежде чем сказать "да" обновлению.
Netconsole был разработан для работы как можно скорее после перезагрузки. Из документации по ядру:
Netconsole был разработан, чтобы быть как можно более мгновенным, до включить регистрацию даже самых критических ошибок ядра. Оно работает из контекстов IRQ, а также не разрешает прерывания, в то время как отправка пакетов. Из-за этих уникальных потребностей конфигурация не может быть более автоматическим, и некоторые фундаментальные ограничения останутся: поддерживаются только IP-сети, пакеты UDP и устройства Ethernet.
Как видите, netconsole предназначен для отладки, а не для ежедневного использования. Для этого дизайнеры хотели, чтобы он был как можно более простым и надежным, даже если его настройка очень грубая.
Если бы функция была разработана автоматически, чтобы выяснить, куда отправить пакет, код должен был бы запросить таблицу маршрутизации, чтобы узнать, находится ли узел назначения в той же подсети, но маршрутизация, вероятно, не настроена при отправке первых сообщений. Даже если мы можем предположить, что узел назначения находится в той же подсети, не зная MAC-адреса назначения, реализация сначала должна будет выполнить ARP-запрос. Во время ожидания ответа ядро аварийно завершает работу и сообщение о сбое теряется.