/proc/sys/kernel/random/boot_id stays the same #4517
Comments
|
Can you report output of |
|
It changes for me on a Pi3: |
|
Yes. It's ok on rpi3. But it reports the same version as the rpi0s I have edited my post above |
|
I confirm that downgrading the kernel to 5.10.52-4 makes it work back again. Maybe that is an archlinux packaging issue because the version of the kernel is the same |
I suspect reverting that would fix the issue. But the question is why is that isn't working on Pi0 but is on Pi3? |
|
I am not an archlinux packager. |
|
It's working for me on a Zero W (which runs the same kernel as the Zero, B+, etc.): |
|
I don't see any difference on a rpi0 W. Still the same problem. |
|
It would help if you could show examples (boot_id and the journalctl output) from a system producing the identical values - those in your first post are different. |
on this rpi0 W, even journalctl does not list the current boot_id. It is even weirder. I don't know what is the boot_id there. I am confused. The boot does not seem to be registered. Or may be a wrong time And for the rpi0 W, there are 2 boot_id..One for a cold boot, one for a reboot. but they stay the same. |
|
Do you have a spare SD card you could install RPiOS onto? Even a Lite version would be enough. Once installed, see if boot_id changes on each boot, then run rpi-update to get the very latest kernel, reboot and check boot_id again. |
|
Could you also confirm that, on your Arch Linux image, |
|
And one more - does Looking at the implementation, one thing that would break the boot_id functionality is if the static 16-byte buffer intended to store the result was not being zeroed at boot time, Another cause might be some element of the OS reading boot_id before the random number generator has woken up, but I'm not sure that's even possible. Adding a small amount of debug logging to proc_do_uuid in drivers/char/random.c would provide answers to both questions. @graysky2 Is this something you have come across? |
|
|
|
It seems fine with RPiOs Lite and latest 5.10.59+ kernel. But I don't know how to check if the option is enabled or not. Edit: so yes, that option is set in the kernel config. |
|
On rpios run: |
|
I'm just going through the effects of adding that flag, to see if it might be causing problems. |
|
So with a kernel compiled with RANDOM_TRUST_BOOTLOADER=n on archlinuxarm (5.10.59), this is working fine. Tested on rpi0 W. But with the option set to yes (default archlinux arm package), this does not work; the boot_id stays the same (one for a cold boot, one for a reboot). |
|
Can you try with this patch?: diff --git a/drivers/char/random.c b/drivers/char/random.c
index 340ad21491e28..e7befd59bcc47 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -2070,8 +2070,15 @@ static int proc_do_uuid(struct ctl_table *table, int write,
static DEFINE_SPINLOCK(bootid_spinlock);
spin_lock(&bootid_spinlock);
- if (!uuid[8])
+ pr_err("%s: uuid %02x%02x%02x%02x-%02x%02x-%02x%02x-%02x...",
+ __func__, uuid[0], uuid[1], uuid[2], uuid[3],
+ uuid[4], uuid[5], uuid[6], uuid[7], uuid[8]);
+ if (!uuid[8]) {
generate_random_uuid(uuid);
+ pr_err("%s: -> %02x%02x%02x%02x-%02x%02x-%02x%02x-%02x...",
+ __func__, uuid[0], uuid[1], uuid[2], uuid[3],
+ uuid[4], uuid[5], uuid[6], uuid[7], uuid[8]);
+ }
spin_unlock(&bootid_spinlock);
}I'd like to confirm that the static storage is initially zero, and at what point in the boot sequence the boot_id is queried. |
If expectation is identical hash, yes. I do not have armv7h or armv6h devices. The "yes" is for arm64 RPi4. |
|
Are you saying that on arm64 you get identical boot_ids between boots? |
Yes, sorry. the output of the cat command matched the hash in the journal. Reboot, same. |
|
I have attached a chopped boot log (grepped on ' random:') Tell me if you want the complete log. What I can see is that when the error happens the line The normal boot log, is a kernel compiled with your patch, but with the option unset. |
|
To be clear, is the expected behavior that If so, then I can confirm the expected behavior on RPi4 running armv7h as well as aarch64. Output for clarity: |
|
Yes - exactly that. And that is the behaviour I observe. @solsticedhiver Your strange log is peculiar. Are the uuids in the kernel log the same as that found in boot_id? And are they also unchanged after a reboot? |
|
Yes the uuids in the log do match the one in boot_id: Yes they do not change. Now it is back at only one uuid for iehter a cold boot or a reboot. I don't know why. |
|
And (last one for now) can you confirm that the uuid property also always returns the same value (c52f7...)? |
|
No - I think uuid will vary. What would be useful is the complete kernel log up until the first appearance of that uuid. |
|
yes That's why there was 2 times the line |
|
The firmware in the ArchLinuxARM-rpi-latest.tar.gz I just downloaded dates from Jun 29. The patch adding the rng-seed property only went in on Jul 13. I suspect the kernel isn't handling the lack of that property very well - grab yourself some new firmware from here: https://github.com/raspberrypi/firmware/tree/master/boot |
|
@pelwell - The images are generated on a bit of an irregular basis and are not meant to be current since Arch ARM is a rolling release. Unless a total newb, Arch [ARM] users generally keep their systems up-to-date. Our firmware packages are currently in parity with your's/upstream. @solsticedhiver - Are you up-to-date? |
|
Understood. I've now installed Arch on a Zero W and updated it ("pacman -Syu"). The kernel is 5.10.60-1-ARCH, the firmware is Aug 19 2021, and /proc/sys/kernel/random/boot_id is working as expected. I'm calling this user error until proven otherwise. |
|
It's even working with the firmware from 29 Jun and the 5.10.60-1-ARCH kernel. |
|
Well, I never said it was a problem with the firmware. I just said it started with kernel 5.10.52-6. I did not track the firmware version @graysky2 yes. I am up to date. And yes, now that I have upgraded to 5.10.60-1-ARCH, it is working a little "better"; And by better, I mean it is not fixed yet. Look at that: Moreover the suppsedly randol boot_id is not random because I get the same uuid on diferrents rpi0s (all W). I mean the boot_id reported on differents rpi0s is matching the one on another rpi0s. Now it is 6fa901e600fc4d0c825c878fa741d8b2, but I suspect it depends on the time. But never mind if it is "user error". I don't see how I can influence the boot_id ?? @graysky2 so I am gonna install a brand new arch on one rpi0 just to be sure. I will report back |
|
@pelwell well, so I have tried with a brand new archlinuxARM install, and I confirm the problem on 2 rpi0s W. I even got the same boot_id on the 2, namely |
|
In response to the deleted comment, I'm sympathetic to the problem but as long as I'm unable to reproduce it there's not a lot that can be done. Feel free to reopen the issue (or just comment) if some important new information comes to light. |
On 2 rpi0s (armv6h) running archlinuxarm (no RTC clock), since I upgraded to 5.10.52-6 kernel, the boot_id stays the same.
journalctl --list-bootlist a different id for current boot though:The text was updated successfully, but these errors were encountered: