dear friend Speccyfighter , i would like to ask you ,
1)what can I do now with repositories?
2)how can I update the system without changing the kernel or modules 
3)how to change this(look photo)to display correctly??? P9
3) what can i do now with pin configuration ?
thanks you
Hello Dimitrios son of Hellas.
I would not have guessed to perform `apt-get dist-upgrade` from p8 to p9 with Pin-Priority
Technically, it is wrong to dist-upgrade from the p8 repository to the p9 repository with Pin-Priority (Pin-Priority applies to downgrade):
man apt_preferences Pin-Priority:
P> 1000
causes a version to be installed even if this constitutes a downgrade of the package
However, the system updated in this way to p9 from 2020/03/17 still shuts down and reboots. I would use this to clarify the source of the shutdown failure a little more precisely: is the kernel to blame, if the kernel is what, or is the system to blame. To clarify what can be in the system on p9 and what should not be, so that there is no shutdown failure. And to make it more predictable in the future.
First, without removing the un-def-4.9 kernel (kernel in Simply p8), install the un-def-5.7 and std-def-5.4 kernels from p9:
Rename /etc/apt/preferences to fallback and inactive:
# mv /etc/apt/preferences /etc/apt/preferences.bak
Comment out the lines through mcedit in /etc/apt/sources.list, putting the # symbol at the beginning of these lines:
# rpm http://ftp.altlinux.org/pub/distributions/archive/p9/date/2020/03/17/ x86_64 classic
# rpm http://ftp.altlinux.org/pub/distributions/archive/p9/date/2020/03/17/ x86_64-i586 classic
# rpm http://ftp.altlinux.org/pub/distributions/archive/p9/date/2020/03/17/ noarch classic
Add repository p9
# apt-repo add p9
Run the command to update the package database
# apt-get update
Install un-def and std-def kernels from p9
# update-kernel -t un-def
# update-kernel -t std-def
Boot with each of them and see which kernel the shutdown fails on. Booting with each of the kernels will show which of the kernels will (or will not) fail shutdown.
In the system, you will also have the un-def-4.9 kernel with which you can boot at any time.
This sequence of actions will more clearly show whether the kernel is indeed at fault. And if the core is to blame, then which one. And if necessary, you can remove the std-def-5.4 and un-def-5.7 kernels, leaving un-def-4.9 - only the specified kernels will be removed.
If any of these kernels are really to blame, you can write a bug report to bugzilla.altlinux.org to fix the error.
Я бы не догадался выполнять `apt-get dist-upgrade` с p8 на p9 с Pin-Priority
Технически, это неправильно выполнять dist-upgrade с перездом с репозитория p8 на репозиторий p9 с Pin-Priority (Pin-Priority применяется для downgrade):
man apt_preferences Pin-Priority:
P > 1000
causes a version to be installed even if this constitutes a downgrade of the package
Однако система обновленная таким образом до p9 от 2020/03/17 у вас всё таки выключается и перезагружается. Я бы воспользовался этим, чтобы прояснить источник отказа выключения чуть более точнее: виновато ли ядро, если ядро то какое, или виновата система. Чтобы уточнить, что в системе на p9 может быть, а чего быть не должно, чтобы не было отказа shutdown. И чтобы в будущем это было более предсказуемым.
Сначала, не удаляя ядро un-def-4.9 (ядро в Simply p8), из p9 установить ядра un-def-5.7 и std-def-5.4:
Переименовать /etc/apt/preferences в резервный и неактивный:
# mv /etc/apt/preferences /etc/apt/preferences.bak
Закомментировать через mcedit в /etc/apt/sources.list строки, поставив в начале этих строк символ #:
# rpm http://ftp.altlinux.org/pub/distributions/archive/p9/date/2020/03/17/ x86_64 classic
# rpm http://ftp.altlinux.org/pub/distributions/archive/p9/date/2020/03/17/ x86_64-i586 classic
# rpm http://ftp.altlinux.org/pub/distributions/archive/p9/date/2020/03/17/ noarch classic
Выполнить добавление репозитория p9
# apt-repo add p9
Выполнить команду обновления базы пакетов
# apt-get update
Выполнить установку ядер un-def и std-def из p9
# update-kernel -t un-def
# update-kernel -t std-def
Загрузиться с каждым из них и посмотреть, на каком ядре последует отказ shutdown. Загрузка с каждым из ядер, покажет, на каком из ядер последует (или не последует) отказ shutdown.
В системе у вас останется и ядро un-def-4.9 с которым можно будет загрузиться в любой момент.
Эта последовательность действий, более ясно покажет, дествительно ли виновато ядро. И если виновато ядро, то какое. А при необходимости можно удалить ядра std-def-5.4 и un-def-5.7, оставив un-def-4.9, - будут удалены только указанные ядра.
Если действительно виновато какое-то из этих ядер, можно будет писать багрепорт на bugzilla.altlinux.org для исправления ошибки.
