Things that make me go "GRrrrrrr" installing FreeBSD 13.1

fernandel said:
As many times drhowarddrfine said the same topics starts again and again.
IMO this is the "war of generation". I am not IT educated but I can compare this debate with my work as researcher (genetics). Everything the same. Older you are less you want changes. But time didn't stop and young people with new ideas are coming but we old one never trust them. But it is not our future, it is future of the young generations.
Click to expand...
Good observation - and it is correct that way, because thus the balance is created. Purely conservative, not moving at all, is death. Purely innovative, wildly growing in all directions, is cancer. None of them could support life.
 
drhowarddrfine said:
fernandel The fundamentals have never changed and text will always trump graphics in the sciences. This is not a question of preferences. It's a question of fundamentals. That will never change.
Click to expand...
Yes, fundamentals are more or less the same. Just compare with PCR machine which was popular in my days or now. When we show the students they just laugh. Settings are very important (not just settings) but fundamentals is the same.
 
The other thing to remember is that change for the sake of change without reason is never a good reason to change. Often you hear the phrase applied to GUI ideas that "a picture is worth a thousand words" but that phrase was created and applied to something entirely different than this topic.

Something being new is not necessarily any better because it's new any more than something old is bad because it's old.
 
PMc said:
Good observation - and it is correct that way, because thus the balance is created. Purely conservative, not moving at all, is death. Purely innovative, wildly growing in all directions, is cancer. None of them could support life.
Click to expand...
Exactly. The reason older folks are skeptical of the new hotness is that we've seen so much hype come and go, and often had to pick up the pieces when the whiz-bang new thing blew up in midair.

However, the brilliant new thing is there somewhere in the pile of buzz and nonsense. Younger and less experienced people are perfect for looking for it because their opinions haven't been colored by so much disappointment yet.
 
ProphetOfDoom said:
Aah don’t get me started on GNU autotools.
Click to expand...
Too late!

GNU autotools does have some considerable advantages to CMake but it is implemented so awkwardly, it barely works on Linux or Hurd either (the two core GNU platforms).

I feel autotools would have worked so much better had GNU not been involved with any of it. I love the concept behind GNU but their technical implementations of anything are always a confused mess.
 
kpedersen said:
Too late!

GNU autotools does have some considerable advantages to CMake but it is implemented so awkwardly, it barely works on Linux or Hurd either (the two core GNU platforms).

I feel autotools would have worked so much better had GNU not been involved with any of it. I love the concept behind GNU but their technical implementations of anything are always a confused mess.
Click to expand...
Here is a parody of GNU autotools (not mine) that – I feel – grabs its essence, at least from a user's perspective:
Code: 
for i in /usr/include/*.h; do echo -n "checking for $i ... "; sleep 1; echo "ok"; done
 
kpedersen : Yes, GNU was the best thing that ever happened to software... the main issue I have with GNU autotools in particular (clearly I wanted to moan about this really) is that it seems to be written with the assumption that autotools itself will never malfunction. And that’s way too optimistic. I recently had to write some patches to nasm (the Netwide Assembler) on Linux for a hobby project of mine, and was trying to build my patched nasm on FreeBSD and I had to fix ~15 or so errors related to autotools. I can’t remember if they were errors in nasm’s input to autotools, or errors in the actual scripts generated by autotools but I think it was the latter. I think bash was assumed, not sh, also.
Holger, time for a pull request? “Removed unnecessary cruft”.
 
First, I love the FreeBSD installer. Ever since FreeBSD 5.x, or maybe I should say as far back as I can remember, I've never had to go read how to install FreeBSD. Literally, if you can `dd` an image or use cdrecord you're good. The availability of thumb drives made it even easier.

Also, with a small bit of reading learning how the installer works is remarkably simple:

It uses gpart to create a partition table and create partitions and boot sectors written. geli is then used to encrypt the disks, and either UFS or ZFS is used to build filesystems on the resulting partitions. The root filesystem is mounted in /mnt; chroot into our new root, and the base.txz is extracted into the root. Password is set, users created, additionally src, lib32 support, man pages, and debug symbols can be extracted as well.. and you can drop into the installation to further customize before reboot.

The advantage of it's simplicity is A) its easy to customize and B) you don't actually have to use the installer.

I am not proposing we do this, but I actually think that the freebsd installer could be further simplified to a single screen asking to select disks and a geli key, create partition tables and partions, install base.txz, zfs on geli, and be done.

Back to the OP. I have the same issue with some of the older hardware I support in regards to needing firmware. I solve this problem by mounting the thumbdrive after `dd`ing onto the thumb drive and loading fiirmware and kernel modules onto the thumb drive. It would be nice to include this in the handbook and if I find some time over the holidays, I'll submit a PR.
 
Another year, another shot at making freebsd my main os over archlinux. This time with 13.2.
On the positive side: I can now have neovim and obs-studio installed side by side without one removing the other, so that's good.
However I did an installation on my Lenovo-Laptop with an integrated intel graphics card. So I followed Chapter 5 of the handbook and did:
"sudo pkg install drm-kmod" followed by "sudo sysrc kld_list+=i915kms", creating the file "/usr/local/etc/X11/xorg.conf.d/20-intel.conf" after that. The reboot did a flicker, indicating that the driver-module was successfully loaded.
Then I typed "startx" and the server crashes, saying there is no driver available. Installing "xf86-video-intel" solves that issue but that isn't mentioned in the handbook and is said to be optional.
If I was a newbie and didn't have that much experience with linux, how would I make sense of this? So for now I leave it at that and it's another thing that makes me go Grrrrrrr with freebsd.
P.S.
Someone in the irc mentioned that drm-kmod might only be built against 13.1. and I'd have to build it against 13.2. from ports, but c'mon, why does it have to be like that?
 
andmars said:
creating the file "/usr/local/etc/X11/xorg.conf.d/20-intel.conf" after that.
Click to expand...
What's in it? Just remove it. It should autodetect the modesetting driver.

andmars said:
Then I typed "startx" and the server crashes, saying there is no driver available. Installing "xf86-video-intel" solves that issue but that isn't mentioned in the handbook and is said to be optional.
Click to expand...
X just looks for the old intel(4) driver by default, doesn't mean it's supposed to be there.

The original post of this thread mentions an NVidia card, why are you installing Intel/AMD drivers?

andmars said:
Someone in the irc mentioned that drm-kmod might only be built against 13.1. and I'd have to build it against 13.2. from ports, but c'mon, why does it have to be like that?
Click to expand...
Not relevant any more. FreeBSD 13.1 is now EoL and packages are being built for 13.2 specifically. And, in this case, the DRM driver built for 13.1 worked just fine on 13.2, so this was never an issue to begin with.
 
SirDice said:
What's in it? Just remove it. It should autodetect the modesetting driver.


X just looks for the old intel(4) driver by default, doesn't mean it's supposed to be there.
Click to expand...
Thank you for the ultra fast response.
Well in the 20-intel.conf is what is written in the handbook:
Code: 
Section "Device"
 Identifier "Card0"
 Driver     "intel"
EndSection

And I use startx because I want to use the dwm window manager instead of something like gdm for gnome, etc. Is there a better way?

(regarding intel and nvidia driver...my main PC has an nvidia card. At the moment I'm installing on my laptop which has an intel chip. If it works all fine on that laptop I want to give it another try on my main machine).
 
Replace Driver "intel" with Driver "modesetting".

andmars said:
And I use startx
Click to expand...
That's fine. I would recommend using that until you get X configured correctly. Makes it easier to test.

andmars said:
because I want to use the dwm window manager instead of something like gdm for gnome, etc. Is there a better way?
Click to expand...
Most, if not all, display managers allow you to select the window manager/desktop environment you want to start for that session.
 
No wireless networks were found. Rescan?

The installer does not find Wi-Fi networks after scanning. I found out over the weekend that if I don't change the regional default (FCC/US) then it shows the networks on the first scan and I set up the connection with no problem.
The network interface seems to get an error when I choose my ETSI region, only during installation. You will probably want to configure regdomain in /etc/rc.conf later.

I think it can be useful for PR, I'm not going to waste more time updating it. The comments seem to go unnoticed.

Bored!

PR 246126
 
SirDice said:
Replace Driver "intel" with Driver "modesetting".
Click to expand...
Replacing "intel" with "modesetting" indeed did the trick and startx also works with it. Same with not having a 20-intel.conf file at all. So this file seems to be obsolete. Should the handbook be edited accordingly?
 
andmars said:
Replacing "intel" with "modesetting" indeed did the trick and startx also works with it. Same with not having a 20-intel.conf file at all. So this file seems to be obsolete. Should the handbook be edited accordingly?
Click to expand...

The instructions aren't obsolete if you have the older (non-modesetting) Intel card, but I agree it is very confusing for those with the more common hardware these days.

https://docs.freebsd.org/en/books/handbook/x11/#x-config-video-cards

The handbook just naturally flows into this "custom xorg.conf" section which is a bit misleading. It should probably clarify that this is for older cards (same with radeon) and most guys can just skip it.

On Linux, don't they call this driver "crocus" or is this a new driver specifically for older chips?
 
astyle said:
Looks like FreeBSD is trying to do something about the NVidia issues...
Click to expand...
Did you miss this?
forums.freebsd.org

Call For Testing: nvidia-drm kernel module

Hello everyone, I'm happy to announce that the port of Nvidia's DRM driver is now ready for public consumption. Please visit the github repo to grab the latest copy of the driver. Simply follow the installation instructions and load the nvidia-drm.ko kernel module to give it a go. Please post...
forums.freebsd.org forums.freebsd.org
 
You must log in or register to reply here.
Back
Top