Сообщения Sferg

Артефакты на экране монитора при установке гостевой ОС Windows 10 в Proxmox. Как побороть?

Здравствуйте, господа. Извлёк vBIOS единственной в системе интегрированной видеокарты Intel UHD 605 из прошивки UEFI материнки и осуществил проброс видеокарты внутрь виртуалки на Proxmox. При запуске виртуалки изображение на экране монитора успешно появилось (без указания файла vBIOS в конфигурации виртуалки изображение не появлялось!). Теперь пытаюсь установить в качестве гостевой ОС Windows 10. Всё бы ничего, да вот только в процессе установки изображение неизменно портится. При этом, через 10-15 секунд, неизбежно процесс установки прерывается с выводом сообщения об ошибке или BSOD (с выводом различных ошибок). Прилагаю видео с экрана монитора с процессом происходящего на YouTube

Текущий файл конфигурации виртуалки /etc/pve/qemu-server/100.conf

agent: 1
args: -device vfio-pci,host=0000:00:02.0,id=hostpci0,addr=0x02,romfile=uhd605_vbios.rom
boot: dc
bootdisk: sata1
cores: 4
cpu: host
memory: 2048
name: Windows10
net0: rtl8139=A2:14:83:CD:2E:2A,bridge=vmbr0
ostype: win10
sata0: local:iso/windows10.iso,media=cdrom,size=4171424K
sata1: local:100/vm-100-disk-0.qcow2,size=32G
scsihw: virtio-scsi-pci
smbios1: uuid=18afecfa-fd48-4314-a226-002bf9d3705f
sockets: 1
usb0: host=0e6a:02c0
usb1: host=062a:0000
vga: none
vmgenid: eab28f6a-5812-43b5-b088-f44f9d6e2462

Обратил внимание вот на какой момент: если виртуалке выделить 1 Гб оперативки, то на экран монитора при запуске виртуалки ничего не выводится. Если выделить 2 Гб, то изображение есть, но при установке Windows 10 изображение портится на 1% стадии «Подготовка файлов для установки». При выделении 4 Гб - изображение портится на 14% процесса, при 5 Гб - на 23%, при 10 Гб - на 60% и т.д. В общем, чем больше оперативки выделяется виртуалке, тем позже испортится изображение и прервётся установка.

Подскажите, пожалуйста, в чём может быть причина и существует ли действенный способ лечения?

gpu, guest, passthrough, proxmox, windows

Sferg
(21.01.20 14:53:38 MSK)

7 комментариев

Почему при подключении через VPN, в сетевом окружении Windows 10 не отображается Samba-шара?

Здравствуйте, господа. По просьбе приятеля, на его Raspberry Pi (у нас разные провайдеры и сети) я настроил VPN-сервер. Там же мною ранее уже была настроена Samba.

Со своего домашнего ПК с Windows 10 (192.168.0.165) я подключаюсь через VPN приятеля (при подключении получаю локальный IP: 10.8.0.6), но у меня в сетевом окружении почему-то не появляется его шара (raspberrypi). Если в адресной строке ввести \\192.168.1.42, то я успешно попадаю в шару, но по hostname она не появляется.

В сетевом окружении также есть шара, находящаяся в моей подсети - с ней проблем никаких нет: она отображается и на неё можно заходить по локальному IP. А вот с отображением шары приятеля из другой подсети через VPN - непонятки.

Подскажите, пожалуйста, каким образом заставить отображаться шару с Raspberry Pi приятеля у себя в сетевом окружении?

network, samba, vpn, windows

Sferg
(04.01.20 00:18:13 MSK)

4 комментария

Каким образом пробросить видеокарту внутрь виртуалки Proxmox?

Здравствуйте, господа. Имеется материнка ASRock J5005-ITX, где установлен Proxmox 6 поверх Debian 10. Осваимваю виртуализацию и пытаюсь пробросить интегрированную карточку Intel UHD Graphics 605 внутрь гостевой ОС Windows 10.

Вывод lspci -nn | grep «VGA»:

00:02.0 VGA compatible controller [0300]: Intel Corporation UHD Graphics 605 [8086:3184] (rev 03)

В /etc/default/grub прописал:

GRUB_CMDLINE_LINUX_DEFAULT="quiet i915.enable_gvt=1 kvm.ignore_msrs=1 intel_iommu=on i915.enable_guc=0 video=efifb:off,vesafb=off vfio-pci.ids=8086:3184"

В /etc/modules прописал:

vfio-pci
vfio
vfio_iommu_type1
vfio_virqfd
kvmgt
mdev
vfio_mdev

В /etc/modprobe.d/pve-blacklist.conf добавил:

blacklist snd_hda_intel
blacklist snd_hda_codec_hdmi
blacklist i915

В /etc/modprobe.d/vfio.conf добавил:

options vfio-pci ids=8086:3184 disable_vga=1

И, наконец, выполнил:

update-grub
update-initramfs -u -k all

и перезагрузился. После перезагрузки вывод lsmod | egrep «kvm|vfio»:

kvm_intel             245760  0
kvmgt                  28672  0
vfio_mdev              16384  0
mdev                   24576  2 kvmgt,vfio_mdev
kvm                   651264  2 kvmgt,kvm_intel
vfio_pci               49152  0
vfio_virqfd            16384  1 vfio_pci
vfio_iommu_type1       28672  0
vfio                   32768  4 kvmgt,vfio_mdev,vfio_iommu_type1,vfio_pci
irqbypass              16384  2 vfio_pci,kvm

Подскажите, пожалуйста, почему не создаётся директория mdev_supported_types по пути /sys/bus/pci/devices/0000:00:02.0/?

passthrough, proxmox, system, video, железо

Sferg
(17.11.19 21:48:00 MSK)

10 комментариев

Intel Pentium J5005: каким образом включить Turbo Boost?

Здравствуйте, господа. Имеется платка ASRock J5005-ITX с процессором Intel Pentium J5005 на борту. Установлен Debian 10 («Stretch»).

Вывод uname -a:

Linux j5005-itx 5.0.21-4-pve #1 SMP PVE 5.0.21-8 (Wed, 23 Oct 2019 17:49:13 +0200) x86_64 GNU/Linux

Вывод lscpu | grep 'MHz':

CPU MHz: 1497.600
CPU max MHz: 1500,0000
CPU min MHz: 800,0000

Но максимальная частота должна быть 2800 MHz, а не 1500 MHz. Аж 1300 MHz неизвестно куда деваются. Безобразие!

Установил пакет intel-microcode, но значение максимальной частоты не изменилось.

Вывод dmesg | grep 'microcode':

[ 0.000000] microcode: microcode updated early to revision 0x2e, date = 2019-01-02
[ 1.217830] microcode: sig=0x706a1, pf=0x1, revision=0x2e
[ 1.217992] microcode: Microcode Update Driver: v2.2.

Подаю команду:

echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo

в ответ получаю ошибку:

bash: echo: ошибка записи: Операция не позволена

Подскажите, пожалуйста, каким образом включить Turbo Boost?

boost, cpu, debian, linux, system

Sferg
(10.11.19 15:07:53 MSK)

32 комментария

После перезагрузки не всегда удаётся подключиться к локалке. В чём может быть дело?

Здравствуйте, господа. Имеется ПК, работающий в качестве роутера с точкой доступа Wi-Fi. На нём установлен Debian 9 («Stretch») + isc-dhcp-server + hostapd.

Проблема вот в чём: иногда, после N-ой перезагрузки системы, ВСЕ устройства не могут подключиться к локалке. К примеру, пытаюсь я подключиться с телефона к точке доступа Wi-Fi. Соединение тут же рвётся и начинает устанавливаться заново. Снова рвётся и снова пытается установиться... И т.д. и т.п. Перезагружу систему несколько раз - устройства подключаются успешно. Снова перезагружу систему - устройства опять подключиться не могут.

Вывод cat /var/log/dhcpd.log:

Jun 23 11:23:12 J5005-ITX dhcpd[1381]: Internet Systems Consortium DHCP Server 4.3.5
Jun 23 11:23:12 J5005-ITX dhcpd[1381]: Copyright 2004-2016 Internet Systems Consortium.
Jun 23 11:23:12 J5005-ITX dhcpd[1381]: All rights reserved.
Jun 23 11:23:12 J5005-ITX dhcpd[1381]: For info, please visit https://www.isc.org/software/dhcp/
Jun 23 11:23:12 J5005-ITX dhcpd[1383]: Internet Systems Consortium DHCP Server 4.3.5
Jun 23 11:23:12 J5005-ITX dhcpd[1383]: Copyright 2004-2016 Internet Systems Consortium.
Jun 23 11:23:12 J5005-ITX dhcpd[1383]: All rights reserved.
Jun 23 11:23:12 J5005-ITX dhcpd[1383]: For info, please visit https://www.isc.org/software/dhcp/
Jun 23 11:23:12 J5005-ITX dhcpd[1383]: Wrote 4 leases to leases file.
Jun 23 11:23:12 J5005-ITX dhcpd[1383]: Multiple interfaces match the same subnet: eth1 br0
Jun 23 11:23:12 J5005-ITX dhcpd[1383]: Multiple interfaces match the same shared network: eth1 br0
Jun 23 11:23:12 J5005-ITX dhcpd[1384]: Server starting service.
Jun 23 11:23:20 J5005-ITX dhcpd[1384]: reuse_lease: lease age 57 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.116
Jun 23 11:23:20 J5005-ITX dhcpd[1384]: DHCPREQUEST for 192.168.0.116 from **:**:**:**:**:** (android-521fcb5b8ea3efe9) via br0
Jun 23 11:23:20 J5005-ITX dhcpd[1384]: DHCPACK on 192.168.0.116 to **:**:**:**:**:** (android-521fcb5b8ea3efe9) via br0
Jun 23 11:24:01 J5005-ITX dhcpd[1384]: DHCPREQUEST for 192.168.0.117 from **:**:**:**:**:** (ASUS-i7) via br0
Jun 23 11:24:01 J5005-ITX dhcpd[1384]: DHCPACK on 192.168.0.117 to **:**:**:**:**:** (ASUS-i7) via br0
Jun 23 11:24:04 J5005-ITX dhcpd[1384]: DHCPINFORM from 192.168.0.117 via br0
Jun 23 11:24:04 J5005-ITX dhcpd[1384]: DHCPACK to 192.168.0.117 (**:**:**:**:**:**) via br0
Jun 23 11:24:07 J5005-ITX dhcpd[1384]: DHCPINFORM from 192.168.0.117 via br0
Jun 23 11:24:07 J5005-ITX dhcpd[1384]: DHCPACK to 192.168.0.117 (**:**:**:**:**:**) via br0
Jun 23 11:24:10 J5005-ITX dhcpd[1384]: DHCPDISCOVER from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:11 J5005-ITX dhcpd[1384]: DHCPOFFER on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:12 J5005-ITX dhcpd[1384]: DHCPREQUEST for 192.168.0.2 (192.168.0.1) from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:12 J5005-ITX dhcpd[1384]: DHCPACK on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:15 J5005-ITX dhcpd[1384]: reuse_lease: lease age 4 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:15 J5005-ITX dhcpd[1384]: DHCPDISCOVER from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:15 J5005-ITX dhcpd[1384]: DHCPOFFER on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:15 J5005-ITX dhcpd[1384]: reuse_lease: lease age 4 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:15 J5005-ITX dhcpd[1384]: DHCPREQUEST for 192.168.0.2 (192.168.0.1) from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:15 J5005-ITX dhcpd[1384]: DHCPACK on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:19 J5005-ITX dhcpd[1384]: reuse_lease: lease age 8 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:19 J5005-ITX dhcpd[1384]: DHCPDISCOVER from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:19 J5005-ITX dhcpd[1384]: DHCPOFFER on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:19 J5005-ITX dhcpd[1384]: reuse_lease: lease age 8 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:19 J5005-ITX dhcpd[1384]: DHCPREQUEST for 192.168.0.2 (192.168.0.1) from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:19 J5005-ITX dhcpd[1384]: DHCPACK on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:23 J5005-ITX dhcpd[1384]: reuse_lease: lease age 12 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:23 J5005-ITX dhcpd[1384]: DHCPDISCOVER from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:23 J5005-ITX dhcpd[1384]: DHCPOFFER on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:23 J5005-ITX dhcpd[1384]: reuse_lease: lease age 12 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:23 J5005-ITX dhcpd[1384]: DHCPREQUEST for 192.168.0.2 (192.168.0.1) from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:23 J5005-ITX dhcpd[1384]: DHCPACK on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:27 J5005-ITX dhcpd[1384]: reuse_lease: lease age 16 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:27 J5005-ITX dhcpd[1384]: DHCPDISCOVER from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:27 J5005-ITX dhcpd[1384]: DHCPOFFER on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:27 J5005-ITX dhcpd[1384]: reuse_lease: lease age 16 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:27 J5005-ITX dhcpd[1384]: DHCPREQUEST for 192.168.0.2 (192.168.0.1) from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:27 J5005-ITX dhcpd[1384]: DHCPACK on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:31 J5005-ITX dhcpd[1384]: reuse_lease: lease age 20 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:31 J5005-ITX dhcpd[1384]: DHCPDISCOVER from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:31 J5005-ITX dhcpd[1384]: DHCPOFFER on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:31 J5005-ITX dhcpd[1384]: reuse_lease: lease age 20 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:31 J5005-ITX dhcpd[1384]: DHCPREQUEST for 192.168.0.2 (192.168.0.1) from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:31 J5005-ITX dhcpd[1384]: DHCPACK on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:35 J5005-ITX dhcpd[1384]: reuse_lease: lease age 24 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:35 J5005-ITX dhcpd[1384]: DHCPDISCOVER from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:35 J5005-ITX dhcpd[1384]: DHCPOFFER on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:35 J5005-ITX dhcpd[1384]: reuse_lease: lease age 24 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:35 J5005-ITX dhcpd[1384]: DHCPREQUEST for 192.168.0.2 (192.168.0.1) from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:35 J5005-ITX dhcpd[1384]: DHCPACK on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:39 J5005-ITX dhcpd[1384]: reuse_lease: lease age 28 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:39 J5005-ITX dhcpd[1384]: DHCPDISCOVER from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:39 J5005-ITX dhcpd[1384]: DHCPOFFER on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:39 J5005-ITX dhcpd[1384]: reuse_lease: lease age 28 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:39 J5005-ITX dhcpd[1384]: DHCPREQUEST for 192.168.0.2 (192.168.0.1) from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:39 J5005-ITX dhcpd[1384]: DHCPACK on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:43 J5005-ITX dhcpd[1384]: reuse_lease: lease age 32 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:43 J5005-ITX dhcpd[1384]: DHCPDISCOVER from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:43 J5005-ITX dhcpd[1384]: DHCPOFFER on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:43 J5005-ITX dhcpd[1384]: reuse_lease: lease age 32 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:43 J5005-ITX dhcpd[1384]: DHCPREQUEST for 192.168.0.2 (192.168.0.1) from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:43 J5005-ITX dhcpd[1384]: DHCPACK on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:46 J5005-ITX dhcpd[1384]: reuse_lease: lease age 35 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:46 J5005-ITX dhcpd[1384]: DHCPDISCOVER from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:46 J5005-ITX dhcpd[1384]: DHCPOFFER on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:46 J5005-ITX dhcpd[1384]: reuse_lease: lease age 35 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:46 J5005-ITX dhcpd[1384]: DHCPREQUEST for 192.168.0.2 (192.168.0.1) from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:46 J5005-ITX dhcpd[1384]: DHCPACK on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:50 J5005-ITX dhcpd[1384]: reuse_lease: lease age 39 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:50 J5005-ITX dhcpd[1384]: DHCPDISCOVER from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:50 J5005-ITX dhcpd[1384]: DHCPOFFER on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:50 J5005-ITX dhcpd[1384]: reuse_lease: lease age 39 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:50 J5005-ITX dhcpd[1384]: DHCPREQUEST for 192.168.0.2 (192.168.0.1) from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:50 J5005-ITX dhcpd[1384]: DHCPACK on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:54 J5005-ITX dhcpd[1384]: reuse_lease: lease age 43 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:54 J5005-ITX dhcpd[1384]: DHCPDISCOVER from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:54 J5005-ITX dhcpd[1384]: DHCPOFFER on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:54 J5005-ITX dhcpd[1384]: reuse_lease: lease age 43 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:54 J5005-ITX dhcpd[1384]: DHCPREQUEST for 192.168.0.2 (192.168.0.1) from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:54 J5005-ITX dhcpd[1384]: DHCPACK on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:58 J5005-ITX dhcpd[1384]: reuse_lease: lease age 47 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:58 J5005-ITX dhcpd[1384]: DHCPDISCOVER from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:58 J5005-ITX dhcpd[1384]: DHCPOFFER on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:58 J5005-ITX dhcpd[1384]: reuse_lease: lease age 47 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:24:58 J5005-ITX dhcpd[1384]: DHCPREQUEST for 192.168.0.2 (192.168.0.1) from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:24:58 J5005-ITX dhcpd[1384]: DHCPACK on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:25:02 J5005-ITX dhcpd[1384]: reuse_lease: lease age 51 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:25:02 J5005-ITX dhcpd[1384]: DHCPDISCOVER from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:25:02 J5005-ITX dhcpd[1384]: DHCPOFFER on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:25:02 J5005-ITX dhcpd[1384]: reuse_lease: lease age 51 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:25:02 J5005-ITX dhcpd[1384]: DHCPREQUEST for 192.168.0.2 (192.168.0.1) from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:25:02 J5005-ITX dhcpd[1384]: DHCPACK on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:25:06 J5005-ITX dhcpd[1384]: reuse_lease: lease age 55 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:25:06 J5005-ITX dhcpd[1384]: DHCPDISCOVER from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:25:06 J5005-ITX dhcpd[1384]: DHCPOFFER on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:25:06 J5005-ITX dhcpd[1384]: reuse_lease: lease age 55 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2
Jun 23 11:25:06 J5005-ITX dhcpd[1384]: DHCPREQUEST for 192.168.0.2 (192.168.0.1) from **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:25:06 J5005-ITX dhcpd[1384]: DHCPACK on 192.168.0.2 to **:**:**:**:**:** (android-4bbe66904fb5f42b) via br0
Jun 23 11:26:35 J5005-ITX dhcpd[1384]: DHCPREQUEST for 192.168.0.3 from **:**:**:**:**:** (Galaxy-A8-2018) via br0
Jun 23 11:26:35 J5005-ITX dhcpd[1384]: DHCPACK on 192.168.0.3 to **:**:**:**:**:** (Galaxy-A8-2018) via br0
Jun 23 11:28:16 J5005-ITX dhcpd[1384]: DHCPREQUEST for 192.168.0.116 from **:**:**:**:**:** (android-521fcb5b8ea3efe9) via br0
Jun 23 11:28:16 J5005-ITX dhcpd[1384]: DHCPACK on 192.168.0.116 to **:**:**:**:**:** (android-521fcb5b8ea3efe9) via br0

В тех случаях, когда после перезагрузки устройствам не удаётся подключиться к сети, в логах фигурируют подозрительные строчки:

reuse_lease: lease age 4 (secs) under 25% threshold, reply with unaltered, existing lease for 192.168.0.2

В случаях, когда устройства благополучно могут подключаться - этих строчек в логах нет.

На всякий случай привожу содержимое своих конфигов.

/etc/default/isc-dhcp-server:

INTERFACESv4="eth1 br0"
INTERFACESv6=""

/etc/dhcp/dhcpd.conf

default-lease-time 600;
max-lease-time 7200;
ddns-update-style none;
authoritative;
log-facility local7;

subnet 192.168.0.0 netmask 255.255.255.0 {
	range 192.168.0.2 192.168.0.254;
	option domain-name-servers 8.8.8.8, 8.8.4.4;
	option domain-name "local";
	option routers 192.168.0.1;
	option broadcast-address 192.168.0.255;
	default-lease-time 600;
	max-lease-time 7200;
}

/etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
allow-hotplug eth0
iface eth0 inet dhcp

allow-hotplug eth1
iface eth1 inet static
address 192.168.0.1
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255

auto br0
iface br0 inet static
bridge_ports eth1 wlan0
bridge_stp off
bridge_fd 0
bridge_maxwait 0
bridge_waitport 0
address 192.168.0.1
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255

Вывод iptables -L:

Chain INPUT (policy DROP) destination anywhere             icmp echo-request limit: avg 1/sec burst 5 anywhere             icmp echo-request anywhere anywhere anywhere             ctstate INVALID anywhere             ctstate NEW tcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,SYN,RST,PSH,ACK,URG anywhere             ctstate NEW tcp flags:FIN,SYN,RST,PSH,ACK,URG/NONE anywhere             ctstate NEW tcp flags:!FIN,SYN,RST,ACK/SYN anywhere             ctstate INVALID,NEW tcp flags:SYN,ACK/SYN,ACK reject-with tcp-reset anywhere             tcp flags:FIN,SYN,RST,PSH,ACK,URG/FIN,PSH,URG anywhere             tcp flags:SYN,RST/SYN,RST anywhere             tcp flags:FIN,SYN/FIN,SYN anywhere             tcp multiport dports ftp-data,ftp,smtp,http,netbios-ssn,https,microsoft-ds,openvpn,****,**** ctstate NEW recent: SET name: ddos_block_conn_tcp side: source mask: 255.255.255.255 anywhere             tcp multiport dports ftp-data,ftp,smtp,http,netbios-ssn,https,microsoft-ds,openvpn,****,**** ctstate NEW recent: UPDATE seconds: 60 hit_count: 180 name: ddos_block_conn_tcp side: source mask: 255.255.255.255 anywhere             udp multiport dports ntp,netbios-ns,netbios-dgm,openvpn ctstate NEW recent: SET name: ddos_block_conn_udp side: source mask: 255.255.255.255 anywhere             udp multiport dports ntp,netbios-ns,netbios-dgm,openvpn ctstate NEW recent: UPDATE seconds: 60 hit_count: 180 name: ddos_block_conn_udp side: source mask: 255.255.255.255 anywhere             multiport dports ftp-data,ftp,smtp,http,netbios-ssn,https,microsoft-ds,openvpn,****,**** #conn src/32 > 16 anywhere             multiport dports ftp-data,ftp,smtp,http,netbios-ssn,https,microsoft-ds,openvpn,****,**** ctstate NEW limit: up to 36/min burst 24 mode srcip anywhere             multiport dports ntp,netbios-ns,netbios-dgm,openvpn #conn src/32 > 16 anywhere             multiport dports ntp,netbios-ns,netbios-dgm,openvpn ctstate NEW limit: up to 36/min burst 24 mode srcip anywhere             multiport dports ftp-data,ftp,smtp,http,netbios-ssn,https,microsoft-ds,openvpn,****,**** #conn src/32 > 16 anywhere             multiport dports ftp-data,ftp,smtp,http,netbios-ssn,https,microsoft-ds,openvpn,****,**** ctstate NEW limit: up to 36/min burst 24 mode srcip anywhere             multiport dports ntp,netbios-ns,netbios-dgm,openvpn #conn src/32 > 16 anywhere             multiport dports ntp,netbios-ns,netbios-dgm,openvpn ctstate NEW limit: up to 36/min burst 24 mode srcip anywhere             multiport dports ftp-data,ftp,smtp,http,netbios-ssn,https,microsoft-ds,openvpn,****,**** #conn src/32 > 16 anywhere             multiport dports ftp-data,ftp,smtp,http,netbios-ssn,https,microsoft-ds,openvpn,****,**** ctstate NEW limit: up to 36/min burst 24 mode srcip anywhere             multiport dports ntp,netbios-ns,netbios-dgm,openvpn #conn src/32 > 16 anywhere             multiport dports ntp,netbios-ns,netbios-dgm,openvpn ctstate NEW limit: up to 36/min burst 24 mode srcip anywhere             PKTTYPE = broadcast anywhere             ctstate RELATED,ESTABLISHED anywhere             ctstate NEW anywhere anywhere             ctstate RELATED,ESTABLISHED anywhere             ctstate NEW anywhere anywhere             ctstate RELATED,ESTABLISHED anywhere             ctstate NEW anywhere destination anywhere             ctstate INVALID anywhere             ctstate RELATED,ESTABLISHED anywhere             multiport dports ftp,ssh,domain,http,81,netbios-ssn,https,microsoft-ds,1024:65535 ctstate NEW anywhere             ctstate RELATED,ESTABLISHED anywhere             multiport dports domain,ntp,netbios-ns,netbios-dgm,1024:65535 ctstate NEW anywhere             ctstate RELATED,ESTABLISHED anywhere             ctstate NEW anywhere             ctstate RELATED,ESTABLISHED anywhere             multiport dports ftp,ssh,domain,http,81,netbios-ssn,https,microsoft-ds,1024:65535 ctstate NEW anywhere             ctstate RELATED,ESTABLISHED anywhere             multiport dports domain,ntp,netbios-ns,netbios-dgm,1024:65535 ctstate NEW anywhere             ctstate RELATED,ESTABLISHED anywhere             ctstate NEW anywhere             ctstate RELATED,ESTABLISHED anywhere             multiport dports ftp,ssh,domain,http,81,netbios-ssn,https,microsoft-ds,1024:65535 ctstate NEW anywhere             ctstate RELATED,ESTABLISHED anywhere             multiport dports domain,ntp,netbios-ns,netbios-dgm,1024:65535 ctstate NEW anywhere             ctstate RELATED,ESTABLISHED anywhere             ctstate NEW destination anywhere anywhere anywhere             ctstate INVALID anywhere             ctstate NEW,RELATED,ESTABLISHED anywhere anywhere             ctstate NEW,RELATED,ESTABLISHED anywhere anywhere             ctstate NEW,RELATED,ESTABLISHED anywhere

пожалуйста, в чём может быть дело? Как-то непонятно: то работает, то, после перезагрузки, уже не работает.

debian, dhcpd, network, system, wi-fi

Sferg
(23.06.19 12:35:35 MSK)

5 комментариев

Как подружить WiFi-адаптер TP-Link Archer T3U и Android 4.4.2?

Здравствуйте, господа. Имеется медиа-приставка DNS T-008 на чипе Rockchip RK3066 с Android 4.4.2 и ядром 3.0.36+. Недавно приобрёл WiFi-адаптер TP-Link Archer T3U на чипе RTL8812BU. Подскажите, пожалуйста, как подружить эти два девайса? Цель: заменить встроенный (на чипе RTL8189ES) в медиа-приставку WiFi-адаптер на более современный внешний, умеющий 802.11ac на 5 GHz.

- Android 4.4.2 SDK утянул отсюда.
- Исходники ядра 3.0.36 взял здесь.
- Исходники драйвера для чипсета RTL8812BU взял тут.

1. Ядро собралось успешно (перед сборкой добавил суффикс «+» в конец версии ядра).
2. Модуль wlan.ko собрался успешно (скопировал его с заменой в /system/lib/modules/, предварительно сделав бэкап)
3. При выполнении на медиаплеере:

rmmod wlan
insmod /system/lib/modules/wlan.ko

сообщения о каких-либо ошибках отсутствуют, однако и внешний WiFi-адаптер не работает: интерфейс wlan0 не создаётся, а dmesg выводит следующее:

[  495.750425] RTW: module init start
[  495.750455] RTW: rtl88x2bu v5.3.1_27678.20180430_COEX20180427-5959
[  495.750498] RTW: build time: Jun  6 2019 22:37:40
[  495.750523] RTW: rtl88x2bu BT-Coex version = COEX20180427-5959
[  495.750605] RTW: rtw_inetaddr_notifier_register
[  495.750998] usbcore: registered new interface driver rtl88x2bu
[  495.751033] RTW: module init ret=0
[  571.454584] RTW: module exit start
[  571.458082] usbcore: deregistering interface driver rtl88x2bu
[  571.464174] RTW: rtw_inetaddr_notifier_unregister
[  571.512956] RTW: module exit success

Подскажите, пожалуйста, в чём я неправ?

P.S. Если вернуть оригинальный wlan.ko, то после перезагрузки встроенный WiFi-адаптер работает как положено. Но хотелось бы завести и внешний адаптер.

android, firmware, rockchip, wi-fi, wireless

Sferg
(08.06.19 16:47:04 MSK)

46 комментариев

Wi-Fi: теряются пакеты при пинге. В чём может быть дело?

Здравствуйте, господа. Имеется самосборный WiFi-роутер (192.168.0.1) на основе ПК c Debian 8 («Jessie») на борту. В качестве точки доступа на роутере используется адаптер TP-Link TL-WN881ND первой ревизии с чипом Qualcomm.

Недавно приобрёл WiFi-адаптер ASUS PCE-AC88 для домашнего ПК (192.168.0.52), на котором установлен Debian 9 («Stretch»). Все беспроводные сетевые устройства без проблем подключаются к роутеру, однако адаптер ASUS PCE-AC88 теряет пакеты при пинге:

# ping ya.ru -c20
PING ya.ru (87.250.250.242) 56(84) bytes of data.
64 bytes from ya.ru (87.250.250.242): icmp_seq=1 ttl=56 time=17.1 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=2 ttl=56 time=17.1 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=3 ttl=56 time=17.2 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=4 ttl=56 time=17.1 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=5 ttl=56 time=28.7 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=6 ttl=56 time=20.0 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=7 ttl=56 time=17.2 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=8 ttl=56 time=17.7 ms

--- ya.ru ping statistics ---
20 packets transmitted, 8 received, 60% packet loss, time 19261ms
rtt min/avg/max/mdev = 17.133/19.062/28.735/3.772 ms

Однако, если пинговать сам WiFi-роутер, то потерь пакетов нет:

# ping 192.168.0.1 -c20
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=0.066 ms
64 bytes from 192.168.0.1: icmp_seq=2 ttl=64 time=0.040 ms
64 bytes from 192.168.0.1: icmp_seq=3 ttl=64 time=0.038 ms
64 bytes from 192.168.0.1: icmp_seq=4 ttl=64 time=0.024 ms
64 bytes from 192.168.0.1: icmp_seq=5 ttl=64 time=0.026 ms
64 bytes from 192.168.0.1: icmp_seq=6 ttl=64 time=0.024 ms
64 bytes from 192.168.0.1: icmp_seq=7 ttl=64 time=0.027 ms
64 bytes from 192.168.0.1: icmp_seq=8 ttl=64 time=0.023 ms
64 bytes from 192.168.0.1: icmp_seq=9 ttl=64 time=0.026 ms
64 bytes from 192.168.0.1: icmp_seq=10 ttl=64 time=0.024 ms
64 bytes from 192.168.0.1: icmp_seq=11 ttl=64 time=0.025 ms
64 bytes from 192.168.0.1: icmp_seq=12 ttl=64 time=0.025 ms
64 bytes from 192.168.0.1: icmp_seq=13 ttl=64 time=0.023 ms
64 bytes from 192.168.0.1: icmp_seq=14 ttl=64 time=0.024 ms
64 bytes from 192.168.0.1: icmp_seq=15 ttl=64 time=0.027 ms
64 bytes from 192.168.0.1: icmp_seq=16 ttl=64 time=0.024 ms
64 bytes from 192.168.0.1: icmp_seq=17 ttl=64 time=0.024 ms
64 bytes from 192.168.0.1: icmp_seq=18 ttl=64 time=0.023 ms
64 bytes from 192.168.0.1: icmp_seq=19 ttl=64 time=0.024 ms
64 bytes from 192.168.0.1: icmp_seq=20 ttl=64 time=0.027 ms

--- 192.168.0.1 ping statistics ---
20 packets transmitted, 20 received, 0% packet loss, time 19402ms
rtt min/avg/max/mdev = 0.023/0.028/0.066/0.010 ms

При пинге чего-либо снаружи - есть потери пакетов, а если пинговать внутри локалки, то потерь нет. Подскажите, пожалуйста, в чём может быть дело? Другие беспроводные устройства, которые подключаются к роутеру, пингуют что-либо без потерь пакетов.

debian, network, system, wi-fi, wireless

Sferg
(06.05.19 22:21:56 MSK)

4 комментария

Высокий пинг у TP-Link TL-WN881ND в Debian. В чём может быть дело?

Здравствуйте, господа. Приобрёл WiFi-адаптер TP-Link TL-WN881ND (2-й ревизии) для работы в режиме точки доступа (hostapd) на ОС Debian 9 («Stretch»). 2-я ревизия отличается от первой тем, что 2-я основана на чипе Realtek RTL8192EE, тогда как 1-я основана на чипе Qualcomm Atheros AR9287.

Вывод lspci:

...
01:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8192EE PCIe Wireless Network Adapter
...

Вывод lsmod | grep rtl8192ee:

...
rtl8192ee             114688  0
btcoexist             172032  1 rtl8192ee
rtl_pci                36864  1 rtl8192ee
rtlwifi               102400  3 rtl_pci,btcoexist,rtl8192ee
mac80211              856064  3 rtl_pci,rtlwifi,rtl8192ee
...

Дело, собственно, вот в чём: у 2-й ревизии адаптера наблюдается высокий и неравномерный пинг (минимум 25 ms, максимум 126 ms):

PING ya.ru (87.250.250.242) 56(84) bytes of data.
64 bytes from ya.ru (87.250.250.242): icmp_seq=1 ttl=58 time=101 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=2 ttl=58 time=125 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=3 ttl=58 time=45.8 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=4 ttl=58 time=68.2 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=5 ttl=58 time=91.1 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=6 ttl=58 time=114 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=7 ttl=58 time=34.7 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=8 ttl=58 time=57.1 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=9 ttl=58 time=80.1 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=10 ttl=58 time=103 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=11 ttl=58 time=126 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=12 ttl=58 time=46.8 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=13 ttl=58 time=69.2 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=14 ttl=58 time=92.2 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=15 ttl=58 time=115 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=16 ttl=58 time=35.8 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=17 ttl=58 time=58.1 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=18 ttl=58 time=81.1 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=19 ttl=58 time=104 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=20 ttl=58 time=92.2 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=21 ttl=58 time=47.6 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=22 ttl=58 time=70.1 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=23 ttl=58 time=93.2 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=24 ttl=58 time=57.8 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=25 ttl=58 time=36.0 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=26 ttl=58 time=59.1 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=27 ttl=58 time=80.0 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=28 ttl=58 time=85.4 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=29 ttl=58 time=25.4 ms
64 bytes from ya.ru (87.250.250.242): icmp_seq=30 ttl=58 time=48.0 ms

--- ya.ru ping statistics ---
30 packets transmitted, 30 received, 0% packet loss, time 29041ms
rtt min/avg/max/mdev = 25.487/74.892/126.296/28.050 ms

И это всё только в обычном режиме работы. В режиме точки доступа пинг, бывает, достигает и 5 (!) секунд.

У адаптера 1-й ревизии на чипе AR9287 с этим проблем не возникает ни в обычном режиме, ни в режиме точки доступа.

Теперь вопрос: возможно ли как-нибудь улучшить работу адаптера 2-й ревизии?

debian, realtek, system, wireless, железо

Sferg
(29.09.18 14:32:21 MSK)

20 комментариев

Проброс портов наружу для VMWare. Как реализовать?

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

В общем, имеется следующее:
1. PC-роутер (192.168.0.1) с внешним белым IP (12.34.56.78, который привязывается к доменному имени с помощью freedns.afraid.org);
2. ПК с ОС Windows 7 (192.168.0.103);
3. Виртуальная машина VMWare Workstation с установленным на ней Debian (192.168.0.32), которая запущена на ПК с ОС Windows 7 (192.168.0.103).

На PC-роутере имеются следующие сетевые интерфейсы:
1. eth0 - смотрит в Интернет;
2. eth1 - смотрит в локальную сеть;
3. wlan0 - беспроводная точка доступа с доступом к локальной сети и к Интернет при помощи сетевого моста;
4. br0 - сетевой мост, для обеспечения доступа к Интернет из локальной сети.

Подскажите, пожалуйста, какие правила нужно прописать с помощью iptables на PC-роутере, чтобы был доступ снаружи к виртуальной машине, которая запущена на ПК?

P.S. На PC-роутере для INPUT и FORWARD по умолчанию установлена политика DROP. PC-роутер, ПК и виртуальная машина по локальным адресам между собой исправно пингуются.

admin, debian, network, port forwarding, vmware workstation

Sferg
(22.07.18 14:10:22 MSK)

54 комментария (стр. 2)

Гостевая виртуальная машина с Debian не получает IP-адрес по DHCP. В чём может быть загвоздка?

Здравствуйте, господа. На ПК с Windows 7 установлена VMWare Workstation 14.1.2. Создана виртуалка и установлен на неё Debian 8 («Jessie»). Хост с виндой подключается к Интернет по Wi-Fi. Для виртуалки выбран тип подключения к сети - VMnet0 (мост), где указан используемый Wi-Fi-адаптер.

Скриншот 1
Скриншот 2
Скриншот 3

Как заставить гостевой Debian подключаться к сети по DHCP в режиме моста? Самое интересное, что если выбрать тип подключения VMnet1 (Только для узла) или VMnet8 (NAT), то система благополучно подключается к сети.

debian, network, vmware workstation, windows

Sferg
(11.07.18 15:27:21 MSK)

30 комментариев

Апгрейд железа домашнего сервачка. Стоит ли овчинка выделки?

Здравствуйте, господа. Имеется домашний сервачок. Основное железо на данный момент:
- Корпус Foxconn RS-338 (Mini-ITX);
- Материнка Intel DN2800MT со встроенным процессором Intel Atom N2800;
- 1-й модуль памяти DDR3 SO-DIMM, 4 Gb, PC-1066;
- 2-й модуль памяти DDR3 SO-DIMM, 2 Gb, PC-1066.
- Wi-Fi-адаптер TP-Link TL-WN881ND;
- USB-сетевушка D-Link DUB-E100C1;
- Жёсткие диски.

Сервачок последние 6 лет крутится на Debian и исполняет следующие задачи:
- Интернет-шлюз;
- Точка доступа Wi-Fi (hostapd);
- Доступ к сетевым дискам (samba);
- Файлопомойка (proftpd);
- Торрентокачалка (transmission-daemon);
- Веб-сервер (nginx, php7-fpm, mariadb, etc).

Назрел вопрос обновления железа. Присмотрелся к следующему:
- Материнская плата ASRock J5005-ITX со встроенным процессором Intel Pentium J5005;
- 1-й модуль памяти DDR4 SO-DIMM, 8 Gb, PC-2400;
- 2-й модуль памяти DDR4 SO-DIMM, 8 Gb, PC-2400.

Цель: при минимальном потреблении (<= 10 W), по возможности, максимальная производительность.

Собственно, вопрос: повлечёт ли замена железа к заметному росту производительности при тех же
задачах (в частности интересует веб-сервер) по сравнению с нынешним железом?

upgrade, железо, сервер

Sferg
(07.07.18 16:13:35 MSK)

43 комментария

Непонятная задержка при загрузке Debian 9. Каким образом можно устранить?

Здравствуйте, господа. При загрузке системы наблюдается непонятная задержка в 22 секунды:

Вчерашняя выдержка из вывода journalctl --system:

мар 19 21:44:49 acer-i7 sh[440]: wlp3s0b1=wlp3s0b1
мар 19 21:44:51 acer-i7 kernel: Console: switching to colour frame buffer device 200x56
мар 19 21:44:51 acer-i7 kernel: radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
мар 19 21:44:51 acer-i7 kernel: [drm] Initialized radeon 2.49.0 20080528 for 0000:01:00.0 on minor 0
мар 19 21:45:13 acer-i7 systemd-timesyncd[474]: Synchronized to time server 93.180.6.3:123 (2.debian.pool.ntp.org).
мар 19 21:45:14 acer-i7 sddm[555]: Running display setup script «/usr/share/sddm/scripts/Xsetup»

Сначала подумалось, что это пошаливает служба systemd-timesyncd и я отключил её. Сегодняшние логи показывают, что задержка в 22 секунды сохранилась несмотря на отключенную службу systemd-timesyncd:

мар 20 20:45:50 acer-i7 sh[428]: wlp3s0b1=wlp3s0b1
мар 20 20:45:52 acer-i7 kernel: Console: switching to colour frame buffer device 200x56
мар 20 20:45:52 acer-i7 kernel: radeon 0000:01:00.0: fb0: radeondrmfb frame buffer device
мар 20 20:45:53 acer-i7 kernel: [drm] Initialized radeon 2.49.0 20080528 for 0000:01:00.0 on minor 0
мар 20 20:46:15 acer-i7 sddm[555]: Running display setup script «/usr/share/sddm/scripts/Xsetup»
мар 20 20:46:15 acer-i7 sddm[555]: Display server started.

Даже если поотключать все службы, следующие за строчкой:

kernel: [drm] Initialized radeon 2.49.0 20080528 for 0000:01:00.0 on minor 0

, то всё равно 22 секунды тратятся на что-то «левое» - что первым попадётся под руку: не systemd-timesyncd, так чему-нибудь другому.

Как выловить этого затаившегося гада?

debian, radeon, system, video, железо

Sferg
(20.03.18 21:28:15 MSK)

5 комментариев

Шумит кулер процессора в ноутбуке при незначительных нагрузках. Как вылечить?

Здравствуйте, господа. Имеется старенький ноутбук Acer Aspire 7750G с процессором Intel Core i7-2670QM на борту. На него, рядом с Windows 7, установил Debian 9 («Stretch») с KDE 5.

Проблема заключается в следующем: спустя примерно 15-20 минут с момента включения ноутбука, от незначительных нагрузок вроде запуска браузера Opera 51, кратковременно повышается температура процессора (примерно до 67 градусов), что сопровождается кратковременным взвыванием кулера. Спустя 2-3 секунды температура возвращается к обычным 50 градусам и кулер стихает. Аналогичная картина наблюдается и в Windows 7. Даже если зайти в BIOS спустя 15-20 минут работы ноутбука, то кулер процессора воет со страшной силой, но стоит только ОС загрузиться, как всё стихает. Подскажите, пожалуйста, что можно настроить в Debian чтобы при малейшей нагрузке процессор не начинал резко нагреваться => кулер не начинал сильно выть?

cpu, debian, system, железо, температура

Sferg
(08.03.18 15:03:51 MSK)

54 комментария (стр. 2)

Как правильно реализовать аппаратное ускорение на Radeon в Debian 9 («Stretch»)?

Здравствуйте, господа. Имеется ноутбук с видеокартой AMD Radeon HD 6850M, где установлен Debian 9 («Stretch»). Подскажите, пожалуйста, как правильно реализовать аппаратное ускорение (иксы\сайты\видео) на свободных драйверах? Хотелось бы избавить процессор от излишней нагрузки, а то кулер процессора начинает время от времени подвывать при просмотре некоторых сайтов или просмотре видео с того же YouTube.

acceleration, debian, radeon, video

Sferg
(21.02.18 17:54:28 MSK)

30 комментариев

Как установить проприетарный драйвер к Radeon HD 6850M для Debian 9 («Stretch»)?

Здравствуйте, господа. Имеется ноутбук со старенькой видеокартой Radeon HD 6850M. Установлена ОС Debian 9 («Stretch»). Возможно ли установить проприетарные драйвера от AMD? Если да, то каким образом? Просто где-то читал, что AMD забросила разработку fglrx для новых версий ОС.

P.S. Вроде как народ состряпал fglrx для свежей «мяты», но как-то боязно такое ставить на Debian.

amd, debian, drivers, radeon, system

Sferg
(19.02.18 22:26:26 MSK)

4 комментария

Долго загружается Cinnamon на Debian 9 («Stretch»). Как побороть?

Здравствуйте, господа. На стареньком ноутбуке с SSD установил Debian 9 («Stretch») c графической средой Cinnamon. Видеокарточка у ноутбука AMD Radeon HD 6580M. Сразу после установки всё запускалось быстро и хорошо (правда, рабочий стол при этом отрисовывался без аппаратного ускорения), поскольку при загрузке требовалось доустановить пакет firmware-amd-graphics. Доустановил. Теперь всё стало загружаться очень медленно. Сначала загрузка висит секунд 10 на запросе логина\пароля:

Debian GNU/Linux 9 acer-i7 tty1

acer-i7 login: _

Затем ещё секунд 5 экран с текстовым курсором в верхнем левом углу экрана. Потом ещё секунд 10 экран пустой. И, наконец, появляется графический курсор и рабочий стол Cinnamon'а.

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

Подскажите, пожалуйста, как можно это победить? Если какие логи нужны - напишите, предоставлю.

cinnamon, debian, system

Sferg
(10.02.18 22:03:16 MSK)

71 комментарий (стр. 2)

Мерцание экрана при загрузке Debian. Каким образом можно устранить?

Здравствуйте, господа. Установил на ноутбук Debian 9 («Stretch») рядом с Windows 7. Надписи в меню Grub'а очень мелкие (полагаю, разрешение 1600x900), после выбора пункта загрузки Debian экран один раз перемигивает (как при смене видеорежима) и, спустя несколько секунд, появляются дальнейшие надписи - тоже очень мелкие (тоже, скорее всего при разрешении 1600x900).

Теперь о деталях. Видеокарта - ATI Radeon HD 6850M. Сразу же после установки системы установил пакет firmware-amd-graphics (при загрузке системы выводилось сообщение с предложением установить данный пакет - после установки сообщение пропало), а также добавил в /etc/default/grub параметр «acpi_backlight=vendor», без которого выводилось сообщение: «Failed to start Load/Save Screen Backlight Brightness of backlight:acpi_video0».

Содержимое /etc/default/grub:

# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
# For full documentation of the options in this file, see:
#   info -f grub -n 'Simple configuration'

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet acpi_backlight=vendor"
GRUB_CMDLINE_LINUX=""

# Uncomment to enable BadRAM filtering, modify to suit your needs
# This works with Linux (no patch required) and with any kernel that obtains
# the memory map information from GRUB (GNU Mach, kernel of FreeBSD ...)
#GRUB_BADRAM="0x01234567,0xfefefefe,0x89abcdef,0xefefefef"

# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console

# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480

# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true

# Uncomment to disable generation of recovery mode menu entries
#GRUB_DISABLE_RECOVERY="true"

# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"

Вывод hwinfo --framebuffer:

02: None 00.0: 11001 VESA Framebuffer
  [Created at bios.459]
  Unique ID: rdCR.61B5R9aQUI6
  Hardware Class: framebuffer
  Model: "(C) 1988-2005, ATI GRANVILLE"
  Vendor: "(C) 1988-2005, ATI Technologies Inc."
  Device: "GRANVILLE"
  SubVendor: "ATI ATOMBIOS"
  SubDevice: 
  Revision: "01.00"
  Memory Size: 16 MB
  Memory Range: 0xb0000000-0xb0ffffff (rw)
  Mode 0x0300: 640x400 (+640), 8 bits
  Mode 0x0301: 640x480 (+640), 8 bits
  Mode 0x0303: 800x600 (+832), 8 bits
  Mode 0x0305: 1024x768 (+1024), 8 bits
  Mode 0x0310: 640x480 (+1280), 15 bits
  Mode 0x0311: 640x480 (+1280), 16 bits
  Mode 0x0313: 800x600 (+1600), 15 bits
  Mode 0x0314: 800x600 (+1600), 16 bits
  Mode 0x0316: 1024x768 (+2048), 15 bits
  Mode 0x0317: 1024x768 (+2048), 16 bits
  Mode 0x030d: 320x200 (+640), 15 bits
  Mode 0x030e: 320x200 (+640), 16 bits
  Mode 0x0320: 320x200 (+1280), 24 bits
  Mode 0x0393: 320x240 (+320), 8 bits
  Mode 0x0395: 320x240 (+640), 16 bits
  Mode 0x0396: 320x240 (+1280), 24 bits
  Mode 0x03b3: 512x384 (+512), 8 bits
  Mode 0x03b5: 512x384 (+1024), 16 bits
  Mode 0x03b6: 512x384 (+2048), 24 bits
  Mode 0x03c3: 640x350 (+640), 8 bits
  Mode 0x03c5: 640x350 (+1280), 16 bits
  Mode 0x03c6: 640x350 (+2560), 24 bits
  Mode 0x0333: 720x400 (+768), 8 bits
  Mode 0x0335: 720x400 (+1472), 16 bits
  Mode 0x0336: 720x400 (+2944), 24 bits
  Mode 0x0353: 1152x864 (+1152), 8 bits
  Mode 0x0355: 1152x864 (+2304), 16 bits
  Mode 0x0356: 1152x864 (+4608), 24 bits
  Mode 0x0321: 640x480 (+2560), 24 bits
  Mode 0x0322: 800x600 (+3200), 24 bits
  Mode 0x0323: 1024x768 (+4096), 24 bits
  Mode 0x03ee: 1600x900 (+1600), 8 bits
  Mode 0x03ef: 1600x900 (+3200), 16 bits
  Mode 0x03f0: 1600x900 (+6400), 24 bits
  Config Status: cfg=new, avail=yes, need=no, active=unknown

Текущее разрешение экрана в TTY выяснил, заглянув в /sys/class/graphics/fb0/virtual_size: 1600,900.

Собственно, вопрос: каким образом устранить это противное перемигивание экрана, сохранив разрешение 1600x900 в меню Grub'a и в консоли по окончании загрузки?

P.S. Добавление в /etc/default/grub параметра nomodeset устраняет мерцание, но я не уверен, что это хорошая идея.

debian, system, video

Sferg
(03.02.18 16:30:50 MSK)

10 комментариев

Как восстановить нормальную работу systemd?

Здравствуйте, господа. Решил поменять hostname в Debian Jessie. Руководствовался статейкой на https://wiki.debian.org/ru/HowTo/ChangeHostname#systemd, где было написано:

systemd
В версиях Debian с установленным systemd, можно использовать команду «hostnamectl set-hostname mymachine». Этот инструмент зависит от dbus поэтому обязательно установите его в первую очередь.

Сперва проверил наличие dbus:

# dpkg -l | grep dbus
ii  libdbus-1-3:amd64           1.8.22-0+deb8u1        amd64        simple interprocess messaging system (library)
ii  libdbus-glib-1-2:amd64      0.102-1                amd64        simple interprocess messaging system (GLib-based shared library)
ii  python3-dbus                1.2.0-2+b3             amd64        simple interprocess messaging system (Python 3 interface)

Поскольку в списке dbus'а я не узрел, то решил его установить с помощью aptitude install dbus. В результате чего посыпались ошибки, пакет dbus появился в списке, но оказался сломанным:

# dpkg -l | grep dbus
pF  dbus                        1.8.22-0+deb8u1        amd64        simple interprocess messaging system (daemon and utilities)
ii  libdbus-1-3:amd64           1.8.22-0+deb8u1        amd64        simple interprocess messaging system (library)
ii  libdbus-glib-1-2:amd64      0.102-1                amd64        simple interprocess messaging system (GLib-based shared library)
ii  python3-dbus                1.2.0-2+b3             amd64        simple interprocess messaging system (Python 3 interface)

Попытался удалить пакет dbus, чтобы вернуться к предыдущему состоянию, но и это мне не удалось из-за ошибок:

# apt-get purge dbus
Чтение списков пакетов… Готово
Построение дерева зависимостей
Чтение информации о состоянии… Готово
Пакеты, которые будут УДАЛЕНЫ:
dbus* (1.8.22-0+deb8u1)
обновлено 0, установлено 0 новых пакетов, для удаления отмечено 1 пакетов, и 1 пакетов не обновлено.
не установлено до конца или удалено 1 пакетов.
После данной операции, объём занятого дискового пространства уменьшится на 903 kB.
Хотите продолжить? [Д/н] y
(Чтение базы данных … на данный момент установлен 47341 файл и каталог.)
Удаляется dbus (1.8.22-0+deb8u1) …
Failed to get D-Bus connection: Нет такого файла или каталога
dpkg: ошибка при обработке пакета dbus (--purge):
подпроцесс установлен сценарий pre-removal возвратил код ошибки 1
Failed to get D-Bus connection: Нет такого файла или каталога
Failed to get D-Bus connection: Нет такого файла или каталога
Failed to get D-Bus connection: Нет такого файла или каталога
invoke-rc.d: initscript dbus, action "start" failed.
dpkg: ошибка при очистке:
подпроцесс установлен сценарий post-installation возвратил код ошибки 1
При обработке следующих пакетов произошли ошибки:
dbus
E: Sub-process /usr/bin/dpkg returned an error code (1)

В итоге не получается ничего запустить\перезапустить\остановить - всё заканчивается ошибкой:

# systemctl start nginx
Failed to get D-Bus connection: Нет такого файла или каталога
# service mysql restart
Failed to get D-Bus connection: Нет такого файла или каталога
# /etc/init.d/proftpd stop
[....] Stopping proftpd (via systemctl): proftpd.serviceFailed to get D-Bus connection: Нет такого файла или каталога
failed!

Подскажите, пожалуйста, как это можно исправить?

admin, debian, jessie, linux, systemd

Sferg
(22.01.18 12:19:40 MSK)

16 комментариев

При UsePAM=no в /etc/ssh/sshd_config портится консоль в Debian. Каким образом можно побороть?

Здравствуйте, уважаемые Знатоки. В целях ускорения подключения к удалённому ПК через SSH, в файле /etc/ssh/sshd_config выставил UsePAM=no. При этом почему-то Midnight Commander стал криво отображаться.

Вот так выглядит Midnight Commander с UsePAM=yes:
Скрин 1

А вот так стал выглядеть Midnight Commander после указания UsePAM=no
Скрин 2

Каким образом можно это побороть? При UsePAM=no всё подключается явно быстрее.

Выхлоп locale при коннекте с UsePAM=yes в /etc/ssh/sshd_config:

LANG=ru_RU.UTF-8
LANGUAGE=ru_RU.UTF-8
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES=ru_RU.UTF-8
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=

Выхлоп locale при коннекте с UsePAM=no в /etc/ssh/sshd_config:

LANG=
LANGUAGE=
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

admin, ssh, system

Sferg
(21.01.18 15:50:45 MSK)

6 комментариев

Как предотвратить попадание на сайт по https://xxx.xxx.xxx.xxx?

Здравствуйте, господа. Имеется связка Nginx + PHP7-FPM. Недавно «созрел» для того, чтобы воспользоваться SSL-сертификатами от Let's Encrypt, дабы перейти с HTTP на HTTPS. Случайно обнаружил в /var/log/nginx/access.log записи, что ко мне пытаются заходить по адресу https://xxx.xxx.xxx.xxx (у меня IP динамический, так что адрес может отличаться, но не суть). Подскажите, пожалуйста, как можно прекратить это безобразие? C HTTP вопросов никаких нет - там всё отсеивается с помощью маленького конфига /etc/nginx/sites-available/default.conf:

server {
    listen                     80 default_server;
    return                     444;
}

где при попытке зайти по http://xxx.xxx.xxx.xxx выводится сообщение о том, что соединение сброшено. Каким образом можно добиться того же для HTTPS? В случае, если бы IP был статическим, то, полагаю, можно было бы сгенерировать сертификат для него и указать IP в конфиге явно, но пока что для экспериментов хватает IP динамического.

linux, nginx, web

Sferg
(17.01.18 12:07:12 MSK)

20 комментариев

следующие →

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