For "knowledgeable people"

I was thinking about sysutils/loaders-update these days. And precisely how very knowledgeable people explaining why such a thing isn't wanted.

Reference: https://forums.freebsd.org/threads/updating-bootcode.88875/

I read again all the thread and saw (again) that almost all the arguments against were wrong.
My observation was: there is a need, and this one can be fulfilled, at least partially.

It was the same concerning the problem with the kernel modules at each minor version upgrade.
Some people said: there is no problem, just compile! But, the FreeBSD staff resolved it.

There is always a trouble concerning the update of the loaders. I don't blame the FreeBSD staff because one of their priorities is the stability of the system. They will take the time needed. And, for now, I saw some huge improvements in the documentation on this subject.

But... "knowledgeable people", please think twice before to disparage an idea.
 
Updating loaders is one of those tasks that in theory should be simple, just "follow the instructions/handbook". But it's also a simple task that if you get it wrong you wind up with an unbootable system.

So what does a competent sys admin typically do in a situation like that? Script the heck out of, verify the script and once verified correct, use the script to prevent mistakes and then share the script with others.

That does not mean others have to use it or even like it, but taking the time to actually write the script means at least one person felt a need.
 
I was thinking about sysutils/loaders-update these days. And precisely how very knowledgeable people explaining why such a thing isn't wanted.

Reference: https://forums.freebsd.org/threads/updating-bootcode.88875/

I read again all the thread and saw (again) that almost all the arguments against were wrong.
My observation was: there is a need, and this one can be fulfilled, at least partially.

It was the same concerning the problem with the kernel modules at each minor version upgrade.
Some people said: there is no problem, just compile! But, the FreeBSD staff resolved it.

There is always a trouble concerning the update of the loaders. I don't blame the FreeBSD staff because one of their priorities is the stability of the system. They will take the time needed. And, for now, I saw some huge improvements in the documentation on this subject.

But... "knowledgeable people", please think twice before to disparage an idea.

Ha! Finally, a chance to thank you for that handy tool. You've completely won me over with it.

Plus, it's saved me a lot of time and hassle.


And much more... :)


Thank you!

Nandor
 
Updating loaders is one of those tasks that in theory should be simple, just "follow the instructions/handbook". But it's also a simple task that if you get it wrong you wind up with an unbootable system.

So what does a competent sys admin typically do in a situation like that? Script the heck out of, verify the script and once verified correct, use the script to prevent mistakes and then share the script with others.

That does not mean others have to use it or even like it, but taking the time to actually write the script means at least one person felt a need.
I get your point. No one is obliged to use loaders-update and when - because it will happen - the FreeBSD upgrade will update the loaders, I hope it will ask confirmation for this task. The admin user will make the final choice.

The point of this thread isn't technical. It's about tolerance of what it seems weird ideas.

I mean, maybe a person that knows well the thing doesn't need it, but what about other people? Each one that quits using FreeBSD is one less contributor. I think that update of the loaders is a cause, there are another, many.
 
Yep I understand; I guess I was trying to point out that pretty much every idea, in every discipline starts out being called "weird". Einstein, Tesla I imagine were called weird.

loaders-update: I really don't know why anyone would call it "weird". I looked at it as "cool a programmatic/repeatible way to check and update loaders if needed".
People saying "it's all in the handbook" well I can imagine (just speculating) that loaders-update could have started with the handbook/man pages.
"what does the documentation say on how to update/know when to update loaders" Let me put that in a script instead of typing 10 commands every time.

I guess that's kind of my point; why would it be considered weird to script a sequence of commands that if you make a mistake give you a bad system.
 
Tolerant? I don't think any a-technical audience cares about whatever people do with their system components if it has no substantial explanation.

I might do it if a secure boot vulnerability appears.
 
IMO there two distinct cases
  1. updating during an install
  2. updating before upgrading a zpool
The first involves copying a loader.efi file that has never been tested on my system, so I'm not keen on overwriting all of the loader files. I configured the bios to boot from the partition that gets mounted on /boot/efi and I update that automatically from my build script - I treat the others as backups. I'm thinking about mounting a second directory and copying from /boot/efi to /boot/efi.backup before copying from $DESTDIR.

The second case is the only time I'd want to update more than one efi directory at the same time and it's extremely rare compared with 1.

The chief problem with automating any of this is preventing an efi file from being overwritten from by one from a lower FreeBSD version. Does loaders-update have a solution to this? Is it safe to write informational text files somewhere in an efi directory?
 
I read again all the thread and saw (again) that almost all the arguments against were wrong.
[...]
But... "knowledgeable people", please think twice before to disparage an idea.
Could it actually be that you simply disagreed with the knowledgable people (and still do)? A random 3rd party port doesn't seem to suggest a shift in people's viewpoints here. I doubt anyone else even knows that port exists because they don't need it so never looked for it.

Many people do not struggle with FreeBSD so much, that they need to keep their bootloader at the very latest version. Sounds like a compulsion rather than a use-case. That's fine; the ports collection is filled to the brim with "personal itches". But for many of them, that is all they are.

what about other people? Each one that quits using FreeBSD is one less contributor. I think that update of the loaders is a cause, there are another, many.
The FreeBSD community (open-source in general) feels a little quieter these days. Possibly consider if people have left because of ideas they don't agree with are slowly dripping in and making FreeBSD worse for those expert users.

People with years of (professional) FreeBSD expertise, simply (and relatively easily) migrating to a cleaner project with more focused goals is not going to help with your view on contributor numbers is it? Junior members usually won't really be able to contribute any more effectively than one of the many AI/LLMs.

The port you mention (loaders-update). Do you have any use-cases / articles where it has been used? Are there any discussions of pulling into official base, or do people explicitly want to keep it separate (in 3rd party ports)? Frankly, it sounds irrelevant.
 
I use grub, gets upgraded with linux upgrade.
When i use freebsd as loader, i until now have never had the need to upgrade.
Indeed. I don't use ZFS. All my operating systems (Debian, Windows 11, FreeBSD) are on separate hard drives. I use Grub2 to boot them. In my configuration, Grub2 directly boots FreeBSD from the UFS root partition using its UUID, so I don't need any script to automate loader updates.
 
As I already mentioned, it's not a technical thread. Some asked me for a backup solution. I am thinking to this, but it can be only for efi.

The FreeBSD community (open-source in general) feels a little quieter these days. Possibly consider if people have left because of ideas they don't agree with slowly dripping in.
It's another discussion. But, I think that FreeBSD - and I say I, not anyone else - wants to move forward. Everyone is free to not stick to an idea. And everyone is free to leave for that. I can't do nothing against this.
 
IMO there two distinct cases
  1. updating during an install
  2. updating before upgrading a zpool
That looks like: If you have installed a system with root on UFS, the boot loader never needs updating.

I agree that updating the boot loader is often needed and therefore important with ZFS on root (especially when a zpool upgrade is in play); however a boot loader also gets updated for reasons other than ZFS alignment. I don't know of an example where it is actually obligatory in all circumstances but, in FreeBSD 14.0-RELEASE Release Notes:
Upgrading from Previous Releases of FreeBSD
[...]
There have been a number of improvements in the boot loaders, and upgrading the boot loader on the boot partition is recommended in most cases, in particular if the system boots via EFI. If the root is on a ZFS file system, updating the boot loader is mandatory if the pool is to be upgraded, and the boot loader update must be done first. [...]

For FreeBSD 13.0-RELEASE Release Notes:
Upgrading from Previous Releases of FreeBSD
[...]
! Important
Updating UEFI ESP partitions (the partition the firmware boots from) has changed. See Boot Loader Changes for important details.
[...]
 
People with years of (professional) FreeBSD expertise, simply (and relatively easily) migrating to a cleaner project with more focused goals is not going to help with your view on contributor numbers is it? Junior members usually won't really be able to contribute any more effectively than one of the many AI/LLMs.

The port you mention (loaders-update). Do you have any use-cases / articles where it has been used? Are there any discussions of pulling into official base, or do people explicitly want to keep it separate (in 3rd party ports)? Frankly, it sounds irrelevant.
It sounds like you speak for all of us. Junior members, as you said, are the future of all projects, including this one. Without them, FreeBSD will die.

The port I mention is well used and outside the pure FreeBSD usage. I think it will don't pull in the base system as sysutils/beadm never get. It's not a software, it's an idea. No one can stop an idea.
 
What I don't understand: why isn't there a unique identifier string, like <versionID><arch>, embedded in the bootloader code? That would certainly enable any utility to uniquely determine the version of a certain bootloader binary. IIRC, Warner Losch mentioned somewhere on a ML that is not what is being done.
 
I say I, not anyone else - wants to move forward. Everyone is free to not stick to an idea. And everyone is free to leave for that. I can't do nothing against this.
Your view of what 'forward' is may differ to another person's view of 'forward'. What do you say to that? What direction would the project go in that case?

It sounds like you speak for all of us. Junior members, as you said, are the future of all projects, including this one. Without them, FreeBSD will die.
A 'junior' FreeBSD member could well be someone who has dealt with UNIX/Linux for decades in their professional work and is now jumping into development. This is the kind of junior who will inherit the project. I feel you may be conflating these guys with casual users who just want a novel OS to watch youtube and play Steam DRM Platform games. The former will be put off by catering to the latter.
 
Indeed. I don't use ZFS. All my operating systems (Debian, Windows 11, FreeBSD) are on separate hard drives. I use Grub2 to boot them. In my configuration, Grub2 directly boots FreeBSD from the UFS root partition using its UUID, so I don't need any script to automate loader updates.
Yeah i also boot ufs, and on this ufs i mount /usr & /var as zfs.
 
Could it actually be that you simply disagreed with the knowledgable people (and still do)? A random 3rd party port doesn't seem to suggest a shift in people's viewpoints here. I doubt anyone else even knows that port exists because they don't need it so never looked for it.
Sorry , but I answer when I see you modified your post.

I disagreed, for sure, and I still disagree. I see now that they were wrong.
They used their knowledge to make their view right, but they miss to think.

There are many people that use or consider my script, even in the FreeBSD staff.
Alan Jude said it's a shoot-gun-y: https://ottawa.place/@mWare

our view of what 'forward' is may differ to another person's view of 'forward'. What do you say to that?
I said I. That should be sufficient. Is it your case or do you speak for the FreeBSD project?
 
I said I. That should be sufficient. Is it your case or do you speak for the FreeBSD project?
I will repeat the question. What way do you feel the project should go if people have a different view of what 'forward' represents? Your definition of 'forward'? You have to consider that is equally unlikely as anyone elses.

You feel a risky boot manager update is 'forward', others do not. So combine this information and which way is the correct 'forward'?
 
I will repeat the question. What way do you feel the project should go if people have a different view of what 'forward' represents?
That's not a question. I have been already clear in my statements. You're not agreed with me. That's ok. Please, don't pollute more the tread.
 
I mean, maybe a person that knows well the thing doesn't need it, but what about other people? Each one that quits using FreeBSD is one less contributor. I think that update of the loaders is a cause, there are another, many.
A user dropping a OS over having to run at max. 10 commands about once a year is a pretty diabolical scenario, and I wonder if such a person would be the valuable "contributor" that you are describing.

Also obligatory XKCD:
is_it_worth_the_time_2x.png

(In this case there is also a 3rd, perpendicular, "brick factor" axis, you can imagine where the stats land)
I guess that's kind of my point; why would it be considered weird to script a sequence of commands that if you make a mistake give you a bad system.
It is not weird, it is unwise, this horse was very much beaten to a pulp on the previous thread.
TL;DR:
  • The matrix of different boot/partition configurations is very wide.
  • This is a task that you spend at max 5 minutes every year doing.
  • The task while short and simple is highly dependent on the user's specific machine and install.
  • There are large margins available if you miss updates.
  • There aren't margins available if you apply a generic script recipe, (or a wrong recipe overall) to a non generic install (which are very common). (Your system is bricked)

I don't see how a user who has read the handbook can make a "mistake" running the commands specific to their system, maybe a severe case of Emacs pinky or a RS232 line that's a bit too long...
 
That was a clear question. I simply suspect you are a little bit inexperienced and can't project the needs of others over their own use-cases. That's fine, you aren't alone, the internet is filled with this.
I'm so inexperienced and I can't projet... Hum, lol. I ain't alone, fine!

Seriously. Wake up! Wake up, before FreeBSD diseapears.
 
baaz, you are on the base of "knowledgeable people".
I know you are very knowledgeable. But, what do you say?
You say the same than before other knowledgeable people told me.

Yet, my script is widely used. So, what you said is void. And I guess, you don't even try it.
 
Back
Top