Solved 12.x to 13.0 update: 13.0 should boot straight into KDE but stops at "login:" in terminal

jdrch

jdrch

UPDATE 2: Solution.



UPDATE: Filed a bug.



I was on 12.x (12.2, I think?) previously, and had KDE setup so that the OS booted right into a graphical login. Post-13.0 update, that no longer happens. Now the OS just shows login: in a terminal, and logging in just keeps me in the terminal and doesn't go into KDE at all.

I've already run # pkg-static upgrade -f to pickup the 13.0 package ABI stuff, but nothing changes after reboot.

FWIW I'm using the open source VESA driver as I'm on an Intel Core 2nd Gen iGPU.

Any ideas on how to boot straight into KDE?
 
Last edited:
Beastie7 said:
What does this mean
Click to expand...
Possible wrong terminology, but the graphical username and password prompt most DEs present at login. Sorry, I'm frustrated enough that in 2021 a major OS can't manage a major version upgrade following documented procedures on a simple iGPU config without breaking the DE. I haven't had this happen since the Windows 95 days.
 
jdrch said:
Any ideas on how to boot straight into KDE?
Click to expand...
Did you have DRM? What type of video card. You should recompile the kernel bound ports. Recompile the graphics/drm-kmod

See my post about that:
forums.freebsd.org

Solved - DRM is dead after 13-RC2 install

Hello! Performed an experiment with 13.0 RC2. Everything went well until the DRM needed to be reinstalled. Do you have any ideas how to proceed? The system is up and working, even my persistent L2ARC from former OpenZFS is there. But I can not build the DRM. Here is my log: bectl create...
forums.freebsd.org forums.freebsd.org
 
richardtoohey2 said:
The sense of entitlement ... which is stunning for a volunteer open source project.
Click to expand...
Expecting a DE to survive an in-place major version upgrade on iGPU system isn't egregious. Every other major FLOSS distro manages to do it. I know this because I run Debian and Ubuntu on bare metal iGPU systems. I'm not entitled; FreeBSD is simply categorically subpar here.
 
Argentum said:
Did you have DRM? What type of video card. You should recompile the kernel bound ports. Recompile the graphics/drm-kmod

See my post about that:
forums.freebsd.org

Solved - DRM is dead after 13-RC2 install

Hello! Performed an experiment with 13.0 RC2. Everything went well until the DRM needed to be reinstalled. Do you have any ideas how to proceed? The system is up and working, even my persistent L2ARC from former OpenZFS is there. But I can not build the DRM. Here is my log: bectl create...
forums.freebsd.org forums.freebsd.org
Click to expand...
Thanks, but I'm not about to become a git expert to fix this. It's just not worth the effort when other capable free OSes don't have this problem and FreeBSD isn't my daily driver (nor it is making a particularly good case.) I've filed a bug; I'll either wait for an upstream package fix or blow my FreeBSD installation away with OpenIndiana, whichever comes first.

I've struggled with FreeBSD's second-class treatment of all things DE since deciding to give it a whirl in 2018 and this was the last straw. If I ever deploy it again it'll probably be in the form of TrueNAS.
 
FreeBSD never had any automatic "Desktop" setup, and with that attitude you're showing here, I really wonder how you ever managed to get it working at all. From your log, it's obvious the X server wants to use DRI, which isn't available. So, install graphics/drm-kmod (or graphics/drm-fbsd13-kmod which should be picked automatically on FreeBSD 13) and make sure you have the driver loaded (kld_list="/boot/modules/i915kms.ko" in /etc/rc.conf).

But then, if you expect a system holding hands with setting up Desktop stuff, yes, look somewhere else.
 
jdrch said:
Expecting a DE to survive an in-place major version upgrade on iGPU system isn't egregious. Every other major FLOSS distro manages to do it.
Click to expand...
  1. FreeBSD is not a "distro". Adjust your expectations.
  2. There's a separation from the OS and your ports and packages.
  3. The handbook explains how to do an update of a major version; One point of it is that you should reinstall all your package (!). This step you have not done.
  4. "drm-kmod" is a package you've once installed. You should know that.
 
jdrch said:
Possible wrong terminology, but the graphical username and password prompt most DEs present at login.
Click to expand...

Oh, that's called a display manager. A few things; install DRM like mentioned above, ensure X.org still works. If you can drop into kwin from tty, then you're golden.

If no cigar, then reinstall the display manager you've chosen.

If still no cigar, backup your home folder, then bake that cake again from scratch. :)

jdrch said:
Also, kindly look at the bug I filed. Per r/FreeBSD it seems the repo Xorg & DRM drivers are broken ... which is stunning for what I've come to expect from RELEASE code.
Click to expand...

jdrch said:
Expecting a DE to survive an in-place major version upgrade on iGPU system isn't egregious.
Click to expand...

jdrch said:
I've struggled with FreeBSD's second-class treatment of all things DE since deciding to give it a whirl in 2018 and this was the last straw.
Click to expand...

Well, the committers are unable to maintain stable API/ABI compatibility because upstream heavily follows Linux interfaces. So KDE/DRM breaking between release upgrades is somewhat inevitable. FreeBSD desktop is upstream Linux at the moment; this is just the reality of the matter. Take it or leave it.

Seriously, some patience and gratitude goes a long way. FreeBSD needs lots of tender love, and care on the desktop. She's trying.
 
Beastie7 said:
Well, the committers are unable to maintain stable API/ABI compatibility because upstream heavily follows Linux interfaces.
Click to expand...
You do realize a major version upgrade is almost guaranteed to break the ABI? That's the whole point of a major version upgrade.
 
Beastie7 said:
But a production desktop/workstation should not break, period.
Click to expand...
Any kind of update or upgrade could break something. There's always a certain amount of risk. This risk factor is usually quite small but it's always going to be there.
 
Beastie7 said:
I do, and that's fine. I'm not knocking FreeBSD on it's merits. But a production desktop/workstation should not break, period. That's what the OP is complaining about.
Click to expand...
I think in this case this is probably impossible. At least kernel bound ports should be recompiled/installed after major version upgrade. Personally I do it after each upgrade for safety.
In this case graphics/drm-fbsd12.0-kmod should be replaced with graphics/drm-fbsd13-kmod. This cannot be fully automatic, especially when older version of the port or package is installed.

Personally, I have one desktop and one laptop machine to 13.0 FreeBSD CUPRUM 13.0-RELEASE FreeBSD 13.0-RELEASE #1 ea31abc26: Tue Apr 13 08:50:16 EEST 2021 root@CUPRUM:/usr/obj/usr/src/amd64.amd64/sys/CUPRUM amd64 and naturally reinstalled the DRM. That was pretty much the only thing needed to do. Everything else remained working.

 
A new ABI isn't the problem here. Breaking changes in major releases are a normal thing, and FreeBSD by default ships with backward compatibility down to FreeBSD 4.

Packages with kernel modules are a different issue, cause inside the kernel, you can have breaking changes between minor releases as well. That's the reason why you have to compile e.g. graphics/drm-fbsd12.0-kmod when upgrading to 12.2 before 12.1 is EOL. This currently doesn't apply to upgrading to 13.0 – there's only one minor release, and graphics/drm-fbsd13-kmod is the correct package for it.

The whole "issue" is that FreeBSD updates don't automate anything not part of the base system. You should know yourself what you have to do (and, of course, there are UPDATING files you should read).
 
SirDice said:
You do realize a major version upgrade is almost guaranteed to break the ABI? That's the whole point of a major version upgrade.
Click to expand...
You do realize this isn't an issue for pretty much any other distribution, right? And also that the fact that 13.0 was made RELEASE without anyone bothering to make sure the DE components worked is egregious.

Look, I've spent years trying to see the magic of FreeBSD and run it, but based on numerous threads like this and also user polling showing no userbase interest in treating DEs as the 1st class citizens, I'm done trying. Plan is to deploy TrueNAS to expand my storage options; hopefully I don't run into the same stonewalling for routine functionality as I have here for years.

From a user perspective, running a DE on FreeBSD just is not worth the effort. The devs don't care, and neither does the rest of the userbase.
 
Beastie7 said:
I do, and that's fine. I'm not knocking FreeBSD on it's merits. But a production desktop/workstation should not break, period. That's what the OP is complaining about.
Click to expand...
Wow, someone who gets it. This is exactly my point.

jmos said:
  1. FreeBSD is not a "distro". Adjust your expectations.
  2. There's a separation from the OS and your ports and packages.
  3. The handbook explains how to do an update of a major version; One point of it is that you should reinstall all your package (!). This step you have not done.
  4. "drm-kmod" is a package you've once installed. You should know that.
Click to expand...
The "D" in the name historically stands for "Distribution." Since FreeBSD enjoys tracing its lineage, one would expect the inherited acronym to be similarly meaningful.

Zirias said:
A new ABI isn't the problem here. Breaking changes in major releases are a normal thing, and FreeBSD by default ships with backward compatibility down to FreeBSD 4.

Packages with kernel modules are a different issue, cause inside the kernel, you can have breaking changes between minor releases as well. That's the reason why you have to compile e.g. graphics/drm-fbsd12.0-kmod when upgrading to 12.2 before 12.1 is EOL. This currently doesn't apply to upgrading to 13.0 – there's only one minor release, and graphics/drm-fbsd13-kmod is the correct package for it.

The whole "issue" is that FreeBSD updates don't automate anything not part of the base system. You should know yourself what you have to do (and, of course, there are UPDATING files you should read).
Click to expand...
I literally followed the update directions in the release notes. There were no links in the release notes suggesting anything else is necessary. Users can't know what they don't know or what official instructions don't prescribe.

But, as I've said, I've come to the realization that running FreeBSD as a workstation is a losing battle. Asking desktop users to compile from source in 2021 is anachronistic regardless of the rest of the OS' engineering. But it is what it is, and after years of effort I'm just done. Time to admit defeat and move on to something else.
 
Zirias, I am not able to understand your attitude, which seems to be misplaced on users-to-users help forums. If you can’t or don’t want-to help, then what are you still doing here?

BTW, in the meantime, quite the same issue has been reported by decuser: https://forums.freebsd.org/threads/kde-login-hangs-with-circle-stopping-on-freebsd-13.79825/

So, do you own a system running sddm and KDE5? If yes, then tell us at least, what your experience was, after upgrading it to FreeBSD 13.0. In case no, stop repelling new users, from asking valid questions.

Remember: „Stupid questions do not exist, there are only stupid answers.“
 
  1. I don't see any questions asked here, looks more like your good old trolling.
  2. Yes, I DO have desktops with KDE and sddm, and they work fine after the upgrade.
  3. From the only sensible piece of information posted here, it's pretty obvious the problem is neither KDE nor sddm but a non-working X server.
And FWIW, I'm helping a lot of people here, people who actually seek help and ask questions. Just complaining and implying FreeBSD should do what your typical "Desktop Linux Distro" does won't ever get a positive reaction from me. I've had this horror just yesterday, having to "fix" some random fedora box. No thanks. Whoever thinks FreeBSD should work that way should, pretty please, use something that does work that way.
 
jdrch said:
But it is what it is, and after years of effort I'm just done. Time to admit defeat and move on to something else.
Click to expand...

I've done the same; although my rage quit began after less time. If your experience doesn't match what you require out of a desktop; it's best to lick your wounds. Keep your eye on helloSystem though.
 
You must log in or register to reply here.
Back
Top