[SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

fizz · 2021-04-22 01:32:19

I have an old Intel Core 2 Duo processor using Nvidia GeForce 6200.

I have been using Arch Linux since September 2020 on this old desktop. I use it every week and keep the packages up to date. Ever since the kernel was upgraded to 5.11.#, the login prompt is not visible. In order to get a login prompt, I have to add nomodeset to the kernel boot in Grub. I also get a login prompt when booting using Linux 5.10.# LTS without nomodeset.

I also did a fresh install using another hard drive following the Arch Linux Installation guide. I only installed a bare bones command line and recreated the same problem of not displaying the login prompt. Again, I get the login prompt with Linux 5.10 lts. I only installed the following packages not listing the dependencies:

base
linux
linux-lts
linux-firmware
networkmanager
grub
os-prober

If you need any more information, please let me know.

Last edited by fizz (2021-07-22 02:36:03)

seth · 2021-04-22 06:13:11

* can you ssh into the system?
* check the journal for the failed boot (sudo journalctl -b -1)
* Try to enforce the "proper" resolution, https://raw.githubusercontent.com/torva … modedb.rst

Also remove the "quiet" parameter from the kernel commandline to see whether you can get a bit more information out of the boot - does it turn black immediately once kms kicks in or does it just stall somewhen before you reach the login prompt (and you can still see some boot messages)?

fizz · 2021-04-23 03:34:11

I use ssh at work but I never tried setting it up on my home network. I generated the key on the sending desktop and the problem desktop using linux LTS but was unable to connect.

I checked the journal but did not see anything obvious. To be honest, there are a lot of details in the journal that is over my head.

I tried to force the resolution on the kernel commandline but that did not work - video=VGA-1:1920x1080@60me. I removed the "quiet" parameter but did not see any errors. The screen does not turn black/blank and the boot messages still display. I know the screen would normally turn black clearing the boot messages and then display the command prompt.

The installation I normally use (not the bare bones command prompt one installed on a separate disk) would normally work as follows.
- The screen would turn to a cleared black screen
- The startup sound plays.
- As the startup sound is playing, the Login Prompt along with the Getty autologin would display. "Startx" is then executed automatically to start Openbox and the desktop is fully displayed with my background picture and panel.

What happens now is the screen does not clear but the sound still plays. I then decided to press <ctl><alt> F2 to open a terminal which I cannot see. I typed my user ID and pw which should log me in at the command prompt. I typed "sudo poweroff" and my shut-down sound plays! I also see drive light activity. However the drive light goes out and the computer never powers off. The PC will not power off if I push the power button. I have to hold in the power button until the PC shuts off.

Last edited by fizz (2021-04-23 03:50:30)

seth · 2021-04-23 07:18:44

press <ctl><alt> F2 to open a terminal which I cannot see. I typed my user ID and pw which should log me in at the command prompt. I typed "sudo poweroff" and my shut-down sound plays

So the system actually boots, just the graphics stack is borked.

but was unable to connect

This seems then unrelated to the problem at hand, you somehow didn't properly setup the ssh server and cannot connect to 5.10.x either, do you?

Getty autologin would display. "Startx"

Because of your bare-bones thing, I don't expect this to help, but can you boot the multi-user.target only (no startx)?

I removed the "quiet" parameter but did not see any errors. The screen does not turn black/blank and the boot messages still display.

Please post a photo of this to get us an idea where things stall.

Wild guess: pass "nouveau.runpm=0 nouveau.nofbaccel" to the kernel parameters

fizz · 2021-04-29 02:54:10

I can't boot to the muli-user.target. I get no login prompt like the bare-bones install.

The first photo is when I remove the "quiet" parameter from the kernel commandline:

When I pass "nouveau.runpm=0 nouveau.nofbaccel" to the kernel parameters, I get the square login screen with black bars on each side on my wide monitor. Same result as "nomodeset":

The last photo displays what the login should look like. This is when I boot using Linux-lts:

Last edited by fizz (2021-04-29 23:33:15)

seth · 2021-04-29 06:12:15

Please replace th oversized images w/ links/thumbnails (I should have been clearer about that, the board has a 200x200 max rule)
The first image looks like and teh context suggests it stalls (right) before activating the framebuffer device.

There's a whole flurry of nouveau commits between 5.10 and 5.11 - you'll unfortunately have to bisect the kernel to spot the bogus one :-(
https://wiki.archlinux.org/index.php/Bi … s_with_Git

fizz · 2021-04-29 23:46:47

I really appreciate your guidance Seth. Bisecting bugs with Git is something I never did before and I do not know how long it will take for me to find the problem. I will do it, however.

I changed the pictures to thumbnails. Going forward, is it best to use thumbnails or a URL to click to see the picture in its original size? I could not see the text clearly in the small thumbnail.

seth · 2021-04-30 06:25:23

is it best to use thumbnails or a URL to click to see the picture in its original size

Yes. The thumbnails are just optional eye-candy.

You can use https://aur.archlinux.org/packages/linux-git/ and "makepkg -ie" to build and install the kernel (the "-e" prevents the sources from being re-fetched and allows you to git bisect around in them)
Obviously, if the HEAD commit has the problem already fixed, you can spare the effort ;-)

fizz · 2021-06-08 03:46:19

Git bisect first bad commit came up as https://git.kernel.org/pub/scm/linux/ke … 7b8909d009.

seth · 2021-06-08 07:12:01

That patch only removes an unused variable in a drm driver for the ARM cortex 72…?
I assume reverting that patch alone will not allow you to boot the kernel?

fizz · 2021-06-09 23:25:03

Yea, you're right. The revert did not correct the problem. I had such a rough time just to get to that point that I was not even thinking further what I should do. My mind was at a state thinking I can not take any further steps since I do not know C/C++ and do not know anything about writing drivers.

Now I feel at this point I must be doing something wrong with git bisect. I dropped using the AUR git bisect method because I could only successfully compile/install 5.13-rc4 (which still contains the current boot problem) but when I started the Git Bisect and tried recompiling/reinstalling, I kept hitting an error (failed twice with 2 different errors). I also stopped because each compile took 6 hours to complete on my old Core 2 Duo system.

I then git cloned the kernel tree using the same URL from the AUR PKGBUILD. Thanks to the great Arch documentation at https://wiki.archlinux.org/title/Kernel … nel_source, I executed "make localmodconfig" and then pressed <enter> to accept the defaults which cut down the compile time to 40 mins! I then saved the ".config" file for the subsequent runs. When I was ready for the next compile, I executed "make mrproper", copied the saved configuration to ".config", and executed "make olddefconfig" so I did not have to respond to prompts. What was annoying was for every subsequent compile, I had to wait about 2 minutes to respond to the following error:

arch/x86/entry/thunk64.o: warning: objtool: missing symbol table
make[2]: *** [scripts/Makefile.build:364: arch/x86/entry/thunk64.o] Error 1

According to https://git.kernel.org/pub/scm/linux/ke … fe4d96d09b, it's a bug with binutils. Most likely this is the culprit why the subsequent compiles using the AUR build failed although I don't recall the same error being generated. Anyway, I have to wait for that error, copy the "thunk64.o" from a good compile sitting in another directory of mine, and re-execute using "make -j3" (may have gave me a little performance gain over "-j2").

I executed the following using Git Bisect. Was this the wrong thing to do?
- git bisect start
- git bisect good v5.10
- git bisect bad v5.11-rc1
- started the compile/install as I explained above (make mrproper, copied the save configuration, etc.)

Using another copy of this kernel tree, I executed "git checkout v5.10" and successfully compiled/installed. The system booted successfully to the command prompt. Then tried "git checkout v5.11-rc1" which of course reproduced the current boot problem.

This is what I don't understand. When I checked out V5.10, the head commit was dated 12/13/2020. When I checked out V5.11-rc1, the head commit was dated 12/27/2020. I thought the git bisect would have only looked between those dates. Why did this thing end up with the first bad commit dated back to 9/21/2020 which is outside of that date range?

loqs · 2021-06-10 01:05:40

Linus merged pull requests that include commits dating before V5.11-rc1.
I built a series of kernels to help some users bisect between 5.10 and 5.11
https://drive.google.com/file/d/1oQUdNT … sp=sharing 5.10
https://drive.google.com/file/d/1vHLWtt … sp=sharing 5.11
https://drive.google.com/file/d/1jp6str … sp=sharing linux-loqs-5.10.r7737.g538fcf57aaee-1-x86_64.pkg.tar which should be the first bisection point.

fizz · 2021-06-10 22:54:26

Hi loqs. I am not sure what to do here. Am I to install all 3 Arch packages and respond with the results? If the first bisection point kernel contains the existing problem, will you send me the next bisection point package? I am assuming you did something different then what I did using git bisect. I did step through all bisect compiles. It estimated 13 compiles and I wound up executing 15 compiles before the bisect finally came up with the first bad commit message. If my assumption is wrong, please let me know.

loqs · 2021-06-10 23:21:01

fizz yes that would be the general approach. The 5.10 and 5.11 are sanity checks to ensure there is a known good and bad kernel. The first bisection point onward would follow the process you performed.
Possibly the first few steps might already be prebuilt.

What confuses me is this line

 git bisect bad v5.11-rc1

Why did you test 5.11-rc1 instead of 5.11? Have you tried linux-mainline? From miffie 5.13-rc5
Edit:
https://drive.google.com/drive/folders/ … sp=sharing is all the 5.10-5.11 kernels I have built from previous bisections

Last edited by loqs (2021-06-10 23:22:48)

fizz · 2021-06-17 23:49:46

I appreciate your packages loqs. It saved me some compiling time at the beginning of the bisect.

I used the 5.10 and 5.11 packages to confirm the good and bad kernel. The reason I used 5.11-rc1 is I thought it may save me a few compiles since the date range between the 2 points were narrower. That turned out to be false. I executed a second bisect using 5.11 this time but the results were the same. The same commits came up and the bisect gave me the same ending result pointing to the same first bad commit.

I believe I know why git bisect pointed to a commit that had nothing to do with my AGP board/Nouveau problem (I have Nvidia GeForce 6200). I believe Kernel support is being dropped for AGP and some code was removed. I first noticed commit https://git.kernel.org/pub/scm/linux/ke … dd99bd1a0d which removed some AGP code from module "include/drm/ttm/ttm_set_memory.h". I then looked in directory "include/drm/ttm" in tars v5.9, v5.10, and v5.11 and noticed modules "ttm_set_memory.h" and "ttm_page_alloc.h" are missing in v5.11. Both 5.9 and 5.10 work fine. I then looked at https://www.kernel.org/doc/html/latest/ … eters.html and noticed command-line parameter settings for "agp=" are "off" and "try_unsupported" which sounds to me AGP support is dropped. I tried "try_unsupported" and out of desperation "on" and it did not solve my problem.

There is an article back in 2020 titled "AGP Graphics Card Support Proposed For Removal From Linux" from a website called "phoronix" (I did not want to place the link because the web page is heavy with advertisements).

loqs · 2021-06-18 00:51:12

Would you mind sharing the bisect log? It is still a bit puzzling to me the first bad commit not being one touching ttm.
For instance if the removed code causing the issue was 4856e5aa0ef1 somehow that commit and all the other commits before 523be44c334b were marked good.

git log --oneline  523be44c334bc4e4c014032738dc277b8909d009...e46f468fef953dea30e7a7c69ad7e0370af26855
523be44c334b drm/imx/dcss: fix unused but set variable warnings
089d83418914 drm/vc4: hvs: Pull the state of all the CRTCs prior to PV muxing
92fdb97d648a drm/ttm: update kernel-doc line comments
afcd0c7d3d4c drm/panfrost: add Amlogic GPU integration quirks
110003002291 drm/panfrost: add amlogic reset quirk callback
91e89097b86f drm/panfrost: add support for vendor quirk
a7d39439f8bd drm/dev: Remove drm_dev_init
df2ce4596c04 drm/amdgpu: Convert to using devm_drm_dev_alloc() (v2)
cd01269d11a3 drm/i915/selftests: align more to real device lifetimes
82be0d7540b1 drm/i915/selftest: Create mock_destroy_device
c7b360612fe7 fbcon: Remove the superfluous break
4e139a9abb00 fbdev: aty: remove CONFIG_PM container
4856e5aa0ef1 drm/ttm: drop evicted from ttm_bo.

fizz · 2021-06-20 00:47:13

Every bisect compile I walked through were all bad. I was expecting at least one of them to turn up good which was why I was thinking I was doing something wrong. I am now confident I did this correctly. I tried compiling some tars to verify specific commits were indeed bad. I here what you are saying loqs. I am puzzled as well.

git bisect start
# good: [2c85ebc57b3e1817b6ce1a6b703928e113a90442] Linux 5.10
git bisect good 2c85ebc57b3e1817b6ce1a6b703928e113a90442
# bad: [f40ddce88593482919761f74910f42f4b84c004b] Linux 5.11
git bisect bad f40ddce88593482919761f74910f42f4b84c004b
# bad: [538fcf57aaee6ad78a05f52b69a99baa22b33418] Merge branches 'acpi-scan', 'acpi-pnp' and 'acpi-sleep'
git bisect bad 538fcf57aaee6ad78a05f52b69a99baa22b33418
# bad: [15b447361794271f4d03c04d82276a841fe06328] mm/lru: revise the comments of lru_lock
git bisect bad 15b447361794271f4d03c04d82276a841fe06328
# bad: [b10733527bfd864605c33ab2e9a886eec317ec39] Merge tag 'amd-drm-next-5.11-2020-12-09' of git://people.freedesktop.org/~agd5f/linux into drm-next
git bisect bad b10733527bfd864605c33ab2e9a886eec317ec39
# bad: [9713158cb2a918c3f6f5522eed23cdeb61f22e75] drm/amdgpu: Add and use seperate reg headers for dcn302
git bisect bad 9713158cb2a918c3f6f5522eed23cdeb61f22e75
# bad: [c0f98d2f8b076bf3e3183aa547395f919c943a14] Merge tag 'drm-misc-next-2020-11-05' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
git bisect bad c0f98d2f8b076bf3e3183aa547395f919c943a14
# bad: [6a6e5988a2657cd0c91f6f1a3e7d194599248b6d] drm/ttm: replace last move_notify with delete_mem_notify
git bisect bad 6a6e5988a2657cd0c91f6f1a3e7d194599248b6d
# bad: [291e8cdd6bc57658035239315d27f3f971ec062b] MAINTAINERS: mark FRAMEBUFFER LAYER as Orphan
git bisect bad 291e8cdd6bc57658035239315d27f3f971ec062b
# bad: [dd60202237a021d6c076546e79a08fcac863327b] drm/vc4: Introduce GEM object functions
git bisect bad dd60202237a021d6c076546e79a08fcac863327b
# bad: [4671078eb8e390bd44c458e2f482fbb61f5bc612] drm/amdgpu: switch over to the new pin interface
git bisect bad 4671078eb8e390bd44c458e2f482fbb61f5bc612
# bad: [0ef1ed813e6b13d29331088070c7f554b350a266] drm/ttm: add bo wait that takes a ctx wrapper.
git bisect bad 0ef1ed813e6b13d29331088070c7f554b350a266
# bad: [4127a6204970b3d7cb140117472eb3dd99bd1a0d] drm/ttm: remove nonsense AGP handling
git bisect bad 4127a6204970b3d7cb140117472eb3dd99bd1a0d
# bad: [b8f8dbf6495850b0babc551377bde754b7bc0eea] drm/vram-helper: Fix use of top-down placement
git bisect bad b8f8dbf6495850b0babc551377bde754b7bc0eea
# bad: [d7b1c018140fb4b513c4e05685d74ef8178ef179] drm/panel: samsung: make vint_table static const
git bisect bad d7b1c018140fb4b513c4e05685d74ef8178ef179
# bad: [523be44c334bc4e4c014032738dc277b8909d009] drm/imx/dcss: fix unused but set variable warnings
git bisect bad 523be44c334bc4e4c014032738dc277b8909d009
# first bad commit: [523be44c334bc4e4c014032738dc277b8909d009] drm/imx/dcss: fix unused but set variable warnings

loqs · 2021-06-20 05:21:31

I have built and uploaded the same commit. As a cross check please test if that is also bad.

fizz · 2021-06-21 04:24:53

Did not work. Package for commit 523be44c334b is bad.

fizz · 2021-07-22 02:36:26

I got a nice surprise! I just installed Linux 5.13.4 through Pacman and it now works!

Arch Linux

#1 2021-04-22 01:32:19

[SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

#2 2021-04-22 06:13:11

Re: [SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

#3 2021-04-23 03:34:11

Re: [SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

#4 2021-04-23 07:18:44

Re: [SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

#5 2021-04-29 02:54:10

Re: [SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

#6 2021-04-29 06:12:15

Re: [SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

#7 2021-04-29 23:46:47

Re: [SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

#8 2021-04-30 06:25:23

Re: [SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

#9 2021-06-08 03:46:19

Re: [SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

#10 2021-06-08 07:12:01

Re: [SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

#11 2021-06-09 23:25:03

Re: [SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

#12 2021-06-10 01:05:40

Re: [SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

#13 2021-06-10 22:54:26

Re: [SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

#14 2021-06-10 23:21:01

Re: [SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

#15 2021-06-17 23:49:46

Re: [SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

#16 2021-06-18 00:51:12

Re: [SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

#17 2021-06-20 00:47:13

Re: [SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

#18 2021-06-20 05:21:31

Re: [SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

#19 2021-06-21 04:24:53

Re: [SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

#20 2021-07-22 02:36:26

Re: [SOLVED] No Login Prompt Since Upgrading to Kernel 5.11.#

Board footer