Rpi-imager: дополнительные параметры не работают в windows 10

Какой образ вы писали?

И вы действительно проверяли на Pi, что процесс sshd не запущен?
(Просто невозможность подключения может иметь и другие причины).

Если вместо того, чтобы вставлять SD-карту в Pi, вы вставляете ее обратно в свой компьютер сразу после записи, создает ли он файл с именем firstrun.sh в разделе FAT?

И если нет, есть ли разница в зависимости от того, ставите ли вы флажок «извлечь носитель по завершении»?

Спасибо за ответ!

Образ представляет собой оригинальную ОС Rasberry Pi (32-BIT). Дата выпуска: 11 января 2021 г.
Я проверил на самом Pi наличие ssh. Но не работает не только функция включения ssh. В меню опций ничего не работает. Пробовал и другие варианты. Пробовал также разные SD-карты, чтобы быть уверенным;)

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

OK. Я смотрю на эту проблему немного дальше, и кажется, что у imager есть проблема с большими SD-картами и USB-накопителями.

Я попробовал SD-карту на 16 ГБ, и с помощью этой карты имидж-сканер создал нужный файл firstrun.sh. Первые SD-карты, которые я использовал, были на 32 и 128 Гб. затем я попробовал внешний USB-накопитель на 250 ГБ, но безуспешно. Нет файла firstrun.sh.
Так может проблема в размере sd-карты?

окно извлечения носителя было снято

Проверка не имеет значения?

Ваш диск сохраняет одну и ту же букву диска до и после создания образа?

установка или снятие флажка в поле извлечения носителя не имеет значения Моя буква диска остается прежней.

На данный момент это не имеет большого значения, потому что я не записываю ОС на SD-карты каждый день. Но эй, установка этих параметров делает процесс установки ОС более удобным для меня, потому что включение ssh по умолчанию означает, что вы можете установить ОС без необходимости подключения экрана к RPI. Вы можете полностью настроить RPI с помощью удаленного подключения через ssh

Первые SD-карты, которые я использовал, были на 32 и 128 Гб. затем я попробовал внешний USB-накопитель на 250 ГБ, но безуспешно. Нет файла firstrun.sh.
Так может проблема в размере sd-карты?

Он был протестирован на SD-карте Samsung на 64 ГБ и Toshiba на 32 ГБ, поэтому размер сам по себе не должен быть проблемой.

Новые USB-накопители могут быть проблемой, если они используют протокол UASP вместо стандартного протокола USB-накопителей.
У меня есть твердотельный накопитель Samsung T7, который Windows рассматривает не как съемное хранилище, а как внутренний диск, и поэтому он не назначает ему букву диска автоматически после создания образа. Вместо этого вам нужно перейти к управлению дисками Windows и назначить букву диска вручную, чтобы он вообще мог видеть файлы в разделе FAT.
Очевидно, что при использовании этого диска Imager не может исправить файлы автоматически, но в этом случае он отображает четкое сообщение об ошибке:

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

У меня похожие проблемы. Я получаю сообщение об ошибке «невозможно записать firstrun.sh». Я бы добавил скриншот, но++X конфликтует со Snagit 2021, поэтому мне пришлось его отключить. ;)

Ошибка возникла с SD-картой на 32 ГБ, но не с USB-накопителем на 16 ГБ.

У меня похожие проблемы. Я получаю сообщение об ошибке «невозможно записать firstrun.sh».

Это означает, что Windows указала, что разделу FAT была назначена буква диска (в противном случае вместо этого вы получите сообщение «Операционная система не смонтировала раздел FAT32»), но открыть файл для записи все равно не удалось.
Возможно, есть задержка в назначении Windows буквы диска и завершении монтирования файловой системы.
В этом случае нам может потребоваться повторить попытку несколько раз.

Получив сообщение об ошибке, вы можете видеть файлы в разделе FAT в проводнике без необходимости переподключения карты или каких-либо специальных действий?

Я вижу раздел FAT32, но, конечно, нет файла firstrun.sh. На моей машине это E:, так как у меня на жестком диске 2 раздела (не спрашивайте). Но это также E: для USB-накопителя.

Я вижу раздел FAT32, но, конечно, нет файла firstrun.sh.

Ok.
Можете ли вы попробовать, если этот работает лучше?

imager-1.7beta.zip

Ожидает до 3 секунд, проверяя, существует ли файл config.txt на букве диска, прежде чем приступить к записи изменений.

Работает как положено. Протестировано с SD-картой на 32 ГБ от создания до цикла загрузки на Pi 4.

Спасибо.

Работает как положено.

Рад слышать.

@TeeSee64 TeeSee64 , можешь попробовать бета-версию?
(Не знаю, поможет ли это решить вашу проблему, так как у вас разные симптомы).

@макснет
Да! Я могу подтвердить, что проблема решена с версией 1.7beta. Теперь пишет файл firstrun.sh и все опции работают. Работает как с SD-картой на 128 Гб, так и с флешкой на 250 Гб.

Спасибо !!

Привет, @maxnet , у меня была такая же проблема, как и у @CharlesGodwin. Также пробовал 1.7бету, но, к сожалению, она у меня не работает. Из-за ваших изменений изменилось только сообщение об ошибке. Теперь отображается сообщение «Невозможно настроить. Файл «I:\/config.txt» не существует».
Проблема может заключаться в том, что раздел FAT32 монтируется в «J:\» вместо «I:\».
Извините, но в настоящее время я не могу провести дальнейший анализ того, почему он смонтирован на «J:\» или почему тепловизор считает, что он смонтирован на «I:\», но, по крайней мере, я хотел поделиться этим с вами. .

Проблема может заключаться в том, что раздел FAT32 монтируется в «J:\» вместо «I:\».

Хм, думаю, у нас были сообщения о том, что буквы дисков не освобождаются, и новая буква диска была назначена диску раньше.
Например: https://github.com/raspberrypi/rpi-imager/issues/31
Однако никогда не удавалось воспроизвести такие проблемы. Так что без понятия, чем это вызвано.
Возможно, что-то блокирует диск (какая-нибудь системная служба или антивирусный сканер?)

Или карта никогда не была доступна в I: раньше?
Какая буква диска отображалась при выборе диска в Imager?

Imager предполагает, что первый том, который Windows сообщает нам, связан с диском, является разделом FAT, который нам нужен.
Не уверен, что есть лучший механизм, например, поиск во всех томах, связанных с диском, для config.txt.

Если вы запустите «diskpart» из командной строки и наберете «список томов», отображаются ли там как I:, так и J:?
Также можно попробовать выбрать их с помощью «выбрать том [номер тома]» и посмотреть, печатает ли «подробный том» (и «подробный раздел» «подробный диск») что-нибудь необычное.

Возможно, что-то блокирует диск (какая-нибудь системная служба или антивирусный сканер?)

Не думайте так.

Какая буква диска отображалась при выборе диска в Imager?

На карте, которая уже была изображена, отображается «Смонтировано как I: \, J: \» (в переводе с использованием немецкой версии).
Также пробовал с неиспользованной картой. Он отображает «Смонтировано как J: \» (I: \ отсутствует, также в проводнике. Не спрашивайте меня, почему...)

Если вы запустите «diskpart» из командной строки и наберете «список томов», отображаются ли там как I:, так и J:?

Нет, там отображается только J:\. Но в проводнике показывает как I:\, так и J:\.

Imager предполагает, что первый том, который Windows сообщает нам, связан с диском, является разделом FAT, который нам нужен.

Кажется, это проблема.

@maxnet Просто идея...
Может быть, индексатор поиска Windows? Иногда, когда я пытаюсь безопасно извлечь SD-карту из своего компьютера, это невозможно, потому что индексатор поиска Windwos занят на этой карте. через несколько секунд индексатор готов, и можно безопасно удалить его.

Может быть, индексатор поиска Windows?

Мы передаем очистку таблицы разделов при запуске Imaging утилите Microsoft diskpart в надежде, что она знает, как заставить каждую службу Microsoft прекратить использование диска и правильно снять все блокировки/буквы дисков.
Помимо системных служб, существуют также сторонние программы, которым нравится запрашивать и держать открытым файл внутри «\System Volume Information» на каждом диске.
Например, я помню, что Symantec Endpoint Security, как известно, ведет учет уже просканированных файлов и сигнатур этих файлов.
Вот почему я упомянул антивирусные сканеры.

@CRGer

Можете ли вы попробовать, если этот работает лучше?

imager-20210322.zip

Следует искать все точки монтирования, связанные с диском, для config.txt, а не только первую.

@maxnet Даже если буква автоматически монтируемого диска изменится до и после записи образа, я предполагаю, что номер физического диска не изменится? Так что, может быть, вы могли бы использовать некоторые вещи WMI для сопоставления букв дисков до и после прошивки образа? :shrug: В качестве альтернативы, я думаю, вы могли бы использовать необработанный размер диска, поскольку маловероятно, что у пользователя будут подключены два диска с одинаковым необработанным размером? (и это тоже не изменится до/после перепрошивки)

@maxnet Даже если буква автоматически монтируемого диска меняется до и после записи образа, я предполагаю, что номер физического диска
не изменится? Так что, может быть, вы могли бы использовать некоторые вещи WMI для сопоставления букв дисков до и после прошивки образа?

Мы уже получили список томов, принадлежащих этому номеру физического диска, после создания образа.

Однако в случае CRGer два тома (I: и J:) возвращаются как принадлежащие этому физическому диску .
В нашем коде ранее предполагалось, что первый является разделом FAT, но в его случае второй является единственным допустимым томом.
Новый код должен сканировать оба тома, возвращенные для config.txt.

Это может закончиться игрой в прятки. возможно, код в диалоговом окне «Какой это диск, пожалуйста», когда ничего не помогает.

Ааа, я неправильно понял, извиняюсь за шум! :подмигивание:

Можете ли вы попробовать, если этот работает лучше?

Попробовал, работает как положено. «firstrun.sh» был создан в моем разделе FAT со всеми выбранными конфигурациями. Хорошая работа @maxnet , спасибо!

Я вижу эту проблему в Ubuntu, пытающейся написать Raspberry PI OS Lite, похоже, что она недостаточно долго ждет монтирования загрузочного раздела, прежде чем пытаться записать firstrun.sh в раздел. Есть ли сборка с большей задержкой для ubuntu?

Кроме того, вместо произвольного ожидания в 3 секунды, как насчет того, чтобы просто проверить, можете ли вы получить доступ к разделу в цикле, скажем, 60 секунд, прежде чем произойдет ошибка или что-то в этом роде?

Я вижу эту проблему в Ubuntu, пытающейся написать Raspberry PI OS Lite, похоже, что она недостаточно долго ждет загрузки
раздел для монтирования, прежде чем пытаться записать в раздел файл firstrun.sh. Есть ли сборка с большей задержкой для ubuntu?

Этот работает лучше?

rpi-imager-ubuntu-20210324.zip

Кроме того, вместо произвольного ожидания в 3 секунды, как насчет того, чтобы просто проверить, можете ли вы получить доступ к разделу в цикле, скажем, 60
секунд до ошибки или что-то еще?

Для справки: установка раздела FAT на моем компьютере с Ubuntu занимает 0,008 секунды.

Я вижу эту проблему в Ubuntu, пытающейся написать Raspberry PI OS Lite, похоже, что она недостаточно долго ждет загрузки
раздел для монтирования, прежде чем пытаться записать в раздел файл firstrun.sh. Есть ли сборка с большей задержкой для ubuntu?

Кстати, вы использовали .deb с веб-сайта Raspberry Pi ранее или снап, предоставленный каноническим?

Как упоминает кто-то другой, проблема возникает только на снимке: https://www.raspberrypi.org/forums/viewtopic.php?f=63&p=1842486 .

почему Ubuntu rpi-imager обсуждается в выпуске под названием «Дополнительные параметры», не работающие в Windows 10

никто не найдет

почему Ubuntu rpi-imager обсуждается в выпуске под названием «Дополнительные параметры», не работающие в Windows 10

Это больше проблема с заголовком, чем то, что это разные проблемы.

Проблема в обоих случаях одна и та же.
Операционная система сообщает, что монтирование выполнено, хотя на самом деле оно еще не готово.

Это НЕ должно происходить в обычных системах Linux.
Но может случиться в стороннем snap-пакете, который мы не создавали.
Ну ладно, в качестве побочного эффекта решения этой проблемы в Windows это также может решить проблему с оснасткой...

Я предполагаю, что проблема _может_ быть переименована в «расширенные параметры, не записывающие настройки на SD-карту», ​​но это не стоит того, если у @maxnet уже есть потенциальное исправление? :slightly_smiling_face:

Я предполагаю, что проблему можно было бы переименовать в «расширенные параметры, не записывающие настройки на SD-карту», ​​но это не стоит того, если @maxnet
уже есть потенциальное исправление в руке?

Подозреваю, что проблема уже решена.
Но пока оставьте это открытым, чтобы другие, использующие 1.6 (вместо git последней версии), не открывали новую проблему.

Исправлено в 1.6.1