LINUX.ORG.RU

ArchLinux файлы *.pacnew - как вы за ними следите?

 ,


3

2

Началось с того, что обновление mkinitcpio прилетело. С новым mkinitcpio.conf.pacnew. Посмотрел, что там нового. Метод сжатия добавили. Хорошо, понятно. Переписал эту строчку в свой mkinitcpio.conf.

Ладно, думаю, это же неудобно. Было бы здорово, если бы мои HOOKS и FILES подхватывались из какого-нибудь внешнего *.conf, а основной не шевелить. Посмотрел в исходник - там вроде нет такой возможности. Вся конфигурация берётся из одного mkinitcpio.conf.

Плохо, думаю, но шут с ним, просто надо помнить про *.pacnew и тщательней за ним следить.

Дай, думаю, поищу вообще сколько таких pacnew уже накопилось и что там наизменялось. Так там их 26(!!!) штук за два года накопилось! Просто не все успеваю заметить, когда прилетают на обновлениях.

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

И внезапно натыкаюсь на вот такое:

cat /etc/systemd/journal-remote.conf 
service tftp
{
	socket_type	= dgram
	protocol	= udp
	wait		= yes
	user		= nobody
	server		= /usr/sbin/tftpd
	server_args	= /var/tftpboot
	disable		= yes
}
т.е. содержимое этого файла - это вообще мусор какой-то, никакого отношения к journal-remote абсолютно не имеющий!
С journal-remote.conf.pacnew - ни одной буквы не совпадает.

Судя по тому, что оба файла одинакового размера 695 байт - похоже на то, что когда-то было аварийное отключение и fsck на ext4 вот так вот его «починило» - подставив какие-то случайные блоки. Где когда и как - видимо уже не узнать.

И ладно, этот файлик мне не нужен. Но раз есть такой прецедент - значит могут где-то в корне быть и другие файлики с мусором! И кто их знает какой они нужности.

--------------

В общем - как страшно жить.

Дорогие арчеводы, а как вы следите за pacnew? И как проверяете целостность содержимого корня?

★★★★

не слежу, я сам настроил софт, и мне насрать, что там в дефолтных конфигах нового, если нужно - man прочитаю

anonymous
()
Ответ на: комментарий от anonymous

Спасибо. Только что-то не то оно проверяет.

Никаких подозрений не вываливает.

Однако вот глазами непосредственно сейчас:

cat udev.conf 
# The file /etc/fuse.conf allows for the following parameters:
#
# user_allow_other - Using the allow_other mount option works fine as root, in
# order to have it work as user you need user_allow_other in /etc/fuse.conf as
# well. (This option allows users to use the allow_other option.) You need
# allow
vs
cat udev.conf.pacnew 
# see udev.conf(5) for details
#
# udevd is also started in the initrd.  When this file is modified you might
# also want to rebuild the initrd, so that it will include the modified configuration.

#udev_log=info
#children_max=
#exec_delay=
#event_timeout=180
#timeout_signal=SIGKILL
#resolve_names=early

Первое - это вообще содержимое fuse.conf должно было быть.

Кажется, что всё даже хуже, чем показалось сначала. По крайней мере paccheck никак на такое не реагирует.

Toxo2 ★★★★
() автор топика
Ответ на: комментарий от anonymous

Этот файл (/etc/udev/udev.conf) я уже успел заменить. Только что. Как нахожу, так меняю.

Вот следующий такой же:

cat /etc/systemd/resolved.conf 
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See systemd-sleep.conf(5) for details

[Sleep]
#AllowSuspend=yes
#AllowHibernation=yes
#AllowSuspendThenHibernate=yes
#AllowHybridSleep=yes
#SuspendMode=
#SuspendState=mem standby freeze
#HibernateMode=platform shutdown
#HibernateState=disk
#HybridSleepMode=suspend platform shutdown
Как видно - это должно было быть содержимым файла systemd-sleep.conf.

Да, он есть в списке измененных по pacman -Qii | awk '/^MODIFIED/ {print $2}'

Toxo2 ★★★★
() автор топика
Ответ на: комментарий от Toxo2

Тогда тебе все измененные файлы проверять, как так могло содержимое файлов поменяться я не представляю

Заодно проверь и непринадлежащие пакетам файлы. Я бы и все пакеты на всякий случай переставил

 sudo find /etc -exec pacman -Qo -- {} + >/dev/null

anonymous
()
Ответ на: комментарий от Toxo2

А не может это cat или что другое глючить подставляя не тот файл. В текст.редакторе графическом тот же файл или в mc не проверял содержимое. Как то очень странна такая замена содержимого

anonymous
()

Дорогие арчеводы, а как вы следите за pacnew?

Никак не слежу, иногда запускаю pacdiff.

Vigi
()
Ответ на: комментарий от anonymous

Конечно в mc и смотрю разницу содержимого файлов.

Давным давно было что-то похожее. Я тут где-то рассказывал. Все файлы *.asm обнаружил однажды полностью затертыми нулями. Размер тот же, имена те же. А внутри - нули. Вот тогда это было совсем страшно )

А сейчас, в общем, почти понятно и привычно. Там же не полностью содержимое других файлов. Там именно мусор - кусок начинается как другой файл, а хвост или обрезан, или добит непечатными символами, до размера оригинала. Это даже проще, чем нули понять. И простить. )

Ладно, пойду дальше вручную искать где-что еще подобное развалилось.

Toxo2 ★★★★
() автор топика
Последнее исправление: Toxo2 (всего исправлений: 2)

Обычно забиваю. Могу иногда диффнуть, если что-то важное. Пару месяцев назад, после обновления, из-за изменившегося конфига, упал необязательный сервис. До сих пор лежит xD. А вообще, pacman каждый раз сообщает, что появился .pacnew. В лог эта инфа тоже попадает.

anonymous
()

Забиваю, до тех пор пока в апстриме не сломают совместимость со старым конфигом.

Раз в пару лет могу запустить pacdiff, который специально для этого придумали.

sergej ★★★★★
()

Судя по тому, что оба файла одинакового размера 695 байт - похоже на то, что когда-то было аварийное отключение и fsck на ext4 вот так вот его «починило» - подставив какие-то случайные блоки. Где когда и как - видимо уже не узнать.

ext4, стабильно и надёжно %)

И как проверяете целостность содержимого корня?

С помощью btrfs.

// мимопроходил, .pacnew сливаю руками по типу find -exec vimdiff

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

ext4, стабильно и надёжно

Это и правда так. Первый раз на ext такое поймал. Сижу вот, разбираюсь.

Пока всё сводится к тому, что я отключал журнал (has_journal) на корнях (на всех своих Arch, Void, Fedora, Debian).

На важных данных, на home, и т.д. на других дисках - конечно не отключал.

Думал, мол, зачем оно на корне? Если что-то пойдет не так, то проще систему переустановить.

Просто очень неожиданно это обнаружилось. Не полез бы pacnew рассматривать - еще бы сто лет не замечал бы, что конфигурационные файлы поломаны. Никаких симптомов не было.

--------------

Из всех дистрибутивов, какие брал в руки - лучше всего в Solus с его eopkg было видно такие вещи. Просто «eopkg check» и он всё сразу рассказывает, где какие файлы подозрительные. В Fedora тоже можно rpm -Va - пусть не так красиво как в Solus, но всё-таки можно отслеживать. С остальными пока не разобрался. По крайней мере paccheck пока не могу заставить реагировать на измененный вручную /etc/udev/udev.conf

Toxo2 ★★★★
() автор топика
Ответ на: комментарий от Toxo2

Пока всё сводится к тому, что я отключал журнал (has_journal) на корнях (на всех своих Arch, Void, Fedora, Debian)

facepalm.jpg

intelfx ★★★★★
()
Ответ на: комментарий от greenman

А ведь отключение барьеров тоже ускоряет ext4 )

Да я тогда не про ускорение думал, когда так делал )

А про ресурс SSD. Мол, зачем мне его лишний раз теребить журналом, коль всё равно на корне нет ничего невосстановимого?

Разбил один диск SSD сразу на 7 разделов.
Первый - это EFI(esp) в FAT на 4ГБ.
А остальные шесть под разные линуксы. Все одинаковые и по размеру, и по опциям.

Потом только rootfs'ы подсовывал в разные разделы, и менял записи в gummiboot.

Они все в одинаковых условиях были.

sda      8:0    0 238,5G  0 disk 
├─sda1   8:1    0   4,1G  0 part /efi
├─sda2   8:2    0  39,1G  0 part /mnt/debian
├─sda3   8:3    0  39,1G  0 part /mnt/fedora
├─sda4   8:4    0  39,1G  0 part /mnt/suse
├─sda5   8:5    0  39,1G  0 part /mnt/ubuntu
├─sda6   8:6    0  39,1G  0 part /mnt/void
└─sda7   8:7    0  39,1G  0 part /
Toxo2 ★★★★
() автор топика
Последнее исправление: Toxo2 (всего исправлений: 2)
Ответ на: комментарий от Toxo2

Realtime для ext4 и trim по таймеру достаточно. Больше записей сделаешь восстанавливая систему чем журналом

anonymous
()

В итоге, по поводу проверки целостности файлов, вот такое нашел:

https://bbs.archlinux.org/viewtopic.php?id=191923
оно же: https://aur.archlinux.org/packages/check-pacman-mtree/

Оно реагирует на изменения внутренностей, например, /etc/udev/udev.conf, что и требовалось.

В исходниках самого pacman для -Qkk пока есть только заглушки для check_file_md5sum().

Всем спасибо, pacdiff наверняка тоже пригодится. Закрываем.

Toxo2 ★★★★
() автор топика
Ответ на: комментарий от anonymous

Там все vmlinuz+initrd лежат.

Каждый vmlinuz это около 10МБ в среднем + каждый initrd это около 30МБ в среднем. Если еще и fallback initrd, то получается под 100МБ на одно ядро для одного линукса, если грубо.

Шесть «линуксов», пусть у каждого по два ядра на выбор. Уже 1200МБ.

Плюс Void вообще все свои старые ядра не удаляет без отдельной команды (vkpurge) - можно хоть десять держать.

Плюс еще и свои самосборные варианты ядер. Итого 2000МБ- запросто может набежать.

Ну и обычно стараюсь на всех дисках держать около 50% свободного пространства. Когда любой из дисков >50% занят - волнуюсь, >75% нервничаю, >90% думаю куда бы перенести.

Как-то так думал, когда делал.

Toxo2 ★★★★
() автор топика
Ответ на: комментарий от Toxo2

если правильно понял, загрузчиками ты не пользуешься, а войд при обновлении ядра сам кладет образ на efi раздел или надо ручками?

anonymous
()
Ответ на: комментарий от anonymous

если правильно понял, загрузчиками ты не пользуешься, а войд при обновлении ядра сам кладет образ на efi раздел или надо ручками?

Там gummiboot загрузчиком. Это как раз Void меня научил им пользоваться.

Во всех остальных дистрибутивах он называется systemd-boot. Если уж совсем всё рассказывать - то я все варианты .efi выдергиваю и складываю на ESP руками. По факту - не вижу особой разницы между ними, поэтому исходный, воидовский gummiboot.efi устраивает. Но остальные, более современные варианты этого efi рядом лежат на всякий случай.

Но сейчас работает - именно оригинальный gummiboot.

Саму организацию loader.conf меня Fedora научила. Я бы сам не догадался. Есть такой kernel-install сценарий из состава systemd - вот он красиво делает раскладку ядер по каталогам, полагаясь на /etc/machine_id.

Но кроме Fedora - никто это не делает автоматом. Всех остальных (в т.ч. и Void) руками надо писать hooks, чтобы руками уже перекладывать образы и ядра.

В Arch это делал через HOOK в mkinitcpio. У всех по-разному.

Toxo2 ★★★★
() автор топика
Последнее исправление: Toxo2 (всего исправлений: 1)
Ответ на: комментарий от Toxo2

loader.conf

интересно, спасибо.

а в чем может быть польза для простых смертных?

я так сказать новичок, многого не понимаю, положил ядро на efi раздел, добавил в меню загрузки с помощью efibootmgr, что-то типа XXX.efi XXX.old.efi (initramfs не пользуюсь, пока не разобрался для чего оно мне нужно), теперь только подсовываю туда новые ядра.

может я чего-то упускаю?

anonymous
()
Ответ на: комментарий от anonymous

Например, опции загрузки ядра?

Бывают UEFI, которые не умеют их в себе сохранять (у меня такой). Плюс gummiboot умеет их редактировать на лету.

Только вы не ориентируйтесь на моих тараканов в голове. Я сам только года два, как стал плотно «играть в Линуксы» на этом уровне. Запросто могу ерунду говорить. До этого дальше LAMP их не ковырял. Просто любопытства ради это всё. Там где мне люди деньги платят - там всё максимально стандартно и скучно, без исподвыподвертов.

Toxo2 ★★★★
() автор топика
Ответ на: комментарий от Toxo2

В итоге, по поводу проверки целостности файлов, вот такое нашел: https://aur.archlinux.org/packages/check-pacman-mtree/

Вернулся поиграть в эту игру. Пытаюсь переписать этот lua сценарий на Си.

Похоже весь затык в том, что libarchive не умеет читать из mtree атрибуты контрольных сумм типа md5digest. В исходниках прям так и написано

if (strcmp(key, "md5") == 0 || strcmp(key, "md5digest") == 0) break;
Т.е. читать-то читает, но ничего с ними не делает. Насколько я понял - потому что его унифицированные archive_entry для разных форматов архивов просто не содержат таких структур под контрольные суммы.

Поэтому настоящие, честные инструменты для libalpm никогда не будут следить за целостностью распакованных пакетов, пока libarchive им этого не позволит.

То есть: [1] надо взять libaplm чтобы ходить по установленным пакетам (alpm_initialize, alpm_get_localdb и т.д.)
[2] надо взять (или написать) настоящий, не «либархивный» читальщик mtree, чтобы получать эти CRC. Или, как в том сценарии на lua, просто zlib распаковывать в гладкий текст.

С [1] вроде всё понятно и просто, работает.
Но с [2] - оказывается mtree в линуксах вообще не в почёте. Пока нашел только какие-то неубедительные попытки портировать из *BSD.

Не понятно. Получается, что один из культовых линуксов использует технологии из BSD, которые еще и не очень-то в линуксах поддерживаются вообще. Ещё более не понятно, конечно, как он стал культовым с таким провалом в пакетном менеджере не умеющим следить за CRC установленных пакетов.

Так просто, поговорил вслух.

Toxo2 ★★★★
() автор топика
Ответ на: комментарий от Toxo2

Он проверяет пакеты при установке. То что ты потом делаешь с файлами это твои проблемы. Если не лезть кривыми руками, то и проблем не будет

anonymous
()
Ответ на: комментарий от anonymous

Если не лезть кривыми руками, то и проблем не будет

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

Toxo2 ★★★★
() автор топика
Последнее исправление: Toxo2 (всего исправлений: 1)
Ответ на: комментарий от Toxo2

зачем волноваться и нервничать, если все равно до 90% не почухаешься

flant ★★★
()
Ответ на: комментарий от Toxo2

пока libarchive им этого не позволит.

Опоздал нервничать, оказывается, буквально на несколько месяцев )

В версии libarchive 3.4.4, которая сейчас на GitHub в разработке уже добавили чтение archive_entry_digest().
Собрал, проверил, работает на pacman'овских mtree.
Красота.

Значит скоро и в pacman -Qkk заработает.

Смешно и неловко вышло.
Ну, зато можно порадоваться, что кому-то ещё это нужно было. Там такая серьезная портянка в PR получилась у человека ради этого.

Toxo2 ★★★★
() автор топика
Последнее исправление: Toxo2 (всего исправлений: 1)
Ответ на: комментарий от Toxo2

Собрал, проверил, работает на pacman'овских mtree.

для ещё не вышедшей libarchive 3.4.4 (!важно!)

#include <sys/types.h>
#include <sys/stat.h>
#include <sys/mman.h>
#include <fcntl.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

#include <archive.h>
#include <archive_entry.h>
#include <alpm.h>
#include <openssl/md5.h>

#define MSG_BUF 512

const char *md5str(const unsigned char digest[], char buf[])
{
    for (int i = 0; i < MD5_DIGEST_LENGTH; i++)
    {
        sprintf(&buf[i * 2], "%02x", digest[i]);
    }
    return buf;
}

int main()
{
    alpm_errno_t alpm_err;
    alpm_handle_t *alpm = alpm_initialize("/", "/var/lib/pacman", &alpm_err);
    if (!alpm)
    {
        printf("Error on create ALPM handle: %d\n", alpm_err);
        return EXIT_FAILURE;
    };

    alpm_db_t *local_db = alpm_get_localdb(alpm);
    for (alpm_list_t *pkgs_list = alpm_db_get_pkgcache(local_db);
         pkgs_list;
         pkgs_list = alpm_list_next(pkgs_list))
    {
        alpm_pkg_t *pkg = pkgs_list->data;
        struct archive *mtree_archive = alpm_pkg_mtree_open(pkg);
        if (mtree_archive == NULL)
        {
            printf("\033[0m%s: \033[1;36mNot found mtree file!\033[0m\n", alpm_pkg_get_name(pkg));
            continue;
        }
        struct archive_entry *mtree_entry;
        while (alpm_pkg_mtree_next(pkg, mtree_archive, &mtree_entry) == ARCHIVE_OK)
        {
            if (archive_entry_filetype(mtree_entry) == AE_IFREG)
            {
                char msg[MSG_BUF] = {0};
                const char *mtree_pathname = archive_entry_pathname(mtree_entry);
                if (mtree_pathname[2] != '.')
                {
                    unsigned char real_md5[MD5_DIGEST_LENGTH] = {0};
                    const unsigned char *mtree_md5 = archive_entry_digest(mtree_entry, ARCHIVE_ENTRY_DIGEST_MD5);
                    if (memcmp(real_md5, mtree_md5, MD5_DIGEST_LENGTH))
                    {
                        const char *real_pathname = &mtree_pathname[1];
                        errno = 0;
                        int fid = open(real_pathname, O_RDONLY);
                        if (fid > 0)
                        {
                            struct stat statbuf;
                            if (fstat(fid, &statbuf) == 0)
                            {
                                unsigned long fsize = statbuf.st_size;
                                const unsigned char *fbuf = mmap(0, fsize, PROT_READ, MAP_SHARED, fid, 0);
                                MD5(fbuf, fsize, real_md5);
                                munmap((void *)fbuf, fsize);
                            }
                            else
                            {
                                snprintf(msg, MSG_BUF, "\033[1;33mUnable to stat file %s (%s)", real_pathname, strerror(errno));
                            }
                            close(fid);
                        }
                        else
                        {
                            snprintf(msg, MSG_BUF, "\033[1;33mUnable to open file %s (%s)", real_pathname, strerror(errno));
                        }
                        if (!msg[0] && memcmp(real_md5, mtree_md5, MD5_DIGEST_LENGTH))
                        {
                            char mtree_md5string[MD5_DIGEST_LENGTH * 2 + 1];
                            char real_md5string[MD5_DIGEST_LENGTH * 2 + 1];
                            snprintf(msg, MSG_BUF, "\033[1;31mWrong md5 %s : %s <> %s", real_pathname, md5str(mtree_md5, mtree_md5string), md5str(real_md5, real_md5string));
                        }
                    }
                    else
                    {
                        snprintf(msg, MSG_BUF, "\033[1;34mDoes not have md5 %s", mtree_pathname);
                    }
                }
                if (msg[0])
                {
                    printf("\033[0m%s: %s\033[0m\n", alpm_pkg_get_name(pkg), msg);
                }
            }
        }
        alpm_pkg_mtree_close(pkg, mtree_archive);
    }
    alpm_release(alpm);
    return EXIT_SUCCESS;
}

Первая, после 25 лет перерыва, программка на Си, которая даже что-то полезное делает. Радости-то, радости )

Toxo2 ★★★★
() автор топика

Не отпускает.

Теперь хочется и сам pacman поправить. Думаю ключи Qk и Qkk лучше оставить как есть, но добавить ключ Qkkk, который будет еще и md5 сверять. Во-первых чтобы не менять поведение первых, во-вторых чтобы пользователь не удивлялся насколько дольше md5 считать.

Читал это Pacman development. Всё, что простое - типа принятый у них CodeStyle, вроде поделал. (Хотя тоже с вопросами - если смотреть их собственный код, то там есть места, которые не вписываются в их же правила. Так, по-мелочи. То там скобочка не там, то сям пробельчик не по фен-шую)

Самое непонятное пока - а где там актуальные исходники-то? Как минимум три места декларируются как исходники - но все они разные.

----------------------
Вопрос: тут есть люди, которые принимали участие в разработке pacman? Или хотя бы отсылали patch?

Не могли бы проконсультировать новичка, опытом поделиться?

intelfx, вы же действующий, боевой разработчик, как я понимаю. Не пытались в pacman что-нибудь менять официально?

Toxo2 ★★★★
() автор топика
Ответ на: комментарий от Toxo2

Я не разработчик pacman.

Самое непонятное пока - а где там актуальные исходники-то? Как минимум три места декларируются как исходники - но все они разные.

Вопрос: тут есть люди, которые принимали участие в разработке pacman? Или хотя бы отсылали patch?

Не могли бы проконсультировать новичка, опытом поделиться?

https://www.archlinux.org/pacman/#_development

Теперь хочется и сам pacman поправить. Думаю ключи Qk и Qkk лучше оставить как есть, но добавить ключ Qkkk, который будет еще и md5 сверять. Во-первых чтобы не менять поведение первых, во-вторых чтобы пользователь не удивлялся насколько дольше md5 считать.

Только я не совсем понял твою идею. Какие md5 ты хочешь сверять и с чем?

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Какие md5 ты хочешь сверять и с чем?

А, пардон, значит надо пересказать краткое содержание всей темы:

  • в pacman нет механизма отслеживания изменений содержимого файлов, входящих в пакет;
  • есть риск иметь в системе измененные файлы незамеченными (ошибки носителя информации или собственные ошибки или злонамеренное изменение содержимого злоумышленниками);
  • текущий libarchive (3.4.3) не читает из mtree md5digest и sha256digest, просто не умеет;
  • в версии libarchive 3.4.4 приняты изменения, которые позволяют читать эти контрольные суммы - работает на pacman'овских mtree, проверил;
  • поэтому после выхода 3.4.4 ничего не будет мешать pacman их проверять.
Toxo2 ★★★★
() автор топика
Ответ на: комментарий от Toxo2

А, всё, я догнал, MTREE же сохраняются локально в /var/lib/pacman.

Тему-то я прочитал, просто сначала не очень было понятно, откуда ты собираешься брать контрольные суммы после распаковки и установки пакета.

Тогда да, наверное, можно попробовать запилить. Только не забудь сделать фильтр по имени пакета (pacman -Qkkk [PACKAGES...]), потому что это единственный вменяемый способ поддержать многопоточность, чтобы не было грустно на современных системах.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от greenman

Осталось написать, что же будет делать pacman -Qk и pacman -Qkk?

Здрасте. ) Они же и сейчас делают. Это его текущие ключи.

/src/pacman/query.c строка 321

	if(config->op_q_check) {
		if(config->op_q_check == 1) {
			ret = check_pkg_fast(pkg);
		} else {
			ret = check_pkg_full(pkg);
		}
	}

а в самой check_pkg_full сейчас вот такая заглушка у них (типа TODO на будущее)

		if(type == AE_IFREG) {
			file_errors += check_file_size(pkgname, filepath, &st, entry, backup);
			/* file_errors += check_file_md5sum(pkgname, filepath, &st, entry, backup); */
		}
И если они так и оставят - реализуют заглушку, то Qkk станет сильно дольше.

Toxo2 ★★★★
() автор топика
Последнее исправление: Toxo2 (всего исправлений: 2)
Ответ на: комментарий от Toxo2

Неправильно понял Значит скоро и в pacman -Qkk заработает, а man посмотреть не догадался.

greenman ★★★★★
()

Всё, вышла и уже прилетела libarchive новая.

Только не 3.4.4, а сразу 3.5.0 она.

Теперь код тремя сообщениями выше собирается и работает штатно.

И проверил, и заодно сразу /etc/systemd/homed.conf нашлось новое ) Там теперь btrfs предлагается в DefaultFileSystemType, хоть и под решеткой.

В сам pacman я предложения не отсылал. Стесняюсь пока. Может есть кто не стеснительный тут?

Toxo2 ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.