News

All news

An update to Raspberry Pi OS Bullseye

One of the things which we spend a lot of time thinking about here at Raspberry Pi is security. Cyber-attacks and hacking are, sadly, constantly on the increase, and Raspberry Pi computers are as much a target as any other, just because there are so many of them out there nowadays!

Over the years, we have gradually ramped up the security of Raspberry Pi OS; not in response to particular threats, but more as a general precaution. There is always a balance to be struck, however, as security improvements usually carry a cost in terms of usability, and we have tried to keep the system as convenient to use as possible, while having an acceptable level of security.

Up until now, all installs of Raspberry Pi OS have had a default user called “pi”. This isn’t that much of a weakness – just knowing a valid user name doesn’t really help much if someone wants to hack into your system; they would also need to know your password, and you’d need to have enabled some form of remote access in the first place. But nonetheless, it could potentially make a brute-force attack slightly easier, and in response to this, some countries are now introducing legislation to forbid any Internet-connected device from having default login credentials.

So with this latest release, the default “pi” user is being removed, and instead you will create a user the first time you boot a newly-flashed Raspberry Pi OS image. This is in line with the way most operating systems work nowadays, and, while it may cause a few issues where software (and documentation) assumes the existence of the “pi” user, it feels like a sensible change to make at this point.

The new wizard

The Raspberry Pi setup wizard should be a familiar sight by now. It was introduced several years ago, and runs on the first boot, configuring international settings, connecting to wireless LAN and installing any software updates; it also prompts you to change the default password. But the wizard has always been optional – if you pressed “Cancel” on the first page, it just went away and you weren’t forced to use it.

From now on, working through the wizard is no longer optional, as this is how a user account is created; until you create a user account, you cannot log in to the desktop. So instead of running as an application in the desktop itself as before, the wizard now runs in a dedicated environment at first boot.

When you boot a new image, you will see the wizard environment. You cannot run any applications from here – the menu button and application launcher have been removed from the taskbar; all the taskbar now allows you to do is to adjust volume and pair Bluetooth devices.

The wizard itself is largely unchanged from before, with the key difference being that when you were previously prompted for a new password, you are now prompted for a user name and a password. (If you really want to, you can set these to “pi” and “raspberry” as before – you will get a warning message that doing so is unwise, but it is your choice – some software might require the “pi” user, so we aren’t being completely authoritarian about this. But we really would recommend choosing something else!)

The other settings which were available in the wizard are largely unchanged. The only other difference is that the page which allows you to apply compensation for monitors with overscan – a black border around the image – now has separate settings for both monitors if you have a second monitor connected, and changing the setting now takes effect immediately; previously the overscan setting only took effect on a reboot.

Once you get to the last page of the wizard and you press the “Restart” button, the system will reboot and the familiar Raspberry Pi Desktop will appear, logged in as the user you just created. And from here on, everything will work just as before.

If you are using the Raspberry Pi OS Lite image, which doesn’t have the wizard, you will still need to create a new user account. You will therefore be prompted to create an account by text prompts at the command line when you first boot a Lite image.

Headless setup

For people who run their Raspberry Pi headless and therefore cannot work through the wizard, the Raspberry Pi Imager tool allows you to preconfigure an image with a user account; when an image created like this is first booted, it will come straight up in the desktop, logged in as the user created in the Imager.

To preconfigure an image like this, when you have selected the source image and destination in Imager, click the “settings” button – the picture of a cogwheel – before clicking “Write”, and use the Advanced options menu to enter a username and password, along with any other preconfiguration you want.

There are also mechanisms to preconfigure an image without using Imager. To set up a user on first boot and bypass the wizard completely, create a file called userconf or userconf.txt in the boot partition of the SD card; this is the part of the SD card which can be seen when it is mounted in a Windows or MacOS computer.

This file should contain a single line of text, consisting of username:encrypted- password – so your desired username, followed immediately by a colon, followed immediately by an encrypted representation of the password you want to use.

To generate the encrypted password, the easiest way is to use OpenSSL on a Raspberry Pi that is already running – open a terminal window and enter

echo 'mypassword' | openssl passwd -6 -stdin

This will produce what looks like a string of random characters, which is actually an encrypted version of the supplied password.

Existing installations

Some people, having read the above, may now be wondering whether they can rename the “pi” user on their existing images. As part of this update, we have included a mechanism to do that.

After updating as described below, make sure you are logged in as the “pi” user, and then open a terminal window and type

sudo rename-user

After a brief pause, you will be prompted to reboot, and the Raspberry Pi will then reboot into a cut-down version of the first-boot wizard which only allows you to change the user name and password.

Once you have entered a new username and password, you will be prompted to restart, and your Raspberry Pi will reboot to the desktop, with your existing user (and your home directory) renamed, but no other changes.

One word of caution – most Raspberry Pi software (if it was written properly…) should handle having the home directory renamed and carry on working as before, but it is possible that some code may have been written with a hard-coded path to the /home/pi directory, and this will need to be modified in order to work correctly with the renamed user.

Also, please note that, due to the way the rename-user process involves temporarily creating and logging in as a different user, this process will not work over a VNC connection (which requires you to be logged in as a specific user); you will need to be a local user in order to rename the”pi” user.

The same rename-user command can also be used on a Lite image to rename the existing “pi” user; in this case it will run the same command-line prompts as are used to set up a user at first boot in the Lite image.

Bluetooth peripherals

While we were creating the new wizard, we decided to address a long-standing issue. If you want to use a Bluetooth keyboard or mouse with your Raspberry Pi, you have always needed to use a USB mouse and/or keyboard to initially pair the Bluetooth peripherals, which is a bit irritating.

That requirement has been removed in the new wizard. When it runs, the first page will prompt you to put any Bluetooth keyboard or mouse you wish to use into pairing mode, and then to wait. As long as you are on the first page of the wizard, the Raspberry Pi will now scan for pairable Bluetooth mice and keyboards, and will automatically pair the first of each which it finds. You will see messages pop up to indicate that a Bluetooth device has been found and is being paired – you may need to wait a few seconds after the final “connected” dialog appears for the newly-connected device to wake up and start being used by the system, but you can now set up a Raspberry Pi from scratch with just Bluetooth peripherals.

This works both with the built-in Bluetooth adapter on Raspberry Pi 3 and 4, and also with USB Bluetooth adapters on earlier models of Raspberry Pi – just make sure the USB adapter is inserted before the Raspberry Pi is booted.

One more thing…

Some of you may have heard of Wayland, a proposed replacement for the X Window System which has underpinned most Unix desktop environments for several decades now. Wayland has various advantages over X, notably security and performance, but it is still fairly new technology and hence still under development. A couple of Linux distros now run on top of Wayland, but it hasn’t yet been widely adopted – that said, it is looking as if Wayland is likely to be the future of desktop Linux.

When we released the Bullseye version of Raspberry Pi OS last year, we started using mutter as the default window manager instead of openbox, and one of the reasons for this was that mutter supports the Wayland protocols. In this release, we are making it possible to run the desktop on top of Wayland as an experimental configuration for people who are interested in trying it.

Before going any further, please note – we absolutely do not recommend most people run on top of Wayland yet! This is experimental code and there are many features which are not yet supported under Wayland. (To name a few – taking screenshots, the screen magnifier, any remote desktop application, the screen resolution setting tool; we hope to get some of these working in due course, but for now, they don’t.)

Also, this is not a pure Wayland implementation of the desktop. There are several features of X – notably communication between applications – which are not supported at all in Wayland, which is purely a graphics protocol. The desktop relies on some of these features of X, and so this version of the desktop is a sort of half-way house. The mutter window manager runs as a true Wayland application, but everything else runs under XWayland, which is basically an implementation of X which uses Wayland to draw the graphics. This means that some of the advantages of Wayland will not be available in this version of the desktop.

Nonetheless, after the use of mutter in the Bullseye release, this is another major step in the direction of Wayland, and people who are interested are welcome to try it. (But please don’t complain to us that some feature you depend on doesn’t work under Wayland – as above, we already know that a bunch of stuff doesn’t work, which is why we’ve warned you in advance!)

Switching to Wayland is easy. Launch the raspi-config application from a terminal window using

sudo raspi-config

and under the Advanced Options menu, just select the Wayland option – enable it, and reboot. You shouldn’t notice any obvious difference, but if you want to check if you are really running on Wayland, open a terminal and do

echo $XDG_SESSION_TYPE

Under X, this will return “x11”; under Wayland it will return “wayland”. If you want to go back to X, use the same option in raspi-config to disable Wayland. (Using Wayland shouldn’t change anything permanently on your system, but we do recommend taking a backup before you enable anything experimental like this, just in case.)

For now, Wayland is more something for the curious to play with than anything of interest to most users. But if you are curious, do have a play!

How do I get it?

The new image is available for download from the usual place: our Downloads page.

To update an existing image, use the usual terminal command:

sudo apt update
sudo apt full-upgrade

The rename-user script will automatically be installed on a desktop image when you update, but it will need to be manually installed on a Lite image, using:

sudo apt install userconf-pi

If you want to install the experimental Wayland support, you will also need to do:

sudo apt install rpi-wayland

As ever, all feedback is welcome, so please leave your comments below.

180 comments

Regarding the renamed pi user’s home directory, creating a symlink in /home to the new location is an easy way to catch any hard coded paths. I always do this when manually renaming users and it can save a lot of headaches.

Please, can you give details of how you do this?
Noobe here

Dead simple! From a terminal do:
cd /home && sudo ln -s newhome pi
Replacing newhome with whatever it’s been renamed to (probably the new username). Then anything that looks in /home/pi will be redirected to /home/newhome.

With Wayland, will Kodi work on it? Also how about Dual Screen support?

I’ve got no idea! Feel free to try it – as we said, it’s experimental. It’s far more efficient for end-users to try their particular use-case than for us to try and guess what all those use-cases might be and work through them all ourselves…

RIP all my youtube tutorials :'(
Seriously though, thanks for providing a way to set up a default user in headless mode. I almost exclusively use the Lite version and set everything up headless, so having a way to do this is super convenient.

Also, a note on the password creation from the command line. In bash, if you type a space before the “echo mypassword” command, it won’t log your password in the terminal history.

Add my thanks for accommodating headless first boot. That’s usually how I install Pi Zeroes and this will make that just a little bit easier.
Did I see an option to set the hostname? Ah… Can’t have everything. ;)

Yes, Imager does include an option to set the hostname, in the same Advanced settings menu as the rest of the customisation.

Ooh, top tip re how to not put the command in history! 👍

Hello. I have a Raspberry Pi OS (Legacy) and the command “sudo rename-user” does not work. what should I do to rename my username? THanks.

When you say it “does not work”, what do you mean? What error message do you get?

Did you update your image using the sudo apt commands at the bottom of the post first? And are you running the latest – bullseye – version of Raspberry Pi OS, or something older? This will only work on bullseye images with the latest updates.

the error I get is “command not know”
I am using Raspeberry Pi OS Legacy, not Bullseye.
How can I change my user name if I am using Legacy?

The process for changing user name is quite complex, which is why we wrote a tool to make it easy. We don’t recommend doing it without the tool (not unless you know what you are doing anyway).

I’d strongly recommend updating to bullseye if you are concerned about security – it has all the latest security patches and a more secure version of Chromium – legacy versions are more vulnerable as a result.

I also would like to upgrade to Bullseye, but I use a program called CubicSDR that has a few bugs with Bullseye, but works very well under the Legacy OS. That is why I have not upgraded to Bullseye.

If we are now required to use the Official Raspberry Pi Imager App to setup headless installs, it would be really nice if the app could handle most if not all of the same settings that are done through raspi-config. If you are going to have a setup utility, please make it more functional. Seriously, what a pain to have to run the imager utility just to get an SSH connection on first headless boot, and then have to run another setup utility after boot. Just have it all done in the imager app so we can just boot and go.

i had the same issue. I am on a lite install on a pi zero, did the upgrade, and rename-user gets “command not found”
pi@zero:~ $ cat /etc/os-release
PRETTY_NAME=”Raspbian GNU/Linux 11 (bullseye)”
NAME=”Raspbian GNU/Linux”
VERSION_ID=”11″
VERSION=”11 (bullseye)”
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian

The fix is the same as quoted before – “sudo apt install userconf-pi” is needed on a Lite image to install the rename-user script.

While I understand the ‘why’ here, this is really going to break a ‘lot’ of folks. I would have hoped that you would have rolled out the new features in this release while still letting the default pi user exist until the ‘next’ release. Just making this change in one big step is a really bad idea.

We are not getting rid of the “pi” user on existing installs.

We are not stopping anyone from entering “pi” and “raspberry” as the username and password on a new install.

So I can’t see how this is going to “break” anything for anyone.

All we are doing is making it easy for people who care about security to not have a default “pi” user – which is something people have been requesting for some time now.

And as mentioned in the post, this is going to become a legal requirement over the next few years anyway; it will become illegal to sell a connected device with a default login. So we are giving people plenty of time to switch things over.

Hi Simon, what is the best way to submit related bugs we encounter in this process. I have a class of 35 students setting up headless devices for the first time this week, and I’m not having a great success rate with the new version of the imager. I have successfully built an image, and so I know it’s possible, but there have also been a lot of failures with what seems like such a straightforward process.

I also found it interesting that we’re seeing the same behavior for students installing the 01/28 release with the latest version of the Imager. Does the newest Imager modify the first run behavior so that it wipes out the Pi user or removes its password? I haven’t tested this process yet myself, but it seems to be the case based on students being unable to connect even with the old image.

To take your second point, no, the Imager shouldn’t apply the pi user changes to earlier images – but bear in mind if you use it now, it will automatically download this image anyway unless you explicitly give it the 1/28 image to use.

Imager bugs can be reported under the Imager GitHub repo at https://github.com/raspberrypi/rpi-imager

Thank you for the link. I’ll thoroughly verify on my own end before reporting any of these issues.
For the issue with the older image, the student did manually download and select the 01/28 image. We tried this after rewriting a couple of times with the latest release and pre-configured credentials (via advanced options). Looks like I might need to rule out issues with the microSD or their PC.

Thanks for the update Simon. For those who are used to the default user ‘pi’, and all that it entails, can you explain or advise how one should go about adding the ‘new_pi` user to all the groups (e.g. bluetooth) that `pi` was part of, and setup of the “password-less” sudo for ‘new_pi’? Will there be a script released at some point to take care of this? Last question: Has The Organization hired new staff to deal with the flood of questions that are surely coming?

If you use the rename-user script, it will automatically put the new user into all the groups of which the old user was a member, and it will retain the passwordless sudo status of the old user. Similarly, when creating a new user with the wizard, it is automatically created as a member of all the groups of which the pi user used to be a member, and it will be set up for passwordless sudo automatically. So this is already handled – there is no need for further scripts or manual intervention.

Is it really hard for you to save people from torment!
by adding a vertical keyboard before boot?
I always have a laptop without Ubuntu and a monitor and only a mouse.
For 3 days I did not find any way out suitable for Windows 10
I can’t use the Pi Imager, I also connect via ssh, but the login and password are no longer valid.
I need to figure out how to set up a repeater network manager

The thing is, if you make a mistake when creating, or entering, the hash of the password into userconf, you will be forever locked out from fixing your mistake… you only get one opportunity to do this on a headless system. The only way out is to rebuild the system and try again. What a waste of time! All to provide the illusion of improving security.

Thanks for this upgrade, good job folks!
Any word about the kernel version bump (5.15) according to the release notes ?

Any picamera2 updates?

1. Does this apply to Lite images?
2. How do I pre-install my ssh public key and disable password logins under the new system?

1. Yes
2. If you flash an image with the Imager application, it allows you to preinstall an SSH key and disable password authentication

Can I still do it without the imager?

We’ve not removed any of the options that already existed for preconfiguration; so whatever worked before in terms of placing files in the boot partition should still work. You will probably need to add a userconf file as described in the post to set the username as well though.

I’m not aware of any way to get ssh keys into the image via the boot partition. The previous method was to mount the ext4 partition and copy the key into /home/pi/.ssh/authorized_keys. Can you confirm the new thing won’t break if the user’s home directory exists and is not empty when the first boot script runs?

That is unlikely to work.

Is there some reason you can’t just use Imager? It is specifically designed to address your situation; it works on Windows, Mac, Linux and Pi; it is free, and as you need to flash a card anyway, you need to use *some* flashing tool, so why not use the one that solves your problem?

It cannot replace existing tooling because the customizations it can make are far too limited, and it cannot be integrated with existing tooling because the customization options are not available on the command line.

It would be great if it was possible to provide an SSH key in the userconf file for people who need to set things up without any user interaction at all.

You can pre-set an SSH key in the advanced options in Imager.

One correction, the provided OpenSSL command does a one way hash of the password, it’s not encrypting it.

Apparently an existing installation does not get rename-user. Not found in repo and not installed following “apt-full-upgrade” (On an existing “Lite” install.)
:(

It’s in the package userconf-pi, which is installed as a dependency of the first-boot wizard. So it will need to be manually added to Lite images. sudo apt install userconf-pi should work.

Hey, will there be a CLI tool for the rename-user tool in the future? my Pi 3 does not have any Xorg

There already is – if you type exactly the same command (sudo rename-user) into a CLI-only install, you will get a CLI equivalent.

Does not work for me

On a Lite image, you need to do “sudo apt install userconf-pi” first to install the relevant script.

These changes are fine and I really like the new installer features. But I do miss xrandr under wayland, any substitutes?

As we said, a lot of stuff doesn’t work under Wayland, and we really don’t recommend people use it yet!

I believe that if you set up a monitor configuration under X, and then switch to Wayland, your X monitor config will be retained in the Wayland environment. So try using the Screen Configuration tool before switching to Wayland.

Thanks for thinking of those wanting to do a headless setup – the advanced section in the Pi imager is such a good feature, glad it has been made more discoverable in recent releases.

The Release Notes start “Default â€œpiâ€ user” – presumably this is Unicode (and I haven’t tried to convert) BUT surely the Release Notes should be plain text.

Please extend the userconf.txt mechanism so that if the username:password line is followed by an ssh key that new user is set up with that key.

For more complex preconfiguration like that, it is much easier to just use Imager to flash the image, and set up SSH keys in the Advanced settings on there.

Awesome, and happy to hear about the new way to create a user headlessly. Like another commenter, I pretty much use that method exclusivly. Out of curiousity, Raspberry Pi OS now has a lot of these initial setup/bootstrap options now. I’m thinking it might be better architecturally to adopt something like cloud-init for them. It would be super handy, and simple, to be able to drop a cloud-init.cfg (or some file name) in the boot directory and have all that functionality. Enabling SSH? Check, add a new user? Check. Add multiple users, each with their own authorized_keys files? Check.
It seems like it would be straight forward to set up and I don’t think it would add much overhear, either.
Thoughts?
Thanks for a great OS! It’s my son’s first computer. :)

The userconf / userconf.txt makes me wonder, do you have a similar facility for setting the wifi country code on headless installs?

Explanation below:
Last headless I did, (bullseye) a few months ago I’ll admit, had the wifi locked down until the country code was set in the raspi-config – this made it kinda annoying to configure in a network without wired available.

And yes, I did set the country code in my wpa_supplicant.conf in the FAT partition.

I get it that many just copy’n’paste the wpa_supplicant.conf, but can we get a wificountry.txt or similar where we can put the country code or something and have the boot-scripts disable the disabling of wifi?

If you don’t set the wifi settings in the /boot/wpa_supplicant.conf file, and you don’t have ethernet, are you setting the wifi via console (keyboard/mouse)? There is a setting in raspi-config:
Localization: L4 WLAN Country
for the country. I can’t see any reason not to use a full /boot/wpa_supplicant.conf file, though if you are not using ethernet, as the info is available to users under /etc/wpa_supplicant/wpa_supplicant.conf after full biit (and it’s removed from /boot during cleanup)
Do you have a unique use case?

My question was how to get it to disable the disabling of the wifi without having to hook it up to something (or just modifying the files on the ext-partition manually – finding out how to do that was the annoying part)

As I wrote, I did set the country code in the /boot/wpa_supplicant.conf , and I did a headless install (so no monitor, keyboard, mouse, nor anything usb expect power).

My issue is that _even_if_ you set the country-code in the wpa_supplicant.conf the new raspbian versions keep the wifi disabled up until the country code is set via the raspi-config – which is a bit hard to run in a headless (no keyboard, mouse, monitor) setup when you can’t ssh into the system when at a place without wired access (due to wifi being down).

My further musings was to get around that people set the wrong country-code due to many just copy-and-paste config-files without reading them.

I’m well aware of the config-options in raspi-conf since I had to vivisect it to find out what I had to do manually to get the wifi working.

I don’t consider it a unique use case to expect to be able to just dd a raspi-lite onto a card, copy in a wpa_supplicant.conf to /boot/ and expect the thing to connect to the wifi.
(Really, the disabling of wifi up until you run the raspi-config kinda makes me question what the idea of /boot/wpa_supplicant.conf is on the new raspi images, since if you need to log into the system anyways…)

This is a new bad behaviour, got introduced in the run-up to bullseye on RPi.

I copy my known working wpa_supplicant.conf file into the /boot partition as part of the imaging process when using a Raspian I didn’t generate (I also use Pi-Gen to ‘roll my own’).
I just tested with 2022-04-04 desktop & lite, and both work on first boot, enabling WiFi so that I can ssh into a PiZeroW, and a PiZero with a Tenda USB Dongle. My wpa_supplicant.conf (for the US):
– – – – –
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=US
network={
ssid=”SSID”
psk=”password”
key_mgmt=WPA-PSK
}
– – – – –

Keyboard layout handler is not working properly, as I am not able to switch between ‘Indian’ and ‘US English’ keyboard layouts. 32 bit Buster Edition do not have this problem.

We really Need pre-compiled drivers for most commond WiFi cards.

There are pre-compiled drivers for all Pi wireless hardware included in the OS. I don’t understand why you would need drivers for anything else!

Maybe they use hats (cellphone-type) or non-supported USB high powered LoRaWan or WiFi devices. There are a number of fairly common USB WiFi devices I have to add (Gigafast ZyDAS ZD1211 being one) and since I use Pi-Gen, it’s auto added into my custom images.

Exactly, i have various USB WIFI sticks.
All of them are RTL based hardware, the oldest ones works well without any configuration needed. Newest not.
Since kernel 5.10.73 we had Mr.Engman scrip but he stopped compiling drivers right now.
We are in trouble!

Because users of Pi 0 non-W machines generally have a lot of trouble and time wasted for compile really commons drivers every time!
Just a little suggest!

In general, the only drivers we maintain are those for Raspberry Pi hardware. Your best bet is to try to get third-party wifi drivers upstreamed into Debian, from where they will automatically be included in RPiOS.

We create custom Raspberry Pi OS images for our CM3-based products. We start with the Raspberry Pi OS images from you, but then we install additional software to support our hardware.
What procedure do you recommend for an OEM-like experience, where the OEM needs to add additional software to the system, but then still let end users run the wizard on first boot to customize their usernames, hostnames, locale, etc?

I’d suggest looking at PiGen

https://github.com/RPi-Distro/pi-gen

Not for the faint of heart though, but this is how we create our distributions in the first place.

Is this functionality (forced user rename) going to be force-pushed into Pi-Gen? The functionality is already built into the config file. I use it for a number of clients for custom images, and it’s a mostly great tool.
As an aside, since it is used to build the primary images you distribute, why couldn’t the same file be used for 1st boot in partition1?

Hi Mike – I’ve just done the same, I used a process based on https://github.com/nmcclain/raspberian-firstboot – this let me use an almost completely stock Raspbian image to download a script from a URL and run it on first boot. The development cycle with this approach was orders of magnitude faster than trying to do all the customization in the image itself.

I can find legislation in the US, UK, and other countries that forbid default passwords, but I’m unable to find new regulations about usernames. Is there any? In any case, it’s still a good initiative to remove the default username for improved security.

Our assumption is that such legislation has been drafted by non-technical individuals, and that “passwords” should actually be “login credentials”. But as you say, in any case, it makes sense to not have a default username as well as not having a default password.

Does trying to configure a headless zero with the lite image fail for anyone else? I’ve tried both wireless networking and with an ENC28J60 ethernet device.

When I connect a monitor and keyboard to debug, I see the userconf dialog and it just goes into a loop of asking me to configure the keyboard, which I do, and then it proceeds back to starting over with configure the keyboard again.

Where is the source to the userconf-pi package?

Where is the appropriate place to report this bug?

Problems like the one you mention are due to one step of the process failing – the userconf process will loop through the keyboard and user setting if any part fails.

The userconf-pi package is at https://github.com/RPi-Distro/userconf-pi – currently private, but should be made public in the next day or so; that is the best place to report issues. The source for userconf can be downloaded from apt.

rename-user didn’t work very well on an existing bullseye system. System hung after rebooting. Power cycled system; ‘pi’ user still there, except that its group ownership (not user, however) had changed to the new username. Another reboot & it hung again.

I’ll try again with a vanilla install.

I failed to mention that it’s hanging where the background looks like appears with the rename-user prompt window, except that there’s no login prompt, not any other UI.

Did not test it yet.
But if the desktop isn’t working, I already know I’ll bump into trouble.
For up untill now I had to change the keyboard to Belgium via /preferences/configuration BEFORE i can make a new password.
Well, surely this is possible by just trying the keys, trial and error, but what If your arabic or chinese?

The first-boot wizard specifically runs the keyboard setting page before prompting for password, as does the command-line version in the Lite image.

Does this including picamera2 and upgrading python3.10(previously 3.9.2)?

Debian Bullseye uses python 3.9.2. We won’t change that.
https://packages.debian.org/bullseye/python3

Thank dom.

Will Wayland break RealVNC (and Anydesk) like it doesn on Ubuntu?

As I said in the post – “there are many features which are not yet supported under Wayland. (To name a few – taking screenshots, the screen magnifier, any remote desktop application…”

So yes, Wayland will break RealVNC.

Lst raspbian release, just launched sudo rename-user, rebooted and i see no wizard to change the username, Now my GUI is just an empty screen with a nice wallpaper (all via VNC): i can only operate via CLI. I don’t wanna connect an HDMI screen. How can i solve this?

I don’t think it is going to be possible to rename a user over VNC. VNC requires you to log in to a session as a specific user, and the rename-user wizard runs as a different user from the desktop (as a user cannot be renamed while logged in as that user). So once the Pi reboots as the wizard user, the VNC connection will become invalid and break.

Running rename-user will probably require you to be a local user, not logged in via VNC. Or at least, I can’t think of a way to do it via VNC!

Here is a way to do it when using VNC or ssh remotely.
Create the userconf.txt file in /boot as described in the post.
Then sudo rename-user.
Because of the presence of the userconf file, the wizard will be skipped, but the user will be renamed.
Just tested this on my Pi4B and it works.
Of course you need to update your VNC entry to use the new username

That’s a good solution – many thanks for the suggestion!

I tried this using userconf.txt file. It did rename the user. But the password is not working. I hashed it as described here before adding to the file. The SSH key still works so have access, but don’t know the password.

I’ve just double-checked this here with a new image and a newly-created userconf file, using the openssl command in the blog to create the hashed password, and it worked as intended – the password was set correctly. I suspect something may have gone wrong in your password hashing, or perhaps you accidentally hit another key while cutting and pasting it, something like that? It is quite hard to spot when you have a typo in a hashed string like that.

Does the new system still create a terminal session for the default user? Advice us to disable using the config tool but (my reading of) the options seem to only allow you to disable it and the autologin to the desktop.

I can still log on to PI and operate my raspberry via CLI, but even using an HDMI connection i see that “empty” GUI.

Something seems to have gone wrong with your configuration in that case. If it helps, you can use ctrl-alt-T to open a terminal window in the wizard environment – from there, you might be able to restore things. “sudo cancel-rename pi” will restore your original pi user if the rename process crashed before completing, which sounds like it is what happened here.

Thank you for all the recent improvements, particularly allowing the default user id to be customised.
Could I ask you to consider recording the name of the image file within the installed OS. This would be so helpful further down the line when one is trying to resolve issues.

cat /etc/rpi-issue | grep reference will show the original image

Thank you, that’s very useful, but it’s not the complete picture; it’s missing “lite”, “wdesktop”, “wdars” etc.. The image file name would give one all the information.

I use a script to query images https://raspberrypi.stackexchange.com/a/85016/8697

Thanks.
That was a headache. Thanks for the Tylenol Mr. Long. I also learned some new stuff.

I really dislike how computer companies, websites, and software companies protect us from ourselves. My Raspberry Pi’s are only used on a hardened internal network. Obviously Raspberry Pi doesn’t realize how much time it is going to take me to re-write all my home brewed software. :-(

Well, if you had written your home-brewed software without hard-coded users and paths, which is universally regarded as best practice in the Linux world, you wouldn’t have to rewrite anything! ;)

And even if you don’t rewrite anything, it is entirely your choice whether nor not to rename the “pi” user; we’re not forcing you to do so. You can leave it alone on existing images; you can call the default user “pi” on new images. But bear in mind that in future, legislation – which is completely out of our hands – will mean this is no longer the case, and the “pi” user will no longer be usable.

All we are doing is giving you a few years to prepare for when that happens. And making it as easy as possible for you to make the change. I’m not necessarily expecting to be thanked for this, but it surely doesn’t warrant a complaint?

“But bear in mind that in future, legislation – which is completely out of our hands – will mean this is no longer the case, and the “pi” user will no longer be usable.”
So, once you make this change, I won’t be able to set the user to something I want? What about the ‘hard coded users: root & admin, and all the other users in /etc/password or /etc/shadow or wherever? I think this is a specious argument, personally. Making setting a username mandatory is a judgement call, and having the option there is a Good Thing(tm). The rest is ???

As I said, it will be out of our hands – we don’t know what the detail of the legislation will be, but whatever it is, we will have no choice but to abide by it. If that bothers you, you need to take it up with your MP, not with us – we’re not making the law; we’re just doing our best to be in a position to obey it when it happens. You could argue that the lawmakers concerned have a poor understanding of technology and are hence making a poor decision – I couldn’t possibly comment…

That said, I cannot think of any particularly strong argument in favour of allowing the use of a login which could constitute a known security vulnerability; one of the things the law is frequently used for is to protect people from themselves.

Pretty much any modern Linux distro won’t let you log in as root, or any other system user, out of the box. If you’re in the habit of enabling root logins manually, some may question your sanity, but nobody is going to stop you.

One last question. Can I clicked updater’s icon?

FYI, the OpenSSL command to compute the hash won’t work quite right as written since `echo` appends a newline to the password. I’d use `echo -n ‘mypassword’ | openssl passwd -6 -stdin` or `printf -n ‘mypassword’ | openssl passwd -6 -stdin`. An even better option for some would be to just run `openssl passwd -6` and forego writing the password on the command line (which by default will be written to shell history).
If you’re trying this out and wondering why you get different results when repeating the command, it is because the SHA512Crypt algorithm factors in a random salt value to prevent cracking with pre-computed hashes. As was mentioned by others, the result of this command is actually a hashed version of the password and not encrypted!

My version of OpenSSL (1.1.1, as shipped with Ubuntu Focal) just ignores the trailing newline: it gives the exact same hash with or without it, provided I request a fixed salt.

I do like the idea of creating your own username/password up front. One of the things I always had to do (in my home network) after installing a new image is to give the user ‘pi’ another uuid (and fix up where needed) and then add my own username(s) to the system so they have the same ids as the rest of the systems on my network. nfs, for example, is picky about such things. This addition will simplify my initial setup going forward! Thank you. Thank you.

Oh, and I run headless most of the time using ssh to get in, so the instructions above will be helpful for setting the initial user.

How about to release a desktop version of Raspberry Pi OS based on Ubuntu? The same way, Armbian does.

WHY ???? Ubuntu are abandoning support for ARMHF, so are you suggesting that an ARM32 Operating System is no longer offered and all BCM2835/6 SoC base RPi Boards become obsolete ????

Of course, I personally do not care about 32 bit, I care about RPi4 performance as a reasonable desktop. Keep 32 bit system and hardware for your 32 bit Debian aka Raspberry Pi OS.

But if you find pleasure of running desktop system on 32 bit chip which was announced 12 years ago accompanied with Videocore 4 GPU both probably targeted to low-cost TV set to box market than it is a different story, but for me it is dead, no matter how much it is recycled. But keep in mind that if ever RPi4 Vulkan driver will mature to usable condition, it can potentially accelerate Gnome desktop also (Gstreamer, GTK4, potentially Wayland) , but anyway, these attempts of adopting Wayland were here already in 2013 even for the earlier RPi models:
https://www.collabora.com/news-and-blog/news-and-events/collabora-brings-wayland-and-x11-graphics-performance-to-raspberry-pi.html
Moreover you have a decent desktop here:
https://www.youtube.com/watch?v=LffWfaROgNw
But my suggestion to run Ubuntu, because development of Wayland/Weston/XWayland started very long time ago and as far as I know these days, the problem is not Wayland itself but native application or XWayland application support and I PERSONALLY think that Ubuntu and Fedora have by far biggest experience with Wayland adoption integration to entire desktop distribution. Moreover Raspberry Pi also serves a desktop distribution like Armbian does, so why not to take advantage of work of another participant in the game, I mean the open-source game, we all benefit from GPL building work on top of others work. I personally do not agree with the fact that Ubuntu is based on Debian and therefore it is the same as Raspbian/Raspberry Pi OS. Debian and Ubuntu differ quite a lot, Debian is just a start for Ubuntu to base it on and it is tuned for desktop use, Debian has different purpose. Anyway, do you think the guys working on Armbian are not so smart to differentiate their desktop and server edition? They support far more SoCs than Raspberry Pi OS with bcm2835 and bcm2711, generally tens or if not hundreds. But feel free to correct my opinion.

Moreover, I think Debian with armhf never supported bcm2835, it is arm v6 not arm v7. Support is custom. Takes probably a lot of work to keep it supported, armhf community probably does not do builds for it. From my point of view, it is another reason why to get rid of it. It is legacy, but I understand a lot of units were sold and a lot of people are using it.

Armbian cherry pick what they want to support, they did support ARMHF ARM32 but chose like Ubuntu to ditch ARMHF ARM32 support.

RPi OS (Raspbian) is Debian ARMv7 compiled for ARMv6 but many packages just *work* as is.

Raspberry Pi Trading still sell the BCM2835 Zero and will do for a few more years, an Operating System Is far more than a fancy Desktop Environment.

I personally prefer to run Debian rather then be at the mercy of Ubuntu with their own kernels and going down the “snaps”
Packaging.

I can’t see what that would achieve. Ubuntu is based on Debian, just as RPiOS is; the difference is the desktop environment. So a desktop version of RPiOS based on Ubuntu would be exactly the same as what we ship now!

I personally think that if you base Raspberry Pi OS on Ubuntu, the rest of the system will be tested by far more users and you can focus on tuning the kernel and all the other stuff which must be fitted to RPi hardware, but you are the expert to tell me more. Why does Armbian use Debian for server and Ubuntu for desktop edition?

The core system – Debian – will be tested just as much in either case; Ubuntu upstream their fixes to Debian. The only parts of the system which will be tested more in Ubuntu than in Debian itself are the parts which are Ubuntu-specific, and those are just desktop components, which we wouldn’t use anyway.

I replied to your answer for the guy in previous post so feel free to correct my opinion. Thank you

You can satisfy some of the people all of the time, and all of the people some of the time, but you can not satisfy all of the people all of the time.

You guys at Raspberry Pi are doing an outstanding job and I think you should just be left to get on with it.

Thank you for the explanation. By the way, what happened to Maynard project you started in 2014?

It was shelved fairly soon afterwards and has not been looked at since; it turned out to be a dead end and there were better ways of getting a hardware-accelerated desktop.

I have found an issue:
If you use the userconf file, you don’t get any of the other setup options, such as enabling bluetooth. I don’t have a problem ssh’ing in, then running raspi-config to enable VNC, but it would be nice to have the bluetooth keyboard discovery option…

Not possible, I’m afraid – the whole point of the userconf file is for people who do not want to run the wizard. And if you want to connect a Bluetooth keyboard, then you surely are using the Pi locally rather than over VNC anyway? I can’t see why you would want both a remote VNC connection and a local Bluetooth keyboard?

I had a big row with the OctoPrint people over this. Everything is hard coded to use “pi” and I have always removed it from every install and put my own user in so couldn’t get their stuff to work. In their eyes I am an idiot. C’est la vie.

Well, with any luck, our making this change will persuade them to do the right thing in future!

After running “sudo rename-user”, I lost my cronjob. Is the file still there?

If your cron job was in the system cron file, then renaming the user shouldn’t have touched it. If you had a local cron job, it should still be in /var/spool/cron/crontabs/pi – I suspect you’ll proably need to move it to /var/spool/cron/crontabs/your_new_user_name.

Why this time wasting solution?
Just because some people are not able to change passwords? Sorry it is stupid.

If you’d read the post properly, you would see that it is nothing to do with changing passwords. It is to do with changing usernames, which is a far less trivial task in Linux than changing a password.

If you want to change the default username, this solution wastes a lot less time than trying to work out how to do it otherwise.

Installed the new Lite version on a new Samsung 32gb card, launched it on my Pi 400. Have set up wireless a zillion times but I keep seeing “device not ready” (network-manager-gnome). SP working fine, SSID is correct, no security, device is selected. Is it possible that the driver was omitted from Lite?

Installed the new 64 Bullseye Lite on a fresh Samsung card, booted on my Pi 400 where everything has worked perfectly. I’ve installed wireless a million times but I keep getting “device not ready” (network-manager-gnome) or AP not associated on CLI. AP works fine, SSID is correct, device identified, no security–still zip. Is it possible the Broadcom wireless driver was omitted from the Lite version?

We’ve checked this, and wifi works correctly in the Lite image. However, we don’t use network-manager-gnome, so it looks as if something you have installed is causing the problem.

(Not sure if you’re still following comments…)
Thanks for testing it. We’ve been testing it as well and it is clear that it works normally as long as the AP has a password. It is failing for me using SOP on an open AP, so I wonder if you have tested it on such an AP? As I mentioned, it is perhaps relevant that the Imager’s advanced config will not accept an empty password.

I’ve opened this as a bug: https://github.com/raspberrypi/rpi-imager/issues/424 because I need to connect to open WiFi APs also.

Oh, seems I forgot I reported this bug earlier and they closed it as ‘won’t fix’ : https://github.com/raspberrypi/rpi-imager/issues/318 though I wholeheartedly disagree with their answer. So if it is important to you, go on the issue tracker and let your needs be known on either or both issue #s.

If this is true, I’m pretty surprised that RPi would be so unprofessional about this. I know of no distro that would make a new release and fail to correct a significant bug when notified.

I am having the same issue, did you find a solution. In the end, I am using other WiFI device, but I don’t want this as a long-term solution!

I run pi’s headless. Tried to run headless bullseye on a pi3b. I’m not a script kid, however I am good at editing and copying scripts if the code is shown. I tried to create a userconfig about 4 times in the root. I’ve looked up and down and can’t find an example. Please excuse my code ignorance, but can someone just show an example like user: foo and password: bar?
:
username is foo? encrypted- password? I opened up ssh on an existing pi and ran
Where do I paste the string? Do I replace “encrypted” with the string? Do replace “password” with bar?
If I mess up do I need to run a script to revert back to default 1st boot?
Thanks,

Here is the contents of an example /boot/userconf file:

test:$6$FdsTan/zaR7eKb8B$mSgk/5q/IFMYOVf2e/NdnUfWBi9clSciE1XD2bHsFNDko0k05zouZkbOPjUeDAYTdkLeWWEwjw5Bow0/le/uv1

This sets up a user called ‘test’ with the password ‘pass’ – although bear in mind that if you create an encrypted version of ‘pass’, it is unlikely to be identical to this one, due to the use of what is called a salt to add additional randomness.

Simon, Thanks for the example. So it is just:

Thanks for quick response, I will give it a whirl

Hello Simon,
In Bullseye version there is/was a bug with the keyboard layout handler. To be exact, even though second language can be added in keyboard layout handler settings, changing language from keyboard shortcuts is not working. At least that was the case in previous bullseye release. Does this issue being addressed in latest release ? Cause it’s a deal breaker.
Thank you!

The keyboard layout switcher has never been something we have supported, and it is not compatible with mutter, the new window manager being used under bullseye. Mutter has its own mechanisms for switching between multiple keyboard layouts, which work with hotkeys in mutter itself and do not require the use of the layout switcher at all – I suggest you investigate those.

I will look into that. Thank you for your quick reply !! :)

I have the same problem with a fresh install of the latest image (04/04/2022) on my pi400.
Once the VNC server is enabled from the Interfaces section of the Raspberry Pi Configuration app and reboot, the keyboard layout handler is working as before.

I tried enabling VNC server as you said in my fresh install of Bullseye 64bit, and now Keyboard Layout Handler works as a charm. Do you know why/how does this works? Thank you

It works because enabling VNC disables the new mutter window manager and re-enables the old openbox window manager. The keyboard layout handler is incompatible with mutter, which has its own mechanism for switching keyboard layouts.

Thanks for your answer Simon. I managed to find a way to switch keyboard layouts in Mutter: (1) Remove the Keyboard Layout Handler from the panel. (2) Install iBus [sudo apt install ibus]. (3) Reboot. Later you get an iBus symbol (keyboard and planet) in the taskbar. Right-click on in and select Preferences > Input Method: You can select your layouts here. The default shortcut for switching keyboards is Super+Space, but it didn’t work for me, so I changed it to Alt+Space in Preferences > General > Keyboard Shortcuts > Next input method. Also, if you left-click on the iBus symbol, the list of your layouts/input-methods is displayed. One left-click should be enough to select a layout, but this seems to be buggy, so I needed to left-click multiple times on a layout to get it selected. Some people also use iBus to input japanese and korean, see [https://raspberrypi.stackexchange.com/a/127722] and [https://dhhwang89.tistory.com/50], which requires additional iBus packages (ibus-mozc and ibus-hangul respectively).

Thank you so much, Cristian – that is really helpful! I have spent the last few days trying to understand mutter’s layout switching code, and have discovered that some key parts of the functionality are completely missing – it may well be because it assumes ibus will be available. I’ll have a play with it – thanks again.

After today’s 23/05/2022 updates (I suppose the lxpanel package update), the language selector is working fine when using mutter. The icon is grayed but it is working either when using the keys combination to change layout or by clicking on the icon. Thanks!

As per the instructions on this page : To update an existing image, use the usual terminal command:

sudo apt update
sudo apt full-upgrade

Ran the above. Rebooted…
ran cat /etc/os-release in terminal: Returned:

PRETTY_NAME=”Raspbian GNU/Linux 10 (buster)”
NAME=”Raspbian GNU/Linux”
VERSION_ID=”10″
VERSION=”10 (buster)”
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL=”http://www.raspbian.org/”
SUPPORT_URL=”http://www.raspbian.org/RaspbianForums”
BUG_REPORT_URL=”http://www.raspbian.org/RaspbianBugs”

:) Still on Buster? What am I missing?

You cannot update a buster image to bullseye just by doing an apt update – by default, an apt update will only update within that major version of Debian. Updating from buster to bullseye is possible, but not recommended; it is better to start with a clean bullseye image. If you really want to update a buster image to bullseye, have a look at the blog post on here for the launch of bullseye; it contains a link to a set of instructions which should work – but take a backup first; you try them at your own risk!

Thank you.

Hi Simon
Thanks for all the info. I am running KDE Plasma as my desktop and the rename user script does not work (nothing happens on reboot). I have tried from the default session, but no result. Can you suggest a way of getting the script to work?

Sorry – I don’t know enough about KDE to know how to run the script under that. I suggest, if possible, you temporarily configure your Pi to boot to the command line rather than the desktop, and just run the script in the command line instead.

Tried to burn a new image to SD this morning with no joy: my Pi400 just sits there flashing an underscore right at the point the initialisation process used to run the partition resizer before rebooting.
I’m using my own install script now with user creation as detailed above (script: https://github.com/smittytone/scripts/blob/main/pi.zsh) in addtion to ssh and WiFi setup in in the usual headless way. Installing the previous PiOS release works just fine — I testeded it just now — but not the new one. Only difference is unpacking a .xz archive rather than a .zip one. Any ideas?

Thank you for making this change. I have always gone through the gyrations of creating a new user, granting them sudo, then removing user ‘pi’ on every new install. Making this part of the install flow is a huge improvement in my eyes.

I love the 64-bit Pi OS version, but I still see xrdp is broken in this latest image unless you add a second user, and that user is not a member of the render group. I tried removing the primary user from the render group (i.e. the first account you create when setting up Pi OS), but xrdp will still not work for this user, even if the xrdp session is the only login instance. This is a pity, as you need to be a member of the render group for graphics hardware acceleration to work. xorgxrpd can use graphics acceleration to improve xrdp session graphics performance, as its glamor enabled. I prefer to use my 8GB Pi 4 headless connected via usb-c ethernet to an iPad Pro with keyboard. The iPad provides the UI via Microsoft iOS RDP client which includes audio support (unlike iOS VNC viewer) … plus, other apps such as blink. I have this fully working on Ubuntu-Mate 21.10 64bit, along with audio support, but performance on Pi OS 64 bit unaccelerated is still better, especially audio, providing you disable mutter (I assume this is due to less overheads of Pi OS c.f. Ubuntu Mate?). I would love to get Pi OS xrdp session running with graphics acceleration, but the permission issue appears to be hardwired into the kernel?

“ZERO information on download site that anything has changed”

Yes, you’re right – zero information…

…other than the first item in the release note, which is clearly linked on the same page as the download:

“* Default “pi” user has been removed; the first-boot wizard enforces the creation of a new user account”

The release note is generally the first place to look to see if there are any important changes. Which is why we publish it each time along with the image. It’s usually not a bad idea to read it, particularly if you find something isn’t working…

So after this version, users are no longer allowed to remote ssh into raspberry pi without a monitor at the first login? sad

If you bother to read the article all the way through you will find, under the section titled “Headless setup”, how to configure remote SSH.

Hi,
I’m having an issue with the forced raspi-config.
I’m using Packer to provision a lite image which will then use the Raspberry Pi imager to set just the hostname.
All other configuration; wireless, keyboard settings, locale, removal of the pi user, creation of a new user is all handled by packer.
Even with the pi user removed, it still prompts to create a new user on boot and even worse, sets it to login automatically.
If I use the /boot/user.conf trick, it still sets that user to login automatically.
How I can I prevent the raspi-config from running on first boot?

Please look at: https://github.com/RPi-Distro/userconf-pi/issues/2

Grabbed rpi-wayland from apt, updated and upgraded, switched to Wayland with raspi-config aaanndd I’m still on x11? Help would be appreciated as my pi is solely for playing back video and Wayland might solve the slight tearing issues.

Wayland is very unlikely to make any difference to your video tearing issues; the video gets sent pretty much directly to the screen from the applications like VLC and Chromium which use hardware acceleration for video playback.

And it will probably only work properly on a relatively clean image; it seems that you don’t at present have to change an image much from the default for Wayland to fail to start.

Like we said, it’s experimental, and most people really don’t need to use it yet…

Ah gotcha that’s probably what happened, in that case I’ll just wait. Thanks for what you do, glad to see things are coming along.

If I place a userconfig file (without .txt extension) and ssh file in root directory and start the pi the first time on a display it tells me during boot:
‘[FAILED] Failed to start User configuration dialog.’
That several times. Then it continues to the Welcome screen. Most important: I can’t connect via ssh to the pi using the username and password which I provided in the userconf file. Is this a known issue?

Sorry, I meant “userconf” not “userconfig”.

We’ve just re-tested this, and it works fine for us. It seems likely that something in your userconfig or ssh file was not correct.

What is para ‘-6’?

All new images (lite 32-64, normal 32-64) are sending me all time to root locked. Updating from previous versions do the same. i changed 4 different SD cards. I just can run previous version on my pi 4 b. New usser prompt never appears. after load/save seed and rfkill, suse module inspection becomes and after that root user is locked message. Please i need help

I’m missing the ‘connected to the internet’ icon after entering the wifi password, which makes you unsure if the connection has been established.

Where is the camera module ? In the new image how to enable camera module to work?

The project I work with, Openmediavault, specializes in creating easy to use NAS servers with an Admin GUI. https://www.openmediavault.org
__________________________
In cases of supporting R-PI’s and other SBC’s, and in support of new users and Linux beginners, the server app installation process is done VIA SSH with a script.
Since the first time boot wizard is not triggered by SSH access, I’ve been forced to direct link to an older image until a work around can sorted out.
Please e-mail me, when it’s convenient.
Regards.

Extra info for the post above:
omvguide@gmail.com
Additional Web Site URL:
https://wiki.omv-extras.org

As someone that doesn’t keep up to date on Raspbian updates the new user thing took me an hour to figure out through reddit.

Anyway to hash the new user password on a non linux os WITHOUT having to homebrew openssl or downloading a yet another disk imager?

I have just used the image maker tool on my Mac to create anew Bullseye image for my Pi3b and I have to say it was a treat to use. Some much easier than the old way.
Thank you,
Bob

This had me stumped. Very much a case of rtfm, but may i suggest a note on the imager? Those using other imaging tools are in for some fun. Perhaps also a note on the Rasbian download page to avoid headaches?

The imager doesn’t make this option obvious at all, meaning you produce a headless image SD card and waste a good half an hour f’ing around trying to work out why pi/raspberry is now being rejected. Personally I think this is a bad change, the experience is now universally worse/more cumbersome in order to cater for people that – frankly – will *always* find a way to produce insecure installations despite your efforts.

If only it were half an hour. 1) it took me 5*that to find this note. 2) I don’t have a computer where the openssl command works. 3) when you do find the cog wheel in imager you aren’t asked for verification of your intended password, just being faced with the blobs.
Talk about unfriendly. It’s positively hostile.

What a disappointment regarding the Headless Setup! 1) Some of us who work only headless, do not have a monitor with a micro-HDMI interface. 2) Some of us cannot install the Raspberry Pi Imager due to library dependency issues or do not wish to install it because we have our own fine tools for that purpose, regardless if the Raspberry Pi Imager is free. 3) The ‘openssl passwd’ with the -6 option may not be supported in our systems (I was lucky that it run in a previous buster image that I had to setup from scratch). Is it really worth the so-called security to avoid providing just one hashed version of the ‘raspberry’ password, considering that consecutive openssl commands produce different results? So, to avoid wasting several hours of frustration with Permission denied, create a file called ‘userconf’ or ‘userconf.txt’ in the boot partition of the SD card with one single line (no linefeed at the end) with the following content and use ‘raspberry’ as password for your first login of user ‘newuser’. newuser:$6$DDAc06HDo9lQufr4$650WAMQfti/nChvgDJKVYdY2fb8gnH6XY50hIYoKKhdn14.RG9LkkDlWM0oNNnuJwaptzJsckYIqu.oi3J3ay/

Thank you! the -6 option kept giving me errors that I could not figure out. After reading your comment, I decided to try using an RPI with a newer distribution, and the command worked. I didn’t try your example hash, but I hope it is useful for others in this situation.
Many Thanks,
Marcus

Hi, could you update your official documentation regarding the default user and SSH? https://www.raspberrypi.com/documentation/computers/remote-access.html#setting-up-an-ssh-server
Thanks.

After imaging the raspberry pi when logging in for the first time by ssh. When I put the default password it is denied.

There is no “default password” any more – you need to create a user account to be able to log in. You can either do this through the first-run wizard, or in Raspberry Pi Imager when you flash the card.

Hey Simon:
Thanks for all you do. I understand the need and importance of security. I also understand that Buster is out of date, and I, and my students all upgraded to Bullseye.

I THOUGHT I understood that Raspberry PI was supposed to be a teaching platform.

That said – why does Raspian Bullseye BREAK the C programming language? GCC doesn’t work. You can’t even compile the simplest possible program
int main(){}
It no longer recognizes the all important stdio.h
Who do I have to beg to get this fixed? I have to retrograde all my students back to Buster to get C to work again! In this respect – Bullseye missed the mark.

Comments are closed

News

The new wizard

Headless setup

Existing installations

Bluetooth peripherals

One more thing…

How do I get it?

Latest posts

"Alexa, start the car": warm up your car remotely with Raspberry Pi

Raspberry Pi detects factory defects with machine learning

OnlyTrains: for fans of trains, and only trains

Meet Brian Corteil: CamJam event runner

Next Post

Code your own top-down Zelda-like | Wireframe #61

Previous Post

A watched stove never burns with Raspberry Pi Pico

Share this post

180 comments

Julian Yon

lwetzel

Julian Yon

Project xXx

Raspberry Pi Staff Simon Long — post author

Lee Carpenter

HankB

Raspberry Pi Staff Simon Long — post author

Alan Robertson

rick m.

Raspberry Pi Staff Simon Long — post author

rick m.

Raspberry Pi Staff Simon Long — post author

rick

LucidEye

geoff

Raspberry Pi Staff Simon Long — post author

Vince

Raspberry Pi Staff Simon Long — post author

Clinton Campbell

Raspberry Pi Staff Simon Long — post author

Clinton Campbell

Seamus

Raspberry Pi Staff Simon Long — post author

Артем Пазухин

Chuck Harris

Laurent

Secret-chest

Alistair Buxton

Raspberry Pi Staff Simon Long — post author

Alistair Buxton

Raspberry Pi Staff Simon Long — post author

Alistair Buxton

Raspberry Pi Staff Simon Long — post author

Alistair Buxton

Nicko

Raspberry Pi Staff Simon Long — post author

Jay Lee

HankB

Raspberry Pi Staff Simon Long — post author

Luna Jernberg

Raspberry Pi Staff Simon Long — post author

Luna Jernberg

Raspberry Pi Staff Simon Long — post author

Elwood Downey

Raspberry Pi Staff Simon Long — post author

Alan Robertson

Milliways

Tim Smith

Raspberry Pi Staff Simon Long — post author

Derek Murawsky

Anonymous

starbasessd

Anonymous

starbasessd

uday

TM

Raspberry Pi Staff Simon Long — post author

starbasessd

Tommaso

Tommaso

Raspberry Pi Staff Simon Long — post author