You can prepare in advance:
- before reboot, save a flag file that says "rebooting", then reboot.
Save it to a non-volatile location. /tmp is volatile. Normally /var/tmp shouldn't be but do check. Or use /home or even /boot.
- at every boot, search for the flag, and erase it so it won't be found again at next boot. If the flag was found, run your task.

You can also try using the "last" command: "last -x reboot", "last -x shutdown", "last -x runlevel" (discussion on SE).
Personally I find the output of "last" confusing, and the absence of RTC on a Pi does not help.

Look into runlevel.
Runlevel is set to 1 at initial boot. It increases to 4 when your operating system move ito multi user mode.
When you select reboot this is set to 6 it remains at 6 throughout the power down process

After the first boot from a fresh SDCard there's no difference between a boot and a reboot from an OS point of view. First boot of Raspbian does a whole bunch of stuff. First boot of NOOBS presents the "choose an OS to install" menu.

The main difference is if have you taken the power off and reconnected it (power on reset sets up the hardware peripherals from cold). That can't be detected by software which can't tell once it's booted and started long running services. You can force a power on reset with the microUSB still connected by connecting the _RESET_ pin to GND. Don't do that on a running system you could trash the filesystem on your SDCard or USB device.

So what are you trying to detect? Why is it important to you? On a clean shutdown you can find the time by reading the tail of /var/log/syslog you can see the boot with /var/log/kern.log and a dmesg command.

Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

Look into runlevel.
Runlevel is set to 1 at initial boot. It increases to 4 when your operating system move ito multi user mode.
When you select reboot this is set to 6 it remains at 6 throughout the power down process

Not with systemd it isn't, it disappered with the (uneventful) demise of sysvinit. Systemd got rid of all that runlevel junk in favour of "targets". There's no popular DebIan or Redhat based distro that still runs with sysvinit.

Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

As usual, no clarification from OP, so we are left to try to figure it out on our own.

My reading of the original thread was that he wants to distinguish between a cold boot (i.e., power on) and a warm boot (software initiated reboot). As has been noted, there's no real way to do this, from a software perspective and which is going to be 100% reliable (or close to 100%).

The obvious question, of course, is: Why do we want to know this? Only OP can clarify that.

That all said, I wonder if you get a heuristic of this by examining the "syslog" file(s) (or possibly other log files in /var/log) and seeing if there is a time gap before the last boot. The idea is that if the Pi has been off for a while, then gets booted, you might conclude that was a "cold boot", while if it was active (doing stuff - putting stuff in the syslog) just before being booted, then it was probably a "warm boot".

devuan isn't worth the pain. Get used to systemd and embrace the way it improves the boot process.

It doesn't improve the boot process, it takes longer to boot!
systemd is like the curates egg, good in parts, pity the good bits are so small

That's not my experience. My headless raspberries take less than 20 seconds from power on to usable. The thing that slows things down is the GUI. Adding a new service with sysvinit is a pain. Adding that with systemd is trivial.

If you want to beat your head against the wall with devuan then please continue to do so.

Note: Having anything humorous in your signature is completely banned on this forum. Wear a tin-foil hat and you'll get a ban.

At boot (power-up) the GPIO are set to a particular state with their pulls. The pulls are not affected by a reboot. Choose a GPIO and change the pull to the opposite of the power-up setting. You can then determine the pull in software and thus distinguish between boot and reboot.

At boot (power-up) the GPIO are set to a particular state with their pulls. The pulls are not affected by a reboot. Choose a GPIO and change the pull to the opposite of the power-up setting. You can then determine the pull in software and thus distinguish between boot and reboot.

Hey! That's actually a good idea. I'll have to test this at some point. Thanks!

N.B. The pull-up flag is set in the script so this will only return booted the first time the script is run after power-up. It might be desirable to move the pigs pud 27 u # set pull-up on GPIO 27. line to another script.