embeded + fstab

LABEL не подходит?

Хмм, об этом как-то не подумал. Надо попробовать. Спасибо за идею

Предлагаю монтировать по LABEL.

$ cat /boot/grub/grub.cfg
...
    linux /boot/vmlinuz-6.1.0-21-amd64 \
        root=/dev/disk/by-label/system20221008 \
...

$ cat /etc/fstab
LABEL=system20221008	/	auto	defaults	0 0

LABEL назначается на файловую систему. Для ext4 утилитой e2label.

Не понял фразу про разные uuid. Если rootfs один то и uuid у него везде одинаковый. Он не в таблице разделов записан, это свойство файловой системы. То что в таблице разделов называется partuuid (и он только если таблица gpt).

На разных устройствах (физически) один и тот же логический диск (например /dev/mmcblk1p2) имеют разные UUID. Соответственно, если я с этой же rootfs, в которой в fstab прописаны UUID дисков начну грузится на другой железке, то в силу отличающихся UUID получу ровно ничего.

Какие-то странные формулировки. Да, у одного и того же логического диска могут быть разные UUID - потому что под этим логическим названием могут оказаться разные устройства. Но если ты будешь втыкать один и тот же физический диск в разные компы, то, под каким бы номером в /dev/ он ни оказался - UUID-ы будут одни и те же. И если ты раздел с файловой системой с него склонируешь с помощью dd - то UUID у клона тоже будет такой же.

А, я кажется понял, речь не про монтирование rootfs, а про остальные разделы, которые уже отличаются. Ну тогда label остаётся, да. UUID-ы технически одинаковыми конечно можно сделать но это наверно неправильно будет для реально разных файловых систем.

Для ext2 взлетело, а вот фат оказался покрепче. Встроенный в бизибокс mkfs.vfat имеет ключ для метки, но blkid эту метку не видит. Причем метку vfat с раздела на sd нормально видит. Похоже надо еще бизибокс хачить и патчить.

Мдя, как хорошо, что погрепал git busybox-а. в 1.35.1 исправили баг с label для vfat. Обновился и сразу все заколосилось как надо.

Всем спасибо, все свободны.

Я остановился на том что меняю порядок контроллеров mmc в u-boot (патчу dtb) в зависимости от того откуда загружаюсь.

Мне кажется метки у разделов – это от лукавого. Оно не сломается если после раскатки на eMMC воткнуть SD с теми же лейблами (UUID, или что там ещё может уникально идентифицировать раздел, но на самом деле не уникально)?

Можно ещё посмотреть в сторону /dev/disk/by-*

Например, использовать by-path или by-id, тогда не важно, будет это mmcblk0 или mmcblk1, устройство будет определяться по физическому подключению.

LABEL — норм вариант, но by-path иногда стабильнее именно для таких случаев с eMMC + SD.

Можно ещё посмотреть в сторону /dev/disk/by-*

У меня нет /dev/disk/by-* Используется полностью самосборная минималистичная система. Образ rootfs целиком ~40-47MB (но хотелось бы подсушить до 30-35), поэтому важно не тянуть лишних зависимостей.

порядок контроллеров mmc в u-boot (патчу dtb)

Зайтеливо. А можно глянуть как меняете порядок контроллеров в dtb?

воткнуть SD с теми же лейблами

Сломается наверно. Но меня спасает, то что источник загрузочных SD я сам и никто кроме меня не будет там метки расставлять. Метки я тоже сам придумываю. Так что вероятность того, что всё сломают исчезающе мала. С другой стороны даже если воткнут такую флешку, в целом никакого ущерба не будет. Исчезнут персистентные настройки, останутся дефолтные, флешку выдернут и все вернется взад.

Оверлей:

/dts-v1/;
/plugin/;

/ {
	fragment@0 {
		target-path = "/aliases";
		__overlay__ {
			mmc0 = "/mmc@fe2b0000";
			mmc1 = "/mmc@fe310000";
		};
	};
};

Кусок в *-u-boot.dtsi:

&fit {
	images {
		fdt-dto-<как-там-тебя-зовут>-overlay-sd-boot {
			description = "какой-нибудь дескрипшн";
			type = "flat_dt";
			compression = "none";

			blob-ext {
				filename = "<имя-файла-с-оверлеем.dtbo>";
			};

#ifdef CONFIG_SPL_FIT_SIGNATURE
			hash {
				algo = "sha256";
			};
#endif
		};
	};

	configurations {
		default = "@config-DEFAULT-SEQ";

		@config-SEQ {
			fdt = "fdt-1",
			      "fdt-dto-<как-там-тебя-зовут>-overlay-sd-boot";
		};
	};
};

Применялка в файле с бордой:

#if CONFIG_IS_ENABLED(LOAD_FIT_APPLY_OVERLAY)
int board_spl_fit_append_fdt_skip(const char *name)
{
	u32 bootdevice_brom_id;

	/* Make SD primary device if we've booted from SD */
	bootdevice_brom_id = readl(BROM_BOOTSOURCE_ID_ADDR);

	if (bootdevice_brom_id == BROM_BOOTSOURCE_SD) {
		if (!strcmp(name, "fdt-dto-<как-там-тебя-зовут>-overlay-sd-boot"))
			return 0;
	}

	return 1;	/* Skip this DTO */
}
#endif

Рокчип, так что BROM_BOOTSOURCE_ID_ADDR – это специфичное для рокчипа.

То есть просто в алиасах меняете имя ссылки на устройство?

Ну да. Работает стабильно. Ядро дополнительно не патчил.

А с eth так сработает? А то на шильдике нарисовали обратную нумерацию.

По идее должно. Сам, честно говоря, не пробовал.

Вообще, не зря же эти алиасы придумали…

Никогда бы не подумал, что энумирация устройств идет по порядку имен в алиасах. Спасибо за идеи, мы ими конечно не воспользуемся )))

Можно с помощью udev сделать так, чтобы rootfs всегда лежала на одной и той же железке.

Можно с

Как было уже понято чуть выше, проблема совсем не rootfs, а остальных дисковых устройствах.

1. PARTUUID, LABEL на разделах
2. Задать определённые фиксированные названия устройствам в DTB, как написал @com (не /dev/sdX, а /dev/microsdX, /dev/emmcX)
3. Задать определённые фиксированные названия устройствам в правилах udev (не /dev/sdX, а /dev/microsdX, /dev/emmcX)
4. Использовать systemd-gpt-auto-generator и различные аналоги, предоставляемые системами обновлений embedded’а (swupdate, rauc)
5. Использовать World Wide Name