Ctrl-Alt-Fn from X leads to blank screen

H

hruodr

After hours upgrading from 14.0 to 14.2, perhaps 5 hours, I got from a working system a broken system.

It is frustrating! Both, the hours of upgrade and a broken result is not surprise, it became normality in FreeBSD.

Perhaps that this happens in a minor upgrade is new.

The problem is, as written above, that I cannot get back to the console.
I need it to see the console messages, at least when I shutdown the system, but not only.
It is a grave thing in my opinion.

This is my motherboard:

E35M1-I - Support

www.asus.com www.asus.com

Any hint? Thanks!

Edit:
Ctr-Alt-F1 brings the monitor to standby state as were the system turned off.
I can return to X11 with Ctr-Alt-F9.
 
Emrion said:
(replace "virtualbox-ose-kmod" by the drm-XX-kmod you use, if you choose to use the FreeBSD-kmod repo)
Click to expand...
Thanks, but I do not understand.

How I get what "drm-XX-kmod I use". I did not know I use that!!!!

And where to replace it?

With pkg_info I get:

# pkg info | grep drm
drm-61-kmod-6.1.92.1401000_3 DRM drivers modules
drm-kmod-20220907_3 Metaport of DRM modules for the linuxkpi-based KMS components
gpu-firmware-kmod-20241114,1 Firmware modules for the drm-kmod drivers
libdrm-2.4.123,1 Direct Rendering Manager library and headers
# pkg info | grep video
xf86-video-amdgpu-22.0.0_2 X.Org amdgpu display driver
xf86-video-ati-19.1.0_7,1 X.Org ati display driver
xf86-video-scfb-0.0.7_2 X.Org syscons display driver
xf86-video-vesa-2.5.0_3 X.Org vesa display driver
Click to expand...
 
from: https://github.com/Emrion/FreeBSD-kmod
When a new minor version of FreeBSD is released, three months are required before the repositories get compiled with this new version.For mundane softwares, there is no incidence, but for the ones that are kernel modules, this can lead to some problems, including crashes.
Click to expand...
Does this do not speak about a very bad politic of FreeBSD?
I need to work with the computer.
On the one side I am compelled to update a working system, because it is not more supported,
on the other side upgrading leads to a broken system.

I repeat: it is frustrating. The upgrading takes hours and leads to a broken system.
This became the rule, not an exception.
 
Ok, you installed the meta port drm-kmod. It's a little more complicated.

You need to make drm-61-kmod and gpu-firmware-kmod "non-automatic installed" software.
pkg set -A0 drm-61-kmod
pkg set -A0 gpu-firmware-kmod
pkg delete drm-kmod
drm-kmod is of no longer use.
You already put the right config file concerning FreeBSD-kmod in /usr/local/etc/pkg/repos/.
pkg delete drm-61-kmod
pkg install drm-61-kmod
It should install the suited and official version of drm-61-kmod.
 
Emrion said:
Ok, you installed the meta port drm-kmod. It's a little more complicated.
Click to expand...
Thanks. I do not need more complicated, but more simple and transparent. That is a reason to go back to OpenBSD.
Emrion said:
You already put the right config file concerning FreeBSD-kmod in /usr/local/etc/pkg/repos/.
Click to expand...
I did it, and made the error of typing "pkg upgrade". It terminated abnormal.
I deleted it.

Do you think the problem will be solved if I wait 3 months and upgrade?

Do people that use FreeBSD as server have such problems? Default for hours do to upgrade?
Waiting months to get things working again?

UPDATE:

What I did was only to change to latest and upgrade, that did not work.

Now I did exactly what you said and I have again a console.

THANKS A LOT!!!!
 
Thanks again, problem is solved. I do not understand exactly how, but solved.
From where did the system download your compiled drm kmod?
Emrion said:
pkg set -A0 drm-61-kmod
pkg set -A0 gpu-firmware-kmod
Click to expand...
Will this not bring problems in the future?
What are the consequences of this?
 
I see now, the solution with /usr/local/etc/pkg/repos is not downloading your compiled module,
but a mechanism of FreeBSD. But what does it mean?
Why did not install the correct module with the upgrade if they know there is an upgraded version?
 
hruodr said:
Why did not install the correct module with the upgrade if they know there is an upgraded version?
Click to expand...
This is not an upgraded version of the drm-61-kmod, it's the same one, but compiled for 14.2-RELEASE instead of 14.1-RELEASE. The issue has been discussed a lot by the community in last months and is mentioned in errata for 14.2.

hruodr said:
But what does it mean?
Click to expand...
Basically, you had three options: upgrade to 14.1, which is not EoL until April, build the kmod yourself from the ports, or find/set a place to download the pre-built package. You chose the 3rd one.
 
hruodr said:
from: https://github.com/Emrion/FreeBSD-kmod

Does this do not speak about a very bad politic of FreeBSD?
I need to work with the computer.
On the one side I am compelled to update a working system, because it is not more supported,
on the other side upgrading leads to a broken system.

I repeat: it is frustrating. The upgrading takes hours and leads to a broken system.
This became the rule, not an exception.
Click to expand...
I'm not here to comment the "politic" chosen by the FreeBSD staff. I just know that FreeBSD is... free. I'm really happy and grateful for what it brings to me.

Are there problems in the use of this OS? Yes, of course, like any OS.

Are some people aware of these problems and working to address it? Absolutely. The FreeBSD-kmod repository is a solution and maybe THE solution for this very problem.
 
hruodr said:
Thanks again, problem is solved. I do not understand exactly how, but solved.
From where did the system download your compiled drm kmod?

pkg set -A0 drm-61-kmod
pkg set -A0 gpu-firmware-kmod

Will this not bring problems in the future?
What are the consequences of this?
Click to expand...
No consequence, except you don't use drm-kmod anymore. It was drm-kmod which pulled drm-61-kmod and gpu-firmware-kmod as dependencies. Now, it's like you installed yourself these last two packages. It's easier for the future upgrades.
 
hruodr said:
What are the consequences of this?
Click to expand...
From the man page, it is as I had installed it manually and will not deleted by autoremove.
Emrion said:
I'm really happy and grateful for what it brings to me
Click to expand...
Of course I am happy and grateful, but the experience is frustrating:
compelled to update, update take hours, at the end one gets a broken system.

Before was the same. I upgraded from 12 to 13 in hours and got a broken system,
immediately I upgraded to 14.0 in some more hours more. And that was not the
first time. Even when I installed, the installer made problems.

In OpenBSD is all much more primitive, one must update from release to release,
twice a year, but it takes about 30 minutes and rarely one gets a a broken system.
The installer is very stable and never makes problems.

I think FreeBSD is neglecting something here.
 
hruodr said:
From the man page, it is as I had installed it manually and will not deleted by autoremove.

Of course I am happy and grateful, but the experience is frustrating:
compelled to update, update take hours, at the end one gets a broken system.

Before was the same. I upgraded from 12 to 13 in hours and got a broken system,
immediately I upgraded to 14.0 in some more hours more. And that was not the
first time. Even when I installed, the installer made problems.

In OpenBSD is all much more primitive, one must update from release to release,
twice a year, but it takes about 30 minutes and rarely one gets a a broken system.
The installer is very stable and never makes problems.

I think FreeBSD is neglecting something here.
Click to expand...
I think you should go back to OpenBSD, you mentioned it many times in your last posts.
 
fmc000 said:
I think you should go back to OpenBSD, you mentioned it many times in your last posts.
Click to expand...
5 hours for a minor upgrade is non go, and much more non go if one ends with a broken system.
You may be FreeBSD fanatic for not seeing it, but it is necessary to point at.
Look at this:

Hi Colin. Why is freebsd-update(8) so slow? When upgrading between releases, it'... | Hacker News

news.ycombinator.com news.ycombinator.com

cperciva on Dec 27, 2018 [–]

FreeBSD Update is doing something it was never designed for. I wrote it as a tool for security updates -- which inherently affect just a handful of files --and have a number of paranoid checks in it, in order that it can be safely run blindly.
We needed a tool for upgrading between releases, and I was able to hack that into FreeBSD Update, but I didn't change the fundamental design. At this point, we're all waiting for pkgbase so there's no reason to revisit the design now.
Click to expand...
The solution to this awful problem is since long due.
But it seems that replacing forth with lua in the well working bootloader was considered more important.
 
Getting artifacts from exiting X with nvidia, I workaround it by shutting down from a terminal while still having xterm access, and do console things before manually starting Xorg when booting up.
 
jb_fvwm2 said:
Getting artifacts from exiting X with nvidia, I workaround it by shutting down from a terminal while still having xterm access, and do console things before manually starting Xorg when booting up.
Click to expand...
Not possible in this case. No virtual terminal after starting X. Unless you connect a VT100 through a serial port.
 
You must log in or register to reply here.
Back
Top