LINUX.ORG.RU

Сообщения NightSpamer

 

сгорел древний аппаратный raid контроллер.

Supertrak ex8350 всё. Запасного нет. Достать такой-же, по всей видимости, уже не представляется возможным. Как собрать мой RAID5 (8*2Tb) обратно? Хотя-бы на время бэкапа с него. mdadm умеет форматы метаданных железных контроллеров?

 ,

NightSpamer
()

Форвардинг от 2х провайдеров в свою LAN - работает только один.

Шлюз, 2 интерфейса смотрят в интернеты через разных провайдеров, 1 в LAN. Внутри LAN есть более другой комп, на который хочется прокинуть tcp:3389 так, чтобы он был виден через оба входа. Но где-то я затупил... Таблицы и правила маршрутизации создал:

# ip ru sh
0:      from all lookup local 
32764:  from AA.AA.AA.AA lookup prov1
32765:  from BB.BB.BB.BB lookup prov2
32766:  from all lookup main 
32767:  from all lookup default
# ip r s ta prov1
default via AA.AA.AA.GW dev vlan101 
AA.AA.AA.0/24 dev vlan101  scope link
# ip r s ta prov2
default via BB.BB.BB.GW dev vlan103
BB.BB.BB.BB.0/24 dev vlan103  scope link
DNAT для всех tcp:3389 на вендокомп:
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 3389 -j DNAT --to-destination DD.DD.DD.DD
В nat/POSTROUTING на всех интерфейсах -j SNAT на соответствующие адреса.
И... вендокомп доступен только через того провайдера, на которого указывает default via в таблице main. Сделал так:
*nat
-A PREROUTING -p tcp -m tcp --dport 3389 -j rdp_redir
-A rdp_redir -j LOG --log-prefix "NPRE:"
-A rdp_redir -j DNAT --to-destination DD.DD.DD.DD
*mangle
-A INPUT -p tcp -m tcp --dport 3389 -j LOG --log-prefix "MI:"
-A FORWARD -p tcp -m tcp --dport 3389 -j LOG --log-prefix "MF:"
Пакет, пришедший от «неактивного» провайдера в nat/PREROUTING попадает (вижу в логе), а в mangle уже нет. Между ними только <routing decision>, если верить этой картинке.
Что не так? Почему пакет пропадает?

NightSpamer
()

Низкая скорость дисковых операций гостя kvm

Имеется гента с app-emulation/qemu-1.1.2-r2. Гость win2k3x64. Диск гостя

    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='writeback' io='native'/>
      <source file='/home/virtman/images/2k3x64.img'/>
      <target dev='vda' bus='virtio'/>
      <alias name='virtio-disk0'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/>
    </disk>

# qemu-img info /home/virtman/images/2k3x64.img
image: /home/virtman/images/2k3x64.img
file format: qcow2
virtual size: 250G (268435456000 bytes)
disk size: 24G
cluster_size: 65536
Производительность дисков хоста
# hdparm -tT /dev/sda2 

/dev/sda2:
 Timing cached reads:   22734 MB in  2.00 seconds = 11379.76 MB/sec
 Timing buffered disk reads: 770 MB in  3.00 seconds = 256.36 MB/sec
В госте копирование 200Mb файла занимает около 15-ти минут. Т.е. раз в 500 медленнее, чем умеет хост... Загрузка на хосте при копировании примерно такая
%Cpu(s):  0.8 us,  1.4 sy,  0.0 ni, 91.5 id,  6.3 wa,  0.0 hi,  0.0 si,  0.0 st
С чем такая печаль может быть связана? Где и как искать затык?

 ,

NightSpamer
()

[gentoo] revdep-rebuild vs dlopen()

Напал глюк:

$ sudo
sudo: не удаётся выполнить dlopen для /usr/lib/sudo/sudoers.so: /usr/lib/sudo/sudoers.so: неверный заголовок ELF
sudo: фатальная ошибка, не удалось загрузить модули

$ head /usr/lib/sudo/sudoers.so
SET(CMAKE_C_CREATE_SHARED_LIBRARY_FORBIDDEN_FLAGS "" )
SET(CMAKE_CXX_CREATE_SHARED_LIBRARY_FORBIDDEN_FLAGS "")

# Setup for Leopard Compatibility
EXEC_PROGRAM(sw_vers ARGS -productVersion OUTPUT_VARIABLE _OSX_VERSION)
# MESSAGE (STATUS "_OSX_VERSION: ${_OSX_VERSION}")
IF ( _OSX_VERSION MATCHES "^10.4" )
  #IF(CMAKE_COMPILER_IS_GNUCC)
    SET (CMAKE_C_FLAGS_INIT "")
    SET (CMAKE_C_FLAGS_DEBUG_INIT "-gdwarf-2")

$ revdep-rebuild -- -pv
 * You are not superuser. Adding --pretend to emerge options.
 * Configuring search environment for revdep-rebuild

 * Checking reverse dependencies
 * Packages containing binaries and libraries broken by a package update
 * will be emerged.

 * Collecting system binaries and libraries
 * Generated new 1_files.rr
 * Collecting complete LD_LIBRARY_PATH
 * Generated new 2_ldpath.rr
 * Checking dynamic linking consistency
[ 100% ]                 

 * Dynamic linking on your system is consistent... All done.
Конечно, sudo я пересоберу... а как узнать, что ещё сломалось?

 

NightSpamer
()

Сборка ядра - изменить root device.

При запуске свежесобранного sys-kernel/gentoo-sources-3.1.5 получаю что-то похожее на

Kernel panic:VFS: Unable to mount root fs on unkown-block (2,0)
Лечится оно добавлением root=/dev/sda1 в /boot/grub/grub.conf, но:
1. Почему оно теперь пытается грузиться с (2,0), если всегда (2.6.*-3.0.6) правильно определялось, что нужно грузиться с (8,1)?
2. Как сделать так, чтобы снова не требовалось дописывать root= в grub.conf? Где это рулится?

NightSpamer
()

RSS подписка на новые темы