Pull to refresh

Comments 22

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

Не совсем понятно в чем разочарование. Было у меня две флешки : одна 8 Гб с рабочей системой, другая чуть меньше оказалась и решил задействовать её для экспериментов над системой.. Ну как бы урезал раздел за счёт незанятого пространства и, с помощью dd , скопировал с большей на меньшую. Я в этом слабо разбираюсь, может и есть какая-то фатальная кривость в том , что я сделал. Но малина работает 24/7 уже дней 10.

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

sudo лишнее. Готовить образ можно и с правами обычного пользователя (dd, sfdisk, genext2fs/debugfs, для fat32/cramfs/squashfs тоже есть утилиты не требующие root). Зачем? Ну например если захочется завернуть это всё в CI/CD.

root/sudo необходимо только при записи образа на карту.

Возможно. Тут я ориентировался на свою систему. То есть у меня в Debian, например, dmesg без sudo не работает. А в Ubuntu, dmesg работает прекрасно для обычного пользователя. Тут уж все индивидуально.) Хотя, конечно, мне нравится идея, чтобы это мог делать обычный пользователь, и возможность завернуть в CI/CD, хотя в этом я пока профан. :-) Не все устройства и не всегда добираются до конвеера, не говоря уже про крупную серию, где это, думаю, это было бы оправдано.

Тут я ориентировался на свою систему. То есть у меня в Debian, например, dmesg без sudo не работает. А в Ubuntu, dmesg работает прекрасно для обычного пользователя

честно говоря, похоже, вы просто не понимаете что делаете.
dmesg требует sudo потому что читает данные из буфера ядра, и по умолчанию ядро не отдаёт непривилегированным приложениям содержимое этого буфера.


если разработчики дистрибутива считают, что непривилегированным пользователям нужен доступ в dmesg, то, как вы уже знаете, это реально.
можно сменить настройки ядра:
https://unix.stackexchange.com/questions/401623/dmesg-with-without-sudo-on-debian-mint
или можно навесить на бинарник dmesg suid.


только какое это всё имеет отношение к созданию файла для образа? создавать файл может обычный пользователь.


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

Я прекрасно понимаю, что все зависит от настроек системы, просто не стал вдаваться в детали, каких и для чего. Зачем?

Я как администратор своей системы волен ограничить использование чего угодно в ней, как и доступ к чему угодно, ради безопастности. Так или нет?

Я как раз предпочитаю использовать sudo, а не сидеть под рутом. Так как мне часто приходилось писать разные инструкции к задачам в Linux для неопотных пользователей, то опыту знаю, что уж лучше пусть люди набирают sudo, чем будут сидеть под рутом.

Согласен, что чтобы создать сам файл права рута не нужны. Тут исправлюсь при первой возможности.

лучше пусть люди набирают sudo, чем будут сидеть под рутом

почему?

Как почему, неопотный пользователь просто опасен под рутом, всегда что-то идет не так) А опытный, он итак разберется, как ему поступить.

если этот неопытный пользователь вместо работы под рутом начинает перед каждой командой вставлять sudo, то опасность никак не снижается.

Это зависит от настроек sudo. В общедоступной системе, то есть не специализированной, думаю да, так и есть, опасность не снижается.

А можете пояснить, зачем создавали loop device через losetup? Оно вроде работает и так, я так понимаю что есть нюансы, но не понимаю в чем. Гугл не помог.

Если имеется в виду способ через "mount -o loop ...", то да работает, но для случая когда уже есть образ с файловой системой и одним форматированным разделом. Даже если есть несколько, то монтируется всегда первый. А если нужно создать несколько разделов, а тем более если нужно отформатировать только некоторые из них, да еще и когда, например, первый монтировать совсем не нужно, то уже не очень работает. Хотя я вполне могу чего-то не знать.

как-то вы сложно начинаете )


  1. файл проще создать так:


    edo@edo-home:~$ truncate -s 1G testfile 

    это будет sparse файл, он создастся почти моментально и не будет занимать место на диске.


  2. fdisk отлично работает с обычными файлами от не-суперпользователя, так что не нужны ни losetup, ни sudo.
    но он лежит в /sbin, который не входит в PATH обычного пользователя, так что надо явно указывать путь:


    edo@edo-home:~$ fdisk testfile
    bash: fdisk: команда не найдена
    edo@edo-home:~$ /sbin/fdisk testfile


# если вам также как и мне требуется на диске u-boot, то не забываем установить:
sudo dd if=u-boot.img of=/dev/loop0 bs=1k seek=1 conv=fsync

способ установки бутлоадера сильно зависит от вашего оборудования, где оно ожидает этот самый бутлоадер увидеть.
и да, conv=fsync тут бесполезен.

Такой вопрос, conv=fsync бесполезен, если я перед этим выполнял буферезированные чтение/запись на диск? То есть синхронизация будет или нет?

честно скажу, не понял ваш вопрос.
при записи на флешку conv=fsync используют для того, чтобы сразу произошла запись на физический носитель и можно было вынуть флешку с записанными данными.
зачем вам нужен fsync при записи в файл?

Перед тем, как я использовал dd, я выполнял операции копирования (cp) на смонтированный диск с файловой системой. Операции копирования, как правило, буферезируются или кэшируются. conv=fsync нужен чтобы буферезированные изменения записались на диск, правильно? То есть conv=fsync будет верен и работать в отношении предыдущей операции cp?

давайте всё с самого начала.


есть отложенная запись (writeback). операционная система принимает команды записи и сразу отмечает их выполненными; но на самом деле сохраняет изменённые данные в буфере и потом в фоновом режиме сбрасывает их на накопитель.
в некоторых сценариях это очень сильно повышает производительность, например, если программа по кругу переписывает данные в одном и том же месте, или пишет очень маленькими блоками.
пример: вы копируете кучу мелких файлов, на каждый файл нужно обновить (притом в нескольких местах) метаинформацию. если писать синхронно (без кэширования), то в случае с hdd, например, это приводит к постоянному перемещению головок, которое занимает относительно много времени, условно говоря, запись идёт в сектора: 11, 21, 1001, 11, 22, 1002, 11, 23, 1003. при использовании отложенной записи операционная система может упорядочить и объединить эти записи, получается 11, 21-22-23, 1001-1002-1003.


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


для борьбы с такими ситуациями и придумали принудительный сброс кэшей (fsync и т. п.).


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

Еще лучше для создания файла использовать fallocate

Поправил в соответствии с вашими замечаниями и комментатора чуть ниже. Спасибо.)

Вместо kpartx можно обойтись одним losetup:

losetup --show -fP /наш/файл.образа

Спасибо, не знал.) Бывает всегда что-то упускаешь из виду.

Only those users with full accounts are able to leave comments. Log in, please.