512kb в debian.iso для загрузки по схеме MBR

У меня подозрение, что это удалит файл /dev/sdX и вместо него попытается скопировать файл, но места в deftmpfs не хватит.

Есть кто-нибудь, кому не лень проверить?

Наверное тут почитать стоит, если я правильно понял вопрос
https://habr.com/ru/companies/ruvds/articles/706070/

Ну что за глупости вы пишете? Записывать загрузочную флешку через dd это общая практика. dd еще более низкоуровенвый чем cp.

но места в deftmpfs не хватит.

Это просто копирование. То же самое если копировать данные с одного диска на другой. Файловая система в RAM тут ни каким боком не стоит.

Вопрос решен. Спасибо.

Ну что за глупости вы пишете? Записывать загрузочную флешку через dd это общая практика. dd еще более низкоуровенвый чем cp.

Я как раз про cp и говорю. Мне почему-то кажется что он удалит файл устройства и запишет обычный файл по тому же имени, если так сделать, но надо бы проверить.

dd-то конечно запишет данные на флешку, тут я уверен, а вот про cp не уверен.

Если идти от идеи «в linux всё файл», то вполне спокойно перезапишет, разве что такого блочного устройства не будет, тогда пойдёт тратить tmpfs раздела.

Не популярно, привычнее dd использовать.

У меня подозрение, что это удалит файл /dev/sdX и вместо него попытается скопировать файл

Странно, что там не cat debian.iso > /dev/sdX

А размонтировать перед копированием?

Хватит всем. Гейтс посрамлён

После cp не изменилась метка F698-C679, то есть или тут по второму кругу то же самое копировалось или не получилось.

И надо было размонтировать раздел прежде чем перезаписывать.

Более надёжно было бы выполнить команду:

ls -l /dev/sd*

Сразу видно было бы, остался /dev/sdc блочным устройством или был заменен на обычный файл.

копировалось или не получилось.

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

Посе cp метка раздела изменилась на DEB0-0001, предидущая метка F698-C679 была от GPT раздела, вероятно сохранилась в kernel так как файловую систему не размонтировали. После вынимания и вставления флешки и перезапуска X вот как отображается.

sdc                               iso9660     Joliet Extension Debian 12.5.0 amd64 1 2024-02-10-12-53-14-00                              
├─sdc1                            iso9660     Joliet Extension Debian 12.5.0 amd64 1 2024-02-10-12-53-14-00                     0   100% /run/media/lbvf50txt/Debian 12.5.0 amd64 1
└─sdc2                            vfat        FAT16                                  DEB0-0001     

Еще до начала записи у меня глючила система по не понянтым причинам, после записи я перезапустил X сервер и заново вставил флешку. В любом случае надо перезаписывать образ на i386.

Эксперемент показал, что cp переписывает iso файл, около 4GB за 13 минут.

Сейчас зашел через sudo -i, запустил lsblk и ls для /dev/sdc*.

[lbvf50txt ~]# lsblk
NAME                                          MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sdc                                             8:32   1  28,9G  0 disk  
├─sdc1                                          8:33   1   3,7G  0 part  /run/media/lbvf50txt/Debian 12.5.0 amd64 1
└─sdc2                                          8:34   1   9,3M  0 part  
sr0                                            11:0    1  1024M  0 rom   
[lbvf50txt ~]# ls -l /dev/sdc*
brw-rw---- 1 root disk 8, 32 сен 23 20:01 /dev/sdc
brw-rw---- 1 root disk 8, 33 сен 23 20:01 /dev/sdc1
brw-rw---- 1 root disk 8, 34 сен 23 20:01 /dev/sdc2

bootable раздел создается размером в 1мб.

Ну, видимо, cp тоже работает. Но dd лучше тем, что позволяет смотреть прогресс, особенно с status=progress или можно pv для прогресс-бара взять.

В общем суть там такова, что на компакт диске первый сектор 2048 байт не используется, поэтому если туда записать загрузочный код и таблицу разделов, то работоспособность загрузки по el-torito не портится. Так что ничего не мешает сделать образ загрузочный одновременно по четырём протоколам:

UEFI / flash, UEFI / cd, BIOS / flash, BIOS / cd.

Если есть желание, можно сделать загрузочную флешку и не через dd, а вручную, причём универсальную, и для BIOS и для UEFI, используя другую файловую систему вместо iso9660, что может быть полезно если есть желание добавлять/редактировать флешку после записи или одновременно использовать её и для переноса данных. хотя для второго можно просто создать ещё один раздел.

Cогласен: возможность отслеживать прогрес в dd большое подоспорье.

dd if=debian-xx.iso of=/dev/sdb bs=4M status=progress; 
sync;

Вчера пока 13 минут копировалось через cp отслеживал происходящие через:

cat /proc/diskstats | grep sdc

Считал как измениись показатели, идет ли чтение.

В данном применении, это аналоги. Не лучше и не хуже. Плохие в том аспекте, что после них придётся «восстанавливать» флешку к нормальному функционированию.

«восстанавливать» флешку к нормальному функционированию.

Да. Надо при помощи parted создать новую таблицу разделов. Потом эти разделы отоформатировать. Перед этим узнать как называется флешка через lsblk. В моем случае sdc.

lsblk 
sudo parted sdc
sudo umount /dev/sdX1
sudo mkfs.vfat -I /dev/sdc1

ВНИМАНИЕ ЧИТАЮЩИМ: при запуске parted необходимо указать устройство, parted sdX, инчае запуститься для sda и можно посносить разделы на основном винте.

В данном применении, это аналоги.

Т.е. cp копирует не файлы а блоки в данной ситуации? Где про этом можно почитать?

UPD: Логично что да, копируем файл в файл.

А где ты там увидел файлы?.. В обоих случаях, единственный файл *.iso. И пункт назначения одинаковый.

/dev это не файловая система, /sys это не файловая система, /proc это не файловая система.

sudo cp m_storage.img /dev/m_storage
cp: error writing '/dev/m_storage': No space left on device
sudo cp m_storage.img /sys/m_storage
cp: cannot create regular file '/sys/m_storage': Permission denied
sudo cp m_storage.img /proc/m_storage
cp: cannot create regular file '/proc/m_storage': No such file or directory

Ты когда в них пишешь, через VFS дергаются определенные функции в ядре.

Видимо это зависит от конкретного дистрибутива, уменя вот файлы в /dev вполне себе создаются. Написано devtmpfs в /proc/mounts.

/dev это не файловая система, /sys это не файловая система, /proc это не файловая система.

Да, /dev не файловая система что на диске опереляет файлы и каталоги, это интерфейсы к драйверам устройств позволяющие обращаться к ним через I/O ситемные вызовы. У Курячего c Маслинским в книге названо просто «файлы-дырки».

Хороший комментарий. Сейчас зашел еще раз перечитать про FHS. И запустил file /dev/sdc, получил отклик - блочное устройство.

Чем дальше гуглю, тем интересней.