установка личинки и рабочего ядра по старой и поврежденной debian системе

CPU

Процесс может снизить свой приоритет CPU (но не уменьшить его, man 2 setpriority ). Кроме того, он может усыпить себя в течение определенного времени. Но он не может решить, как экономить время ЦП другим процессам.

Ситуацию с потоками см. в комментарии psusi.

память Новый процесс получает начальный объем ОЗУ (однако не знаю, является ли это значением ядра по умолчанию или заданным в данных заголовка двоичного файла). Если требуется больше оперативной памяти, процесс запрашивает у ядра дополнительную информацию (см. man 2 mmap ).

Как и во время ЦП, процесс не может решить, какой процесс получит больше памяти, если освободит часть.

Выход из процесса

Если процесс завершает работу (либо по собственному решению, либо в результате прекращения), то ядро автоматически освобождает свои ресурсы. Процесс может освободить «все» его ОЗУ перед выходом, но нет причин для этого. Вместо этого используются вызовы _ exit или exit _ group .

-121--210006-

Попробуйте этот парень =):

sed -n 'line_num p' | bash

или

"$(sed -n 'line_num p')"
-121--41183-

Поскольку $ ДИСПЛЕЯ правильно наборы и файл ~/.Xauthority не создан, это может означать, что, хотя X11 пересылка принимается во внимание, xauth не выполняется. Одной из причин может быть то, что его нет в пути (у меня была эта проблема в Mac OS X, но это было бы странно в Linux). Можно выполнить работу самостоятельно, создав файл ~/.ssh/rc . Например, у меня есть следующее:

if [ -n "$DISPLAY" ]; then
  echo "DISPLAY: $DISPLAY" >&2
  if read proto cookie; then
    if [ `echo $DISPLAY | cut -c1-10` = 'localhost:' ]; then
      echo add unix:`echo $DISPLAY | cut -c11-` $proto $cookie
    else
      echo add $DISPLAY $proto $cookie
    fi | $HOME/.ssh/xauth.wrapper -q -
  fi
fi

, где ~/.ssh/xauth.wrapper является оболочкой для xauth , которая реализует блокировку файла ~/.Xauthority . Но вы можете использовать только xauth или полный путь к xauth на всякий случай... Это во многом похоже на то, что описано на справочной странице sshd (8) (см. раздел «SSHRC»).

Будьте осторожны, чтобы не ошибиться.

0
25.07.2014, 18:47
2 ответа

Как заметил Дероберт, hda -> sda - ожидаемое изменение с давних пор.

Изменение имени рейд-массива было странным, но в конце концов оно разрешилось само собой.

Я попытался загрузиться с live cd-дистрибутива, смонтировать массив raid, смонтировать загрузочный раздел, затем apt-get install новое ядро. Эта процедура вызвала ошибку, потому что я не знал, что мне следовало смонтировать / boot , / proc и / sys .

Таким образом, точная процедура такова:

  • загрузка из живого дистрибутива (debian CD 1 в режиме восстановления в порядке)

  • смонтировать корневой раздел (например, в / chroot) и, в конечном итоге, загрузочный раздел, если он отличается от корневого)

  • bind монтировать специальные устройства:

    • mount --bind / sys / chroot / sys
    • mount --bind / proc / chroot / proc
    • mount - привязать / dev / chroot / dev
  • chroot к корневому разделу

  • установить новое ядро ​​

  • перезагрузить

0
28.01.2020, 02:52

новый драйвер ATA в ядре использует /dev/sda, старые драйверы все еще поддерживаются, но вам придется редактировать ядро с помощью chrooting в вашей системе с помощью livecd.

Device drivers --->
 <*> ATA/ATAPI/MFM/TLL support (deprecated)
 <*> Serial ATA and Parallel ATA drivers --->

Для chrooting я всегда использую минимальную установку gentoo cd и как работать в chrooting в вашей системе вы можете прочитать в gentoo handbook, он также должен работать с вашей системой. Возможно, есть другой способ для пользователей debian, но этот способ должен работать для вас двоих.

Я надеюсь, что это решение вашей проблемы.

1
28.01.2020, 02:52

Теги

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