[BUG]: Imager 1.9.0 - can't set login password using macOS 15.0.1 or Windows 11

[richb-hanover]

What happened?

I saw this behavior with Imager 1.9.0 running both on macOS 15.0.1 and on Windows 11.

I downloaded the imager from this github repo and installed it in the normal way. I then ran the imager, selecting:

• RPi4
• Ubuntu Server 24.04.1 LTS
• The microsd card I had just inserted
• Clicked NEXT and "Edit settings"

I set the following:

• RPi4-at-LLL.local
• ubuntu/ubuntu for credentials (typed extremely carefully, verifying each character)
• Wireless LAN: "HBTL" with no password
• Wireless LAN Country: US
• Time Zone: New York
• Keyboard: US
  then clicked Save.

I clicked YES for apply customisation settings, then cicked YES to erasing the media. I authorized the Mac to write the microSD, then it wrote and verified the media in the expected way.

Problems:

1. After checking the User/password checkbox, I could not de-select it.

2. More importantly, although the microSD card caused the RPi4 to boot as expected, after being presented with the login: prompt, those credentials (ubuntu/ubuntu) did NOT work. I cannot log in.

What other troubleshooting information could I provide? Thanks

Version

1.9.0

What host operating system were you using?

Windows

Host OS Version

Windows 11; macOS 15.0.1

Selected OS

Ubuntu server 24.04.1 LTS

Which Raspberry Pi Device are you using?

Raspberry Pi 4B, 400, and Compute Modules 4, 4S

What kind of storage device are you using?

microSD Card in a USB reader

OS Customisation

• Yes, I was using OS Customisation when the bug occurred.

Relevant log output

How would I get log files?

[richb-hanover]

Update: I have used the imager several times over the last few years, and it has always worked as expected...

[tdewey-rpi]

Thanks for the report, @richb-hanover

This is a fairly confusing one - in particular, the failure of the Set username and password checkbox is troubling - because I don't see it on macOS 15.0.1 or Windows 11. Is your report that the tickbox literally does not clear?

Concerning the password failure, its harder to determine what has precisely gone wrong. Ubuntu Server carries a different security posture to Raspberry Pi OS - and there have been numerous reports over the last few years of people failing to use ubuntu as the username. My first suggestion would be to try a different username & password combination - and fore safety reasons, ensure that password would comply with the Ubuntu Server password complexity requirements: https://ubuntu.com/server/docs/user-management#password-policy

[richb-hanover]

@tdewey-rpi thanks for your response.

1. The first half of the report was that the tickbox would not clear. But I cannot reproduce this with either 1.8.5 or 1.9.0 today. The checkbox works as expected. So let's write this off as "Rich's brain fade"... (Sorry for the false alarm)

2. The second part (problem with username/password) persists. The other day, I was able to create a usabe microSD card by giving blank credentials to the imager (defaulting to ubuntu/ubuntu). I tried again this morning to use "deploy" and a random four-letter, four digit (e.g. AAAA#### format) password and was not able to log in using the resulting microSD.

You're off the hook for now. I will look more carefully at the hash in the file on the microSD to see if I can see any anomalies. I'll report back if I see anything useful (or if I make everything work...) Thanks again

[tdewey-rpi]

@tdewey-rpi thanks for your response.

1. The first half of the report was that the tickbox would not clear. But I cannot reproduce this with either 1.8.5 or 1.9.0 today. The checkbox works as expected. So let's write this off as "Rich's brain fade"... (Sorry for the false alarm)

Not a problem - better to report all issues and then discard them later, than miss critical user experience problems in a cloud of doubt.

2. The second part (problem with username/password) persists. The other day, I was able to create a microSD card with blank credentials (defaulting to ubuntu/ubuntu). I tried again this morning to use "deploy" and a random four-letter, four digit (e.g. AAAA#### format) password and was not able to log in.

Interesting - I wonder if our cloud-init configuration file is now incorrect for Ubuntu Server 24.04.

You're off the hook for now. I will look more carefully at the hash in the file on the microSD to see if I can see any anomalies. I'll report back if I see anything useful (or if I make everything work...) Thanks again

Good stuff - I'll hold this issue open for now, in case we see other reports.

[richb-hanover]

cloud-init configuration...

Hmmm... I did see some blah blah blah about this scroll by. Because I wasn't expecting it, I didn't pay attention. Let me gather more data (later this week - day job, etc) and report back when I have something that feels interesting. Thanks

[lurch]

Interesting - I wonder if our cloud-init configuration file is now incorrect for Ubuntu Server 24.04.

ping @waveform80 in case he's able to provide any useful insight 🙂

[richb-hanover]

Update: I am still having trouble with this. I attempted to flash a microsd with blank login credentials (I quit the app, re-launched and clicked clear settings to get back to the un-configured state).

I then set the mDNS name, the Wi-Fi credentials (no password - it's an open AP), and the time zone. I also checked "enable SSH" and "Allow Password". This got me to the state that I could not un-check the Set Username/password box. (Can I not use the default ubuntu/ubuntu password?)

Also: I am still unable to supply user/password credentials - all are being rejected after booting up.

@waveform80 - any thoughts? What other information can I provide? Many thanks.

[lurch]

I also checked "enable SSH" and "Allow Password". This got me to the state that I could not un-check the Set Username/password box. (Can I not use the default ubuntu/ubuntu password?)

I just had a look at this in Raspberry Pi Imager v1.9.1 (running on Raspberry Pi OS), and I can confirm that if you set "Services -> Enable SSH - Allow public-key authentication only" then you can uncheck "General -> Set username and password"; but if you set "Services -> Enable SSH - Use password authentication" then you can't uncheck "General -> Set username and password".
This is presumably because Raspberry Pi OS (which is obviously the primary use-case for Raspberry Pi Imager) doesn't have a default username and password, and so without a username and password set, the "Use password authentication" SSH option doesn't make sense? 🤔 Also, from a security standpoint having SSH enabled with a default username and password in place is obviously a very bad idea, so I suspect that we probably won't allow this in future anyway.

[tdewey-rpi]

@lurch is correct - weakening the security posture around passwords isn't something I'm prepared to entertain.

I may, however, consider improving the UI hints around this behaviour.

[richb-hanover]

Thank you for the speedy response.

1. I agree that allowing password authentication should require specification of a username and password. A better hint from the UI would be helpful.

2. The major reason for this report is that when I do set a username and password and create an image, those credentials do not work to log into Ubuntu Server 24.04.

I plan to attempt to build an image from 22.04 to see if the version makes a difference as hinted here

[tdewey-rpi]

Thank you for the speedy response.

1. I agree that allowing password authentication should require specification of a username and password. A better hint from the UI would be helpful.

I'll count that as a +1 for better OS customisation feedback!

2. The major reason for this report is that when I do set a username and password and create an image, those credentials do not work to log into Ubuntu Server 24.04.

Unfortunately, this isn't strictly a problem with Imager - there's multiple components in play:

• Imager
• cloud-init
• Ubuntu login policy

I'd also suggest it's worth considering waveform80's response in the forums: https://forums.raspberrypi.com/viewtopic.php?t=278897

Specifically, it might just be that cloud-init has taken longer to run than expected, and thus the creation of your default account is taking longer than you might expect.

I plan to attempt to build an image from 22.04 to see if the version makes a difference as hinted here

[richb-hanover]

Cancel Code Red... :-) I now have a working system using both 22.04 and 24.04: the Raspberry Pi Imager 1.9.0 worked as expected for each. Here are the hurdles that I encountered (and that caused me to think that things were broken) and potential workarounds (in italics):

1. I had to WAIT a long time - a couple minutes? - after the initial login: prompt appeared. I discovered this because I started up a newly-flashed MicroSD, but was called away for a conversation. When I returned, I was able to log in using the credentials entered in the Imager. I suspect that the failures that prompted this report occurred because I had attempted to log in immediately after the login: prompt - I had not waited long enough. I don't know how to address this - I suspect it's completely out of your hands...

2. I wanted to use an open Wi-Fi SSID, but the Imager doesn't seem to allow for it. During the boot process, I did see an error message to the effect of "...passphrase must be between 8 & 63 characters..." I suspect that means the network didn't come up, and that halted the cloud-init process. When I configured a SSID that had a password, the system booted. Perhaps the Imager could give advice about using a blank password. NB To enter a blank password, the /etc/netplan/50-cloud-init.yaml file could have:

   access-points:
     my-SSID: {}
   

3. I already mentioned my confusion about the "Set username/password" checkbox. Perhaps clicking the "Set username and password" box could raise a warning that it cannot be un-checked when "Allow password" was selected._

Thanks again for the detailed attention you gave to this issue

[lurch]

I now have a working system using both 22.04 and 24.04: the Raspberry Pi Imager 1.9.0 worked as expected for each.

Hooray! 🎉 Thank you for keeping us updated 👍

I wanted to use an open Wi-Fi SSID, but the Imager doesn't seem to allow for it.

#718 suggests that this should already be possible. Has there been a regression?

[richb-hanover]

I cannot say whether there's been a regression - I didn't understand the info in #718 enough to say one way or the other...

I entered the SSID and left the password field blank. Should that be enough?

[lurch]

ping @cillian64

[cillian64]

#718 only fixed it for raspberry pi OS. Ubuntu uses a different configuration mechanism (cloud-init), it sounds like that would need a different trick to configure an open network.

[richb-hanover]

Closing this. I think the solution was waiting for the initial startup (see #977 (comment))