[SOLVED] Unreadable console after update (32-bit or drirc related?)

esuhl · 2017-10-16 05:30:16

I have a 32-bit Asus EEE 901 running Arch. I recently did an upgrade with pacman -Syu. Quite a few packages were upgraded, but the only "interesting" message that I noticed during the upgrade was the new /etc/drirc.pacnew.

I haven't modified the drirc file, so I had a look at the changes (with meld), and it looked like there had been a few sections added, so I backed up the old drirc file and replaced it with drirc.pacnew.

On rebooting, the BIOS and GRUB messages appear correctly, but just after Arch (appears to) check the storage devices, the display glitches, showing only dots and lines and two flashing text cursors.

I *tried* to log in blindly, and replace the new drirc file with the old backup, but this hasn't worked.

Is there any way I can make the console text visible again so I can troubleshoot? Perhaps there's a kernel command I can pass to GRUB to prevent Arch from loading a messed up display driver...?

Help! :-)

Last edited by esuhl (2017-10-23 08:57:57)

jasonwryan · 2017-10-16 06:12:44

Boot from a live medium and read your journal for the failed boot. Also, look at your pacman.conf to see what else was updated.

The 901 has an Intel card from memory, you could try using native modesetting by uninstalling the Intel driver (and removing any conf files in /etc/X11/xorg.d/).

seth · 2017-10-16 07:28:17

Afaiu the problem is already in the linux console, not X11.

Pass "nomodeset" (you won't get X11 for sure) and if you can see something, install the linux-lts kernel and try to boot that (w/o "nomodeset" parameter)
/etc/drirc is part of MESA and only the possible cause if you'd boot straight into a GL driven environment. The difference between the files should be some game differences.

myrlin · 2017-10-16 20:30:03

I've got exactly the same problem.

I did a re-install of a basic system (without GUI) but still get the same result.

seth · 2017-10-17 04:44:02

too often wrote:

Re-installation does not fix anything on a deterministic system.

Check "nomodeset", compare the lts kernel and as a random guess:
https://wiki.archlinux.org/index.php/In … _early_KMS
https://wiki.archlinux.org/index.php/In … ompression

myrlin · 2017-10-17 11:41:16

The latest version of the kernel seems to have resolved the problem.

BTW, my apologies for not explaining my actions clearly in my original post (in the interests of brevity).
I would NEVER normally re-install before resolving a problem. I had some capacity issues during the problem-causing update, so I took the opportunity to carry out a complete re-install, and used the initial base installation as a reference point. I hope this clarifies my earlier post.

randombit · 2017-10-17 13:15:09

I ran into this yesterday as well. I worked around it by rebooting with init=/bin/bash, editing /etc/default/grub setting

GRUB_GFXMODE=640x480
GRUB_TERMINAL_OUTPUT=console

After grub-mkconfig and reboot, everything is fine again.

esuhl · 2017-10-18 23:47:30

Thanks, all.

seth wrote:

Afaiu the problem is already in the linux console, not X11.
Pass "nomodeset" (you won't get X11 for sure) and if you can see something, install the linux-lts kernel and try to boot that (w/o "nomodeset" parameter)

Fantastic! Both the "nomodeset" paramater and linux-lts worked, so I had a usable system.

myrlin wrote:

The latest version of the kernel seems to have resolved the problem.

Hmm. Not for me. I did a full upgrade (which upgraded both the linux kernel and Intel video drivers), but the problem persisted.

randombit wrote:

I ran into this yesterday as well. I worked around it by rebooting with init=/bin/bash, editing /etc/default/grub setting
GRUB_GFXMODE=640x480
GRUB_TERMINAL_OUTPUT=console
After grub-mkconfig and reboot, everything is fine again.

Aha! Just setting GRUB_TERMINAL_OUTPUT=console worked for me (leaving GRUB_GFXMODE=auto).

Apparently this disables the console framebuffer. From what I've read, the framebuffer enables graphics capabilities within the console(?). Since I've never even seen any graphics in the console (except for the odd boot logo), can I assume that the framebuffer is pretty much pointless, so it's fine to disable it?

Last edited by esuhl (2017-10-18 23:48:15)

seth · 2017-10-19 06:53:26

As a workaround, but there's recently quite some trouble w/ the i915 kernel module what looks like modesetting related.

myrlin · 2017-10-20 14:44:29

The upgrade "solution" turned out to be temporary. Strange, since it seemed to survive several trial re-boots.

The GRUB_TERMINAL_OUTPUT=console workaround is working fine for me.

Many thanks to everyone for their help.

Arch Linux

#1 2017-10-16 05:30:16

[SOLVED] Unreadable console after update (32-bit or drirc related?)

#2 2017-10-16 06:12:44

Re: [SOLVED] Unreadable console after update (32-bit or drirc related?)

#3 2017-10-16 07:28:17

Re: [SOLVED] Unreadable console after update (32-bit or drirc related?)

#4 2017-10-16 20:30:03

Re: [SOLVED] Unreadable console after update (32-bit or drirc related?)

#5 2017-10-17 04:44:02

Re: [SOLVED] Unreadable console after update (32-bit or drirc related?)

#6 2017-10-17 11:41:16

Re: [SOLVED] Unreadable console after update (32-bit or drirc related?)

#7 2017-10-17 13:15:09

Re: [SOLVED] Unreadable console after update (32-bit or drirc related?)

#8 2017-10-18 23:47:30

Re: [SOLVED] Unreadable console after update (32-bit or drirc related?)

#9 2017-10-19 06:53:26

Re: [SOLVED] Unreadable console after update (32-bit or drirc related?)

#10 2017-10-20 14:44:29

Re: [SOLVED] Unreadable console after update (32-bit or drirc related?)

Board footer