Как вернуться к выпускам ядра LTS по умолчанию после модернизации ядра вручную?

Я столкнулся с аппаратной проблемой, которая заставила меня понизиться до более низкого уровня (5,4) ядра. Но через несколько месяцев проблема кажется исправленной и последними ядрами (5.10 на данный момент). Моя проблема сейчас заключается в том, что, видимо, вручную сохраняя старое ядро Ubuntu по умолчанию, затем вручную обновляя на одну точку выпуска, моя система больше не загружает/не устанавливает стандартные обновления ядра выпуска.

Я вручную установил (через Mainline) последнее ядро 5.10, но, как и большинство ядер из Mainline, они обозначены значком Tux. Мое последнее установочное ядро по умолчанию все еще там, обозначенное круглым оранжевым логотипом Ubuntu. Кажется, я сейчас не в курсе.

Я бы не хотел продолжать использовать Mainline для загрузки/установки стабильных обновлений ядра в полуручном режиме. Как вернуться на трек получения обычных обновлений ядра с помощью Ubuntu в стандартном обновлении программного обеспечения?

Ubuntu 20,04

Я сделал ряд поисков способов выполнения сценария или команды при возобновлении из приостановки, и придумал несколько различных методов для этого, таких как то, что описано здесь - ни один из которых не работал на меня.

Первым методом, который я нашел, было использование pm-utils. Видимо, этот метод был удален из Ubuntu , начиная с или около 15,04

Следующее, что я обнаружил, было использовать systemd/system-sleep - это также не сработало для меня. Я попробовал создать сценарий в каталоге/usr/lib/systemd/system-sleep, также попробовал каталог/lib/systemd/system-sleep (который, очевидно, связан с/usr/lib/systemd/system-sleep, поскольку изменения в одном появляются в другом). Я также попытался изменить уже существующий сценарий, называемый hdparm - это также не сработало (модификация, которую я сделал, была touch/tmp/xmodlog.log , но файл так и не появился).

Итак, кто-нибудь может сказать мне, какой правильный способ запустить сценарий или команду после возобновления?

Спасибо за любые входные данные/предложения/веб-сайты - особенно с подробными инструкциями и объяснениями того, что происходит на этом пути...

Изменить:

На основе ответа , предоставленного Matigo, я сделал следующее:

В/etc/pm/sleep.d я создал сценарий, названный 00xmodkey.sh. Я добавил следующий код сценария в этот файл, затем убедился, что он принадлежит root и что у него есть разрешения на выполнение.

Содержимое сценария (в качестве оболочки были использованы sh и bash):

#!/bin/sh

case "${1}" in
    resume|thaw) 
        touch /tmp/xmodlog.log
        echo "$(date) - lib testing" >> /tmp/xmodlog.log
        ;;
esac

Проверенное владение и разрешения:

ls -l 00xmodkey.sh
-rwxr-xr-x 1 root root 257 Feb  4 22:49 00xmodkey.sh

Затем я ввел систему в режим приостановки. Ждал около 20 секунд. Разбудили систему. Поиск файла xmodlog.log. Нет файла.

Значит, я все еще упускаю что-то...

Изменить 2:

На основании ответа blitzter47 я поместил сценарий в /lib/systemd/system-sleep/ под названием 20xmodmap, который впоследствии был помечен как исполняемый. Файл сценария содержал следующее:

#!/bin/sh
# Remap a key to allow context menu access

case "$1" in
    post) 
        echo "$(date) - lib testing" >> /tmp/xmodlog.log
        ;;
    *)
        echo "$(date) - $(1) $(2) - lib testing" >> /tmp/xmodlog.log
        ;;
esac

exit 0

Файл xmodlog.log никогда не появляется в/tmp, поэтому либо что-то не так со сценарием, либо сценарий никогда не выполняется.

Изменить 3:

На основании приведенных ниже комментариев я изменил сценарий, чтобы явно задать путь к командам, и использовал touch , а не echo . Никаких изменений в результатах. Также пыталось перемещение расположение временного файла, просто чтобы убедиться, что это не что-то странное происходит из-за использования /tmp , но опять же, никаких изменений. Вот модифицированный сценарий:

#!/bin/sh
# Remap a key to allow context menu access

case "$1" in
    post) 
        /bin/touch /home/tracy/xmodlog.log
        ;;
    *)
        /bin/touch /home/tracy/xmodlog.log
        ;;
esac

exit 0

Так что, даже если все явно указано, и с помощью папки, к которой, я знаю, мой пользователь имеет доступ (система должна иметь доступ к чему-либо, если она работает в системном контексте), она все равно, кажется, не работает.

Edit 4:

Запрошенные выходные данные от 'sudo systemctl status sleep.target suspend.target hibernate.target hybrid-sleep.target':

tracy@tracy-HP17:~$ sudo systemctl status sleep.target suspend.target hibernate.target hybrid-sleep.target
● sleep.target - Sleep
     Loaded: loaded (/lib/systemd/system/sleep.target; static; vendor preset: e>
     Active: inactive (dead)
       Docs: man:systemd.special(7)

● suspend.target - Suspend
     Loaded: loaded (/lib/systemd/system/suspend.target; static; vendor preset:>
     Active: inactive (dead)
       Docs: man:systemd.special(7)

● hibernate.target - Hibernate
     Loaded: loaded (/lib/systemd/system/hibernate.target; static; vendor prese>
     Active: inactive (dead)
       Docs: man:systemd.special(7)

● hybrid-sleep.target - Hybrid Suspend+Hibernate
     Loaded: loaded (/lib/systemd/system/hybrid-sleep.target; static; vendor pr>
     Active: inactive (dead)
       Docs: man:systemd.special(7)

Edit 5:

Итак, я вошел и очистил сценарий, и убедился, что все работает (работает из командной строки). Ниже приведены команды и выходные данные настройки и запуска сценария:

tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ which ls
/usr/bin/ls
tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ which echo
/usr/bin/echo
tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ ls -la /lib/systemd/system-sleep
total 32
drwxr-xr-x  2 root root  4096 Mar  9 21:30 .
drwxr-xr-x 17 root root 12288 Jan 19 13:39 ..
-rwxr-xr-x  1 root root   405 Mar  9 21:22 20xmodmap
-rwxr-xr-x  1 root root   148 Feb 26 22:01 hdparm
-rw-r--r--  1 root root   404 Mar  9 20:54 holding.txt
-rwxr-xr-x  1 root root   219 Jul 21  2020 unattended-upgrades
tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ nl 20xmodmap
     1  #!/bin/sh
     2  # Remap a key to allow context menu access
       
     3  /usr/bin/ls /home/tracy/TestScript/
       
     4  case "$1" in
     5      post) 
     6  #       /usr/bin/touch /home/tracy/TestScript/xmodlog.log
     7          /usr/bin/echo "post" > /home/tracy/TestScript/xmodlog.log
     8          ;;
     9      *)
    10  #       /usr/bin/touch /home/tracy/TestScript/xmodlog.log
    11          /usr/bin/echo "default" > /home/tracy/TestScript/xmodlog.log
    12          ;;
    13  esac
       
    14  /usr/bin/ls /home/tracy/TestScript/
       
    15  exit 0
tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ ls /home/tracy/TestScript
tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ sudo ./20xmodmap
[sudo] password for tracy: 
xmodlog.log
tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ ls /home/tracy/TestScript
xmodlog.log
tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ nl /home/tracy/TestScript/xmodlog.log
     1  default
tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ rm /home/tracy/TestScript/xmodlog.log
rm: remove write-protected regular file '/home/tracy/TestScript/xmodlog.log'? y
tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ ls /home/tracy/TestScript

Ниже приведены две последние строки (по метке времени), показанные журналом как перед сном, так и после возобновления:

Последние две строки перед сном

tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ journalctl -xe | grep 'sleep\|suspend'
Mar 09 21:30:21 tracy-HP17 sudo[132552]:    tracy : TTY=pts/0 ; PWD=/usr/lib/systemd/system-sleep ; USER=root ; COMMAND=./20xmodmap
Mar 09 21:37:40 tracy-HP17 sudo[132821]:    tracy : TTY=pts/0 ; PWD=/usr/lib/systemd/system-sleep ; USER=root ; COMMAND=./20xmodmap

Последние две строки после возобновления

tracy@tracy-HP17:/usr/lib/systemd/system-sleep$ journalctl -xe | grep 'sleep\|suspend'
Mar 09 21:30:21 tracy-HP17 sudo[132552]:    tracy : TTY=pts/0 ; PWD=/usr/lib/systemd/system-sleep ; USER=root ; COMMAND=./20xmodmap
Mar 09 21:37:40 tracy-HP17 sudo[132821]:    tracy : TTY=pts/0 ; PWD=/usr/lib/systemd/system-sleep ; USER=root ; COMMAND=./20xmodmap

Похоже, что сценарий не выполняется после возобновления, так как выходные данные журнала как до, так и после идентичны....

Изменить 6:

OK, поэтому, основываясь на комментарии ниже blitzter47, я углубился в то, что все происходит здесь с точки зрения управления питанием. И похоже, у меня были некоторые (неверные) предубеждения о том, что происходит.

Сначала, следуя примеру комментария, выдав sudo systemctl приостановить , затем пробуждение системы выполняет скрипт, расположенный в /lib/systemd/system-sleep , как указано создаваемым целевым файлом и содержащий слово «post». Это первый раз (кроме выполнения сценария из командной строки), когда это произошло (и я, понятно, рад, что этот прогресс достигается).

Это заставило меня задуматься, в чем разница в этом повелении и что я делал. И после прочтения статьи Understanding Suspend Я полагаю, что произошло то, что я достиг состояния S1, но что команда sudo systemctl suspend достигла состояния S3. Или, говоря другим путям, я просто запирал экран, но на самом деле не приостанавливал работу компьютера (за исключением случаев, когда машина не работала в течение длительного периода времени,который я затрону через только минуту).

Так, я возвратился по тому, что я на самом деле пытался выполнить - который должен заставить особое сочетание клавиш выживать, когда система "приостановила". Я ранее отметил, что были некоторые случаи, где сочетание клавиш выживет, когда я возвратился к компьютеру и некоторым случаям, где это не сделало, но я не выяснил точно, куда это прибывало из. Ну, я теперь устанавливаю это времена, которые это пережило, были времена, когда система просто заблокировала экран (т.е. достиг состояния S1), но на самом деле не приостановил (т.е. не достиг состояния S3). Принимая во внимание, что времена, которые сочетание клавиш не пережило, машина, на самом деле достигли подозреваемого (S3) состояние - возможно, будучи оставленным без помех в течение более длительного промежутка времени.

Так, нижняя строка, кажется, что системный сон делает работа правильно для того, что я пытаюсь сделать (теперь, когда я на самом деле понимаю то, что это). Так, мой следующий шаг должен будет на самом деле обновить сценарий от Редактирования 5 (который работает правильно, когда я достигаю, приостанавливают (т.е. состояние S3)) с командой для восстановления моего сочетания клавиш, затем посмотрите, существуют ли ситуации, где сочетанию клавиш не удается выжить, затем переоценить то, что происходит в той точке.

Так, учитывая все это, я собираюсь отметить исходный ответ blitzter47 , как принято, и если/когда я отмечу, что мое сочетание клавиш не переживает особое состояние, то я отправлю новый вопрос с (надо надеяться), лучшей идеей того, какова первопричина.