Rpi-imager: advanced options not working on windows 10

[TeeSee64]

I wanted to use the advanced options and enable ssh by default. But after writing the sd-card ssh was not enabled.. So i tried other options and they also did not work.

Iam using imager version v1.6 on a windows 10 computer.

[maxnet]

What image were you writing?

And did you actually check on the Pi the sshd process was not running?
(Just not being able to connect can have other reasons).

If instead of putting the SD card in the Pi, you put it back in your computer immediately after writing, did it create a file called firstrun.sh on the FAT partition?

And if not, is there any difference depending on whether you check the "eject media when finished" box?

[TeeSee64]

Thanks for the respond!

The image is the original Rasberry Pi OS (32-BIT) Release date 2021-01-11
I checked on the Pi itself for the ssh. But it is not just the ssh enable function that is not working. Nothing in the options menu is working. Tried the other options as well. Tried also different SD-Cards just to be sure ;)

I have just checked and used another sd-card, did everything exactly as before and it did not create a file called firstrun.sh.
eject media box was uncheked.

[TeeSee64]

OK. I look in this problem a little further and it seems that imager has a problem with big sd-cards and usb drives.

I tried a 16 GB sd-card and with that card imager produced the wanted firstrun.sh file. The first sd-cards i was using were 32 and 128 Gb. next i tried a external 250Gb usb drive but no succes. No firstrun.sh file.
So the problem is the size of the sd-card maybe?

[maxnet]

eject media box was uncheked

Checking it does not make a difference?

Your drive does keep the same drive letter before and after imaging?

[TeeSee64]

eject media box check or uncheck does not make any difference My drive letter stays the same.

For now it is not a big deal because i dont wrtite OS to sd-cards on a daily base. But hey, setting those options makes the proces of installing OS more handy for me because turning on ssh by default does mean you can install the OS withoud the need of connecting a screen to the RPI. You can setup a RPI completly by remote connection via ssh

[maxnet]

The first sd-cards i was using were 32 and 128 Gb. next i tried a external 250Gb usb drive but no succes. No firstrun.sh file.
So the problem is the size of the sd-card maybe?

It did was tested on a 64 GB Samsung SD card and 32 GB Toshiba, so size itself should not be a problem.

Newer USB drives do may be a problem if they speak UASP protocol instead of the standard USB mass storage protocol.
I have a Samsung T7 SSD, that Windows does not treat as removable storage but as internal drive, and it therefore does not assign a drive letter to it automatically after Imaging. Instead you have to go to Windows disk management and assign a drive letter manually for it to get to see the files on the FAT partition at all.
When using that drive Imager obviously cannot fix up the files automatically, but it does display a clear error message in that case:

Which is different to your case of the changes we write to disk being lost.

[CharlesGodwin]

I have similar problems. I'm getting an "unable to write firstrun.sh" error. I'd include a screenshot but ++X conflicts with Snagit 2021 so I had to disable it. ;)

The error occurred with a 32GB SD card but not with 16GB USB stick.

[maxnet]

I have similar problems. I'm getting an "unable to write firstrun.sh" error.

That's mean that Windows did indicate the FAT partition has been assigned a drive letter (otherwise you get "Operating system did not mount FAT32 partition" instead), but opening the file for writing still failed.
Maybe there is a delay in Windows assigning a drive letter, and when the file system finished mounting.
If that's the case we may need to retry multiple times.

After receiving the error, you do am able to see the files on the FAT partition in explorer without having to replug the card or do anything special?

[CharlesGodwin]

I can see the FAT32 partition but of course no firstrun.sh file. On my machine it is E: as I have 2 partitions on my HDD (don't ask). But it is also E: for the USB stick.

[maxnet]

I can see the FAT32 partition but of course no firstrun.sh file.

Ok.
Can you try if this one works better?

imager-1.7beta.zip

Waits up to 3 seconds checking if config.txt exists on the drive letter before proceeding to write the changes.

[CharlesGodwin]

Works as expected. Tested with 32GB SD card from create through boot cycle on Pi 4.

Thanks.

[maxnet]

Works as expected.

Good to hear.

@TeeSee64 can you also give the beta a try?
(No idea if it does anything for your issue, as you do have different symptons).

[TeeSee64]

@maxnet
Yes! I can confirm that the problem is solved with the 1.7beta version. It now writes the firstrun.sh file and all the options are working. Works with both 128Gb sd-card and a 250Gb usb drive

Thank you !!

[CRGer]

Hi @maxnet, I had the same issue like @CharlesGodwin. Also tried the 1.7beta, but unfortunately it doesn't work for me. Only the error message changed due to your changes. It now displays "Unable to customize. File 'I:\/config.txt' does not exist.".
The problem might be, that the FAT32 partition is mounted to "J:\" instead of "I:\".
I'm sorry but i'm currently unable to do any further analysis on why it's mounted to "J:\" or why the Imager thinks it is mounted to "I:\", but at least I wanted to share this with you.

[maxnet]

The problem might be, that the FAT32 partition is mounted to "J:\" instead of "I:\".

Hmm, think we had reports about drive letters not being released, and a new drive letter being assigned to the drive before.
Like: https://github.com/raspberrypi/rpi-imager/issues/31
Never managed to reproduce any such issues though. So no idea what is causing it.
Perhaps something holding a lock on the drive (some system service or virus scanner?)

Or was the card never available at I: before?
What drive letter was shown when you selected the drive in Imager?

Imager does assume the first volume that Windows tells us is associated with the drive is the FAT partition we are after.
Not sure if there is a better mechanism, like search all volumes associated with drive for config.txt instead.

If you start "diskpart" from a command prompt, and type "list volumes", does it show both I: and J: there?
May also try selecting them with "select volume [number of volume]", and see if "detail volume" (and "detail partition" "detail disk") prints anything out of the ordinary.

[CRGer]

Perhaps something holding a lock on the drive (some system service or virus scanner?)

Don't think so.

What drive letter was shown when you selected the drive in Imager?

The card, which has already been imaged, displays "Mounted as I:\,J:\"(translated, using German version).
Also tried it with an unused card. It displays "Mounted as J:\" (I:\ is missing complety, also in explorer. Don't ask me why...)

If you start "diskpart" from a command prompt, and type "list volumes", does it show both I: and J: there?

No, it only shows J:\ there. But in explorer it shows both, I:\ and J:\.

Imager does assume the first volume that Windows tells us is associated with the drive is the FAT partition we are after.

That seems to be the problem.

[TeeSee64]

@maxnet Just a idea...
Maybe the windows search indexer ? Somtimes when I try to safe remove a SD-Card from my computer, it is imposible because windwos search indexer is busy on that card. after a few moments, indexer is ready and safe remove is possible.

[maxnet]

Maybe the windows search indexer ?

We outsource wiping the partition table at start of Imaging to Microsoft's diskpart utility, in the hope that knows how to get every Microsoft service to stop using the drive, and release all locks/drive letters properly.
Other than system services there are also third-party programs that like to claim and keep open a file inside "\System Volume Information" on every drive.
E.g. I recall Symantec Endpoint Security is known to keep bookkeeping about what files it already scanned, and signatures of those files there.
That's why I mentioned virus scanners.

[maxnet]

@CRGer

Can you try if this one works better?

imager-20210322.zip

Should search all mountpoints associated with drive for config.txt instead of just first one.

[lurch]

@maxnet Even if the auto-mounted drive-letter changes before and after writing the image, I assume the physical disk number won't change? So maybe you could use some of the WMI stuff to correlate drive-letters before and after flashing the image? :shrug: Alternatively, I guess you could use the raw drive size, as it's probably unlikely the user will have two drives with the same exact raw size connected? (and that also won't change before/after flashing)

[maxnet]

@maxnet Even if the auto-mounted drive-letter changes before and after writing the image, I assume the physical disk number
won't change? So maybe you could use some of the WMI stuff to correlate drive-letters before and after flashing the image?

We already fetch the list of volumes belonging to that physical drive number after imaging.

However in the case of CRGer two volumes are returned (I: and J:) as belonging to that physical drive.
Our code previously assumed first one is FAT partition, but in his case second one is the only valid volume.
New code should scan both volumes returned for config.txt

[CharlesGodwin]

It may end up a game of wack a mole. maybe code in a dialog box "Which drive is it, please" when all else fails.

[lurch]

Ahh, I misunderstood, apologies for the noise! :wink:

[CRGer]

Can you try if this one works better?

Tried it and it works as expected. "firstrun.sh" was created an my FAT partition with all selected configurations. Good work @maxnet, thank you!

[mcinnes01]

I'm seeing this issue on ubuntu trying to write Raspberry PI OS Lite, it appears like it doesn't wait long enough for the boot partition to mount, before trying to write the firstrun.sh to the partition. Is there a build with a longer delay for ubuntu?

Also rather than some arbitrary 3 second wait, what about just testing if you can access the partition in a loop for say 60 seconds before erroring or something?

[maxnet]

I'm seeing this issue on ubuntu trying to write Raspberry PI OS Lite, it appears like it doesn't wait long enough for the boot
partition to mount, before trying to write the firstrun.sh to the partition. Is there a build with a longer delay for ubuntu?

Does this one work better?

rpi-imager-ubuntu-20210324.zip

Also rather than some arbitrary 3 second wait, what about just testing if you can access the partition in a loop for say 60
seconds before erroring or something?

For reference: it takes 0.008 second before the FAT partition is mounted on my Ubuntu computer.

[maxnet]

I'm seeing this issue on ubuntu trying to write Raspberry PI OS Lite, it appears like it doesn't wait long enough for the boot
partition to mount, before trying to write the firstrun.sh to the partition. Is there a build with a longer delay for ubuntu?

BTW did you use the .deb from the Raspberry Pi website previously, or the snap provided by canonical?

As someone else is mentioning the problem only occurs on the snap: https://www.raspberrypi.org/forums/viewtopic.php?f=63&p=1842486

[CharlesGodwin]

why is the Ubuntu rpi-imager being discussed in an issue titled advanced options not working on windows 10

no one will find it

[maxnet]

why is the Ubuntu rpi-imager being discussed in an issue titled advanced options not working on windows 10

That's more of a problem with the title, than that it are different problems.

Problem in both cases is the same.
The operating system reports a mount is done, when it is not actually ready yet.

This should NOT happen on normal Linux systems.
But may happen in the third-party snap package that we did not create.
Oh well, as a side effect of working around this issue on Windows, it may workaround the snap issue as well...

[lurch]

I guess the issue _could_ be renamed to "advanced options not writing settings to SD card", but it doesn't seem worth it if @maxnet already has a potential fix in hand? :slightly_smiling_face:

[maxnet]

I guess the issue could be renamed to "advanced options not writing settings to SD card", but it doesn't seem worth it if @maxnet
already has a potential fix in hand?

I suspect the issue is already fixed.
But leaving this open for now, to prevent others using 1.6 (instead of git latest) from opening a new issue.

[maxnet]

Fixed in 1.6.1