-p8 is out :D

good news

bad news FreeBSD 13 eoled

mosaid, maybe bad but maybe not news? I thought that was planned years in advance?

yeah, I need to update now.. and found some why to do fast

*find

Hm this seems kinda bad, vnode_if.h which is needed to build drm-kmod doesn't actually exist, despite being referened from /usr/src/sys/sys/vnode.h ..??

and drm-66-kmod fails to build on 15 too, as of recently

isn't the fastest way to use freebsd-update? :)

guess i'll update fbsd again

If you haven't moved to pkgbase, I suggest freebsd-rustdate from ports. Since you said "fast", it's easily 20x faster than stock freebsd-update..

Hi, I am trying to fix a freebsd system as pkg is broken complainig about license files in /usr/local/share/licenses/pkg not being found this system was upgraded from 14.0 threw each release to 15.0 and now pkg 1.2 is still installed and is totally broken what I want to know is either how to fix this myself or are there people I can have login to my system and correct these issues?

Ltning: thatnks for the tip

Do FreeBSD companies or support technisions exists that you can higher to help you out if something breaks?

i don't think so

I don't think its being used in industries at all or companies take it seriously.

So is all of the support free and if you can not fix it there is no hope then?

Is this a user supported channel or are official FreeBSD developers here?

It's both.

Most of us here are the user community. But there are also developers here too.

Remember that developers are also users too. But if you want paid support you will need to contract for that yourself.

And there are some very large companies that use FreeBSD as their core infrastructure.

Because IRC is about who just happens to be here at that moment, generally I think you might get better help from people on the mailing list because the timezone problem is less inherent there.

Basically I am trying to get my 15.0 system on the new pkg system from the distribution sets upgraded to the pkg setup is failing from the pkgbasify github script with pkg is to old it expects version 7 or newer and it is on version 6.2 so is there a way to fix this?

I know nothing about the pkgbase system. I am still using either sets, or source.

Hang around a while and someone who is knowledgeable about pkgbase will appear. A lot of people here are advocates of it.

yes sets the triditional format can I stay with that for updates or do you have to upgrade to the new pkg base format or are sets going to be supported for sometime yet?

Tradition sets are going to be supported through the life of 15 at least. For 16 the current plan is to transition to pkgbase entirely.

But by then all of the early bugs will have been worked out of it by that time. Right now people are hitting the types of bugs that always occur when something is brand new and just getting started.

So I should not worry about it now right?

I am not going to worry about it for another couple of years.

Why are you worrying about it? What's happening with you?

please don't bother with this nickgaw

I want to be ready for the change but it is messed up as pkgbasify on github is complaining about pkg being to old so it will not switch over so you are saying just wait until bugs get fixed?

if you want to do some experimantation, plase create new BE (boot environment) for thesting, boot into it, upgrade packages and entiere system, and then test how pkgbasify works

My rationale is that if you are not wanting to help /develop/ pkgbase then you shouldn't be using it yet. Wait and let other people work through the problems first.

If you just want things to Just Work then stick with sets for now. For another year or two even. There is no hurry to get off sets.

This is a purely testing setup so if I want to try out beta version 16 of FreeBSD is this possible?

I think if you are wanting to test out CURRENT then that should be done from source. That's just my opinion but...

From reading the documentation there is going to be lot of manual changes to do to upgrade to source right not a automatic script that murges configuration and just makes it work right?

Huh? Citation of documentation? Because it is easy to upgrade to a source install. And it is easy to upgrade from a source install to sets. And it is supposedly easy to upgrade to pkgbase (I have not done it so cannot comment).

The handbook I am trying to fix these issues I am having with pkgbasify with pkg not being the correct version and I have read the directions but so am trying to fins what is exactly broken.

Perhaps if things are really broken for you that you should boot back to a previous Boot Environment that was from before and was working. Then start again from there. Note that any changes made between will be in the BE that holds the data between. /home should be persistent because it is not in the BE. But any other data will be in the BE.

That's confusing to say. But for example if I upgrade and it is messed up. And debugging the upgrade I install somethingfoo to /usr/local/bin/somethingfoo and then reverse back to a previous Boot Environment. In that previous BE then /usr/local/bin/somethingfoo will also have been removed. I can reach into the BE holding it and copy it forward if I need to though.

I will look into this.

But if things are really messed up for you then reverting to a previously working Boot Environment would reset things back to before. Then you can try again. And again repeating that process. As many times as needed until everything is working.

"bectl list" will list out the BEs. NR is Now active and active on next Reboot.

You can either use bectl to make a different BE active on the next reboot and then "shutdown -r now" to reboot to it. Or you can "shutdown -r now" and at boot time from the boot menu select the BE interactively and boot it.

(I am trying to train myself from saying "reboot" to saying "shutdown -r now" so that people do the right command to do it.)

is reboot not the same thing?

If you decide to do this and then want help making a new default Boot Environment from a previous one let us know and more commands will be suggested. It's easy!

The "reboot" command is not the same as the "shutdown -r now" command. No.

I did not know that what is the differences and this is on a virtual private server so I do not have access to the boot loader.

On many systems without much running the reboot command is not too bad. It just kills everything with a SIGTERM, pauses a short time, kills anything left with SIGKILL, and then reboots. Probably for your personal desktop that is okay.

But if one is running other things then that's not good. If running a MariaDB or other SQL database it might take longer to flush caches to disk than reboot will wait. That will cause data loss in a database if it is SIGKILL'd before it can flush its buffers.

If one is running jails or bhyve virtual machines then it might take longer to shut those down and the same problem occurs for them. Jails will probably be okay but virtual machines with file systems will effectively be a crash and they will need to go through crash recovery.

So really one should run "shutdown -r now" to run the shutdown scripts for all of these and gracefully shutdown and reboot. Where "now" is a time, on multiuser machines it is polite to give people notice and time to save and logout with +5 or +25 minutes even.

This is a purely testing setup for me so no databses installed yet so would doing the shurdown method be best still?

Yes. Always use "shutdown -r now" when people say reboot. It's the safest way.

<insert reson we need reboot>

(Someone will pop up that in CURRENT there are changes to make reboot safer. But pretty sure we are not there yet in any RELEASE yet.)

And also this use of shutdown for a safe reboot applies across all of Unix and *BSD systems. Also systemd systems too. Though there reboot is also remapped. So knowing "shutdown -r now" works everywhere which is nice.

Is there an installation iso that when booted that would setup dhcp and launch ssh that way a user can install from scratch with a ssh server for the installation process?

Are you actually saying that you don't have console access?

just ssh access as it is setup on the running system.

Because otherwise the standard FreeBSD disc1 install iso should be good to go.

You will need to say more about your environment and limitations. I don't understand. If you have ssh access then you /already/ have an installed system.

Understandable but is there not a way to boot the installation with a ssh server running so I can ssh into the installer and complete the installation?

nickgaw: There is. Let see if I can remember the name

mfsbsd.

I used that before when I had eyes/ears at a phy location

Is it basically Free BSD with an ssh installer?

I think so but I'm not sure how well maintained it is.

mfsbsd.vx.sk is very handy. And it is often used to "side load" FreeBSD onto VPS hosting providers that do not otherwise support installing FreeBSD.

I am also totally blind and use screen readers like jaws for windows or speakup on linux so am looking for an accessible like threw ssh as vnc is not accessible so thought I would locate a way to reinstall Free BSD over the netowrk accessibly.

Hmm... Thank you for mentioning that as I will try to keep that in mind. I am very impressed when users are able to do this. You are an inspiration!

I use mfsbsd to install FreeBSD on OVH hosting. It's a lot of steps though and not completely trivial.

Could I not rebuild the iso image for Free BSD with a ssh server instead of the console so I could boot the iso image and then ssh into the iso image and reinstall the operating system?

In concept the general procedure I use is to create a new VM with any linux distro. Then immediately boot it into rescue mode which runs a Debian rescue image. On that ram based rescue system I then download mfsbsd and then install qemu-kvm and then qemu boot the mfsbsd image. That gets me to a running BSD system over ssh.

That would work great.

Then I use that to run the FreeBSD installer completely overwriting the previously installed linux system that was on the new VM when I had it created.

I will look into this.

Then reboot and hope I did the process correctly. Log into the new FreeBSD system.

As this way I would not need to pay for a virtual private server and run it on my own system right?

If I screw something up the worst that happens is that I must boot again into the Debian rescue system and simply try it all again. Repeating until I get it right. That's the general concept of things.

I did not understand "this way I would not need to pay for a virtual private server and run it on my own system right?" This really confuses me.

Is there something preventing you from running FreeBSD on your own system now?

I mean rather then rent a virtual private server I would run the Free BSD installation on my own hardware in a virtual machine?

Yes. Most definitely! I also do that too.

For example a linux system running a VM system such as libvirt or proxmox or other. Anything that can run virtual machines could run FreeBSD as a virtual machine.

Hello, all. newsyslog(8) supports specification of logfiles as glob patterns, but when I tried to use it, is started to rotate its own rotated files: notice.log -> notice.0.log -> notice.0.0.log &c. Shall I take care to exclude rotate files from the pattern?

What pattern are you trying to use?

^ Will see what it does with: /var/log/tor/*[!0-6].log

rwp, I was tring to use: /var/log/tor/*

That "*" will match all of the files. That's a problem. ALL of the files will then be attempted to be rotated.

Just using /var/log/tor/*.log should have been sufficient.

"will be attempted to be rotated" -- I like the phrase somewhy.

rwp, thanks: now that newsyslog appends numbers to the filename, .log is sufficient indeed.

I said it that way because rotating foo.log is going to rotate all of the other files down the numbers. But then newsyslog is going to try to rotate those down. Which might have moved. It's going to be a confusing situation.

Order of operations will strongly affect what happens. But it is not desired. Don't do it! For the Love Of Elvis! :-)

I had some fun recently removing the 'J' from newsyslog.conf so that files would not be compressed. Since I am running on zfs with compression enabled already. That's been a good result here.

rwp, yes, I understand that (now both in theory and in practice).

What would be a light, easy, and lazy way for backing up a FreeBSD configuration? I have thought about backing up /etc and /usr/local/etc . Anything else?

might want a copy of /boot/loader.conf

Indeed. I forgot about it, but it contains my customisations.

One of the nice things about FreeBSD is that there are only a few files that contain system customizations. /etc/rc.conf /etc/jail.conf any custom users added, /usr/local/etc/ config files. If one is disciplined about keeping a list of these things then it is easy to rebuild a system and re-deploy these files and have a new system rebuilt and provisioned in just a few minutes.

I am doing this exact thing right now to one of my machines.

I will begin with a simple backup of the two etc directories and loader.conf .

Hint: If one takes a snapshot before doing configuration and then another one later then zfs-diff can be used to show the files that changed between the two snaphots. It's a way to know what was configured to make something work.

Ooops. I am not using ZFS currently, but now that it is reported to work well on system with less than 4 Gb RAM, I might consider it.

zfs should work fine.. zfs requiring massive amounts of ram is a myth .. i guess the minimum suggested is 2GB but i mean you'd probably lose cache performance from any fs with less ram

My normal small utility VM is 1GB RAM and I run ZFS on all of them.

at least in a normal sense of using zfs

When a standard system had 256 MB of RAM then every byte saved was important.

lets not delve into the before time :)

I was dissuaded from using ZFS by the RAM warning in the FreeBSD installer.

then again... considering ram prices...

i'm trying to consider where ram would be a serious consideration with zfs.... dedupe maybe?

or using like 2TB of l2arc on a low ram system :)

zfs dedup is the usual example. But friends do not let friends run dedup.

i'm sure it has its use case

I think people running a home or SOHO server system should stop reading articles about how to make zfs scale up to the size and speed needed to run a VLSI design lab building CPUs. You are not going to need it and it only makes things more complicated than you need at this point in your life.

it's always good to future proof tho

nah

i think the bigger issue is that people want a nas to be a catch all do anything

let a nas be a nas :)

i like snapshots

In astronomy it used to be that people would make their own 6-inch reflector telescope. That was somewhat of a sweet spot. The advice was always to start by making a 4-inch mirror first. Then what you learned there will make the 6-inch mirror easy. But if you jump straight into the larger one first it will take you three times as long.

It's the same thing everywhere. With FreeBSD and ZFS start with a basic simple system. Use it. Learn it. Get comfortable with it. Then start optimizing it. Not before.

astomoners are out there mining ores to smelt mirrors?

rwp: its hard to sell boring

Not boring at all as long as your brain is loaded with growing used to a new system/tool/interface .

i think zfs is at a point where most of its features are rather basic with the exception of a few special cases

but i still think any astronomer hand crafting their own mirror is like an indiana jones of astronomy :)

omg that's legit

ant-x: that 8GB comment in the installer is wrong and was recently changed to be more accurate

Good to know, thanks.

Macer, I wouldn't lie to you! :-)

Yes many astronomers DIY grind their own lenses! It's a thing!

And my previous career was VLSI chip design in a CPU lab with 300 people. I know all about maintaining thousands of systems and petabytes of storage. There is no need to make things up. Truth is stranger than fiction. And the world is a big place with a lot of interesting things in it!

then there's this guy who just takes it to the next level

really went down the rabbit hole with that. that guy doesn't look like he uses zfs tho