ALT Linux Bugzilla – Full Text Bug Listing
| Summary: | Ошибка обновления с P8 до Sisyphus | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Sisyphus | Reporter: | Sergey Novikov <sotor> | ||||
| Component: | timeshift | Assignee: | Alexander Makeenkov <amakeenk> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | qa-sisyphus | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | amakeenk, bochenin, evg, galilley, glebfm, gorini41995, klark.devel, legion, m, mike, rider, shaba | ||||
| Version: | unstable | ||||||
| Hardware: | all | ||||||
| OS: | Linux | ||||||
| Bug Depends on: | 34505, 34508 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
В сизифе совсем новый rpm. Во всех описаниях на wiki для обновления с одной ветки на другую, рекомендуют сначала обновить apt и rpm. 1) apt-get install apt rpm lua5.3 liblua5.1- lua5.1-alt-compat- liblua5.1-preinstall- lua-module-luasocket 2) apt-get update 3) apt-get dist-upgrade А это помогает ? я это проверил в виртуалке, которую мне выделили. Я завтра ещё раз посмотрю и закрою сам. # apt-get install apt rpm lua5.3 liblua5.1- lua5.1-alt-compat- liblua5.1-preinstall- lua-module-luasocket Выдает следующее: Пакет liblua5.1-preinstall не установлен, и не может быть удалён. Следующие дополнительные пакеты будут установлены: chrpath libapt liblua5.3 libquvi0.9 librpm7 luarocks synaptic Следующие пакеты будут ОБНОВЛЕНЫ: apt libapt libquvi0.9 lua-module-luasocket luarocks rpm synaptic Следующие пакеты будут УДАЛЕНЫ: liblua5.1 lua5 lua5.1-alt-compat Следующие НОВЫЕ пакеты будут установлены: chrpath liblua5.3 librpm7 lua5.3 7 будет обновлено, 4 новых установлено, 3 пакетов будет удалено и 1144 не будет обновлено. ... file /usr/lib/rpm/macros from install of librpm7-4.13.0.1-alt1 conflicts with file from package librpm-4.0.4-alt101.M80P.1 file /usr/lib/rpm/rpmrc from install of librpm7-4.13.0.1-alt1 conflicts with file from package librpm-4.0.4-alt101.M80P.1 E: Ошибка во время исполнения транзакции Это отдельный баг, который стоит повесить на librpm7. Возможно, сделав его зависимостью этого бага, если ещё останется. Получается следующее: 1) обновляются библиотеки 2) обновляется udev и пытается перезапуститься. - Если sysv - то вызывается сам бинарник udevd из init-скрипта. - Если systemd - то используется systemctl restart udevd, но systemctl еще не обновился, а библиотеки уже обновились. 3) обновляется systemd (где новый systemctl) Варианты решения: 1) попробовать добиться установки systemd сначала, а потом udev. 2) в %post пакета udev определять init, и если это sysv то запускать рестарт, если systemd то ничего не делать и перезапускать udev в %post пакета systemd. ещё вариант - сделать отдельный upgrade mode для сложных ситуаций и загружаться в него. (В ответ на комментарий №8) > ещё вариант - сделать отдельный upgrade mode для сложных ситуаций и загружаться > в него. Такой режим предусмотрен в systemd. Только мы его не используем. И не умеем использовать, надо сначала научиться. наверное, есть смысл подумать в эту сторону. Нужна какая-то интеграция в apt ? (В ответ на комментарий №8) > ещё вариант - сделать отдельный upgrade mode для сложных ситуаций > и загружаться в него. Вот уж этого мегакостыля хотелось бы по возможности избежать. Снизу постучать будет сложно. Какой уж это мегакостыль ? вполне нормальное поведение для системы. Один чёрт сейчас графискую систему (например KDE) приходится перегружать самостоятельно, что бы потом ничего не взрывалось. Буквально на днях обсуждал с Глебом. Я думал сделать фичу, что если в корне системы появляется исполняемый /initramfs.sh, то initrd перемонтирует корень в RW b выполнит этот скрипт вместо init= и после завершения скрипта сделает reboot. Скрипт же должен либо сам себя удалить, либо оставить вместо себя новую стадию и они в свою очередь будет выполнена. (В ответ на комментарий №12) > Какой уж это мегакостыль ? вполне нормальное поведение для системы. Для моих -- нет. > Один чёрт сейчас графискую систему (например KDE) приходится перегружать > самостоятельно, что бы потом ничего не взрывалось. А мне не приходится. Причём по тому бородатому анекдоту как только начинаешь давать себе такие "технологические поблажечки" -- так и всё, путь под откос открыт: "ну ведь режим же специальный есть". Будешь потом сам не рад бутаться по каждому чиху. </rant> (В ответ на комментарий №13) > Буквально на днях обсуждал с Глебом. Я думал сделать фичу, что если в корне > системы появляется исполняемый /initramfs.sh, то initrd перемонтирует корень в > RW b выполнит этот скрипт вместо init= и после завершения скрипта сделает > reboot. > > Скрипт же должен либо сам себя удалить, либо оставить вместо себя новую стадию > и они в свою очередь будет выполнена. какой-то функционал есть в systemd. Может быть, он там более продуман ? Можно ведь переложить эту задачу на init, а не на initramfs. "Буквально на днях обсуждал с Глебом. Я думал сделать фичу, что если в корне системы появляется исполняемый /initramfs.sh, то initrd перемонтирует корень в RW b выполнит этот скрипт вместо init= и после завершения скрипта сделает reboot." А если у меня BTRFS и подтома @, @home, система стоит в @, то, судя по путям вида /@/boot/ в grub.cfg initrd монтирует корень без параметра subvol=@, а уже в kernel cmdline передается rootflags=subvol=@ , то есть ваш скрипт будет по пути /@/initramfs.sh, а не /initramfs.sh, если я все правильно понимаю. При этом корневой подтом воовсе необязательно должен называться @. (In reply to comment #0) > E: Unmet dependencies. Try using --fix-broken. (In reply to comment #2) > А это помогает ? Мне вчера помогло! apt-get dist-upgrade --fix-broken просто снёс более старый удав и всё. (В ответ на комментарий №15) > какой-то функционал есть в systemd. Может быть, он там более продуман ? Можно > ведь переложить эту задачу на init, а не на initramfs. Ну моё дело сказать. (В ответ на комментарий №16) > А если у меня BTRFS и подтома @, @home, система стоит в @, то, судя по путям > вида /@/boot/ в grub.cfg initrd монтирует корень без параметра subvol=@, а уже > в kernel cmdline передается rootflags=subvol=@ , то есть ваш скрипт будет по > пути /@/initramfs.sh, а не /initramfs.sh, если я все правильно понимаю. При > этом корневой подтом воовсе необязательно должен называться @. Может вы меня не поняли, а может я вас. А что непонятного? Как я представляю процесс, файла /initramfs.sh не будет до загрузки ядра на стадии initrd, даже если в процессе работы системы он был положен в /initramfs.sh (В ответ на комментарий №19) > А что непонятного? Как я представляю процесс, файла /initramfs.sh не будет до > загрузки ядра на стадии initrd, даже если в процессе работы системы он был > положен в /initramfs.sh Сначала вопрос: что вы прописываете в init=, буквально пример можно ? То есть на стадии initrd будет $ ls / @ @home А после initrd, когда загрузится ядро Linux, будет $ ls / etc initrd.img media proc run srv usr bin cdrom grub lib mnt root sbin sys var boot dev home lib64 opt rosa snap tmp vmlinuz Я ничего не прописываю в init вручную, все автоматом, на Ubuntu инсталлятор такую разбивку делает автоматом, если указать точку монтирования / в BTRFS и не указывать /home отдельно, на Альте вручную переделывал уже установленную систему на такую схему разбивки на подтома BTRFS, тоже работает.
$ cat /boot/grub/grub.cfg | grep '/@/boot/'
linux /@/boot/vmlinuz-4.15.0-13-generic root=UUID=355fccdc-c430-43b5-929b-f38e35136c1c ro rootflags=subvol=@
initrd /@/boot/initrd.img-4.15.0-13-generic
linux /@/boot/vmlinuz-4.15.0-13-generic root=UUID=355fccdc-c430-43b5-929b-f38e35136c1c ro rootflags=subvol=@
initrd /@/boot/initrd.img-4.15.0-13-generic
linux /@/boot/vmlinuz-4.15.0-13-generic root=UUID=355fccdc-c430-43b5-929b-f38e35136c1c ro recovery nomodeset rootflags=subvol=@
initrd /@/boot/initrd.img-4.15.0-13-generic
$ cat /etc/fstab | grep btrfs
UUID=355fccdc-c430-43b5-929b-f38e35136c1c / btrfs defaults,subvol=@,compress=lzo 0 1
UUID=355fccdc-c430-43b5-929b-f38e35136c1c /home btrfs defaults,subvol=@home,compress=lzo 0 2
# UUID=355fccdc-c430-43b5-929b-f38e35136c1c /home btrfs nofail,discard,defaults,subvolid=264,compress=lzo
UUID=355fccdc-c430-43b5-929b-f38e35136c1c /home/user/.config/chromium btrfs nofail,discard,defaults,subvol=@home_chromium,compress=lzo
UUID=355fccdc-c430-43b5-929b-f38e35136c1c /home/user/.thunderbird btrfs nofail,discard,defaults,subvol=@home_thunderbird,compress=lzo
UUID=355fccdc-c430-43b5-929b-f38e35136c1c /home/user-rosa/ btrfs nofail,discard,defaults,subvol=@home_rosa,compress=lzo
# UUID=355fccdc-c430-43b5-929b-f38e35136c1c /tmp btrfs nofail,discard,defaults,subvol=@tmp
UUID=355fccdc-c430-43b5-929b-f38e35136c1c /home/user/.PlayOnLinux btrfs nofail,discard,defaults,subvolid=335,compress=lzo
#UUID=355fccdc-c430-43b5-929b-f38e35136c1c /rosa btrfs nofail,discard,defaults,compress=lzo,subvol=@rosa
#UUID=355fccdc-c430-43b5-929b-f38e35136c1c /var/lib/libvirt/images/ btrfs nofail,discard,defaults,subvol=@libvirt-images
UUID="20de7529-5a39-4514-80d7-c5ef71a52b75" /media/3TB_Toshiba_BTRFS/oblako-backup btrfs nofail,compress=lzo,subvol=@oblako-backup
UUID="20de7529-5a39-4514-80d7-c5ef71a52b75" /var/lib/libvirt/ btrfs nofail,subvol=@libvirt
UUID="20de7529-5a39-4514-80d7-c5ef71a52b75" /home/user/Загрузки/ btrfs nofail,subvol=@downloads
UUID="20de7529-5a39-4514-80d7-c5ef71a52b75" /media/3TB_Toshiba_BTRFS/files btrfs nofail,compress=lzo,subvol=@files
UUID="20de7529-5a39-4514-80d7-c5ef71a52b75" /media/3TB_Toshiba_BTRFS/Linux-Dumalogiya btrfs nofail,compress=lzo,subvol=@linux-dumalogiya
UUID="20de7529-5a39-4514-80d7-c5ef71a52b75" /home/user/.steam btrfs nofail,compress=lzo,subvol=@steam-mikhailnov
user@pay2:~$ cat /proc/cmdline BOOT_IMAGE=/@/boot/vmlinuz-4.15.0-13-generic root=UUID=355fccdc-c430-43b5-929b-f38e35136c1c ro rootflags=subvol=@ user@pay2:~$ sudo btrfs subvol list / [sudo] пароль для user: ID 264 gen 525182 top level 5 path @home_rosa ID 277 gen 527110 top level 5 path @home_thunderbird ID 307 gen 470827 top level 5 path @tmp ID 335 gen 526322 top level 264 path @home_rosa/@home_playonlinux ID 389 gen 506764 top level 5 path @libvirt-images ID 391 gen 454544 top level 5 path timeshift-btrfs/snapshots/2017-11-27_05-47-23/@ ID 392 gen 527114 top level 5 path @ ID 393 gen 527111 top level 5 path @home ID 395 gen 470839 top level 5 path @home_24122017_Thunderbird58 ID 398 gen 470839 top level 5 path @home_thunderbird_22012018backup ID 401 gen 527111 top level 5 path @home_chromium ID 405 gen 525214 top level 392 path tmp/@home_08022018_18.04upgrade ID 406 gen 470839 top level 5 path @_08022018_18.04inProgressUpgrade ID 407 gen 470839 top level 5 path @apt-snapshot-release-upgrade-bionic-2018-02-08_15:27:27 ID 408 gen 470839 top level 5 path @home_16022018_gnomeWayland ID 409 gen 470839 top level 5 path @_16022018_cleanDevPlgs ID 410 gen 470995 top level 5 path @_24022018_fontsRemove ID 411 gen 470839 top level 5 path @home_24022018_fontsRemove ID 412 gen 506764 top level 5 path @libvirt-images_19032018_lxc ID 413 gen 514532 top level 264 path @home_rosa/@home_playonlinux_22032018_finereader14 user@pay2:~$ mount | grep btrfs /dev/sdb4 on / type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=392,subvol=/@) /dev/sdb4 on /home type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=393,subvol=/@home) /dev/sdb4 on /home/user/.config/chromium type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=401,subvol=/@home_chromium) /dev/sdb4 on /home/user/.thunderbird type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=277,subvol=/@home_thunderbird) /dev/sdb4 on /home/user-rosa type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=264,subvol=/@home_rosa) /dev/sdb4 on /home/user/.PlayOnLinux type btrfs (rw,relatime,compress=lzo,ssd,space_cache,subvolid=335,subvol=/@home_rosa/@home_playonlinux) /dev/sda1 on /media/3TB_Toshiba_BTRFS/files type btrfs (rw,relatime,compress=lzo,space_cache,subvolid=321,subvol=/@files) /dev/sda1 on /media/3TB_Toshiba_BTRFS/Linux-Dumalogiya type btrfs (rw,relatime,compress=lzo,space_cache,subvolid=506,subvol=/@linux-dumalogiya) /dev/sda1 on /media/3TB_Toshiba_BTRFS/oblako-backup type btrfs (rw,relatime,compress=lzo,space_cache,subvolid=258,subvol=/@oblako-backup) /dev/sda1 on /home/user/Загрузки type btrfs (rw,relatime,compress=lzo,space_cache,subvolid=300,subvol=/@downloads) /dev/sda1 on /home/user/.steam type btrfs (rw,relatime,compress=lzo,space_cache,subvolid=807,subvol=/@steam-mikhailnov) /dev/sda1 on /var/lib/libvirt type btrfs (rw,relatime,compress=lzo,space_cache,subvolid=260,subvol=/@libvirt) Это все для полноты понимания картины, в целом расположено в порядке убывания важности. $ sudo parted -l Модель: ATA TOSHIBA HDWD130 (scsi) Диск /dev/sda: 3001GB Размер сектора (логич./физич.): 512B/4096B Таблица разделов: gpt Флаги диска: Номер Начало Конец Размер Файловая система Имя Флаги 1 1049kB 2784GB 2784GB btrfs 3 2784GB 2994GB 210GB btrfs 4 2994GB 2994GB 262MB fat32 загрузочный, esp 2 2994GB 3001GB 6816MB linux-swap(v1) Модель: ATA KingDian S400 12 (scsi) Диск /dev/sdb: 120GB Размер сектора (логич./физич.): 512B/512B Таблица разделов: gpt Флаги диска: Номер Начало Конец Размер Файловая система Имя Флаги 1 1049kB 99,6MB 98,6MB fat32 загрузочный, esp 4 99,6MB 119GB 119GB btrfs 3 119GB 120GB 1030MB linux-swap(v1) Ладно, не важно. Это всё оффтопик тут. (В ответ на комментарий №19) > Как я представляю процесс, файла /initramfs.sh не будет до > загрузки ядра на стадии initrd, даже если в процессе работы системы он был > положен в /initramfs.sh Ошибочное представление. Стадия initrd выполняется тогда, когда ядро и initramfs уже загружены загрузчиком. Задача initrd -- найти и смонтировать правильный корень, возможно, предварительно подгрузив нужные модули УЖЕ ЗАГРУЖЕННОГО ядра. Разве скрипт /initramfs.sh поможет в решении проблемы обновления текущего ядра вместе с initrd? Видел как отдельные товарищи вкорячивают подобное в init-bottom из make-initrd-propagator, но ничего хорошего из этой практики не вынести. Есть лишь один путь в этом направлении без lowmem + перезапуск, IMHO. "Ошибочное представление. Стадия initrd выполняется тогда, когда ядро и initramfs уже загружены загрузчиком. Задача initrd -- найти и смонтировать правильный корень, возможно, предварительно подгрузив нужные модули УЖЕ ЗАГРУЖЕННОГО ядра." То есть initrd выполняется уже после загрузки ядра с cmdline rootflags=subvol=@ и монтирование, эквивалентного выполнению команды "mount /dev/sdXY -o subvol=@ /" ? Только после этого адрес скрипта будет не /@/initramfs.sh, a /initramfs.sh . (В ответ на комментарий №13) > Буквально на днях обсуждал с Глебом. Я думал сделать фичу, что если в корне > системы появляется исполняемый /initramfs.sh, то initrd перемонтирует корень в > RW b выполнит этот скрипт вместо init= и после завершения скрипта сделает > reboot. Можно не фичу, а маленький патчик init-bottom, но отсутствие lowmem желательно тоже проверять. По сути, нужен временный [активный] пункт загрузки, может даже временный grub.cfg без выбора вариантов и пауз, на случай деликатных обновлений, затрагивающих ядро, initramfs, системные службы. Загрузка в этом случае обязательно должна выполняться в оперативку, хотя мы никогда старые ядра, модули и initramfs не удаляем сразу, но без такой проверки это невозможно сделать вообще. (В ответ на комментарий №27) > Только после этого адрес скрипта будет не /@/initramfs.sh, a /initramfs.sh Вас действительно трудно понять. Если initrd находит корень, он и скрипт в корне найдёт. Специального адреса для этого не требуется! Требуется. * создайте раздел btrfs /dev/sdXY и точку монтирования /tmp/0 * mount /dev/sdXY /tmp/0 * ls 0 - будет пусто * btrfs subvol create /tmp/0/@; btrfs subvol create /tmp/0/@home * ls 0; будет @ @home * touch /tmp/0/@/testfile * umount /tmp/0 * mount /dev/sdXY -o subvol=@ /tmp/0 * ls /tmp/0; будет testfile Только вместо testfile будут /bin, /lib и остальные папки корня системы вместо с initramfs.sh (В ответ на комментарий №26) > Разве скрипт /initramfs.sh поможет в решении проблемы обновления текущего ядра > вместе с initrd? А вот на такие вопросы хочется отвечать. Этот скрипт исключить все пользовательские программы и пользователя самого из поцесса обновления. Кроме того, это гарантирует перезагрузку системы с обновлением. В целом, это мысли не мои. А в нашем startup в rc.sysinit существует целый ряд таких флагов, которые выполняются в процессе инициализации системы (/fastboot, /forcefsck, /.autorelabel). Также если вернуться к обновлениям, то, например, fedora обновляет. На такой подход есть разные точки зрения. (В ответ на комментарий №29) > Требуется. Нет, не требуется. > Только вместо testfile будут /bin, /lib и остальные папки корня системы вместо > с initramfs.sh Ну и что? Есть же /initramfs.sh в корне? > * btrfs subvol create /tmp/0/@ А теперь хорошенько подумайте зачем вы только что это сделали в Альт-Линуксе! И какая документация перед вами открыта!? ;-) Ubiquity здесь нет и про его привычки здесь мало кто знает. С удивлением для себя узнал, что он это делает. > * touch /tmp/0/@/testfile Всё куда проще. Смонтировали subvolume, сделали touch, назначили этот subvolume корнем, если уж хотите жить в убунте^W^W по феншую^W^W иметь корень в отдельном subvolume с таким экзотическим именем: btrfs subvolume set-default 333 /tmp/0/@ А вообще, Михаил, отрадно что Вы занимаетесь масштабными внедрениями, тянетесь к знаниям, но продолжение темы правильной работы с btrfs здесь неуместно. (В ответ на комментарий №30) > Этот скрипт призван исключить все пользовательские программы и > пользователя самого из поцесса обновления. Да я в целом за, просто и сам делал/напрывался на всякие грабли, видел, как другие тужатся, в том числе, переделывая наш initrd. Практика есть плохая и хорошая. Если уж идти по такому пути, надо понимать, зачем мы это делаем. Например, этот скрипт может много чего с собой тащить. Может и весь диск переразметить / отформатировать. Но всего это не сделаешь, если ядро, initrd и сам этот скрипт не будут лежать в оперативке в не привязанном к корневому разделу и даже всему диску состоянии. > Кроме того, это гарантирует перезагрузку системы с обновлением. echo u > /proc/sysrq-trigger sleep 2 echo b > /proc/sysrq-trigger в конце этого скрипта гарантирует на любых системах, ага! :) Тогда давайте сделаем отдельный баг или для обсуждения этой темы. --------- > Ну и что? Есть же /initramfs.sh в корне? На этапе работы initrd в корне есть только @, а внутри директории @ есть initramfs.sh, если я правильно понимаю работу initrd и загрузку системы. Соответственно, в корне initramfs.sh нет на эатпе загрузки системы в initrd. > А теперь хорошенько подумайте зачем вы только что это сделали в Альт-Линуксе! И какая документация перед вами открыта!? ;-) Ubiquity здесь нет и про его привычки здесь мало кто знает. С удивлением для себя узнал, что он это делает. И что? Эта стандартная функция BTRFS (и Grub тоже), какая разница Альт это или не Альт? btrfs-progs, coreutils и ядро одинаковые. > Всё куда проще. Смонтировали subvolume, сделали touch, назначили этот subvolume корнем, если уж хотите жить в убунте^W^W по феншую^W^W иметь корень в отдельном subvolume с таким экзотическим именем: > btrfs subvolume set-default 333 /tmp/0/@ Это _иная_ схема снапшотирования, она мне менее удобная, чем описанная выше, почему — расписать можно, но не в этом баге. Нет, не проще и не логичнее. Под нее постепенно пишу скрипт https://github.com/mikhailnov/dumasnap для автоматизации снапшотирования, пока что умеет только создавать снапшоты. И вообще, если такая установка и работа системы возможны, то значит возможны и никакие извороты не должны ее ломать или отваливаться на ней. Обсуждать нужно не нужность, краосту и популярность такой схемы разбивки системы на подтома, а ее совместимость с предложенным решением /initramfs.sh. ("Я думал сделать фичу, что если в корне системы появляется исполняемый /initramfs.sh, то initrd перемонтирует корень в RW b выполнит этот скрипт вместо init= и после завершения скрипта сделает reboot.") на btrfs мир не заканчивается. есть ещё другие файловые системы, из которых кто-то поддерживает снэпшоты, а кто-то нет. И ещё - я с удивлением узнал что на альте кто-то использует btrfs в production. Не будет ли вам так сложно описать несколько ваших сценариев его использования - можно по почте или на www.altlinux.org. Мы по ним добавим тесты в нашу систему тестирования и вероятность взрыва при обновлении у вас станет меньше. А то я так смело перекладываю btrfs из Sisyphus в p8, делая минимальные тесты... Не совсем понимаю при чём тут timeshift, да и p8 уже не поддерживается. |
Created attachment 7306 [details] Лог обновления Обновлении Workstation с P8 до Sisyphus завершается с ошибками (см. прикрепленный файл) После обновления: # apt-get dist-upgrade Чтение списков пакетов... Завершено Построение дерева зависимостей... Завершено You might want to run `apt-get --fix-broken install' to correct these. Следующие пакеты имеют неудовлетворенные зависимости: udev#1:233-alt0.M80P.1: Для установки требует: udev-rules (= 1:233-alt0.M80P.1) Для установки требует: udev-hwdb (= 1:233-alt0.M80P.1) Для установки требует: systemd-utils (= 1:233-alt0.M80P.1) udev-hwdb: Конфликтует: udev (< 1:235-alt3) udev-rules: Конфликтует: udev (< 1:235-alt3) E: Unmet dependencies. Try using --fix-broken.