A new update each day?

Emrion

Emrion

I just upgraded my stations and my server to p7. And then, new patches come. And they come in a way I'm obliged to reboot. Never seen that in 6 years at least.
 
Yes, today I'm upgrading my server and workstations (VirtualBox), system and ports and today there are 2 more updates, also graphics/drm-66-kmod give me error, looking at freebsd bugs there is one about it reported today. I do not care a lot, I always make updates at the first of each month, both system and ports. Upgrading system is a fast business (with freebsd-update), about ports is another thing. There seems to be a lot of movement around the system, which is good news.
 
Well, i think that's the issue with Security updates. Sometimes you go months, other time hours. It all depends on what's reported when and when they get fixed. I always read them and see if there are workarounds or if they apply to me.

Example: recent PF one. If you don't use PF, who cares?
So I do the update install and then take my time rebooting
 
This is preferable. TBF. You're already disturbed. You remember the routine (it was yesterday). It doesn't break up long stretches of uptime.
 
AlfredoLlaquet, I understand, I think, your point, but keep in mind that many people run FreeBSD servers that many people depend upon, and doing a reboot could literally inconvenience thousands of users. So, it's not just a first world problem in the sense that you mean it. (In the sense that computer servers running a business, it might be applicable). But if some Sysadmin reboots at the wrong time, aggravating an ignorant executive and getting fired for it, it's not a trivial problem.
 
scottro very very good point. My FreeBSD desktops that only affect me I have control over when they get rebooted.
A server? Anyone that has worked telecom with a "5 9's" uptime requirement knows that reboots and scheduling and keeping the executives quiet are non trivial requirements.
 
freethread said:
also graphics/drm-66-kmod give me error, looking at freebsd bugs there is one about it reported today.
Click to expand...
With duplicates. 😭

When I filed PR 294870, there were no others yet.
Encountered when I was proceeding the last-minutes rebasing for patch to upgrade NVIDIA driver ports to 595.71.05 before filing PR / opening review for it, thus, pending until graphics/drm-61-kmod and graphics/drm-66-kmod are fixed. These are dependencies for corresponding graphics/nvidia-drm-{61|66}-kmod{-devel} ports.

Next, different one was filed as PR 294875 by another person, which happenes on 15.0 and older but not on recent enough stable/15 and main, thus I couldn't even notice.

And duplicate ones like PR 294878 (with additional helpful thoughts), PR 294905 and PR 294914 are filed.:eek:
 
Emrion said:
I just upgraded my stations and my server to p7. And then, new patches come. And they come in a way I'm obliged to reboot. Never seen that in 6 years at least.
Click to expand...
Usually, fixes are first tested on main (aka -CURRENT) branch at least in 3 days, then, MFC'ed (Merge From Current) into affected stable branches.
If the codebase affected are already NOT in sync, this is needed to port and confirmed the fixes.

And if codebases for affected parts of stable branches and corresponding RELEASEs branched from there are already NOT in sync, basically 3 days for testing at minimum are given before MFS (Merge From Stable).

These minimum 3 days of delay (as the latter are NOT given when the code to fix still matches) allows some other fixes found within the periods to be incorporated into single patch releases (*-p* form of updates).

But for critical vulnerabilities that need urgent patch releases, the delays coule be NOT AT ALL given and committed into main, stables and relengs AT ONCE (if the fix can be applied to all supported) if Security Officers decides it to be needed.

So if any critical vulnerabilities are found and addressed just after patch releases are released, following new patch release could be done once the fixed builds become available. But I think (and hope) it should be rare.
 
bakul said:
See my comment in that PR. git -C /usr/port checkout to the commit previous to d94082fc7 to build drm-6{1,6}-kmod.
Click to expand...
As seen in the PRs, I've proposed temporal fixes (but as I wasn't enough sure, not as attachments but described inside my posts). But the devs seems to be working on upgrading upstream and update ports once it finishes, rather than introducing "hot-fixes" on ports side.
 
T-Aoki said:
But the devs seems to be working on upgrading upstream and update ports once it finishes, rather than introducing "hot-fixes" on ports side.
Click to expand...
Right approach but with security fixes coming in at a fast clip I felt we needed a workaround. And unfortunately there seems to be strong coupling between kernel code and drm-*-kmod.
 
bakul said:
And unfortunately there seems to be strong coupling between kernel code and drm-*-kmod.
Click to expand...
Exactly. So, in some unfortunate cases, rolling back graphics/drm-*-kmod causes unworkable (with GUI) computers.

Usually rebuilding are sufficient, though, but this can happen when the upgrades for graphics/drm-*-kmod are to chase LinuxKPI changes.

And this is why I recommend to use NVIDIA GPUs in old-school (UMS) way instead of recent DRM/KMS way using graphics/nvidia-drm-*-kmod* whenever possible. With this respect, non-NVIDIA GPUs cannot be recommended even for iGPUs, as recent iGPUs and dGPUs from Intel and AMD are supported only via DRM/KMS way.
 
Emrion said:
Two reboots in a day are far too much for me. AI is at control and men are corrected it somehow.
I know that world is moving fast, but I can't stand that at this level.
Click to expand...
I used openSUSE Tumbleweed on a webserver for years and got used to daily rebooting every OS (if no updates that day then it gets rebooted just to clear up any potential odd firmware stuff, memory leaks, or rogue longstanding connections); on a low-end VPS it'd be down maybe 15 secs (my laptop with GNOME boots faster so better server specs could probably have <10s reboots/happen sooner than the browser page refresh timeout)
 
Looks like the updates are going to become more frequent. All we can do is review the code a lot and that is not foolproof as there will always be bugs.

Is there a way to place a hold on those patches that require a reboot and perform them at a later time? I have seen companies change Linux distributions just for this ability.

If so, can the operator bail out and are they notified (in a way that they can point to after the fact) that a reboot is going to be required before they even begin the process? If they are notified and go ahead, they own it. If they can cancel the job and let their supervisor make the management decision to go ahead then it is not really their concern. Either way, they are covered.

If the only way of knowing if a reboot is required is to apply the update, the ‘old school’ approach might work. For those younger admins, it was to patch a tertiary set of servers and if that worked, move on to DR and then swap that set with production while the production set was patched; then swap back. Every set has to be in sync and the patches had to be applied in order. I have seen the tertiary set skipped for budgetary reasons but this was always considered suboptimal. This method is still followed in hypercritical 24/7 banking and government operations who can pay. That said it does catch the reboot problem before service is interrupted.

IMHO, it is far better to place the hold if we can.
 
Last edited by a moderator:
You must log in or register to reply here.
Back
Top