После нескольких безуспешных часов мой коллега зашел и нашел две статьи(Как переключаться между графическими картами Intel и Nvidia в Ubuntu , Как выбрать встроенную графическую карту вместо NVIDIA? ), что очень помогло. В моем случае я сначала хотел выбраться из странной консоли, которая через какое-то время заглючила.
Оказалось, что графический адаптер Intel работал, но не тогда, когда я запускал систему в обычном режиме. Итак, я добрался до сломанного терминала и, прежде чем он успел выйти из строя, я сделал следующее:
mount -o rw,remount /
Это перемонтировало файловую систему как доступную для чтения/записи, чтобы я мог сохранить внесенные изменения.
startx
Невероятно, но это запускало X в корневом режиме с графическим адаптером Intel. Я думал, что смогу использовать тот же инструмент с графическим интерфейсом, чтобы переключить адаптеры обратно, но когда я попытался, я получил трассировку Python с сообщением об ошибке, в котором говорилось, что он не может найти dbus. Dbus был остановлен, и я не смог его запустить. Невозможно было переключиться на другой терминал с помощью Ctrl+Alt+F#
, сенсорная панель не работала (, но USB-мышь работала ), Cinnamon немедленно зависал, даже после того, как я попытался перезапустить его. Но у меня уже был базовый интерфейс, поэтому я мог открыть терминал GNOME для работы.
Последним шагом было выполнение следующей команды из упомянутой выше статьи:
prime-select nvidia
Это изменило некоторые символические ссылки и, возможно, отредактировал один или два файла конфигурации, и после следующего перезапуска я вернулся туда, где был до того, как попытался изменить графический процессор, используемый системой!
Извлеченный урок :Несмотря на значительные улучшения, произошедшие за последние пару лет, все еще есть тривиальные вещи, которые вы можете сделать с системой, чтобы сделать ее невозможной для загрузки. В следующий раз,Я не позволю установщику выбирать свою собственную файловую систему и выберу ту, которая поддерживает моментальные снимки, например btrfs
. Наличие моментального снимка предотвратит подобные проблемы.
Не существует переносимого, надежного, универсального метода извлечения оборудования. название модели в Linux. Позвольте мне описать 2 разных случая :ARM -на основе Raspberry Pi с установленным Raspbian и маршрутизатором TP -LINK на базе MIPS -с установленным OpenWRT.
Raspberry Pi имеет процессор ARM, а устройства ARM обычно используют устройство -дерево для описания оборудования и Статья в Википедии даже упоминает, что это обязательно с 2012 года . Древовидная структура устройства -доступен в пользовательском пространстве и может использоваться для получения имени модели с помощью cat
ing /proc/device-tree/model
где /proc/device-tree
само по себе является символической ссылкой на /sys/firmware/devicetree/base
вот так (обратите внимание, что есть нет новой строки в конце файлов дерева устройств -, поэтому мы создаем помощник функция с именем catn
, которая запускает файл и добавляет новую строку):
pi@raspberrypi:~$ catn () { cat $1 && echo; }
pi@raspberrypi:~$ catn /proc/device-tree/model
Raspberry Pi 3 Model B Rev 1.2
pi@raspberrypi:~$ catn /sys/firmware/devicetree/base/model
Raspberry Pi 3 Model B Rev 1.2
или путем ручного сброса /sys/firmware/fdt
плоского устройства -большого двоичного объекта дерева с кодом неисправности:
pi@raspberrypi:~$ sudo dtc /sys/firmware/fdt 2>/dev/null | grep model
compatible = "raspberrypi,3-model-b\0brcm,bcm2837";
model = "Raspberry Pi 3 Model B Rev 1.2";
Если используется официальный форк Raspberry Pi Linux, модель также написано в /proc/cpuinfo:
pi@raspberrypi:~$ grep "^Model" /proc/cpuinfo
Model : Raspberry Pi 3 Model B Rev 1.2
Также обратите внимание, что полное название платы-Raspberry Pi 3 Model B Rev 1.2
создано микропрограммой низкого уровня -и что вы не будете найти такую полную строку где-нибудь в коде ядра Linux:
pi@raspberrypi:~$ strings /boot/start.elf | grep 'Raspberry Pi '
Raspberry Pi %s Rev %s
Raspberry Pi Bootcode
model
— стандартное свойство дерева -устройства, описанное в DTSpec .
Другие архитектуры, такие как RISC -V, также используют дерево устройств для описания оборудование, но у меня нет платы RISC -V для проверки.
Нет ни дерева /proc/device -, ни /sys/firmware/devicetree/base, ни /sys/firmware/fdt на моем маршрутизаторе TP -LINK -означает, что он либо вообще не поставляется с деревом устройств -или каким-либо подходящим Linux параметры конфигурации ядра были отключены, а дерево устройств -не подвергается воздействию пользовательского пространства. Однако первое более вероятно, т. вместо него есть /tmp/sysinfo:
~ $ cat /tmp/sysinfo/board_name
tl-wdr4300
~ $ cat /tmp/sysinfo/model
TP-Link TL-WDR3600 v1
Эти значения генерируются ar71xx.sh сценарий что довольно длинно, но вы можете видеть, что name
присваивается в строке 1313:
*"TL-WDR3600/4300/4310")
name="tl-wdr4300"
;;
основано на TL-WDR4900 v2
, которое, в свою очередь, взято из поля machine
из /proc/cpuinfo:
machine=$(awk 'BEGIN{FS="[ \t]+:[ \t]"} /machine/ {print $2}' /proc/cpuinfo)
и затем присваивается AR71XX_BOARD_NAME
и записывается в /tmp/sysinfo/board_name
к концу скрипта.
Полное значение поля machine
в /proc/cpuinfo на этом маршрутизаторе равно:
~ $ grep "^machine" /proc/cpuinfo
machine : TP-LINK TL-WDR3600/4300/4310
Но Neofetch не ищет имя /tmp/sysinfo/board _, он ищет для /tmp/sysinfo/model. Он не берется из /proc/cpuinfo, а читается из флэш-раздел firmware
:
~ $ cat /proc/mtd
dev: size erasesize name
mtd0: 00020000 00010000 "u-boot"
mtd1: 0010c5a4 00010000 "kernel"
mtd2: 006c3a5c 00010000 "rootfs"
mtd3: 00490000 00010000 "rootfs_data"
mtd4: 00010000 00010000 "art"
mtd5: 007d0000 00010000 "firmware"
~ $ dd if=/dev/mtdblock5 bs=4 count=1 skip=16 2>/dev/null | hexdump -v -n 4 -e '1/1 "%02x"' && echo
36000001
Модель назначается в строке 321:
"360000"*)
model="TP-Link TL-WDR3600"
;;
Конечно, трудно представить, что универсальная программа, такая как Neofetch, было бы столько знаний о каждой прошивке, ее прошивке и т. д. Однако я мог представить реализацию на основе MIPS -, которая не поддерживает дерево устройств -и не предоставляет какой-либо полезной аппаратной модели. информация в /tmp/sysinfo и в любом другом месте и в таких случаях /proc/cpuinfo можно использовать как последнее средство для получения любой информации об оборудовании.
Чтение исходного кода Neofetch прояснило путаницу. Строка 1174 для Neofetch версии 7.0.0 имеет проверку условия :
.if [[ -d /system/app/ && -d /system/priv-app ]]; then
model="$(getprop ro.product.brand) $(getprop ro.product.model)"
elif [[ -f /sys/devices/virtual/dmi/id/product_name ||
-f /sys/devices/virtual/dmi/id/product_version ]]; then
model=$(< /sys/devices/virtual/dmi/id/product_name)
model+=" $(< /sys/devices/virtual/dmi/id/product_version)"
elif [[ -f /sys/firmware/devicetree/base/model ]]; then
model=$(< /sys/firmware/devicetree/base/model)
elif [[ -f /tmp/sysinfo/model ]]; then
model=$(< /tmp/sysinfo/model)
fi
На самом деле он проверяет различные пути, а не один путь, чтобы получить подробную информацию. Так что это не жесткая проверка, которая работает на каждом отдельном дистрибутиве GNU/Linux. Например, первое условие if проверяет конкретный путь, который можно найти на Android.
Я протестировал файлы на различных дистрибутивах и оборудовании:
Для всех моих систем /sys/devices/virtual/dmi/id/product_name
содержит информацию о модели.
В моем смартфоне Raspberry Pi 3 Model B и Android файл /sys/firmware/devicetree/base/model
содержит информацию о модели.
Debian работает в Virtualbox, Neofetch показывает Virtualbox 1.2
как хост, который можно найти по cat /sys/devices/virtual/dmi/id/product_name /sys/devices/virtual/dmi/id/product_version
.
Обратите внимание, что продукт _версия может быть просто символом новой строки, поэтому лучше удалить полосу (, полосу!в Ruby )завершающие символы новой строки после чтения файлов и объединения строк.
Так что может иметь смысл поставить все условия и проверить существующие файлы, а также прочитать файлы, чтобы получить информацию о модели.