Свершенно верно. Драйвер иксов: xf86-video-vmware
Модули ядра вроде в ядре присутствует изначально:
$ find /usr/lib/modules/*/kernel -iname "*vmw*ko*"
/usr/lib/modules/4.4.16-1-lts/kernel/drivers/misc/vmw_balloon.ko.gz
/usr/lib/modules/4.4.16-1-lts/kernel/drivers/misc/vmw_vmci/vmw_vmci.ko.gz
/usr/lib/modules/4.4.16-1-lts/kernel/drivers/scsi/vmw_pvscsi.ko.gz
/usr/lib/modules/4.4.16-1-lts/kernel/drivers/gpu/drm/vmwgfx/vmwgfx.ko.gz
/usr/lib/modules/4.4.16-1-lts/kernel/net/vmw_vsock/vmw_vsock_vmci_transport.ko.gz
/usr/lib/modules/4.6.4-1-ARCH/kernel/drivers/misc/vmw_balloon.ko.gz
/usr/lib/modules/4.6.4-1-ARCH/kernel/drivers/misc/vmw_vmci/vmw_vmci.ko.gz
/usr/lib/modules/4.6.4-1-ARCH/kernel/drivers/scsi/vmw_pvscsi.ko.gz
/usr/lib/modules/4.6.4-1-ARCH/kernel/drivers/gpu/drm/vmwgfx/vmwgfx.ko.gz
/usr/lib/modules/4.6.4-1-ARCH/kernel/net/vmw_vsock/vmw_vsock_vmci_transport.ko.gz
Vadim
Пробовал закоментировать -ничего не даёт.
Как я уже сказал, после этого надо перезагрузить и иксы, и ту консоль, из которой они запускались, чтобы добиться исчезновения переменных LINES и COLUMNS. В конце концов, это легко проверить, исчезли они или нет. В крайнем случае перезагрузить систему вообще.

Если всё перечисленное не помогло – искать дальше, уже не сами переменные, раз они задаются неявно командой shopt -s checkwinsize, а саму команду:
grep -rl checkwinsize ~/.profile ~/.bash_profile ~/.bashrc /etc/bash.bashrc /etc/profile /etc/profile.d/ ~/.fluxbox/

Что касается Eterm, то видимо, он эти переменные переопределяет сам, что снимает проблему частично, только в рамках Eterm.
Vadim, ещё раз: volumeicon тут при при чём, дело в наследовании переменных окружения от родителей к потомкам. Если alsamixer наследует переменные COLUMNS и LINES, он игнорирует действительные размеры терминала и настраивается под размер, заданный в этих переменных. Если хотите в этом убедиться, впишите
xterm -hold -e env
в настройки volumeicon.

Поскольку сама программа volumeicon чисто графическая, и никакого отношения к терминалу не имеет, переменные она получает от своего родителя, то есть от скрипта ~/.fluxbox/startup , а он, в свою очередь, скорей всего, от консоли Linux, которая запускается ДО иксов, занимает ВЕСЬ экран, и действительно может иметь размеры 240x75 символов. Не думаю, что эти переменные может выдумать Fluxbox – он тоже не консольная программа.

Предлагаю сделать так:
grep -rl COLUMNS ~/.profile ~/.bash_profile ~/.bashrc /etc/bash.bashrc /etc/profile /etc/profile.d/ ~/.fluxbox/
Если эта команда найдёт какие-то файлы, покажите их содержимое.
jim945
Так вот его биос и граб не видят совсем. А образ арча в случае чего нужно запустить с него)))
ahci спасает не принося проблем.
Не встречал такого бага в биосе, но спасибо за пример, буду иметь в виду :)
vasek, volumeicon бывает полезен, если используемый "большой" микшер не имеет "малой" версии для трея. К "кривому" терминалу, как и терминалу вообще, он не имеет никакого отношения.

Vadim, всё ясно. В обоих терминалах у вас зачем-то заданы переменные COLUMNS и LINES. У меня таких переменных нет, потому и не выходило воспроизвести ваш фирменный глюк :)
С использованием этих непонятно кем и зачем объявленных у вас переменных мне удалось "обмануть" alsamixer, и заставить его поверить в неправильные размеры терминала, хотя правильные, как и у вас, по прежнему легко читаются через tput или stty.

В "правильном" терминале они у вас послушно равны 80 и 24 соответственно, а в "кривом" стоят COLUMNS=240 и LINES=75, отсюда и попытки alsamixer рисовать длинные строки с многократными переносами.

Далее вам самому придётся найти и ликвидировать в своей системе источник этих переменных. Честно говоря, я не знаю, откуда они берутся, но они явно мешают: без них размер терминала определяется автоматически, а с ними – нет.

P.S.
Я тут подумал, и кажется понял, где собака зарыта.
Проверьте ваши профили шелла и запускаемые из них скрипты, как то
~/.profile
~/.bash_profile
~/.bashrc
/etc/bash.bashrc
/etc/profile
/etc/profile.d/*
Возможно, где-то в них прячется зловредный кусок кода, который читает текущие размеры терминала и пишет в переменные. Поскольку в запуске программы в "голом" терминале баш не участвует, ей достаются значения переменных от родительского процесса, а ему, очевидно, от баша в консоли LInux, которая занимает весь экран, и действительно может иметь размеры 240x75 символов.

Избавившись от нехорошего кода, а потом перезапустив иксы и шелл в консоли до иксов, то есть всё, использующее баш, и убедившись в отсутствии переменных COLUMNS и LINES, вы избавитесь и от вышеуказанного глюка.
Если GRUB видит диск, но не видит разделы, значит не загружен модуль таблицы разделов, part_msdos или part_gpt.

Обычно все нужные модули, и для диска, и для таблицы разделов, и для ФС, включаются в образ при установке через grub-install автоматически. Явная загрузка таких модулей может потребоваться только в особых случаях, например если вы установили GRUB на один диск, а ядро на другой, и у них разные типы таблицы разделов и/или ФС, либо (был такой баг, не знаю, исправлен ли), GRUB устанавливали на образ, подключённый через loop-устройство, и потому таблица разделов не определилась автоматически.

P.S.
Загрузка в GRUB модулей диска, отличных от стандартного, работающего через BIOS либо EFI, не требуется, и более того, мне неизвестны случаи, когда их подключение приносило что-либо, кроме сбоев и невозможности чтения с диска. Такое извращение, как прямое чтение дисков в GRUB в обход BIOS/EFI, может понадобиться только на очень специфическом "железе", которое почему-то читается собственный драйвером груба лучше, чем прошивкой материнской платы.
Судя по скриншоту, у вас alsamixer (справа) почему-то не может определить настоящие размеры терминала.
К сожалению, я не могу воспроизвести этот глюк, у меня в "голом" (даже без настроек) XTerm размеры терминала определяются нормально, и alsamixer той же командой, что и у вас, запускается без проблем.

Выполните команду
xterm -hold -e 'stty size'
и вы увидите, что у вас читается вместо размеров терминала.
Выполните команду
xterm -hold -e env
и вы увидите все переменные окружения, которые получает программа, запущенная в xterm. Сравните результат с выводом команды env в баше, и поищите отличия.
Ошибка "no such device", выдаваемая ядром linux, означает, что оно не нашло указанного устройства.
Причина – не загружен модуль, либо такого устройства правда не обнаружено.

Если вы не убирали из mkinitcpio.conf хук base , после выдачи этой ошибки вы должны были попасть в аварийный шелл, который вполне позволяет проверить, какие у вас обнаружены дисковые устройства, например, той же командой blkid.

Если устройство таки обнаружено, вы его увидите.
Если нет – значит либо оно не определилось, либо у вас в initramfs нет модуля для него.

Так или иначе, при правильной установке возникновение такой ошибки практически невозможно.
grayich
но при этом не собирать пакет
А куда успел деться ранее собранный?
Насколько я понимаю, pacman никак не может установить пакет, не имея этого самого пакета.

Так что, если ранее установленный пакет был зачем-то похерен, то либо собирать, либо идём в /var/lib/pacman/local/ , меняем версию в имени каталога пкета и в файле desc внутри каталога.
Это значит, что ноут всё же выходит из ждущего режима, но зависает (по крайней мере, не запускается видеокарта) из-за какого-то сбоя.