Потому что в задаче явно указано «не использовать initramfs». Если бы я использовал initramfs, я бы вообще не создавал этот топик.

Во-первых, конкретно про корень я не говорил. Во-вторых, корень не всегда монтируется ядром. Например, ядро не может собрать определённые виды MD RAID, не может подключить dm-crypt, не может найти/активировать группы/тома LVM. Во всех этих случаях используется mount.

Не важно. udev так же юзерспэйсная штука и живет всяко где-то около

Кажись ведро умеет в uuid без удева. Смотрим сюда и видим, что через kernel_init_freeable() мы в конце концов попадаем в name_to_dev_t(), которое через devt_from_partuuid(name) помогает ядру смонтировать корень по uuid. А дальше читаются модули и запускаются init'ы. Т.е. я теперь не понимаю почему оно не должно работать.

корень монтируется ядром а не mount

А при загрузке с mdadm, cryptsetup, lvm2, NFS, ftp… корень тоже ядром монтируется?

И если что я не спорю с этим а лишь намекаю на то что скорее всего не всё так просто и, к примеру, может потребоваться всё тот же mdev/udev который есть в юзерспэйсе но никак не в ядре.

partuuid != fsuuid

кстати

дополнительно обрабатывает mount. Если ты запишешь «/dev/disk/by-label/ROOT», то это будет не совсем то же, что «LABEL=ROOT

# strace mount LABEL=ROOT |& grep by-label
stat("/dev/disk/by-label/ROOT", 0x7fff4e40e4b0) = -1 ENOENT (No such file or directory)
stat("/dev/disk/by-label/ROOT", 0x7fff4e40e4b0) = -1 ENOENT (No such file or directory)

мм?

Кажись ведро умеет в uuid без удева.

Если это действительно так то как минимум информация во многих источниках очень сильно устарела и нуждается в серьезных корректировках. К примеру и когда оно редактировалось последний раз там тоже можно посмотреть

Угу, затупил не по детски. Но таки вот все что ядро умеет без initramfs - https://github.com/torvalds/linux/blob/master/init/do_mounts.c#L183.

Сыплю пепел голова не uuid а partuuid.

Придётся самому дописывать поддержку других способов загрузки. Или всё-таки создать таблицу разделов.

А при загрузке с ... NFS

да, ядром

Сыплю пепел голова не uuid а partuuid.

Я ж говорю не все так просто…

да, ядром

А сеть у тебя тоже само ядро будет подымать? Даже если это wifi/wpa_suplificant/dhcp? Ню ню…

Да, тут я глупость сморозил.

А сеть у тебя тоже само ядро будет подымать?

CONFIG_IP_PNP

но сейчас ты сморозишь что нибудь вроде загрузки через 3g свисток

CONFIG_IP_PNP

И это всё конечно замечательно… Но и примеров когда тебе это ничем не поможет тоже предостаточно. Потому что даже сейчас ты намерено игнорируешь mdadm, cryptsetup, lvm2 тыкая в меня NFS-ом.

ты допускаешь ошибки в аргументации, я просто поправляю

ты допускаешь ошибки в аргументации, я просто поправляю

А ты намерено игнорируешь то что тебя не устраивает хотя прекрасно понимаешь о чем я говорю.

игнорирую что хочу, я же не отстаиваю какую-то позицию, лол

игнорирую что хочу, я же не отстаиваю какую-то позицию, лол

Отсутствие позиции это тоже позиция. ЛОЛ1111ОДИНОДИН

ты куришь отсутствие сигар и умрёшь от отсутствия рака лёгких

кто-то, давным давно дурью маялся.

Вся разработка ядра с этого пошла :-) А эта штука называлась kHTTPd и была в 2.3/2.4 ядрах. То есть сначала засунули, а потом выкинули.

И никогда не знаешь, что в ядре будет, а что посчитаю избыточным. Когда-то initrd не было, и монтирование корня было только через /dev/hda?, зато md-raid с суперблоком 0.9 ядро собирало само. Потом добавили initrd, зато в ядро не стали делать автосборку mdraid версии 1.x. А потом добавили, что ядро может монтировать по идинтификатору раздела PARTUUID, хотя, initrd и с этим мог справиться.

господин иисусе, а раньше то оно как грузилось?

я и хочу узнать, почему задача так стоит? из какого практического ограничения в вашем случае вытекает это?

CONFIG_BLK_DEV_INITRD увеличит размер ядра и время загрузки. Не нужно.

Ох ты ж ёлки-палки. У тебя счёт на десятки килобайт?

У меня даже таблицы разделов нет.

Ты упоротый. Тебе говорят: можно показать ядру на корень через встроенную командную строку. Ты в ответ с умным видом начинаешь нести что-то про случаи, когда это не сработает. К чему ты вообще начал про NFS, mdadm и прочее? К тому, что _случается_, что без initrd никак? Ну, будем откровенны, ты прямо-таки нашёл чем удивить. ТС просил без initram, а ты всё своё заладил.

Это может быть никак не связано с ограничениями на размер ядра. У тебя там суровый эмбеддед, или ты так развлекаешься?

Развлекаюсь. Суровый эмбеддед запорол.

Ты упоротый.

Упорот я или нет это не отменяет того что с initrd/initramfs такой проблемы как у ТС вообще не существует. Весь объем initrd/initramfs компенсируется во первых его сжатием во вторых банально исключением ненужного из ядра. К тому же алгоритм и степень сжатия тоже можно подобрать так что и читать будет быстро и сжато будет достаточно.

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

«Счет на килобайты»? Да во всех эмбеддет системах на основе linux счет на килобайты и все они используют initrd/initramfs для своей работы.

Да во всех эмбеддет системах на основе linux счет на килобайты и все они используют initrd/initramfs для своей работы.

4.2

""

4.2

Факты конкретные конечно же есть?

Мало того «на килобайты»? Реально? Да в любых сраных современных поделиях счет уже другими величинами.

И это не говоря о том, что поднять initrd/initramfs проще и быстрее чем подымать дальше корень с чего бы то ни было и кроме того туда же пакуется собственно то ради чего и делается эмбеддет система. Так что тебе 4.2.

Я, похоже, не в теме. Оно ж уже хрен-те сколько лет монтируется либо по UUID, либо по метке...

Читай тред. Монтирует скрипт в iniramfs, а ядро умеет только по PARTUUID.

shit, не могу проверить: у меня хоть ведро и без initrd, но на всякий пожарный я написал:

cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-3.12.21-gentoo-r1 root=/dev/sda1 rw vt.default_utf8=0

Раньше-то я сидел в говне, поэтому не парился (initrd во всех убогих дистрах есть).

Но можно попробовать будет как-нить.

А при загрузке с mdadm, cryptsetup, lvm2, NFS, ftp… корень тоже ядром монтируется?

Как раз с NFS - вполне монтирует (ещё от царя Гороха).

А корень по ftp://FTP... оригинально:)

Придётся самому дописывать поддержку других способов загрузки.

До 1-го сентября не успеешь.

А сеть у тебя тоже само ядро будет подымать? Даже если это wifi/wpa_suplificant/dhcp?

Да, малыш, и dhcp - тоже. Иди читай букварь, ламо.

CONFIG_BLK_DEV_INITRD увеличит размер ядра и время загрузки.

Идиот.

Я, похоже, не в теме.

Ты ламер - тебе простительно.

Уж кто б вякал…

Обиделсо, малыш?:)

синхронно и однопоточно

vt.default_utf8=0

ох болезный, и сюда добрался

Придётся самому дописывать поддержку других способов загрузки.

Ты если серьезно, покажешь? Немного поковырялся, получается однако, интересно. Все способы загрузки в которые умеет ядро используют описатели сущности «блочное устройство» - ядро находит устройство с которого оно будет хотеть грузится и затем пробует монтировать его, перебирая файловые системы, которые оно умеет. А в твоей хотелке надо идти с другой стороны - перебрать ВСЕ блочные устройства, найте ВСЕ ВОЗМОЖНЫЕ суперблоки и сравнить uuid из них с искомым. Такая проблема курицы и яйца, интересно как удев делает /dev/disk/by-uuid/.

на UEFI приводит к тому что нет того через что можно передавать параметры загрузки и в этом случае встроенная командная строка единственный выход

бредятина полная, все можно передавать. man efibootmgr

Есть нативная поддержка PARTUUID:

root=PARTUUID=...

Значение PARTUUID можешь посмотреть в выводе

blkid