Как узнать тип файловой системы раздела без системных утилит?

Масса полезной информации находится в /sys/block/diskname

А как вы ее оттуда берете? Без утилит?

в заголовке файловой системы который находится в её начале :)
система тоже читает этот заголовок при инициализации файловой системы и распознанные данные запихивается в соотвествующие файлы /dev /sys …

file -s /dev/sda1

в заголовке файловой системы который находится в её начале :) система тоже читает этот заголовок при инициализации файловой системы и распознанные данные запихивается в соотвествующие файлы /dev /sys …

Сначала, как я понимаю, в /sys, потом уже в /dev И для того что бы в Linux определить тип файловой системы, так же UUID, PARTID не обязательно читать сам диск. Эта информация должна быть где-то в /sys или /proc

Кроме того. df, lsblk выдают информацию без root привилегий, а обратится напрямую, нпример, к /dev/sda из под юзверя не выйдет

У тебя походу причина и следствие перепутаны

У тебя походу причина и следствие перепутаны

lsblk -n -o 'rm' /dev/sda > /sys/block/sda/removable

:)

man 2 statfs

(это системный вызов если что)

информация в системным разделах /dev /sys появляется после того, как раздел смонтирован в систему.
/dev и /sys это просто метод доступа к внутренним данным ядра системы.

как вариант взять исходники утилит и глянуть чего откель они берут.

ты лучше прямо скажи что тебе надобно ?? а то ходить обходными путями можно долго

информация в системным разделах /dev /sys появляется после того, как раздел смонтирован в систему.

Что ты имеешь в виду под «смонтирован в систему»? У меня, в данный момент не смонтирован ни один из разделов /dev/vdb в системе, однако…

ls /sys/block/vdb/ -lah
итого 0
drwxr-xr-x 14 root root    0 мая  3 10:43 .
drwxr-xr-x  3 root root    0 мая  3 10:43 ..
-r--r--r--  1 root root 4,0K мая  3 10:45 alignment_offset
lrwxrwxrwx  1 root root    0 мая  3 12:58 bdi -> ../../../../../../virtual/bdi/254:16
-rw-r--r--  1 root root 4,0K мая  3 12:58 cache_type
-r--r--r--  1 root root 4,0K мая  3 12:58 capability
-r--r--r--  1 root root 4,0K мая  3 10:43 dev
lrwxrwxrwx  1 root root    0 мая  3 10:45 device -> ../../../virtio8
-r--r--r--  1 root root 4,0K мая  3 10:45 discard_alignment
-r--r--r--  1 root root 4,0K мая  3 12:58 events
-r--r--r--  1 root root 4,0K мая  3 12:58 events_async
-rw-r--r--  1 root root 4,0K мая  3 12:58 events_poll_msecs
-r--r--r--  1 root root 4,0K мая  3 12:58 ext_range
-r--r--r--  1 root root 4,0K мая  3 10:45 hidden
drwxr-xr-x  2 root root    0 мая  3 10:45 holders
-r--r--r--  1 root root 4,0K мая  3 12:58 inflight
drwxr-xr-x  2 root root    0 мая  3 12:10 integrity
drwxr-xr-x  4 root root    0 мая  3 12:10 mq
drwxr-xr-x  2 root root    0 мая  3 12:10 power
drwxr-xr-x  2 root root    0 мая  3 10:45 queue
-r--r--r--  1 root root 4,0K мая  3 12:58 range
-r--r--r--  1 root root 4,0K мая  3 10:45 removable
-r--r--r--  1 root root 4,0K мая  3 10:45 ro
-r--r--r--  1 root root 4,0K мая  3 10:43 serial
-r--r--r--  1 root root 4,0K мая  3 10:45 size
drwxr-xr-x  2 root root    0 мая  3 10:45 slaves
-r--r--r--  1 root root 4,0K мая  3 12:58 stat
lrwxrwxrwx  1 root root    0 мая  3 10:43 subsystem -> ../../../../../../../class/block
drwxr-xr-x  2 root root    0 мая  3 12:10 trace
-rw-r--r--  1 root root 4,0K мая  3 10:43 uevent
drwxr-xr-x  5 root root    0 мая  3 12:53 vdb1
drwxr-xr-x  5 root root    0 мая  3 12:53 vdb2
drwxr-xr-x  5 root root    0 мая  3 12:53 vdb3
drwxr-xr-x  5 root root    0 мая  3 12:53 vdb4
drwxr-xr-x  5 root root    0 мая  3 12:53 vdb5

ты лучше прямо скажи что тебе надобно ?? а то ходить обходными путями можно долго

Да, вроде, я сказал. Хочу узнать откуда всякие там lsblk, blkid & etc… берут информацию о файловой системе несмонтированного раздела, ее UUID и прочую инфу

Если бы ты хотел это узнать, ты просто посмотрел бы в исходники.

Если бы ты хотел это узнать, ты просто посмотрел бы в исходники.

Исходники данных утилит?

Тебе не приходило в голову, что разбирать их код занятие, мягко говоря, длительное.

Я думал, что проще получить информацию, спросив.

В редких случаях, когда вопрошающий совсем уж тупит в элементарных вещах, можно в сердцах бросить: «RTFM», однако это не является хорошим тоном. Если не чего ответить по существу, или нет желания писать большую «простыню» ответа, то лучше пройти мимо.

Очевидно при загрузке системы все эти данные считываются и рассовываются по полочкам.

Не будет проще посмотреть /etc/mtab?

Очевидно при загрузке системы все эти данные считываются и рассовываются по полочкам.

Вооот! Я тоже так думаю. Большую часть информации можно найти в /sys, но вот информацию, касательную файловой системы несмонтированных разделов, я не нашел.

Если не чего ответить по существу, или нет желания писать большую «простыню» ответа, то лучше пройти мимо.

исходники ядра. оно само делает init при загрузке/hotplug и филлит /dev /sys.
начни с usb-стека, например. или в job.

Не будет проще посмотреть /etc/mtab?

Не проще.

В /etc/mtab есть информация лишь о смонтированных разделах, а не о всех доступных.

lsblk выдает интересующую информацию о блочных устройствах, при этом не требует root прав. Следовательно ни чего он не монтирует и не читает устройство напрямую, типа: cat /dev/vdb :)

Большую часть информации можно найти в /sys, но вот информацию, касательную файловой системы несмонтированных разделов, я не нашел.

Потому что файловая система - то, что внутри блочного устройства. Пока оно не смонтировано, система про него ничего не знает.

А ты возможно вообще путаешь с какими-нибудь метками блочных устройств? Так вот они - тоже не про файловую систему.

Следовательно ни чего он не монтирует и не читает устройство напрямую, типа: cat /dev/vdb :)

The lsblk command reads the sysfs filesystem and udev db to gather information.

Потому что файловая система - то, что внутри блочного устройства. Пока оно не смонтировано, система про него ничего не знает.

А ты возможно вообще путаешь с какими-нибудь метками блочных устройств? Так вот они - тоже не про файловую систему.

Блин…

Посмотрите lsblk. Эта утилита, в том числе, выдает информацию о НЕСМОНТИРОВАННЫХ блочных устройствах!

Мало того…

lsblk -o path,size,label,fstype,uuid /dev/vdb2
PATH      SIZE LABEL FSTYPE UUID
/dev/vdb2   2G BOOT  ext4   ef87b9e7-a14b-4d27-ab7a-59aa4069c2d3

mkfs.vfat -n HZ /dev/vdb2
mkfs.fat 4.2 (2021-01-31)

lsblk -o path,size,label,fstype,uuid /dev/vdb2
PATH      SIZE LABEL FSTYPE UUID
/dev/vdb2   2G HZ    vfat   D395-1386

Все вызовы подряд. Между ними ни каких дополнительных команд не было.

The lsblk command reads the sysfs filesystem and udev db to gather information.

Воот!

Спасибо!

Недостающую информацию можно нарыть в /run/udev/data/

Например:

cat /sys/block/vdb/vdb1/dev
254:17

cat /run/udev/data/b254:17
S:disk/by-partuuid/f58a4da7-5bd7-7947-bd98-0279f346a826
S:disk/by-path/virtio-pci-0000:09:00.0-part1
S:disk/by-label/EFI
S:disk/by-uuid/F0EB-8CD6
S:disk/by-path/pci-0000:09:00.0-part1
W:281
I:7761055427
E:ID_PATH=pci-0000:09:00.0
E:ID_PATH_TAG=pci-0000_09_00_0
E:ID_PART_TABLE_UUID=aa558219-071b-d84b-aeee-9bf960bd90bc
E:ID_PART_TABLE_TYPE=gpt
E:ID_FS_LABEL=EFI
E:ID_FS_LABEL_ENC=EFI
E:ID_FS_UUID=F0EB-8CD6
E:ID_FS_UUID_ENC=F0EB-8CD6
E:ID_FS_VERSION=FAT32
E:ID_FS_TYPE=vfat
E:ID_FS_USAGE=filesystem
E:ID_PART_ENTRY_SCHEME=gpt
E:ID_PART_ENTRY_UUID=f58a4da7-5bd7-7947-bd98-0279f346a826
E:ID_PART_ENTRY_TYPE=c12a7328-f81f-11d2-ba4b-00a0c93ec93b
E:ID_PART_ENTRY_NUMBER=1
E:ID_PART_ENTRY_OFFSET=2048
E:ID_PART_ENTRY_SIZE=1048576
E:ID_PART_ENTRY_DISK=254:16
G:systemd
Q:systemd
V:1

Тебе не приходило в голову, что разбирать их код занятие, мягко говоря, длительное.

У тупых или ленивых некомпетентых людей - несомненно. Но они обычно такими вопросами и не задаются.

В редких случаях, когда вопрошающий совсем уж тупит в элементарных вещах, можно в сердцах бросить: «RTFM»

Ты и есть тот самый (совсем не редкий) случай. Тебе был нужен именно RTFM, потому что у тебя ушли сутки на то, чтобы дождаться здесь цитаты с буквально вторым по счету предложением из man blkid. Ты ведь смог бы сам прочитать два предложения из мана за сутки, м?

Иногда проще посмотреть результат strace, чем исходники...

Иногда прочитать исходники проще, чем вкурить man (и выхлоп) strace.

Посмотрите lsblk. Эта утилита, в том числе, выдает информацию о НЕСМОНТИРОВАННЫХ блочных устройствах!

Верно, но никаких сисколлов кроме чтения файлов из /proc/filesystems, /sys/dev и /sys/block оно не делает.

есть масса утилит, которые возвращают fstype, но они же эту информацию от куда-то берут!

Безусловно.
Почитайте как организованы разделы и далее продвинутым шестнадцатеричным редактором
посмотрите (если вы программист, то можно и код на коленке написать).

Она у вас с поддержкой udev собрана?

Масса полезной информации находится в

например?

То есть читать с диска тебе нельзя, а новую ФС накатить можно? Что-то ты недоговариваешь, мне кажется.

вполне возможно что udev при монтировании блочного устройства прочитывает его начало и записывает в параметрах ядра «есть ли там чё», такая информация как минимум не помешает.
надо смотреть исходники udev