Всем здравствуйте.

Хочу установить Linux на старое железо (есть несколько материнок на Intel i440BX и VIA KT133A и россыпь Coppemine’ов и Tualation’ов к ним). Материнки исправны, но наиболее «топовые» процессоры не держат (всё виснет посреди POST), хотя по спецификациям должны. Есть подозрение, что BIOS тупо не знает некоторых cpuid, что можно исправить с помощью последних версий BIOS с Ultimate Retro и BIOS Patcher.

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

Вопрос: у кого есть положительный опыт с EZP 2019 или MiniPro TL866ii+?

Можно ли прошить старые 32-х и 34-пиновые микросхемы AWARD BIOS с помощью более дешёвого CH341A, который так хвалит современная молодёжь?

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

Всем здравствуйте.

Итак, задача.

Задача

Заела ностальгия, хочу увидеть старую добрую фреймбуферную консоль с пингвином (CONFIG_LOGO_LINUX_VGA16 или CONFIG_LOGO_LINUX_CLUT224).

Всё это безобразие я пытаюсь выполнить на не самом старом ноутбуке с Core i7-7700HQ и i915 в качестве основной видеоплаты (есть ещё дискретная видеоплата AMD, но речь сейчас не о ней). Причём грузится Linux посредством UEFI (не BIOS).

«Родное» разрешение экрана – 1920x1080, поэтому в обычных условиях (без извращений, т. е. без efifb либо inteldrmfb) GRUB как-то автоматически цепляет именно это разрешение, а дальше я гружу ядро с параметрами video=eDP-1:1920x1080 video=HDMI-A-1:1920x1080.

Но вернёмся к задаче. Вопрос не об inteldrmfb и не о KMS – вопрос именно о включении VGA- или VESA-режимов. Основная проблема в том, что перевести фреймбуфер

• в разрешение 720x400x16 (текстовая VGA-консоль 80x25)
• либо в 640x480x16 (VGA16)
• либо в любое из VESA-разрешений (хотя бы 800x600)

– я не могу. В худшем случае после меню GRUB я вижу просто чёрный экран, в лучшем – для вывода используется узкая полоска высотой 20px вверху экрана (похоже, что ядро просто пишет в самое начало видеопамяти, да ещё предполагает глубину цвета 4bpp вместо 32bpp). В обоих случаях приходится заходить на компьютер по сети.

Ход эксперимента

Варианты, которые я использовал:

• текстовая консоль VGA (CONFIG_FB_VGA16 is not set, CONFIG_VGA_CONSOLE=y)
• vesafb (CONFIG_FB_BOOT_VESA_SUPPORT=y, CONFIG_FB_VESA=y)
• vga16fb (CONFIG_FB_VGA16=m)
• uvesafb, VESA framebuffer в userspace, использующий «виртуальный» x86 BIOS (CONFIG_FB_VGA16=m, CONFIG_FB_UVESA=m, v86d установлен)

В случае с vga16fb у меня даже появляются /dev/fb0 и /sys/class/graphics/fb0/*, но, ещё раз, вывод приходится на самое начало видеопамяти .

Что я пытался сделать:

1. Включал/выключал KMS (nomodeset, i915.modeset=0, вот это всё). В конце концов для чистоты эксперимента просто перестал собирать модули i915 и amdgpu.
2. Играл с параметрами video= и vga=, как описано здесь, здесь здесь и здесь. Варианты vga=normal, vga=extended, vga=ask, vga=301, video=vga16fb:640x480-4, video=vesa, video=uvesafb н к чему не приводят, ядро на них кладёт.
3. Играл с настройками GRUB. Команда vbeinfo отсутствует, команда videoinfo выводит пустой список видеорежимов. Установка GRUB_GFXPAYLOAD_LINUX=text приводит к тому, что GRUB радостно сообщает: «text» mode is not available и продолжает загрузку в слепом (blind) режиме. Т. е. это тоже чёрный экран, но уже средствами не ядра, а GRUB.
4. Запускал hwinfo --framebuffer. Пустой список.

В сухом остатке – у меня ощущение, что я косячу либо с настройками GRUB, либо с параметрами ядра (в последнем случае не скажешь наверняка, т. к. документация на тот же vesafb была написана 20 лет назад, и хрен поймёт, насколько она актуальна сейчас).

Либо же то, что я наблюдаю – особенности именно интеловского фреймбуфера.

Либо же VGA- и VESA-режимы вообще недоступны пр загрузке через UEFI, но подтверждения этому я нигде не нашёл. Но, с другой стороны, x86 BIOS недоступен, да.

Вопрос

Собственно, вопрос. Оно вообще возможно – VGA или VESA через UEFI? Если да – то какие настройки GRUB и параметры ядра должны быть?

P.S. Смотрел в /boot/grub/x86_64-efi/video.lst – там только efi_gop, efi_uga, video_bochs, video_cirrus, что, в общем, закономерно. Никакого vbe там нет.

P.P.S. Ядро 4.19.251, хотя это и не важно. Модули, которые меня интересуют, не менялись десятилетиями.

Всем здравствуйте.

Хочется странного. Хочется привязать линтер X к типу файлов Y в редакторе Z (причём Z == Vim).

Я так понимаю, есть два пути:

1. Создать свой compiler plug-in, который бы определял makeprg и errorformat и положить его ~/.vim/compiler:

   CompilerSet makeprg=...
   CompilerSet errorformat=...
   

   а затем динамически включать и выключать описанный «компилятор» при смене типа файла:

   autocmd Filetype Y compiler X
   

2. Внедриться в syntastic, который и так уже поддерживает 100500 статических анализаторов кода.

Вопросы:

1. Какие ещё пути существуют?
2. Как обычно решается вопрос с проверкой содержимого «безымянного» буфера, у которого уже есть filetype, но которому не соответствует никакой файл на диске?
3. Стоит ли заморачиваться с написанием модулей расширений на Python или Ruby?
4. Есть ли возможность непрерывно, как это делают современные IDE, анализировать код по мере ввода текста?
5. Есть ли возможность выводить результаты анализа не в «линейке редактора» («editor gutter»), как это делают syntastic и vim-gitgutter и не в Error Window (:copen), а прямо в буфере с кодом (возможно, до след. redraw)?

Есть ли расширения Vim, которые уже делают что-то подобное?

За последние несколько лет мне пришлось столкнуться с множеством вопросов, которые были сформулированы примерно так: «мой проект не открывается в среде CLion». В свою очередь, это приводило к необходимости из раза в раз объяснять разным людям примерно одно и то же. Статья имеет целью сохранить тот опыт, который был накоплен в процессе анализа десятков разных проектов.

( читать дальше... )

Всем здравствуйте.

Допустим, есть один или несколько почтовых ящиков у одного оператора (скажем, gmail.com), и необходимо выполнить миграцию (или банально продублировать) всей почты к другому оператору (скажем, ya.ru).

Какими средствами это лучше сделать? Перетаскивание мышкой в Thunderbird/Claws Mail не предлагать.

Про mail forwarding в настройках исходного оператора я в курсе. Интересует миграция именно исторической почты.

P. S. Уже нашёл imapsync. Что ещё можете порекомендовать? Каков был опыт непосредственно с imapsync?

Всем здравствуйте.

Решил попробовать модуль TabNine для Vim, но предварительно запустил антивирусную проверку. Из-под оффтопика, но это не так важно.

И DrWeb мне говорит, что TabNine заражён Linux.Siggen.2488 (снимок экрана).

Конечно, это вновь наводит на мысль, что бинарные «блобы» хрен знает, откуда, лучше не качать. Особенно радуют пути вида

/root/.config
/root/.config/TabNine
/root/.config/TabNine/.atomicwrite.MhUOrZxqnoBr
/root/.w3m

– видимо, тот, кто впервые сообщил о вредоносном поведении, запускал TabNine из-под рута.

Что думаете?

Обсуждалась ли эта проблема ранее?

Всем здравствуйте.

Есть установленное окружение TDE (14-й версии для Debian 10, но это несущественно).

В настройках (tqtconfig) выбираю произвольный стиль оформления – от Asteroid до dotNET. Сам tqtconfig немедленно меняет свой внешний вид.

А вот произвольные прикладные программы (напр., /opt/trinity/bin/konsole) упрямо отображаются в стиле Plastik.

Удаление глобальных настроек в /etc/tqt3 не помогает.

В файлах ~/.qt/qtrc и ~/.qt/tqt_plugins_3.5rc никакого криминала нет.

Частичный вывод strace konsole:

[pid 17777] openat(AT_FDCWD, "/home/bass/.qt/qtrc", O_RDONLY) = 6
[pid 17777] read(6, "[3.3]\nlibraryPath=/usr/lib/trini"..., 4096) = 1039
[pid 17777] openat(AT_FDCWD, "/opt/trinity/share/locale/ru/LC_MESSAGES/tdelibs.mo", O_RDONLY) = 11
[pid 17777] openat(AT_FDCWD, "/opt/trinity/lib/trinity/plugins/styles", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
[pid 17777] openat(AT_FDCWD, "/opt/trinity/lib/trinity/plugins/styles", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 11
[pid 17777] openat(AT_FDCWD, "/home/bass/.qt/tqt_plugins_3.5rc", O_RDONLY) = 12
[pid 17777] read(12, "[opt]\ntrinity/lib/trinity/plugin"..., 4096) = 1696
[pid 17777] openat(AT_FDCWD, "/opt/trinity/lib/trinity/plugins/styles/plastik.so", O_RDONLY|O_CLOEXEC) = 11
[pid 17777] openat(AT_FDCWD, "/home/bass/.qt/qtrc", O_RDONLY) = 12
[pid 17777] read(12, "[3.3]\nlibraryPath=/usr/lib/trini"..., 4096) = 1039

И, что характерно, на соседней машине с ровно теми же версиями ПО всё прекрасно.

ЧЯДНТ?

Всем здравствуйте.

Допустим, у меня есть исходный код на C, в пути к которому есть пробелы и двоеточия, и который собирается с помощью Make. Тогда, если подобное встречается в строке, где цель(и) и зависимости, спецсимволы должны быть экранированы с помощью \:

main: C\:/Program\ Files/main.c
        $(CC) -o $@ $<

В этом случае GNU Make ведёт себя логично, совершенно точно собирает всё, как надо, и не выдаёт малопонятной белиберды вроде

Makefile:1: *** target pattern contains no '%'.  Stop.

В то же время, насколько я могу судить, BSD Make (у меня в системе установлен bmake) этот самый бэкслэш игнорирует, считая его частью пути файла.

Вопрос: как в условиях задачи написать Makefile совместимым и с GNU, и с BSD?

Насколько я знаю, никому (в т. ч. alt-x) завести это чудо не удавалось. У меня есть Solaris, есть дистрибутив MSIE – но он, зараза, не стартует. Не хватает чего-то.

Тем не менее, у кого-то получилось. Вижу эти кадры впервые:

https://www.youtube.com/watch?v=_AoyQeUzbEU

Всем здравствуйте.

Есть виртуальная машина (VirtualBox), далее guest.

Хочу обеспечить guest’у выход в сеть (в т. ч. интернет), поместив его/её в отдельную подсеть и настроив host как маршрутизатор, минуя стандартные средства VirtualBox (Bridged, NAT, NAT Network).

Соот-но, на самой VM поднята только host-only network, этой сети на host’е соответствует интерфейс vboxnet0:

vboxnet0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.138.1  netmask 255.255.255.0  broadcast 192.168.138.255
        inet6 fe80::800:27ff:fe00:0  prefixlen 64  scopeid 0x20<link>
        ether 0a:00:27:00:00:00  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11796  bytes 1496688 (1.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Host и guest прекрасно видят друг друга, guest использует в кач-ве шлюза по умолчанию 192.168.138.1 (интерфейс vboxnet0 host’а).

В /etc/networks дополнительно определена сеть vboxnet0:

vboxnet0       192.168.138.0

Далее, iptables на host’е настроены примерно так:

*nat

-A POSTROUTING -o vboxnet0 -j MASQUERADE

COMMIT


*filter

# Incoming traffic from virtual network interfaces
-A INPUT -i vboxnet0 -j ACCEPT

# Incoming traffic to virtual networks
-A INPUT --destination vboxnet0/24 -j ACCEPT

-A FORWARD -i eth0 -o vboxnet0 -j ACCEPT
-A FORWARD -i vboxnet0 -o eth0 -j ACCEPT
-A FORWARD -j DROP

-A OUTPUT -j ACCEPT

COMMIT

В результате виртуальная машина «видна» извне (из физической домашней сети 192.168.0.0/24, куда подключён host своим инрефейсом eth0), но вот сама она ничего, кроме host’а (192.168.138.1), не видит.

ЧЯДНТ?

Всем здравствуйте.

После обновления ядра (Debian, 4-19 -> 4.19) начинают «течь» «иксы».

  Mem[||||||||||||||||||||||||||||||||||||||||||||||||||||||||16.5G/31.3G]   Uptime: 2 days, 22:45:57
  Swp[|                                                       6.50M/7.89G]   Tasks: 225; 1 running
  Bat[|||||||||||||||||||||||||||||||||||||||||||||||||||||||||96.0%(A/C)]   Load average: 0.79 0.96 0.99 

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
23175 root       20   0 15.2G 13.7G  195M S  3.3 43.8  2h05:43 Xorg -listen tcp -deferglyphs 16 +iglx -auth /home/bass/.Xauthority

«Свежие» значения M_SIZE (VIRT) и M_RESIDENT (RES) редко превышают 1.5 ГБ:

  Mem[|||||||||||||||||||||||||                    974M/31.3G]   Uptime: 2 days, 23:00:03
  Swp[|                                           6.50M/7.89G]   Tasks: 188; 1 running
  Bat[|||||||||||||||||||||||||||||||||||||||||||||96.0%(A/C)]   Load average: 0.37 0.50 0.73 

  PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command
28315 root       20   0 1594M  165M  118M S  2.0  0.5  0:02.64 Xorg -listen tcp -deferglyphs 16 +iglx -auth /home/bass/.Xauthority

Затем, за сутки-двое «натекает» 16-32 ГБ. После этого только REISUB.

Знаю, что корреляция не всегда означает причинно-следственную связь, так что ядро м. б. и ни при чём.

Куда копать?

Могут ли (в принципе) причиной утечки быть некие короткоживущие X-клиенты?

Всем здравствуйте.

Ситуация такая.

Хочу залезть на http://deb.devuan.org/merged/dists/ (да, по HTTP). Браузер – Chromium и любые на его основе: Chrome, Opera, Vivaldi).

Движок Chromium, отличающийся излишней ретивостью и заботой о моей безопасности, зараза такая, автоматически добавляет в запрос

Upgrade-Insecure-Requests: 1

В результате web-сервер «поднимает» протокол до HTTPS (HTTP 307), отдавая мне https://deb.devuan.org/merged/dists/, и дальше бабушка надвое сказала:

• либо проблема с SSL-сертификатом (потому что сервер – зеркало, одно из многих, и принадлежит какой-то CDN, и его имя вовсе не deb.devuan.org),
• либо HTTP 404, потому что на 443-м порту отдаётся совсем другое содержимое, и вообще deb-пакеты обычно не передаются по HTTPS.

С одной стороны, это не совсем корректная настройка сервера.

С другой – мой слишком заботливый браузер, мать его, тупо не даёт мне просмотреть содержимое HTTP-ресурса. Mozilla и lynx, кстати, всё позволяют.

Вопрос: как это к х#рам отключить?

Потому что даже вписав к конфиг squid

request_header_access Upgrade-Insecure-Requests deny all

я всё равно не могу добиться желаемого результата (кроме «чистого» дебиановского Chromium’а).

Для остальных браузеров (Chrome, Opera, Vivaldi) даже блокировка доменов checkdomain.de и 1e100.net на уровне колхозного DNS-сервера ни к чему не приводит: похоже, что IP-адреса узлов домена 1e100.net жёстко прописаны в коде, и соединение с ними происходит вообще всегда (DNS over HTTPS отключён).

При этом, если смотреть HTTP-трафик wireshark’ом, то кажется, что с целевым сервером (deb.devuan.org) HTTP-соединения вообще не происходит: Google «знает», что этот сервер может отвечать по HTTPS, и сразу пытается соединить меня с 443-м портом.

Update: именно так. Если на стороне прокси-сервера вообще запретить HTTPS-трафик, то попытка открытия http://deb.devuan.org/merged/dists/ приводит к ошибке ERR_TUNNEL_CONNECTION_FAILED. И не потому, что пресловутый deb.devuan.org не ответил по HTTPS (до этого не дошло), а потому, что поделие Google (Opera, Vivaldi) не смогло позвонить домой в Google (Google, Google).

Всем здравствуйте.

Дано: есть некий HTTPS-ресурс, про который известно, что он может отвечать, используя TLS 1.2. И есть правильно (до определённой степени) настроенные iptables:

# HTTP traffic blocked by the ISP                                                                                            
-A INPUT -p tcp --sport 80 -m string --string "Location: http://195.94.233.66?UrlRedir=http%3A%2F%2F" --algo bm -j DROP
-A INPUT -p tcp --sport 80 -m string --string "Location: http://stop.seven-sky.net" --algo bm -j DROP
-A INPUT -p tcp --sport 80 -m string --string "Location: http://95.167.13.50/?st" --algo bm -j DROP
-A INPUT -p tcp --sport 80 -m string --string "Location: http://blackhole.beeline.ru" --algo bm -j DROP

# HTTPS traffic blocked by the ISP
-A INPUT -p tcp --sport 443 --tcp-flags RST RST -j DROP

И вот теперь я пытаюсь зайти на этот самый ресурс по HTTPS:

$ wget --inet4-only --https-only --secure-protocol=TLSv1_2 -O - https://www.linkedin.com
--2021-10-06 14:33:28--  https://www.linkedin.com/
Resolving www.linkedin.com (www.linkedin.com)... 13.107.42.14
Connecting to www.linkedin.com (www.linkedin.com)|13.107.42.14|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 88377 (86K) [text/html]
Saving to: ‘STDOUT’

-                     0%[                    ]       0  --.-KB/s               <!DOCTYPE html>
<html lang=ru>
<head>
<link rel="stylesheet" type="text/css" href="/waltz/combined.css?20210926-1635">

<link rel="yandex-tableau-widget" href="/manifest.json" />
<meta name="referrer" content="always">

<title>LINUX.ORG.RU — Русская информация об ОС Linux</title>
...

Всё хорошо. А теперь попробуем то же самое с помощью curl:

$ curl -v --tlsv1.2 --tls-max 1.2 https://linkedin.com
* Expire in 0 ms for 6 (transfer 0x55acfeaa3f50)
...
* Expire in 50 ms for 1 (transfer 0x55acfeaa3f50)
*   Trying 13.107.42.14...
* TCP_NODELAY set
* Expire in 149971 ms for 3 (transfer 0x55acfeaa3f50)
* Expire in 200 ms for 4 (transfer 0x55acfeaa3f50)
* Connected to linkedin.com (13.107.42.14) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* Operation timed out after 300179 milliseconds with 0 out of 0 bytes received
* Closing connection 0
curl: (28) Operation timed out after 300179 milliseconds with 0 out of 0 bytes received

И тишина. И, что характерно, причина отнюдь не в User-Agent, потому что curl -A 'Wget/1.20.1 (linux-gnu)' -v --tlsv1.2 --tls-max 1.2 https://www.linkedin.com тоже не получает ответа.

Совершенно аналогичным образом, lynx и elinks как раз работают, а w3m, links и обычные браузеры как раз нет.

В чём разница?

Update: openssl s_client -connect www.linkedin.com:443 лишь устанавливает TCP-соединение, и не более того, так что отладочной информации, увы, нет.

Update 2: призываю всех проголосовать за Issue 908132: FR: Support for Encrypted SNI (ESNI).

Собственно, вот.

Взгляните на автора сообщения – не правда ли, мир тесен?

Всем здравствуйте.

На NFS-сервере есть правильно настроенный NIS и вот такие (идентичные в урезанном варианте) определения сетевых групп (в /etc/netgroup):

trusted (proxima,bass,) (proxima-eth0,bass,)
proxima (proxima,bass,) (proxima-eth0,bass,)

И вот так выглядит /etc/exports:

/export/backup0 @trusted(mp,rw,sync,subtree_check,pnfs)
/export/backup1 @proxima(mp,rw,sync,subtree_check,pnfs)

И вот загвоздка в том, что NFS-клиенту proxima один из сетевых ресурсов (/export/backup0) доступен, а второй нет.

Возникло внезапно. До сих пор всё долгие месяцы работало как часы.

WTF?

Всем здравствуйте.

Хочу обновить память в ноутбуке (Core i7-7700HQ). Сейчас установлена одна «планка», работающая на частоте 2400 МГц, и, похоже, это максимально возможная частота для моего контроллера памяти (DDR4-2400). dmidecode не выдаёт ничего интересного, кроме значения лимита в 32 ГБ:

# dmidecode --type 16
# dmidecode 3.2
Getting SMBIOS data from sysfs.
SMBIOS 3.0.0 present.

Handle 0x0024, DMI type 16, 23 bytes
Physical Memory Array
        Location: System Board Or Motherboard
        Use: System Memory
        Error Correction Type: None
        Maximum Capacity: 32 GB
        Error Information Handle: No Error
        Number Of Devices: 2

Вопрос.

Можно ли воткнуть в ноутбук память, номинально рассчитанную на работу на частоте в 2666 или 3200 МГц?

Не будет ли проблем с совместимостью?

Всем здравствуйте.

Закончил подбор «железа» для Solaris 8 на x86 (SPARC-машины тоже есть, но сейчас речь не о них).

Долго промучился с настройкой карты Sound Blaster 16 (CT2230), но так и не добился возможности вывода 16-разрядного PCM-звука. В результате была куплена плата AWE64 (CT4380), которая была опознана системой и сразу заработала.

Результат на снимке.

«Железо»:

• Intel Celeron 500 MHz,
• материнская плата ECS (EliteGroup) P6VAP-A+ на чипсете VIA,
• память: 1.5 ГБ (3x512 МБ),
• видеоплата: Matrox G450 PCI DVI (единственная, которая в связке с сервером Xsun смогла «выдать» 1600x1200x32bpp – перепробовал множество разных «матроксов» от G400 до G550 и ATI Rage 128),
• сетевая плата 3Com 3c509,
• Sound Blaster AWE64 (CT4380).

Всем здравствуйте.

Собственно, есть такой контроллер: Silicon Image 3114. Он вставляется в PCI-шину, поддерживает до 4-х SATA-дисков, может работать в режиме IDE-совместимости и потому идеален для миграции старого железа с уходящих в небытие IDE HDD-дисков.

Например, на него можно установить голый DOS (и загрузиться), не говоря уже о том, что любой Linux моложе 2004 года становится на эту железку просто на «ура».

Я решил перенести старый восьмой «Солярис» с IDE-диска. Сделал всё, как рекомендуют советчики в сети:

1. Добавил в базу устройств, используемую Solaris Configuration Assistant (/boot/solaris/devicedb/master):

   pci1095,3114 pci-ide msd pci ata.bef "Silicon Image 3114 SATA Controller"
   

   Пробовал также вместо pci-ide pci1095,3114:

   pci1095,3114 pci1095,3114 msd pci ata.bef "Silicon Image 3114 SATA Controller"
   

2. В /etc/driver_aliases явно сказал, что устройство pci1095,3114 – это ATA-контроллер:

   ata "pci1095,3114"
   

3. Перезагрузил систему (touch /reconfigure; reboot -- -r).

В результате Configuration Assistant таки находит устройство, котороя я заботливо вписал ему в базу (снимок), но загружаться предлагает только со старого IDE-диска (снимок).

После загрузки самого Solaris утилиты format и fdisk «видят» только исходный IDE-диск (что подтверждается файлами устройств в /devices), а prtconf -pv выводит следующее:

        Node 0x190798
            66mhz-capable:  
            assigned-addresses:  81005810.00000000.0000d800.00000000.00000008.81005814.00000000.0000dc00.00000000.00000004.81005818.00000000.0000e000.00000000.00000008.8100581c.00000000.0000e400.00000000.00000004.81005820.00000000.0000e80
0.00000000.00000010.82005824.00000000.df000000.00000000.00000400.82005830.00000000.00000000.00000000.00080000
            class-code:  00010600
            compatible:  31696370.2c353930.34313133.69637000.35393031.3131332c.63700034.39303169.31332c35.70003431.6c636963.2c737361.36303130.00003030
            device-id:  00003114
            devsel-speed:  00000001
            fast-back-to-back:  
            interrupts:  00000001
            max-latency:  00000000
            min-grant:  00000000
            model:  'PCI: 1095,3114 - Silicon Image 3114 SATA Controller'
            name:  'pci1095,3114'
            power-consumption:  00000001.00000001
            reg:  00005800.00000000.00000000.00000000.00000000.01005810.00000000.00000000.00000000.00000008.01005814.00000000.00000000.00000000.00000004.01005818.00000000.00000000.00000000.00000008.0100581c.00000000.00000000.00000000.00000004.01005820.00000000.00000000.00000000.00000010.02005824.00000000.00000000.00000000.00000400.02005830.00000000.00000000.00000000.00080000
            revision-id:  00000002
            slot:  00000003
            subsystem-id:  00003114
            subsystem-vendor-id:  00001095
            unit-address:  'b'
            vendor-id:  00001095

Для сравнения, для встроенного IDE-контроллера выводится в т. ч. и список присоединённых к нему устройств:

        Node 0x18f5d8
            #address-cells:  00000001
            #size-cells:  00000000
            assigned-addresses:  81003910.00000000.000001f0.00000000.00000008.81003914.00000000.000003f6.00000000.00000001.81003918.00000000.00000170.00000000.00000008.8100391c.00000000.00000376.00000000.00000001.81003920.00000000.0000d000.00000000.00000010.81003924.00000000.00000000.00000000.00000000
            boot-interface:  00000013.00000000.00000000.00000010
            class-code:  0001018a
            compatible: 'pci-ide' + 'pci1106,571' + 'pciclass,01018a'
            device-id:  00000571
            device_type:  'pci-ide'
            devsel-speed:  00000001
            fast-back-to-back:  
            max-latency:  00000000
            min-grant:  00000000
            model:  'PCI: 1106,571 - Bus Mastering IDE controller'
            name:  'pci-ide'
            power-consumption:  00000001.00000001
            reg:  00003900.00000000.00000000.00000000.00000000.81003910.00000000.000001f0.00000000.00000008.81003914.00000000.000003f6.00000000.00000001.81003918.00000000.00000170.00000000.00000008.8100391c.00000000.00000376.00000000.00000001.01003920.00000000.00000000.00000000.00000010.01003924.00000000.00000000.00000000.00000000
            revision-id:  00000010
            slot:  00000000
            unit-address:  '7,1'
            vendor-id:  00001106

            Node 0x18fb78
                name:  'ide'
                reg:  00000000
                unit-address:  '0'

            Node 0x18fc48
                name:  'ide'
                reg:  00000001
                unit-address:  '1'

Вопрос: был ли у кого-нибудь положительный опыт?

Всем здравствуйте.

Внезапно, файлы, входящие в состав Solaris Configuration Assistant (на платформе x86), оказались исполняемыми файлами MS-DOS.

2 штуки *.exe и одна штука *.com (пруф).

Кто-нибудь может объяснить, почему?

Всем здравствуйте.

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

1. Наличие пакетов под Debian. Собирать вручную и самостоятельно поддерживать уже надоело.
2. Распределённая архитектура (с возможностью либо устанавливать на наблюдаемую машину агента, либо, лучше, заходить по SSH по ключу и захватывать вывод произвольной команды). Ибо хочу наблюдать 4 машины и консолидировать данные.
3. Хранение истории метрик (желательно, в базе – MySQL или PostgreSQL).
4. Наличие Web-интерфейса для наблюдения метрик.
5. Наличие Web-интерфейса для настройки (это то, чего лишены Nagios и Icinga).
6. Умение мониторить SMART-атрибуты дисков без ужимок, прыжков, необходимости запускать процесс от имени root и вручную описывать наблюдаемую сущность. Вот это ключевое, потому что XXI век на дворе, а я только что убил полчаса на настройку /usr/lib/nagios/plugins/check_ide_smart – и ловлю себя на мысли, что проще с нуля приготовить MRTG, чем иметь дело с костылями под названием Nagios и его форками.

У кого есть опыт работы с OpenNMS, Zabbix, MRTG, PRTG, Cacti – да хоть чёртом в ступе – поделитесь, пожалуйста.