find /lib -exec pacman -Qo -- {} +
ошибка: не удалось установить владельца каталога '/lib'
/lib/libnss_db.so.2 принадлежит glibc 2.16.0-1
/lib/libdl-2.16.so принадлежит glibc 2.16.0-1
/lib/libcidn-2.16.so принадлежит glibc 2.16.0-1
/lib/libdl.so.2 принадлежит glibc 2.16.0-1
/lib/libutil-2.16.so принадлежит glibc 2.16.0-1
/lib/libanl-2.16.so принадлежит glibc 2.16.0-1
/lib/libcrypt.so.1 принадлежит glibc 2.16.0-1
/lib/libc-2.16.so принадлежит glibc 2.16.0-1
/lib/libnss_dns.so.2 принадлежит glibc 2.16.0-1
/lib/libm.so.6 принадлежит glibc 2.16.0-1
/lib/libthread_db-1.0.so принадлежит glibc 2.16.0-1
/lib/libmemusage.so принадлежит glibc 2.16.0-1
/lib/libSegFault.so принадлежит glibc 2.16.0-1
/lib/libnss_nis.so.2 принадлежит glibc 2.16.0-1
/lib/libcidn.so.1 принадлежит glibc 2.16.0-1
/lib/libpthread.so.0 принадлежит glibc 2.16.0-1
/lib/libnss_files.so.2 принадлежит glibc 2.16.0-1
/lib/libanl.so.1 принадлежит glibc 2.16.0-1
/lib/libnss_files-2.16.so принадлежит glibc 2.16.0-1
/lib/libnss_dns-2.16.so принадлежит glibc 2.16.0-1
/lib/libc.so.6 принадлежит glibc 2.16.0-1
/lib/ld-linux-x86-64.so.2 принадлежит glibc 2.16.0-1
/lib/librt.so.1 принадлежит glibc 2.16.0-1
/lib/libresolv-2.16.so принадлежит glibc 2.16.0-1
/lib/libnss_compat-2.16.so принадлежит glibc 2.16.0-1
/lib/libpcprofile.so принадлежит glibc 2.16.0-1
/lib/libBrokenLocale-2.16.so принадлежит glibc 2.16.0-1
/lib/libnsl.so.1 принадлежит glibc 2.16.0-1
/lib/libnss_compat.so.2 принадлежит glibc 2.16.0-1
/lib/libpthread-2.16.so принадлежит glibc 2.16.0-1
/lib/ld-2.16.so принадлежит glibc 2.16.0-1
/lib/libnss_db-2.16.so принадлежит glibc 2.16.0-1
/lib/libresolv.so.2 принадлежит glibc 2.16.0-1
/lib/libthread_db.so.1 принадлежит glibc 2.16.0-1
/lib/libnss_nis-2.16.so принадлежит glibc 2.16.0-1
/lib/libm-2.16.so принадлежит glibc 2.16.0-1
/lib/libnss_nisplus.so.2 принадлежит glibc 2.16.0-1
/lib/libBrokenLocale.so.1 принадлежит glibc 2.16.0-1
/lib/libnss_nisplus-2.16.so принадлежит glibc 2.16.0-1
/lib/librt-2.16.so принадлежит glibc 2.16.0-1
/lib/libnss_hesiod-2.16.so принадлежит glibc 2.16.0-1
/lib/libcrypt-2.16.so принадлежит glibc 2.16.0-1
/lib/libnsl-2.16.so принадлежит glibc 2.16.0-1
/lib/libnss_hesiod.so.2 принадлежит glibc 2.16.0-1
/lib/libutil.so.1 принадлежит glibc 2.16.0-1
Вроде ничего левого нет.
Ну вот почему он не хочет обновляться? Задолбало воссланавливать либ с лайвсиди. Как это сделать одной командой чтоб glib не успел отвалиться при обновлении
sudo pacman -Syu
glibc: /lib уже существует в файловой системе
Есть аналоги e4rat под btrfs?
realloc в btrfs не работает т к сразу определяет файловую систему.
Вообще, preload дает порядка 5 секунд выйгрыша при использовании сжатого бтрфс, но при общем времени более минуты (минута и 10 сек от груба+enter до появления рабочего стола кед, после чего еще много всего грузится) Т е нецелесообразно. Возможно эффект сильнее проявляется на приложениях, которые запускаются после загрузки.
“”Никогда не используйте –force во время этого обновления“”
Чего делать тем, кто сначала делает, потом думает, и только потом читает руководства?
Сразу после попытки апдейта все программы перестали находиться по своим местам проживания. (хотя файлы на месте) После ребута ядро в панике.

Все решается созданием вручную ссылки ln -s /usr/lib /lib
При обновлении glibc с ключем -f он убивает /lib, а симлинк создать не успевает.
При попытке обновить другую машину по инструкциям тоже ничего не вышло, даже после удаления всех левых файлов из /lib (остались только принадлежащие glibc) Действовал также как ив первом случае ))
Надо допиливать процесс обновления, так никуда не годится.
Замечательный способ убить несколько часов в воскресенье.
Не так давно мучился. HPLIP на той машине почему-то все время просил плагин, но сам его поставить не мог, да и тот что из AUR не видел. В общем, настраивал через купс, расшаривал через него же (протокол ipp). Еще понадобилось написать правило udev чтобы давать принтеру права на запись для всех, после чего все заработало. На машине с виндой возможно понадобиться драйвер от принтера, но можно попробовать некий дефолтный.
Сканер не настраивал, но копать в строну sane. Утилиты HP шарить сканер вроде бы не умеют.
Ставил недавно какой-то линукс-роутер на базе центОС. Производительность сразу была на уровне без всяких шаманств и виртио дров.
Этот же дистр в вибоксе загружаться отказался совсем.
После обновления он нашел еще несколько локальных подписей и предложил подписать. Если отказаться, то похоже что из комьюнити ничего не поставится.

ошибка: mutagen: signature from “Eric Belanger <[email protected]>&rdquo; is unknown trust
ошибка: libgpod: signature from “Ionut Biru <[email protected]>&rdquo; is unknown trust
ошибка: protobuf: signature from “Sven-Hendrik Haase <[email protected]>&rdquo; is unknown trust
ошибка: clementine: signature from “Stéphane Gaudreault <[email protected]>&rdquo; is unknown trust

Пришлось подписать.
ElSonador
Говоря короче, неюзабельный шлак.
Чем Hyper-V не устроил?

Нашел прикольные графики.
http://www.phoronix.com/scan.php?page=a … virt&num=3
Там тоже видно явный провал по i/o в KVM. Видать без паравиртуальных дров оно нормально в принципе не работает. это минус.
По прочим же параметрам (это без спец дров в KVM, получается) вибокс отстает в разы.
http://docs.redhat.com/docs/en-US/Red_H … /virt.html
Direct Asynchronous IO (AIO) that is not issued on filesystem block boundaries, and falls into a hole in a sparse file on ext4 or xfs filesystems, may corrupt file data if multiple I/O operations modify the same filesystem block. Specifically, if qemu-kvm is used with the aio=native IO mode over a sparse device image hosted on the ext4 or xfs filesystem, guest filesystem corruption will occur if partitions are not aligned with the host filesystem block size. Generally, do not use aio=native option along with cache=none for QEMU. This issue can be avoided by using one of the following techniques:

Align AIOs on filesystem block boundaries, or do not write to sparse files using AIO on xfs or ext4 filesystems.
KVM: Use a non-sparse system image file or allocate the space by zeroing out the entire file.
KVM: Create the image using an ext3 host filesystem instead of ext4.
KVM: Invoke qemu-kvm with aio=threads (this is the default).
KVM: Align all partitions within the guest image to the host's filesystem block boundary (default 4k).

Прочитал TFM http://www.linux-kvm.org/page/Windows7Install
При установке виртио дров во время установки винды, та устанавливается быстро как в виртуалбоксе, но после перезагрузки во время “настройки” наглухо виснет. Я к тому же отключил кеширование на диске, включих потоки (многопоточность?) Использовал формат raw как самый быстрый (почему-то по умолчанию был). Если прочитать то, что выше на английском, то такая связка вкупе с ext4 на хосте должна вызывать проблемы. Возможно зависон отсюда. Ну и хранилище дисков сделал в домашней директории, т к в var места нет.
Вирт-мэнеджер генерирует такое безобразие
/usr/bin/qemu-kvm -S -M pc-0.15 -cpu phenom,+nodeid_msr,+wdt,+skinit,+ibs,+osvw,+3dnowprefetch,+misalignsse,+sse4a,+abm,+cr8legacy,+extapic,+cmp_legacy,+lahf_lm,+rdtscp,+pdpe1gb,+popcnt,+cx16,+ht,+vme -enable-kvm -m 1024 -smp 1,sockets=1,cores=1,threads=1 -name w7 -uuid e022bff9-c975-66c3-ab11-168077840e3e -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/w7.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-shutdown -boot order=cd,menu=on -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x5 -drive file=/home/deem/Documents/w7.img,if=none,id=drive-virtio-disk0,format=raw,cache=none,aio=threads -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x6,drive=drive-virtio-disk0,id=virtio-disk0 -drive file=/home/deem/1GB_lin/Programs/virtio-win-0.1-22.iso,if=none,id=drive-ide0-0-0,readonly=on,format=raw -device ide-cd,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0 -drive file=/home/deem/1GB_lin/Programs/7600.16385.090713-1255_x86fre_enterprise_en-us_EVAL_Eval_Enterprise-GRMCENEVAL_EN_DVD.iso,if=none,id=drive-ide0-1-0,readonly=on,format=raw -device ide-cd,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -netdev tap,fd=20,id=hostnet0 -device rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:0e:d8:fe,bus=pci.0,addr=0x3 -chardev pty,id=charserial0 -device isa-serial,chardev=charserial0,id=serial0 -chardev spicevmc,id=charchannel0,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.spice.0 -device usb-tablet,id=input0 -spice port=5900,addr=127.0.0.1,disable-ticketing -vga qxl -global qxl-vga.vram_size=67108864 -device intel-hda,id=sound0,bus=pci.0,addr=0x4 -device hda-duplex,id=sound0-codec0,bus=sound0.0,cad=0 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x7
/etc/init.d/vboxdrv уже давно не нужен и его нет. Модули сами обновляются когда надо. Ну если ведро кастомное, то гляньте в вики, мож там новый способ есть.
Подгружайте модули и работайте.
Ну что же. Комп 4 ядра, 8 гигов. Под виртуалку выделяется 1 ядро, 1 гиг, 6,5ГБ диск.
Поставил винду 7 в виртуалбокс - 10 минут (из них минут 5 компилял программку в фоне)
Ставлю c этого же образа через виртмэнеджер. Уже прошло 10 минут. Процесс еще на 30%. Скорость дисковых операций такая же низкая как у меня на ноуте. Все заметно медленнее чем в вибоксе. spice тоже грузит процессор (как vnc) если двигать мышкой. Видать тупо сжимается видеопоток и тут же разжимается.
Диск шуршит заметнее, загрузка процессора ощутимая (вроде повыше). Прошло 20 минут - 60%
через программку aqemu.(без libvirt) еще в несколько раз медленнее.