Ну во-первых, я не виноват, что в настройках неправильно пишут :)
  • dpi — dot-per-inch — это про печать
  • ppi — pixel-per-inch — про экраны

А во-вторых, дело же не в этом. А в том что Gnome не запускается, а мне он нужен, а не Cinnamon :(
Про ppi я упомянул лишь к тому, чтобы указать, что настройки, работающие в gdm при работающем gnome-shell, теперь тоже не действуют.
Я не красноглазик, я фаерфоксик ^_^
После прилетевшего вчера (24.04.2017) обновления всего гнома этот самый гном сломался. Судя по тому, что ещё нет тем об этом, наверно сломалось только у меня (не представляю, что мог такого сделать для этого).

Симптомы:
  1. в любом режиме (обычный, классический, через иксы) переход в DE приводит к чёрному экрану
  2. gdm работает, но отвалилась настройка ppi (у меня 192) и сейчас на экране входа всё стало мелким
  3. Cinnamon работает нормально.
Это всё мне подсказывает (но я в гноме пока дуб-дубом, пару месяцев назад с кед пересел), что сломался именно gnome-shell со всеми его настройками (в том числе ppi).
При обновлении не было ошибок, было только одно предупреждение:
(1/1) переустановка networkmanager                 [######################] 100%
предупреждение: права доступа различаются у каталога /etc/NetworkManager/system-connections/
файловая система: 755  пакет: 700
Но сильно сомневаюсь, что networkmanager мог до такого довести.

Вопросы:
  • Куда копать?
  • Что ковырять?
  • Что ещё предоставить?
Я не красноглазик, я фаерфоксик ^_^
indeviral, ох спасибо!
Я не красноглазик, я фаерфоксик ^_^
А я один, обновился незаметив ничего, и только месяц спустя в rss-ленте добрался до этой новости? :)
Я не красноглазик, я фаерфоксик ^_^
Спасибо, поковыряю и в эту сторону
Я не красноглазик, я фаерфоксик ^_^
Обязательно знать C и C++? Там же вроде написано просто скомпилировать.

Разработчик не забивает. Он сделал как для его софта удобно. В Эпле не расчитывают на то, что будут другие оси ставить. Даже странно, что у них такая хрень завелась как BootCamp (для удобной установки винды).

Ладно, буду ковырять компиляторы.
Я не красноглазик, я фаерфоксик ^_^
Вторая проблема — это не работающий регулятор подсветки экрана. Показывается регулировка (от плазмы), в настройках (уже не помню где, что-то совсем низкоуровеневое смотрел) значения меняются, но изменений никаких вплоть до нулевого значения — при нуле подсветка из яркой сразу в ноль вырубается. Ставил xbacklight, и менял через
xbacklight -set 50
То же самое — значение меняется, но экран продолжает выжигать глаза.
Дальше я пока решил эту проблему не ковырять, ибо что-то мне подсказывает, что она может быть связана с невырубленой невидией. Надо сначала с ней разобраться, вырубить окончательно, потом уже (может даже в другой теме) подсветку поковыряем, если само не решится.
Я не красноглазик, я фаерфоксик ^_^
Снова здравствуйте! Продолжение эпопеи.

Я таки переустановил всё с нуля. И теперь всё правильно примонтировано и установлено. И даже теперь графика работает через Intel. Но остались некоторые проблемы с nVidia. Долго пытался сам понять что делать, но не смог. Сам смог победить сумасшедшего kworker (он разгонял одно из ядер проца до 100%).

Дело в том, что даже при работе графики через Intel, nVidia не отключается от питания, и продолжает жрать энергию и греться (уже не так жутко, как в тот раз, но всё равно — до первой гифки в браузере, которая становится последней каплей и кулеры врубаются).
Next, gpu-switch will not completely power down the dedicated card. To do that, you will have to create a custom grub menuentry and compile a program that will power off the dedicated card.
To do that, please refer to the following article, MacBookPro10,x#Graphics_2.
Далее по ссылке, как я понял мне нужно скомпилировать этот код:
#include <stdio.h>
#include <sys/io.h>

#define GMUX_PORT_SWITCH_DISPLAY	0x10
#define GMUX_PORT_SWITCH_DDC		0x28
#define GMUX_PORT_SWITCH_EXTERNAL	0x40
#define GMUX_PORT_DISCRETE_POWER	0x50
#define GMUX_PORT_VALUE			0xc2
#define GMUX_PORT_READ			0xd0
#define GMUX_PORT_WRITE			0xd4

#define GMUX_IOSTART		0x700

typedef unsigned char u8;

enum discrete_state {STATE_ON, STATE_OFF};
enum gpu_id {IGD, DIS};

static void index_write8(int port, u8 val)
{
	outb(val, GMUX_IOSTART + GMUX_PORT_VALUE);
	outb((port & 0xff), GMUX_IOSTART + GMUX_PORT_WRITE);
}

static u8 index_read8(int port)
{
	u8 val;
	outb((port & 0xff), GMUX_IOSTART + GMUX_PORT_READ);
	val = inb(GMUX_IOSTART + GMUX_PORT_VALUE);

	return val;
}

static void set_discrete_state(enum discrete_state state)
{
	if (state == STATE_ON) {	// switch on dGPU
		index_write8(GMUX_PORT_DISCRETE_POWER, 1);
		index_write8(GMUX_PORT_DISCRETE_POWER, 3);
	} else {			// switch off dGPU
		index_write8(GMUX_PORT_DISCRETE_POWER, 1);
		index_write8(GMUX_PORT_DISCRETE_POWER, 0);
	}
}

static u8 get_discrete_state()
{
	return index_read8(GMUX_PORT_DISCRETE_POWER);
}

static void switchto(enum gpu_id id)
{
	if (id == IGD) {	// switch to iGPU
		index_write8(GMUX_PORT_SWITCH_DDC, 1);
		index_write8(GMUX_PORT_SWITCH_DISPLAY, 2);
		index_write8(GMUX_PORT_SWITCH_EXTERNAL, 2);
	} else {		// switch to dGPU
		index_write8(GMUX_PORT_SWITCH_DDC, 2);
		index_write8(GMUX_PORT_SWITCH_DISPLAY, 3);
		index_write8(GMUX_PORT_SWITCH_EXTERNAL, 3);
	}
}

int main(int argc, char **argv)
{
	if (iopl(3) < 0) {
		perror("No IO permissions");
		return 1;
	}

	//switchto(IGD);
	set_discrete_state(STATE_OFF);
	//printf("Discrete state: 0x%X\n", get_discrete_state());

	return 0;
}
Вот с этим засада, ибо до этого компиляцию видел только из далека, в смысле через йогурт, где уже всё в PKGBUILD настроено. Несколько раз сморел в сторону ABS (правда давно) — так и не вкурил, как с ним подружиться.

Может что подскажете, куда копать, что изучить? Или может готовое что есть?
Я не красноглазик, я фаерфоксик ^_^
Загрузка через rEFInd. Я не умею Grub патчить. Если бы не эта проблема с дискреткой, вообще бы не парился, использовал бы systemd-загрузчик.
Я не красноглазик, я фаерфоксик ^_^
Ага, уже руки чешутся, вот только бекап Арча делать не хочу.

Но всё-таки, куда же надо монтировать efi-раздел? В этом случае в примере /boot. А в следующем — в /boot/efi. Ведь от этого зависит, в какой директории окажутся изначальные файлы efi-раздела, и наоборот — в какую директорию изначального efi-раздела будут прописываться файлы новой оси при его монтировании. Как это может зависить от того, будет ли арч единственной осью или нет?

Тот вопрос интересен, но в данной ситуации не критичен. А критичен следующий:
Куда мне его монтировать (при установке арча, то есть с учётом /mnt) этот раздел, если макось должна остаться и отдельного раздела для /boot в арче я не хочу?
Я не красноглазик, я фаерфоксик ^_^