One's problem on working headless, is frequently to know the IP address that the raspberry has got from the router.
The best approach to get it from the routers DHCP info is not always possible.
Would'nt it be a good practise to report the IP assigned during the boot process in a text file called e.g. boot.ip in the fat boot partition?
So one could easily read that info (or error messages if not successful) from the sd-card on any computer and use it to ssh at the second attempt.

I mean to have it at the very initial run with no configuration, straight from Balena Etcher.
You can give in the wpa_supplicant credentials in /boot , so it would boot into WLAN, but you need the IP to do everything else.

If your machine is equipped with the same (Macs have it via Bonjour, PCs via ITunes, Bonjour or later versions of Windows 10, Linux via lots of programs) then you do not need the IP address as you can just use raspberrypi.local to access it.

If you then change its name(good idea by the way), it still shows on the network as <newname>.local

One's problem on working headless, is frequently to know the IP address that the raspberry has got from the router.
The best approach to get it from the routers DHCP info is not always possible.
Would'nt it be a good practise to report the IP assigned during the boot process in a text file called e.g. boot.ip in the fat boot partition?
So one could easily read that info (or error messages if not successful) from the sd-card on any computer and use it to ssh at the second attempt.

How is this supposed to work ?
1) Boot Pi
2) Pull power
3) Put card in PC and find IP in boot partition
4) Put card in Pi
5) Power on
No what if the DHCP server decides to change the IP address because of a) lack of addresses or b) policy ?
There is no guarantee that the same IP address will be offered on the second boot

No what if the DHCP server decides to change the IP address because of a) lack of addresses or b) policy ?
There is no guarantee that the same IP address will be offered on the second boot

I guess 99,9% of the private routers do assign IP addresses based on the mac and practically never change its address.
All my VNC clients run that way and I never experienced an address change, even if I never minded to chnge DHCP to fixed addresses.

If your machine is equipped with the same (Macs have it via Bonjour, PCs via ITunes, Bonjour or later versions of Windows 10, Linux via lots of programs) then you do not need the IP address as you can just use raspberrypi.local to access it.

If you then change its name(good idea by the way), it still shows on the network as <newname>.local

That might work... if you ensure that you always change the raspi's name immediately and you have got no other Pi with the initial name on the same network.

No, it does not work.
Just used a fresh SD card from Balena, with wpa_supplicant adapted on /boot.
It boots into WLAN at a given IP address, VNC activated.
VNC runs well from the numeric IP, not from raspberrypi.local. "the given name is unknown".

Ping to raspberrypi.local brings the same error.
Ping to [MyComputerName].local works.

So it is clearly the Raspberry that does not have avahi enabled by default.

That might work... if you ensure that you always change the raspi's name immediately and you have got no other Pi with the initial name on the same network.

No, it does not work.
Just used a fresh SD card from Balena, with wpa_supplicant adapted on /boot.
It boots into WLAN at a given IP address, VNC activated.
VNC runs well from the numeric IP, not from raspberrypi.local. "the given name is unknown".

Ping to raspberrypi.local brings the same error.
Ping to [MyComputerName].local works.

So it is clearly the Raspberry that does not have avahi enabled by default.

It does - did two machines yesterday - a Zero W with Stretch and a 3B+ with Buster

Only times I’ve know this to fail are:
1) The host machine has not got zero-config on it (Windows 10 often seems to have problems - I use a Mac)
2) The ‘switch’ or access point is a Plus-net router. Spent weeks with their tech support to be told - stick the issue on the forum as we do not know!

One's problem on working headless, is frequently to know the IP address that the raspberry has got from the router.
The best approach to get it from the routers DHCP info is not always possible.
Would'nt it be a good practise to report the IP assigned during the boot process in a text file called e.g. boot.ip in the fat boot partition?
So one could easily read that info (or error messages if not successful) from the sd-card on any computer and use it to ssh at the second attempt.

There's a problem with that: it's not guaranteed to get the same IP address on the second boot. There's a high probability that it will but that depends on a number of factors including how long between boots, router/dhcp configuration, and whether the first and subsequent boots use the same network hardware.

Writing uselessly to the FAT partition is not the best idea for boot reliability and for random bits of trivia /opt is a better place than /boot.

A custom discovery+provisioning service could be interesting I think.
Let's say mDNS already has discovery sorted.
Every Pi could run a client sending/fetching config from, e.g. pi-master.local, the service name of the server. Some sort of Cloud-init.

Writing uselessly to the FAT partition is not the best idea for boot reliability and for random bits of trivia /opt is a better place than /boot.

Yeah, but how many pi owners, especially those who need this functionality, have a PC that can read ext4 partitions? The point about writing to /boot is that it's a FAT partition and almost every device on the planet* that has the hardware to access uSD cards can handle FAT.

The current design is basic, it is also minimal. (Well it was until SSH had to be disabled out of the box)
Using the FAT partition as a user output area is not only futile (an IP address is volatile) and ill advised but in addition at runtime it means writing whatever you want in /boot...

The need for information/configuration on a headless machine is clear, but this proposition is not sound.

MAY be volatile!
Practically, on 99,9% of the private routers, it is perfectly stable.
I use to run many many Pis on IP addresses with VCN and had NEVER EVER got the need to configure them specifically for a fixed address.
The Routers just keeep the IP tied to the MAC...

Still having issues with the original need to be honest - with support for .local in one form or another on modern systems I’ve never struggled to find a Pi on the network when it’s configured correctly.

MAY be volatile!
Practically, on 99,9% of the private routers, it is perfectly stable.
I use to run many many Pis on IP addresses with VCN and had NEVER EVER got the need to configure them specifically for a fixed address.
The Routers just keeep the IP tied to the MAC...

99.9% is a little strong, it's unlikely that you have experience of that many routers. And it depends on a number of factors (see my post above).

If the machine is on when the lease expires it'll probably get the same address back but if not it may not. That depends on the ration between the number of client machine and the size of the address pool, and whether any additional machine have connected in the mean time.

OK to summarize, the best way to start comfortably a raspberry pi zero headless without any additional hardware would be:
-Get the image
-Burn the image with Balena etcher.
-Create a file in the /boot/ directory named wpa_supplicant.conf with this content:

I do a lot of development on a Windows 10 machine. I use it to burn my SD cards. I've installed Bonjour but for the life of me can't get it to find other computers on the network with their hostname.

What I think would be the slickest setup for people that have lots of Pis running headless using DHCP is to have a program that sends out a UDP packet on the broadcast address with their hostname and IP. You could listen using Wireshark or write a simple program to listen for ID packets and would know right away what computers were up and running. I don't know what is involved in getting a program added to the OS distribution, maybe somebody can enlighten? That way, you start your headless Pi and in a bit you have its address. If it changes on the next boot, you've still got it.