Segmentation fault при апдейте на 10.1 через freebsd-update

[xM]

Короче, поимел проблему в точности, как описано в первом посте.
https://forums.freebsd.org/threads/segm ... ase.48977/
Чего делать?

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[guest]

Короче, поимел проблему в точности, как описано в первом посте.
https://forums.freebsd.org/threads/segm ... ase.48977/
Чего делать?

в форуме куча проблем перечислена, если Вы о креше связанном с ZFS:

https://www.freebsd.org/releases/10.1R/errata.html

Код: Выделить всё

FreeBSD/i386 10.1-RELEASE configured with a multi-disk ZFS dataset (mirror, raidz1, raidz2, raidz3) may crash during boot when the ZFS pool mount is attempted while booting an unmodified GENERIC kernel.

As described in /usr/src/UPDATING entry 20121223, rebuilding the kernel with options KSTACK_PAGES=4 has been observed to resolve the boot-time crash. This, however, is not an ideal solution for inclusion in the GENERIC kernel configuration, as increasing KSTACK_PAGES implicitly decreases available usermode threads in an environment that is already resource-starved.

Taking into account the heavy resource requirements of ZFS, in addition to the i386-specific tuning requirements for general workloads, using ZFS with the FreeBSD/i386 GENERIC kernel is strongly discouraged. 

Нужно мало-мало почитать перед апгрейдом.
Было еще это:
https://www.freebsd.org/security/adviso ... 12.zfs.asc
и еще Persival написал что на зеркалах отсутствовала часть файлов, но это исправлено.

Те, на i386 пересобрать ядро с указанной опцией и все должно пройти, и всегда апдейтить bootcode:

# gpart bootcode -b /mnt/boot/pmbr -p /mnt/boot/gptzfsboot -i 1 adaN

adaN замените на свое

[xM]

Насчёт чтения, так тут все грамотные.
Кроме того, у меня UFS.
Попытка make buildчтонибудь вызывает ту же segmentation fault.

[guest]

Насчёт чтения, так тут все грамотные.

ну так в чем проблемы?

Кроме того, у меня UFS.
Попытка make buildчтонибудь вызывает ту же segmentation fault.

апгрейд с какого релиза на какой был и как (действия)?

код какой после segmentation fault? (make.conf, src.conf, версия pkg?)

# cat /sys/conf/newvers.sh | grep -v ^# | head

[xM]

1. c 10-RELEASE на 10.1-RELEASE
2. стандартные

#freebsd-update upgrade -r 10.1-RELEASE
#freebsd-update fetch
#freebsd-update install
... merge ...
#shutdown -r now
...
#freebsd-update install
...
segmentation fault

3. код 11. почти на любые утилиты - top, mtree...
4. Там стоит 10-RELEASE и p12
5. pkg свежайший из портов

[guest]

1. c 10-RELEASE на 10.1-RELEASE
2. стандартные

#freebsd-update upgrade -r 10.1-RELEASE
#freebsd-update fetch
#freebsd-update install
... merge ...
#shutdown -r now
...
#freebsd-update install
...
segmentation fault

3. код 11. почти на любые утилиты - top, mtree...
4. Там стоит 10-RELEASE и p12
5. pkg свежайший из портов

странно, а зачем reebsd-update fetch после "freebsd-update upgrade -r 10.1-RELEASE"

вижу варианты:

1) freebsd-update rollback
2) если система грузится - посмотреть что говорит uname, определить какое ядро
и ls -la [/bin|/sbin|...|/usr/lib] - встали все бинарники или остались старые?
далее по факту, загрузить свое старое ядро и посмотреть что будет работать
3) плюнуть на разбор, загрузиться с live-usb и выполнить сборку и установку системы и ядра, разумеется
используя достоверные sources на смонтированном диске с системой и сборку на диск

mount /dev/... /mnt
...
cd /mnt/usr
mv src src.xxx
svnlite co ... /mnt/usr/src
на usb-live
mv /usr/src /usr/src.orig
ln -s /usr/src /mnt/usr/src
переопределяем /usr/obj -> MAKEOBJDIRPREFIX=/mnt/usr/obj
далее все как в обычной сборке, бинарники будут использоваться с live-usb, сборка из исходников
которые на диске, obj будет на диске
флешка нужна "правильная"
На 8'ми ядерном сервере ~40 мин (ядро обязательно собрать, хоть GENERIC)

Апгрейд через сборку на более чем 10'ти серверах и нескольких WKS прошел без проблем.

[xM]

1) freebsd-update rollback

segmentation fault

2) если система грузится - посмотреть что говорит uname, определить какое ядро

В single user mode
10.1-RELEASE стоит по факту

и ls -la

segmentation fault

[/bin|/sbin|...|/usr/lib] - встали все бинарники или остались старые?

сейчас залью с релизной флэшки руками. но сомнительно.
Склоняюсь к предложенному вами третьему варианту, но приберегу его на сладкое...
Спасибо.

[guest]

1) freebsd-update rollback

segmentation fault

2) если система грузится - посмотреть что говорит uname, определить какое ядро

В single user mode
10.1-RELEASE стоит по факту

и ls -la

segmentation fault

[/bin|/sbin|...|/usr/lib] - встали все бинарники или остались старые?

сейчас залью с релизной флэшки руками. но сомнительно.
Склоняюсь к предложенному вами третьему варианту, но приберегу его на сладкое...
Спасибо.

загрузившись с флешки можно было бы и посмотреть дату-время у ядра и бинарников с библиотеками.
такое ощущение что ядро обновилось, бинарники не полностью
Да нафик сладкое если нужно быстро: развернуть руками с флешки 10.1 и перегрузиться,
затем mergemaster, ошметки freebsd-update из /var удалить, ну и не забыть про /usr/src
чтобы потом make delete-old ...

Удачи

[xM]

такое ощущение что ядро обновилось, бинарники не полностью

Да, так оно и есть.
План "А" в виде копирования бинарников с фэшки не имели успеха.
Приступаю к плану "Б".

З.Ы. Впервые попробовал бинарно апдейтится. Не, теперь только традиционно - только из исходников.

[snorlov]

Я вот нифига не понял этих действия

Код: Выделить всё

#freebsd-update upgrade -r 10.1-RELEASE
#freebsd-update fetch

Вы обновляете систему до 10.1, а затем вдруг скачиваете обновления 10.0, вот и получилась мешинина...

[xM]

Я вот нифига не понял этих действия

Код: Выделить всё

#freebsd-update upgrade -r 10.1-RELEASE
#freebsd-update fetch

Вы обновляете систему до 10.1, а затем вдруг скачиваете обновления 10.0, вот и получилась мешинина...

Ничего подобного при этом получиться не может. Попробуйте...
Проблема не здесь.

З.Ы. Попутно, сообщаю, что мне все-таки удалось таки уйти от segmentation fault путём принудительной замены всех lib*** с дистрибутива.
Однако, работоспособность прикладного софта не восстановлена из-за каких-то возникших проблем с правами на доступ (?!). Попрошу заметить, что их-то, включая юзеров и группы, никто руками не трогал.
Визуально все права и группы выглядят неизменёнными.

[guest]

Я вот нифига не понял этих действия

Код: Выделить всё

#freebsd-update upgrade -r 10.1-RELEASE
#freebsd-update fetch

Вы обновляете систему до 10.1, а затем вдруг скачиваете обновления 10.0, вот и получилась мешинина...

Ничего подобного при этом получиться не может. Попробуйте...
Проблема не здесь.

З.Ы. Попутно, сообщаю, что мне все-таки удалось таки уйти от segmentation fault путём принудительной замены всех lib*** с дистрибутива.
Однако, работоспособность прикладного софта не восстановлена из-за каких-то возникших проблем с правами на доступ (?!). Попрошу заметить, что их-то, включая юзеров и группы, никто руками не трогал.
Визуально все права и группы выглядят неизменёнными.

дык Вы как разворачивали то...!?

usb-live 10.1:

# fsck_ffs -fy /dev/adaXpY
прогоняем fsck на все партиции на которых FS на системном диске, допустим /,/tmp,/usr,/var (отдельные)
# mount /dev/adaXp2 /mnt (корень)
# mount /dev/adaXp4 /mnt/tmp
# mount /dev/adaXp5 /mnt/usr
# mount /dev/adaXp6 /mnt/var
# rm -rf /mnt/usr/src

# cd /usr/freebsd-dist/
# for file in base.txz lib32.txz kernel.txz src.txz ; do (cat $file | tar --unlink -xvpJf - -C /mnt); done

развернули поверх старой _битой_ системы, все, теперь останется перезагрузиться и
выполнить: cd /usr/src && make delete-old

ps. Чет Вы накосячили с бинарным обновлением и затем с разворачиванием с live образа,
если /home не трогали, все остальное можно восстановить через mtree (chown & chmod)

[xM]

В точности так и делал. Единственное что у меня gmirror на дисках, но не суть.
make delete-old забыл, да. сейчас попробую.
А можно про mtree подробнее?

[guest]

В точности так и делал. Единственное что у меня gmirror на дисках, но не суть.

суть, UFS + SUJ?, gmirror на партиции или на целый диск?

make delete-old забыл, да. сейчас попробую.
А можно про mtree подробнее?

# man mtree

например:
# mtree -U -p /usr -f /etc/mtree/BSD.usr.dist

[xM]

В точности так и делал. Единственное что у меня gmirror на дисках, но не суть.

суть, UFS + SUJ?, gmirror на партиции или на целый диск?

На весь диск UFS + SUJ.

[xM]

Ой, соврал. На этом ящике журналирования нет.

[guest]

На весь диск UFS + SUJ.

не советую использовать SUJ, особенно в связке с gmirror - массу экспериментов провел,
правда на 9.x, пришлось добавить в /etc/rc.conf принудительную проверку "-f", иначе дело швах.
Опять же dump/restore (snapshots), в 10'ке не следил - можно ли делать снапшоты LIVE если
UFS + SUJ, вроде до сих пор нельзя.

Посему в случае SUJ для gmirror,gstripe,graid в /etc/rc.conf:

Код: Выделить всё

#-- forced fsck-y
fsck_y_enable="YES"
fsck_y_flags="-f"
#-- disable background fsck
background_fsck="NO"

иначе проблемы при пропадании питания, обновлении & etc
В bsdinstall by default даже для корня делают SUJ - ни в коем случае!

ps. В SUJ еще долго будут вылавливать ошибки, невзирая на то что к 9.3 много исправили,
если вспомним - в SU их вычищали около 10 лет...

[xM]

Спасибо. Но проблемный ящик вроде как сервак и на нем журналирования нет. На рабочих ноутбуках есть оно.
Но, спасибо за совет.
Похоже, make delete-old таки помог. Часть прикладного софта не завелась пока, но сейчас попробую его обновить.
Возможно, косяк из-за танцев с бубном перед этим случился, не знаю точно.
В любом случае, спасибо за быструю и толковую помощь.
Кстати, вы бы зарегистрировались, что б не теряться...
Буду признателен!

[guest]

Спасибо. Но проблемный ящик вроде как сервак и на нем журналирования нет. На рабочих ноутбуках есть оно.
Но, спасибо за совет.
Похоже, make delete-old таки помог. Часть прикладного софта не завелась пока, но сейчас попробую его обновить.
Возможно, косяк из-за танцев с бубном перед этим случился, не знаю точно.

make delete-old и libs - удаляет ошметки которые не нужны новой системе и особенно не влияют
на софт из портов если он не от старых версий FreeBSD (compatXY).
Начиная с 9.0 - если обновление в пределах ветки: 9.0 ... 9.3 или 10.0 ... 10.x - пересборка портов
не нужна. Вот при 9.x -> 10.x могут быть проблемы с libiconv, ибо на 9.x мы ее ставили, а в 10.x она
часть системы и libc, получаем бяку. Те при переходе с ветки 9 на ветку 10, лучше пересобрать порты

В любом случае, спасибо за быструю и толковую помощь.
Кстати, вы бы зарегистрировались, что б не теряться...
Буду признателен!

не на чем
регистрироваться - упаси бог, столько грязи льется от ленивых и не желающих учиться читать, думать
(man ... воспринимается как нах... ) и работать, да еще воинствующих незнаек, лучше уж пусть guest
чем пачкать имя

[xM]

make delete-old и libs - удаляет ошметки которые не нужны новой системе и особенно не влияют

Принимая во внимание, что система старая и прошла все релизы начиная с 8.0, то я бы не исключал их влияния.

Те при переходе с ветки 9 на ветку 10, лучше пересобрать порты

Было дело...
В общем, вылезло какое-то количество косяков в юзер-аккаунтами приложений, которые их ребидом были побеждены.
После всей этой истории осталось непонятным, что это было.

[guest]

make delete-old и libs - удаляет ошметки которые не нужны новой системе и особенно не влияют

Принимая во внимание, что система старая и прошла все релизы начиная с 8.0, то я бы не исключал их влияния.

про это было, только без запятой "если", те это разумеется, если остаются старые порты при переходе с ветки, либо оставлять старые библиотеки - что в корне неверно, правильно ставить compatXY, еще лучше - избавляться
от старого ПО которого больше нет в портах или использовать виртуалку для такой старой системы (личное мнение)

Те при переходе с ветки 9 на ветку 10, лучше пересобрать порты

Было дело...
В общем, вылезло какое-то количество косяков в юзер-аккаунтами приложений, которые их ребидом были побеждены.
После всей этой истории осталось непонятным, что это было.

чего в жизни не бывает, но на лишний freebsd-update fetch - советую обратить внимание и обыграть в
виртуалке - быстро и без хлопот.

[Neus]

«А вы тоже актер? Как ваша фамилия?» — «Мое имя вам ничего не скажет: Смоктуновский. Ну что?»

[xM]

но на лишний freebsd-update fetch - советую обратить внимание и обыграть в
виртуалке - быстро и без хлопот.

Ну понятно. Просто до этого на релиз вполне успешно через бинарники переехало несколько ноутбуков и дескотопов под PCBSD.
А тут вот такие грабли.
Склоняюсь на будущее вернуться к старому доброму способу установки новых релизов из исходников.
Для меня этот бинарный апдейт, признаться, был экспериментом. Как оказалось, неудачным.

[xM]

Похоже, ситуация с этой проблемой постепенно проясняется.
Судя по форуму FreeBSD проблема в обновлении библиотек, которые содержатся в дистрибутивном архиве lib32.txz.
Я бы пока поостерёгся от бинарных апдейтов на 10.1.
Ставьте из исходников.

[guest]

Похоже, ситуация с этой проблемой постепенно проясняется.
Судя по форуму FreeBSD проблема в обновлении библиотек, которые содержатся в дистрибутивном архиве lib32.txz.
Я бы пока поостерёгся от бинарных апдейтов на 10.1.
Ставьте из исходников.

если не обновятся lib32 - ничего особо страшного не должно быть, тем более segmentation fault, 32'битные
библиотеки должны влиять лишь на 32'битные applications.