-1

I got done installing yesterday. Throughout configuring it , I've been noticing that it has terrible delays in the tty , right from first boot (so this has nothing to do with anything I might have installed) . I'm not going to install and a WM or DE so, this is quite painful.

I tried reading the Arch wiki and searching the forum and came across this. I'm not having the exact same problems , his issue is slow output, my issue is a lag before the output : after entering a command / quitting vim / pressing enter after giving password during login , The cursor " _ " just sits and blinks on the new line with no output for a very noticeable amount of time, when it ought to be instantaneous. But, his fix was setting vga=offand GRUB2 has deprecated that so it fixes nothing now.

Am using Intel HD Graphics 4000 and 6000 , and on both machines, the problem persists.

What can be done ?


EDITS:

To visualise the issue , this is similar to how when you run dd / cp / mv / gcc on a large file and press [ENTER], so the cursor moves to the start of the next line in the tty and blinks for a while until the program exits and then the shell prompt is displayed, like :

xyz@xyz ~#

I have the same issue at random when doing simple commands or sometimes when logging in, exiting vim, etc.

Some strange output lag is occurring between my input/program finishing and the shell displaying the output of said program and the prompt, as I can confirm by running time and then my command : the time taken for the command is very very little, less than a second, and yet I end up waiting for 30-40 seconds before getting the output and prompt.

The same stuff is instantaneous on the install ISO, my Ubuntu install , and basically everywhere else.

I'm using the linux-lts kernel but that shouldn't matter ?

Pastebin of dmesg : https://pastebin.com/GYp7mDqT

Did a bunch of testing in bash --norc --noprofile with a file tmp consisting of 256 MiB of zeros from /dev/zero :

time cp tmp tst

real 1m11.480s
user 0m0.000s
sys 0m0.348s

but

time sleep 1

real 0m1.002s
user 0m0.001s
sys 0m0.001s

Indicating that File I/O is somehow involved ? Considering that after writing to files, the system takes an abnormal amount of time to get back to giving me the necessary output ?

3
  • 1
    Is this limited to just the VTs, or does it also happen if you somehow start a graphical terminal through X or Wayland? Is this limited to bash, or does it also affect other shells such as zsh, dash, ksh or tcsh? (Note that 'sh' on Arch is bash.) Have you in fact tried other kernels besides linux-lts (which I assume is still at 5.4.x on your system)? The whole Linux VT is entirely a kernel-side feature, as are the graphics drivers, as are other things such as storage drivers, so overall it matters a lot. Feb 16, 2021 at 9:19
  • @user1686 I don't have X/Wayland as I wish to stick to a tty ; Its just as bad in both bash and zsh, others I do not have ; I have not tried other kernels and yes, it is 5.4.98-1 . I suppose I could try using another kernel but know nothing about these and was trusting the devs and so am a bit reluctant ... If you reccommend trying the linux kernel could you point me to a reliable guide ?
    – An Ant
    Feb 16, 2021 at 9:29
  • @user1686 I've added a pastebin of dmesg , I read through it but understood nothing, can you spot anything wrong ?
    – An Ant
    Feb 16, 2021 at 10:24

1 Answer 1

-1

Moved my Arch install to another disk , and it runs just fine now.

Commands were slow because they all were randomly accessing files from a very slow disk, nothing else.

Summary of what I did :

  1. Backup Ubuntu disk entirely with dd from macOS
  2. Copied my arch root partition to a new ext4 partition on my Ubuntu disk with dd while logged into Ubuntu
  3. Updated Grub to show arch and fstab to corrected UUIDs rebooted, Arch would kernel panic not finding root partition, so booted into install ISO , arch-chrooted , mounted everything, regenerated init with mkinitcpio
  4. Arch would boot but into read-only, saw fstab, realised mkinitcpio or something screwed the UUID for root part there, corrected it in Ubuntu, rebooted into Arch
  5. And Viola ! everything back to working !

If slow disk is not your issue and you have the same problem, see if suggestions for my question in the Arch Forums are useful.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .