Re: [sisyphus] Reeboot в процессе dist-upgrage

Re: [sisyphus] Reeboot в процессе dist-upgrage

[Sergey]

On Tuesday 09 April 2019, Yuri Khachaturyan wrote:

> 225: systemd-sysvinit-1:241-alt4             ####################### [ 30%]
> 226: systemd-1:241-alt4                      ####################### [ 30%]

Ещё один пострадавший. Вот тут про аналогичную ситуацию:
https://lists.altlinux.org/pipermail/devel/2019-March/207479.html

> И система уходит в циклический ребут с kernel-panic.

У меня всё же грузилось.

> Через rescue при попытке chroot выдает:
> на все, что есть в /lib64/*.so - file too short. 

а rpm запускается? Если да, то в следующих сообщениях от вышеприведённой
ссылки процесс описан.

-- 
С уважением, Сергей
a_s_y@sama.ru

Re: [sisyphus] Reboot в процессе dist-upgrage

[Sergey]

On Tuesday 09 April 2019, Sergey wrote:

> > 225: systemd-sysvinit-1:241-alt4             ####################### [ 30%]
> > 226: systemd-1:241-alt4                      ####################### [ 30%]
> 
> Ещё один пострадавший. Вот тут про аналогичную ситуацию:
> https://lists.altlinux.org/pipermail/devel/2019-March/207479.html

https://bugzilla.altlinux.org/36579

-- 
С уважением, Сергей.

Re: [sisyphus] Reeboot в процессе dist-upgrage

[Anton V. Boyarshinov]

В Wed, 10 Apr 2019 12:49:17 +0300
Yuri Khachaturyan <yukh@yukh.ru> пишет:

> rpm -Uvh --force --nodeps *.rpm
> 
> помогло частично. Сервер загрузился, сервисы все поднялись, но не могу
> залогиниться ни локально, ни через ssh (под юзером ssh пустил, а вот
> su- выдает ошибку).

Указание того, какую именно ошибку выдаёт su, может помочь

> 
> 
> 
> вт, 9 апр. 2019 г. в 20:36, Sergey <a_s_y@sama.ru>:
> 
> > On Tuesday 09 April 2019, Yuri Khachaturyan wrote:
> >  
> > > 225: systemd-sysvinit-1:241-alt4
> > > ####################### [  
> > 30%]  
> > > 226: systemd-1:241-alt4
> > > ####################### [  
> > 30%]
> >
> > Ещё один пострадавший. Вот тут про аналогичную ситуацию:
> > https://lists.altlinux.org/pipermail/devel/2019-March/207479.html
> >  
> > > И система уходит в циклический ребут с kernel-panic.  
> >
> > У меня всё же грузилось.
> >  
> > > Через rescue при попытке chroot выдает:
> > > на все, что есть в /lib64/*.so - file too short.  
> >
> > а rpm запускается? Если да, то в следующих сообщениях от
> > вышеприведённой ссылки процесс описан.
> >
> > --
> > С уважением, Сергей
> > a_s_y@sama.ru
> > _______________________________________________
> > Sisyphus mailing list
> > Sisyphus@lists.altlinux.org
> > https://lists.altlinux.org/mailman/listinfo/sisyphus  
> 
> 
> 

Re: [sisyphus] Reeboot в процессе dist-upgrage

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 585 bytes --]

On Wed, Apr 10, 2019 at 01:55:24PM +0300, Yuri Khachaturyan wrote:
> По ssh на сервер захожу через public key, по паролю не пускает ни локально,
> ни удаленно ни под одним пользователем.
> Через ssh su выдает:
> 
> su: Memory buffer error
> 
> В логе 12й консоли вижу:
> 
> su: pam_tcb(su:auth): crypt_ra: Invalid argument
> su: pam_tcb(su:auth): Authentication failed for root from (uid=500)
> 
> При попытке локального входа тоже самое.

Скорее всего, у вас libcrypt неправильный.

Куда смотрит /lib64/libcrypt.so.1, чем является то, куда она смотрит?


-- 
ldv

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [sisyphus] Reeboot в процессе dist-upgrage

[Sergey]

On Wednesday 10 April 2019, Yuri Khachaturyan wrote:

> Еще заметил вот такое:
> 
>         SysVinit conflicts with systemd-sysvinit-1:241-alt4.noarch
>      SysVinit conflicts with (installed) systemd-sysvinit-1:241-alt4.noarch
> 
> Может это быть связано?
 
В плане pam не представляю, как это может быть связано, но
вот как sysvinit в системе оказался при наличии systemd?
Или это когда-то раньше случилось? И не было ли старых 
ненужных пакетов в /var/cache/apt/archive, которые не надо
было ставить? Во-первых, надо удалить тот из инитов, который
лишний (очевидно sysvinit, раз именно systemd всё это устроил),
во-вторых, может быть, удалить ещё лишние пакеты:

https://www.altlinux.org/APT_в_ALT_Linux/Советы_по_использованию#apt-scripts:_«ненужное»_и_«не_в_текущем_репо»

-- 
С уважением, Сергей.

Re: [sisyphus] Reeboot в процессе dist-upgrage

[Sergey]

On Wednesday 10 April 2019, Yuri Khachaturyan wrote:

> Скорее всего именно из /var/cache/apt/archive поставилось то, что не нужно.
> Удалить systemd-sysvinit?
 
Нет, это к systemd относится. sysvinit (то, что в конфликте значится,
как SysVinit), возможно с sysvinit-utils: rpm -qa| grep "^sysvinit-"

-- 
С уважением, Сергей.

Re: [sisyphus] Reeboot в процессе dist-upgrage

[Sergey]

On Wednesday 10 April 2019, Yuri Khachaturyan wrote:

> [root@sqln log]# rpm -qa| grep "^sysvinit-"
> sysvinit-utils-2.88-alt5.x86_64
> sysvinit-initramfs-2.88-alt5.x86_64
> 
> На втором, работающем сервере, эти же пакеты тоже установлены.

Да, тут я не прав похоже, в системе с systemd эти компоненты от
sysvinit тоже нужны. systemd у меня мало, не очень пока знаю.

> А вот так он пытается удалить половину системы:

> [root@sqln ~]# apt-get remove SysVinit

> systemd systemd-services systemd-sysvinit systemd-utils udev udev-extras

Это тоже неправильно. Это systemd-sysvinit провайдит SysVinit. Тогда
не очень понятно, откуда этот конфликт. На сервере, где проблема,
rpm -qa| grep "^sysvinit-" что показывает? Если sysvinit нет, то
получается, что там конфликт сам с собой. И тут вопрос тогда про
rpm --rebuilddb из соседнего сообщения актуален. Делался?

-- 
С уважением, Сергей.

Re: [sisyphus] Reeboot в процессе dist-upgrage

[Sergey]

On Wednesday 10 April 2019, Yuri Khachaturyan wrote:


> [master f0977c5] saving uncommitted changes in /etc prior to apt run
>  2 files changed, 11 deletions(-)
>  delete mode 100644 my.cnf.rename
>        SysVinit conflicts with systemd-sysvinit-1:241-alt4.noarch
>      SysVinit conflicts with (installed) systemd-sysvinit-1:241-alt4.noarch
> E: Transaction set check failed
 
Даже не знаю. А если сначала переустановить всё, что связано с systemd?
Кстати, от предыдущей версии systemd не осталось пакетов? Что-нибудь, что
стояло, но не было в архив скачано (хотя вряд ли, на самом деле - по
dist-upgrade должно было всё приехать). 

-- 
С уважением, Сергей.

Re: [sisyphus] Reeboot в процессе dist-upgrage

[Sergey]

On Wednesday 10 April 2019, Yuri Khachaturyan wrote:

> От предыдущей - ничего не осталось, все по dist-upgrade обновилось.
> Переустановка не проходит по той же причине:
> 
> [root]# apt-get install --reinstall `rpm -qa| grep "systemd" |sed "s/-[^-]\+-[^-]\+$//"`
 
Тут так не пойдёт, надо rpm -Uvh, и, видимо, --force. И --nodeps
по ситуации. Их не так много будет, это не долго. Можно даже как
в начале - rpm -Uvh --force *.rpm, сложив в отдельный каталог всё,
что ищется по "241-alt4". Там ещё udev будет и т.п.

-- 
С уважением, Сергей.

Re: [sisyphus] Reboot в процессе dist-upgrage

[Sergey]

On Wednesday 10 April 2019, Yuri Khachaturyan wrote:

> rpm -Uvh --force --nodeps *.rpm
> 
> помогло частично. Сервер загрузился, сервисы все поднялись,
> но не могу залогиниться ни локально

В смысле с клавиатуры под root не пускает? Прямо в консоли?
Или сервер с X-ами и в X-ах не пускает?

> ни через ssh (под юзером ssh пустил, а вот su- выдает ошибку).

По ssh под root в ALT и не должно пускать. Что за ошибка? Может
настройки control для su слетели?

Что показывает control|grep "su " от root (или если опять с LiveCD
из chroot посмотреть) и что показывает groups от пользователя?

-- 
С уважением, Сергей.

Re: [sisyphus] Reboot в процессе dist-upgrage

[Sergey]

On Wednesday 10 April 2019, Sergey wrote:

> По ssh под root в ALT и не должно пускать. Что за ошибка?
> Может настройки control для su слетели?
> 
> Что показывает control|grep "su " от root

Можно кстати просто "control su", тоже достаточно.

-- 
С уважением, Сергей.

Re: [sisyphus] Reboot в процессе dist-upgrage

[Sergey]

On Wednesday 10 April 2019, Yuri Khachaturyan wrote:

> Временно разрешил PermitrootLogin yes и положил ключик
> в /root/.ssh чтобы войти рутом, но какие дальнейшие действия? 
 
Попробовать понять, что осталось разломано, и переустановить
эти пакеты. Видимо, ещё должны были дубли остаться, их надо
зачистить. Как раз заодно и переустановятся, может поломка 
та будет как раз в этих пакетах, и пропадёт. удалять rpm-ом
с --allmatches и --nodeps и ставить один обратно. Предварительно
смотреть, что это и как может повлиять. Скажем, сам rpm так
удалять не надо.

-- 
С уважением, Сергей.

Re: [sisyphus] Reboot в процессе dist-upgrage

[Alex Moskalenko]

Yuri Khachaturyan писал 10.04.2019 14:47:

> Дублей было немного, их зачистил и установил заново:
> 
> [root@sqln pam.d]# rpm -qa |sort |uniq -d
> libX11-1.6.7-alt1.x86_64
> libX11-locales-1.6.7-alt1.noarch
> liblua5.1-preinstall-5.1.5-alt15.x86_64
> libxcb-1.13.1-alt1.x86_64
> 
> ср, 10 апр. 2019 г. в 14:33, Sergey <a_s_y@sama.ru>:
> 
>> On Wednesday 10 April 2019, Yuri Khachaturyan wrote:
>> 
>>> Временно разрешил PermitrootLogin yes и положил ключик
>>> в /root/.ssh чтобы войти рутом, но какие дальнейшие действия?
>> 
>> Попробовать понять, что осталось разломано, и переустановить
>> эти пакеты. Видимо, ещё должны были дубли остаться, их надо
>> зачистить. Как раз заодно и переустановятся, может поломка
>> та будет как раз в этих пакетах, и пропадёт. удалять rpm-ом
>> с --allmatches и --nodeps и ставить один обратно. Предварительно
>> смотреть, что это и как может повлиять. Скажем, сам rpm так
>> удалять не надо.

Если rpm/apt работают, то выполните rpm -Va > /tmp/verify.txt и 
проинспектируйте /tmp/verify.txt на предмет отсутствующих/поврежденных 
файлов, не являющихся конфигами. Переустановите пакеты с 
поврежденными/отсутствующими файлами (rpm -qf $file, apt-get reinstall)

---
WBR, Alex Moskalenko

Re: [sisyphus] Reboot в процессе dist-upgrage

[Sergey]

On Wednesday 10 April 2019, Yuri Khachaturyan wrote:

Про rpm -Va это было хорошо замечено, что-то я забыл даже.

> Увы, но кроме конфигов ничего внятного не выдало на что
> стоило бы обратить внимание.

Тогда странно, откуда "Memory buffer error" у su. Точно
надо пытаться через strace смотреть, кто это пишет на 
самом деле. И вот с этим непонятно, причина это, или следствие:

su: pam_tcb(su:auth): crypt_ra: Invalid argument
su: pam_tcb(su:auth): Authentication failed for root from (uid=500)

Но тут, может быть, strace поможет догадаться. Ещё в /etc/pam.d/su
можно посмотреть, может какой-то плагин просто пропал вместе с 
удалившимся пакетом (потому и с rpm -Va не видно). Хотя они, по
большей части, к самому пакету pam относятся. На всякий случай,
что у меня в Сизифе есть сейчас (но тут и лишнее в списке может
быть):

# rpm -qa| grep "^pam"
pam0-config-1.7.0-alt1.noarch
pam0_tcb-1.1.0.1-alt2.x86_64
pam_krb5-4.7-alt1.x86_64
pam_systemd-241-alt4.x86_64
pam0_mktemp-1.1.1-alt3.x86_64
pam-config-control-1.7.0-alt1.noarch
pam0_passwdqc-1.3.1.2-alt2.x86_64
pam-config-1.7.0-alt1.noarch
pam-1.3.1.0.5.955b-alt2.x86_64
pam_mount-2.16-alt1.3.x86_64
pam0_userpass-1.0.2-alt6.x86_64
pam_ldap-186-alt1.x86_64
pam0_console-1.0.0-alt1.x86_64
pam-ck-connector2-1.2.1-alt5.x86_64

-- 
С уважением, Сергей.

Re: [sisyphus] Reboot в процессе dist-upgrage

[Alex Moskalenko]

Yuri Khachaturyan писал 10.04.2019 15:10:

> Увы, но кроме конфигов ничего внятного не выдало на что стоило бы 
> обратить внимание.
> 
>> 
>> Если rpm/apt работают, то выполните rpm -Va > /tmp/verify.txt и
>> проинспектируйте /tmp/verify.txt на предмет отсутствующих/поврежденных
>> файлов, не являющихся конфигами. Переустановите пакеты с
>> поврежденными/отсутствующими файлами (rpm -qf $file, apt-get 
>> reinstall)
>> 

Есть вероятность повреждения базы данных rpm. Возможно, rpm после этого 
просто не знает об некоторых установленных пакетах, и не проверяет их 
целостность.
Попробуйте что-то типа find /{bin,sbin,lib,lib64} 
/usr/{bin,sbin,lib,lib64} -type f -exec sh -c "rpmquery -f '{}' > 
/dev/null 2>&1 || echo 'Not found: {}'" \; - покажет файлы, которые rpm 
не считает принадлежащими пакетам. Если таковые находятся в 
перечисленных каталогах и Вы сами их туда не помещали - с базой rpm 
что-то нехорошо. Попробуйте установить пакеты, которым принадлежат 
неопознанные файлы.

Re: [sisyphus] Reboot в процессе dist-upgrage

[Sergey]

On Wednesday 10 April 2019, Alex Moskalenko wrote:

> Попробуйте что-то типа find /{bin,sbin,lib,lib64}

только перед этим rpm --rebuilddb не повредит, если
ещё не делалось. Хотя с установкой из архива и rpm
наверное переустановился, соответственно и rebuilddb,
видимо, запускался. 

-- 
С уважением, Сергей.

Re: [sisyphus] Reboot в процессе dist-upgrage

[Alex Moskalenko]

Yuri Khachaturyan писал 10.04.2019 16:27:

> Неопознанных файлов действительно много, причем среди них есть те, 
> которые были удалены с помощью apt-get remove или apt-get dist-upgrade.
> В частности /usr/lib64/pgsql/backup/libpq.so.5.10 из пакета libpq5.10 
> был заменен на libpq5, но файл остался, правда в бэкапе.
> 
Ну что ж, для начала будем считать, что с файловой системой все ок (fsck 
с livecd был запущен). Далее будем считать, что физически/логически на 
уровне db5 (или что там сейчас) с базой rpm тоже все ок (ошибок движка 
базы вроде не видно). Остается Вам разобраться с неопознанными файлами - 
найти их пакеты и переустановить их. После этого скорее всего и система 
запустится должным образом. Таким же образом есть смысл проверить и 
остальные каталоги в /usr. Можно попытаться заскриптовать, но лучше 
все-таки руками в этой каше разбираться.

PS Может, есть смысл забэкапить /etc, /home, /srv, 
/что-у-Вас-еще-используется, установить чистую систему и вернуть /etc, 
/home, ...?

---
WBR, Alex Moskalenko

Re: [sisyphus] Reboot в процессе dist-upgrage

[Sergey]

On Wednesday 10 April 2019, Yuri Khachaturyan wrote:

> su: Memory buffer error

Тут надо su и все зависимые пакеты переставить для начала,
вероятно где-то библиотеки разъехались. Но после починки
дублей, если apt и rpm нормально работают и дают возможность
починить. Ещё можно попробовать посмотреть strace-ом, где
именно вываливается.

-- 
С уважением, Сергей.

Re: [sisyphus] Reboot в процессе dist-upgrage

[Sergey]

On Wednesday 10 April 2019, Yuri Khachaturyan wrote:

> rpm -Uvh --force --nodeps *.rpm

Если вдруг ещё кому надо будет. Вот тут предварительно можно было
попробовать apt-get autoclean сделать, исходя из того, что база
данных по репозиторию обновлена и старое не нужно, и если apt жив.
Но, может быть, сохранив содержимое /var/cache/apt/archives (хотя
пока не знаю, зачем оно может понадобиться).

-- 
С уважением, Сергей.

Re: [sisyphus] Reboot в процессе dist-upgrage

[Sergey]

On Wednesday 10 April 2019, Sergey wrote:

> Но, может быть, сохранив содержимое /var/cache/apt/archives
> (хотя пока не знаю, зачем оно может понадобиться).

Нет, знаю. Если там совсем что-то старое залежалось, отличное
от версий получившихся в системе дублей, можно это поставить
посредством rpm -U, а не удалять и ставить, что может оказаться
затруднительно в каких-то случаях, когда продублировано что-то
совсем нужное.

-- 
С уважением, Сергей.