Search results

Generally speaking it's easier to stick with supported versions, because that way you can actually ask for help whenever something goes wrong. Don't let names like STABLE & CURRENT fool you; these are developer versions and running them kind of implies that you're on your own. If you're having...

First... keep in mind that CURRENT is an unsupported version and thus more or less offtopic on this forum. Second... you're not giving us much to go on. Considering the error I'm tempted to blame userland settings instead of contributing this to a problem with the OS itself. How did you set up...

Might want to check the systems hardware stats too. I could easily imagine the system shutting down when, for example, the CPU overheats for whatever reason.

You'd be surprised, because that's definitely a thing. I've been there... Unix? Isn't that this ancient OS that was awesome in the past and has been surpassed by Windows and MacOS? (Free)BSD? What's that? Linux? Oh, right! That's the free (!) unix thingie that's now supported by...

Why run a highly unstable developer version when you obviously can't handle it? You should keep this forum rule in mind: https://forums.freebsd.org/threads/topics-about-unsupported-freebsd-versions.40469/ ... not to mention check up on /usr/src/UPDATING. The idea of releasing versions like...

Others have already explained that this is generally speaking a bad idea. The unwritten rule is basically not to combine ports and packages, period. But ... there is a gray area. This is actually another good example of why I became such a huge fan of ports-mgmt/portmaster because it does...

Here's another noodle for you: the full command you should actually be using is # make install clean, because why on earth would you want to leave all that temporary mess behind? Yet this also implies that if you just use the install build target then everything that got created in the process...

It's definitely bad practice to edit system files like RC scripts manually because the moment you install an update then your changes get immediately overwritten, and that can result in highly unwanted behavior. There should also be no need... I don't run OpenDMARC myself but did take a peek...

What do you think -x does or stands for? pkg-search is your friend here: pkg search [--{comment,description,depends-on,full,origins,prefix}] [--{quiet,raw,size,no-repo-update}] [--repository reponame] [--{case-sensitive,exact,glob,case-insensitive,regex}]...

Can't miss out on something I never actually used ;) Of course that's not saying that BSD doesn't support containers; there are Jails, there's Bhyve, etc. But even though I've read about Docker in the past I never felt the urge to look deeper into it. I just don't see the point.

First: keep in mind that mixing ports and packages isn't always a good idea and could result in problems along the way. There are basically 2 reasons why a key would be considered insecure... first are the file permissions, second is the trust factor; keys are usually signed by an authority and...

Having such permissions accessible still differs from actually using them, which is the point. Because it would still create a barrier between what normal users can access and/or do and root. Which is also why I'd argue that not using a password doesn't have to be insecure at all, also...

Hi gang, So... I'm biased: I plain out don't like security/sudo, never have. Instead I heavily relied on /usr/bin/su but also on lowering requirements. For example: make a ports group, give it rw access to /var/db/ports and you don't have to bother with root to (re)configure your ports as long...

Bit late to this, but here's what I'd do: Create a new directory: /boot/kernel.bck, then extract kernel.txz in there. Edit /boot/loader.conf, then add this: kernels="kernel kernel.old kernel.bck". Reboot, and select your 'new' kernel. I always keep such a 'backup' kernel available in case of...

Well, when in doubt I'd try to rule out possible causes. Do you have a bare GENERIC kernel available? If not you can simply grab kernel.txz from download.freebsd.org and try booting the system with that to see if this behavior changes.

Custom kernel problem. By default the kernel includes the linux.ko module which provides support for that file type.

This is why you should make sure to become familiar with the shell you're working in, and get a grasp on redirection. Either using a pipe | or just redirecting output using >. Of course together with the impact of /dev/stdout, /dev/stderr and /dev/null. In other words: just redirect the output...

As far as I know you don't handle that in the Makefile but let pkg deal with it, courtesy of pkg-list. See also pkg-create, in specific the section about the PLIST format. So during the build process you don't bother with any of this, but specify what needs to be done during installation with...

You're not wrong, but the mindset itself dates from long before that. I mean... I'm old enough to have (briefly!) worked with CP/M and back then an application was essentially its own directory which contained everything needed to run (and sometimes also build) the application. Bit of the same...

Yah, I saw that. Unfortunately experienced doesn't say everything, it's no guarantee that you'll never overlook anything. And well, that VM was messy (no offense!). I'm considering it. But not just right now, best to let this cool off a bit and then we'll see where it takes me. I did copy the...