"Reboot required" notification needed

[GlowInTheDark]

I hope it is clear that even if the messages are there, they obviously aren't sufficient. I.e., the people saying "Well, see, the messages are there, therefore this thread should be deleted (and the OP banned)" are clearly missing the point.

It needs to be big and unignoreable. Like it is in Windows.

Mind you, I'm not saying it should be automatic - that would be going too far. The user has to be given an OK/Cancel screen. Note that (in the dark past) some DOS/WIndows apps did this - they didn't even prompt you - they just went ahead and rebooted. This is, as I said, going too far.

[hippy]

Code: Select all

Setting up python3-pil.imagetk:armhf (5.4.1-2+deb10u2) ...
Setting up liblirc-client0:armhf (0.10.1-6.2~deb10u1) ...
Setting up libdbus-1-3:armhf (1.12.20-0+deb10u1) ...
Setting up dbus (1.12.20-0+deb10u1) ...
A reboot is required to replace the running dbus-daemon.
Please reboot the system when convenient.
... snip ...

I see this and similar messages all the time, as above, update from a few mins ago. "A reboot is required to replace the running dbus-daemon."

Sure I see that too. Well, only if I happen to spot it as it whizzes by. It's another case where it would help to hold the notification to the end of the update process, and maybe even prompt for a re-boot.

But the point isn't that some things do indicate a re-boot is required, it's that other things like kernel updating do not indicate a re-boot is required when it is.

"Kernel updating doesn't notify re-booting is required" is not resolved nor even addressed by other things indicating that a re-boot is required.

[GlowInTheDark]

"Kernel updating doesn't notify re-booting is required" is not resolved nor even addressed by other things indicating that a re-boot is required.

Agreed, 100%. But I think (not sure, but I think) that at least some posters have maintained that kernel updating does generate some kind of message (just like dbus updating does). Not, of course, that anyone would see it, since it is just part of the jumble of messages scrolling by.

Also, a message like "A reboot is required to replace the running dbus" doesn't exactly tell the story to an average user. It sounds too much like "Eggs are required to make omelettes" - Most people hearing that will have no immediate interest in making an omelette, so the message is meaningless.

It doesn't tell them that they really need to reboot. Now.

[hippy]

I think (not sure, but I think) that at least some posters have maintained that kernel updating does generate some kind of message (just like dbus updating does).

If anyone saying such messages are given when updating the kernel can produce evidence of that I will happily stand corrected. But so far, after a number of tests, I see no evidence of that.

I suspect most people are seeing "re-boot needed" messages as a result of dbus or ui-mods updates which will often accompany kernel updates. Yes, those do indicate a re-boot is needed, kernel updates by themselves do not.

Also, a message like "A reboot is required to replace the running dbus" doesn't exactly tell the story to an average user ...

It doesn't tell them that they really need to reboot. Now.

Indeed. It doesn't tell a user if they should reboot, need to reboot, or can happily carry on without rebooting without adverse effect.

And I expect many people will miss the message as it scrolls by anyway, having gone to make a cup of tea or do other things while the upgrade runs its course. They will be blissfully unaware that anything has changed or will changed when they do next reboot.

That's particularly the case for a kernel upgrade where hundreds of 'adding diversion' and 'removing diversion' messages - 472 in total in my last test - pretty much bury other, more useful or important messages - only 39 in total, though I understand why they are there.

A kernel upgrade takes an incredibly long time on a Zero W and even slower Pi's, even longer if kernel-headers are upgraded, and no one can really be expected to sit there and watch the lines scroll by. "Blink and you'll miss it" also applies.

I expect scrolling back through the messages when available, to see what actually happened, is more rare than likely. Completion will simply be taken as just that; job done, nothing more to do.

[rpdom]

There are two issues here.

The first is that apt and apt-get should have a mechanism for displaying a message at the very end of the updates to signal that a reboot is now required. It has methods to defer other things to later in the process, so a reboot message should be one of them.

The other is that the Raspberry Pi kernel package should also flag that a reboot is needed, ideally within apt, and possibly also by creating /var/run/reboot (or whatever is needed).

Possibly also an applet for the task bar on the desktop that periodically checks for that /var/run/reboot file and turns red and pops up a message when it happens.

[GlowInTheDark]

The first is that apt and apt-get should have a mechanism for displaying a message at the very end of the updates to signal that a reboot is now required.

Not just a "message", but an actual, unavoidable, prompt. A "About to reboot now - press any key to continue" thing.

And not just some mealy-mouthed text based thing - Something GUI if a GUI is running or, lacking that (if you're running a non-GUI system), something with dialog/whiptail. Something that the user won't just ignore as part of the jumble of messages produced by apt/apt-get.

Also, hippy is right - that there are degrees of urgency:

1) The kernal has been upgraded - you NEED to reboot ASAP (or else random things will just start failing for no apparent reason).

2) You really should reboot, but it is not critical (I think the "dbus" thing falls here).

3) It'd be a good idea to reboot soon, but there is no urgency.

[hippy]

The other is that the Raspberry Pi kernel package should also flag that a reboot is needed, ideally within apt...

I'm not fussed how it's done, but the path of least disruption could be another package which is always released alongside the kernel packages we already have.

That would have zero effect on what already exists, other than RPT-side who have to generate this additional package, create its code.

'raspberrypi-reboot-checker' or something. Pre-installed with new images, apt installable for everyone else.

[rpdom]

The first is that apt and apt-get should have a mechanism for displaying a message at the very end of the updates to signal that a reboot is now required.

Not just a "message", but an actual, unavoidable, prompt. A "About to reboot now - press any key to continue" thing.

Never will such a monstrosity be enabled on a system that I control!

Warnings, messages, alerts, dancing pixies - yes.

Unavoidable reboots - NO.

That's as bad as Windows doing its random updates thing, then saying "I'm going to reboot in 30 seconds if you don't click here" while you are answering the call of nature or something and have left an important project open and unsaved.

[jojopi]

That's particularly the case for a kernel upgrade where hundreds of 'adding diversion' and 'removing diversion' messages - 472 in total in my last test - pretty much bury other, more useful or important messages - only 39 in total, though I understand why they are there.

Another Pi specific facet, because kernel and firmware need to be installed in the FAT filesystem, and dpkg does not like that.

To expand on my previous comment, apt will run needrestart if it is installed. It gives a prominent interactive warning that you cannot easily miss. By default it stops short of actually rebooting for you.

On my Debian desktop, it currently tells me that I have a pending kernel and that my running firefox-esr process is outdated. Both entirely correct, and useless to me. I have no need or intention to boot the new kernel, and I was already well aware that I should restart the browser.

[buja]

I think the Linux Mint Update Manager nailed it: warnings, but no automatic actions/changes, leaving control to the user.
It gives a signal when updates are available, but you have to initiate the actual upgrade yourself.
The reboot warning seems to be very simple mechanism: if kernel update, then give reboot warning.
Again, it's the user who decides if and when to reboot, not the system.

If I install a new program it's usually with APT or Synaptic, so I suppose under the hood the Update Manager is a fairly simple GUI program that just generates some APT commands. It would be nice to have a program like that for RaspiOS.

[emma1997]

Two engineers stuck in the desert when the car mysteriously quits.

Hardware Guy: "So pop the hood. I'll check out the carb, starter, plugs, and stuff."

Software Guy: "No, I got a better idea."

Software Guy opens the door, steps out into the sun, gets right back in, shuts the door, and says: "Ok, try it now!"

lol

tap... tap... tap... hello? is this thing on? tap...

[GlowInTheDark]

Lotta straw man args here.

Remember, I never said that it should automatically reboot, like MS does. In fact, I talk about this explicitly in one of my prior posts - that it should always be up to the user to click that final OK. NO timers, no auto-reboot. So, anyone arguing that I want that (auto-reboot or a timer) is straw-manning.

Now, that said, 90% of the time you will want to click that OK and if you're a newb, then the figure rises to 99%.

[bensimmo]

Lotta straw man args here.

Remember, I never said that it should automatically reboot, like MS does. In fact, I talk about this explicitly in one of my prior posts - that it should always be up to the user to click that final OK. NO timers, no auto-reboot. So, anyone arguing that I want that (auto-reboot or a timer) is straw-manning.

Now, that said, 90% of the time you will want to click that OK and if you're a newb, then the figure rises to 99%.

MS doesn't, it asks, reminds and allows you to defer and even schedule automatic updates.
Win10 Home a bit less so, but that is for people's own good, the ones that don't update, miss security updates etc.
It's actually quite good and flexible.

[ejolson]

Lotta straw man args here.

Remember, I never said that it should automatically reboot, like MS does. In fact, I talk about this explicitly in one of my prior posts - that it should always be up to the user to click that final OK. NO timers, no auto-reboot. So, anyone arguing that I want that (auto-reboot or a timer) is straw-manning.

Now, that said, 90% of the time you will want to click that OK and if you're a newb, then the figure rises to 99%.

In my opinion, installing a new kernel should never delete the module library for the currently running kernel. While some people may be using very low capacity SD cards, it would make more sense to delete the old kernel and modules only after the new one has booted and is running.

On a different note, all that diversion stuff in the boot directory is also very fragile. To make things worse, the installation process performs a chown on every file copied back and if that fails then aborts. In the standard SD card setup, the kernel installation scripts should know better than performing a bunch of chown operations on an MSDOS filesystem. In my cardless setup I mount boot through sshfs. It took a while to figure out uid and mappings so the kernel updates didn't remove everything from the boot directory and then error out.

[bjtheone]

"Kernel updating doesn't notify re-booting is required" is not resolved nor even addressed by other things indicating that a re-boot is required.

Agreed, 100%. But I think (not sure, but I think) that at least some posters have maintained that kernel updating does generate some kind of message (just like dbus updating does). Not, of course, that anyone would see it, since it is just part of the jumble of messages scrolling by.

Also, a message like "A reboot is required to replace the running dbus" doesn't exactly tell the story to an average user. It sounds too much like "Eggs are required to make omelettes" - Most people hearing that will have no immediate interest in making an omelette, so the message is meaningless.

It doesn't tell them that they really need to reboot. Now.

Note that many (most?) updates that cannot be directly applied do not require a reboot for the continued correct functioning of the system. They require a reboot to have the new software take effect. In most cases you can happily continue until it works for you to reboot. This is so much better than Windows that defaults to reboot for pretty much everything.

[GlowInTheDark]

This is so much better than Windows that defaults to reboot for pretty much everything.

Exactly my point. The standard joke is:

A gnat fa*ted in East Timur. Reboot now (30 second timeout) ?

[rpdom]

This is so much better than Windows that defaults to reboot for pretty much everything.

Exactly my point. The standard joke is:

A gnat fa*ted in East Timur. Reboot now (30 second timeout) ?

I thought it was:
It has been detect that you moved you mouse. You must reboot now for the changes to take effect

[GlowInTheDark]

That's good, too.

[hippy]

Note that many (most?) updates that cannot be directly applied do not require a reboot for the continued correct functioning of the system. They require a reboot to have the new software take effect. In most cases you can happily continue until it works for you to reboot.

Yes, that's been my experience for 'dbus' and other changes. It seems to only be a kernel update which pulls the rug from under its own feet for some use cases, requires a reboot to resolve those issues.

If a kernel update didn't pull the rug from under its own feet I would accept not needing a reboot notification.

[GlowInTheDark]

Yes, that's been my experience for 'dbus' and other changes. It seems to only be a kernel update which pulls the rug from under its own feet for some use cases, requires a reboot to resolve those issues.

Yes, that's why I suggested a 3-tiered classification scheme above.

1) Kernel upgrade - reboot ASAP. Basically, when the kernel has been upgraded, you are now in the land of UB (Undefined behavior) - where anything can (and usually will) happen.

2) Some other integral (by "integral", I mean not really user-visible - not a front-line application) part of the system that could start to fail, but if it does, the effect is likely localized (unlike with the kernel) I think this "dbus" thing falls into that category.

3) Some piece of software that is "front line" - and which won't be working completely right (or at all) until you reboot. This area you obviously can do whenever you like, because you know what is going on.

The general principle here is that the more "under the covers" something is, the more it behooves you to do the reboot sooner than later, since you (as an end-user) will be less likely to accurately diagnose whether or not things are failing.

If a kernel update didn't pull the rug from under its own feet I would accept not needing a reboot notification.

Right, although it would still be nice. At some point, one or the other of us ought to "apt install" that "needreboot" thing mentioned by jojopi and see if that works well or not.

I also like the idea suggested by another poster that the old modules be kept around (and used) until the next reboot. That would solve the whole problem.

[Dragontail281]

i am fairly new to Linux, only been messing around with my Pis for about a year now.
I remember watching tutorials early on, even before I got my first Pi, where everyone did a reboot after every update/upgrade, so I pretty much do it every time as well.
Is this overkill?
Possibly, but at least I won't miss a time when it truly is necessary.

[DougieLawson]

i am fairly new to Linux, only been messing around with my Pis for about a year now.
I remember watching tutorials early on, even before I got my first Pi, where everyone did a reboot after every update/upgrade, so I pretty much do it every time as well.
Is this overkill?
Possibly, but at least I won't miss a time when it truly is necessary.

If you don't need long uptimes (because your RPi isn't a server) then your strategy is perfect. sudo apt update; sudo apt dist-upgrade -y; sudo reboot;

[GlowInTheDark]

As long as you don't mind all the time and bother getting everything (all your processes and such) running again after the reboot...

For me, that's a major time sink.

In fact, once of the nice things about running an older version (at this point, either Jessie or Stretch) of Raspbian is the knowledge that there won't be any kernel upgrades. So, you can do upgrades safe in the knowledge that you won't be needing to reboot afterwards.

In fact, what I'd really like is a warning - ahead of time - when updating Buster - that "This upgrade includes a kernel upgrade and thus will require a reboot afterwards. Are you OK with that?"

Yes, I know you can get that info by carefully inspecting the list of packages that it says it is about to upgrade, but again, that's a pain and shouldn't be necessary.

[jahboater]

As long as you don't mind all the time and bother getting everything (all your processes and such) running again after the reboot...

Sounds like you need to automate things:

/etc/rc.local
/etc/crontab/@reboot .....

[hippy]

Rebooting after every upgrade is a fairly good strategy. If something has catastrophically changed you will know about it sooner rather than later. And it won't be such a mystery as to why things have gone bad when you reboot in the future and don't so obviously relate it to an earlier upgrade.

But it's easy to stray off track; leave an upgrade running over a break, come back and keep on working, forgetting about the reboot entirely.

Sod's law will have it, that every time you do reboot; you didn't actually have to. The times you forget are the ones where you really should have rebooted.