Skip to main content
Topic: Attempting to Fix a VM (Login Shell and TTY Invisible After Update) (Read 1285 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Attempting to Fix a VM (Login Shell and TTY Invisible After Update)

Last night, I ran an update as I normally do:



After restarting the VM, I got this far before encountering a black screen:



In an attempt to rescue the VM, I booted into a recent LiveDVD (downloaded it late last night) to attempt chroot. However, I have not had success thus far. My first attempt went as follows:



After reading this thread, I tried this instead:

Code: [Select]
cd /mnt
mkdir fake_root
cd fake_root
mkdir boot var home
cd ..
mount /dev/sda4 /mnt/fake_root/boot
mount /dev/sdb1 /mnt/fake_root/var
mount -o subvol=@home /dev/sda2 /mnt/fake_root/home
mount -o subvol=@ /dev/sda1 /mnt/fake_root
artix-chroot /mnt/fake_root /bin/bash

But my attempt to mount @home failed, with the command stating that /mnt/fake_root/home did not exist. I replaced that command with:

Code: [Select]
mount /dev/sda2 /mnt/fake_root/home

However, the real nightmare began after
Code: [Select]
artix-chroot /mnt/fake_root /bin/bash
-- I had messed up my attempt again. When checking for the pacman cache and logs, both directories (under /var) were completely empty.

I need help chroot'ing into this VM. I used BTRFS for this install, which may have complicated things (compared to if I had just used EXT4 instead).

Is anyone familiar with how to chroot in this situation? While the VM doesn't have any important information on it, I was hoping to clone it for use in the near future. But I can't use it in this state :(

Re: Attempting to Rescue a VM (Broke After Update)

Reply #1
You are doing things in the wrong order.
mount -o subvol=@ /dev/sda1 /mnt/fake_root
should be first not last. The previous mounts you did are not (easily) accessible once you mount   /dev/sda1 on /mnt/fake_root

I can't really be sure about the rest of the syntax as I took one look at at  sub-volumes, and thought 'nah', a long time ago.

Re: Attempting to Rescue a VM (Broke After Update)

Reply #2
You are doing things in the wrong order.
mount -o subvol=@ /dev/sda1 /mnt/fake_root
should be first not last. The previous mounts you did are not (easily) accessible once you mount   /dev/sda1 on /mnt/fake_root

I can't really be sure about the rest of the syntax as I took one look at at  sub-volumes, and thought 'nah', a long time ago.

Thank you for informing me of this. I will attempt that in a bit, and post the results here.

Re: Attempting to Rescue a VM (Broke After Update)

Reply #3
You are doing things in the wrong order.
mount -o subvol=@ /dev/sda1 /mnt/fake_root
should be first not last. The previous mounts you did are not (easily) accessible once you mount   /dev/sda1 on /mnt/fake_root

I can't really be sure about the rest of the syntax as I took one look at at  sub-volumes, and thought 'nah', a long time ago.

Okay, this is going to either make you laugh or cringe...

I went on and let Project:ArcZ boot into the black screen again.

After that, I acted as if the login shell was in front of me (entered username and password).

Then, I entered startxfce4, as if the normal Bash or Zsh shell was there.

It started as if nothing was wrong -- I got the graphical desktop.



Heck - CopyQ was still picking up things that I copied and cut as well


The good news is, the install isn't completely broken.

The bad news is, I need to see my TTY.

oof

Re: Attempting to Fix a VM (Login Shell and TTY Invisible After Update)

Reply #4
Do you still have the same symptom of some openrc output and then it stops ?
You could set:
/etc/rc.conf
Code: [Select]
rc_logger=yes
rc_verbose=yes #try if nothing obvious shows without it
And see if there are any errors around the time the output stops.
/var/log/rc.log

What happens if you switch vt .Do you see a login prompt or is it a blank screen again ?

Re: Attempting to Fix a VM (Login Shell and TTY Invisible After Update)

Reply #5
Do you still have the same symptom of some openrc output and then it stops ?
You could set:
/etc/rc.conf
Code: [Select]
rc_logger=yes
rc_verbose=yes #try if nothing obvious shows without it
And see if there are any errors around the time the output stops.
/var/log/rc.log

What happens if you switch vt .Do you see a login prompt or is it a blank screen again ?

So far, I haven't found anything out-of-the-ordinary in rc.log . I will probably have to enable verbose logging, to see if anything pops up. Switching vt ( [Ctrl] + [Alt] + [F#] ) leads to the same -- can't see, but can blindly enter commands. The display also stays dark upon shutdown. The only time I get to see output is during initial power-on, up until

Code: [Select]
termencoding        | * Setting terminal encoding  [UTF-8]  ...

Re: Attempting to Fix a VM (Login Shell and TTY Invisible After Update)

Reply #6
Try to change the VM display driver, if possible.

Re: Attempting to Fix a VM (Login Shell and TTY Invisible After Update)

Reply #7
Try to change the VM display driver, if possible.

I'm not sure that I understood that. Does Artix have alternative driver that I can use? If so, I'm open to trying it out.

Currently reading through this article:
 - https://wiki.archlinux.org/title/VMware/Install_Arch_Linux_as_a_guest#Xorg_configuration

Would I use this as the primary display driver?
 - https://archlinux.org/packages/extra/x86_64/xf86-video-vmware/

Re: Attempting to Fix a VM (Login Shell and TTY Invisible After Update)

Reply #8
Not sure about vmware, in virtualbox there's vboxsvga, vboxvga and vmsvga as a GPU driver option in the VM settings.

Re: Attempting to Fix a VM (Login Shell and TTY Invisible After Update)

Reply #9
Not sure about vmware, in virtualbox there's vboxsvga, vboxvga and vmsvga as a GPU driver option in the VM settings.

Can I find detailed info about Artix's boot-up/power-on process in the wiki? Just curious...

 


Re: Attempting to Fix a VM (Login Shell and TTY Invisible After Update)

Reply #12
So far, I haven't found anything obvious in the dmesg output. However, I did poke around a bit. Apps like lightdm, emptty, and ly are impacted as well -- can't see them, even when switching TTYs.

Re: Attempting to Fix a VM (Login Shell and TTY Invisible After Update)

Reply #13
No, each init works differently.

I've been searching more, and encountered the following resources:

I am now wondering if I need to change
Code: [Select]
rc_default_runlevel="default"
in rc.conf, to force TTY instead of graphical/default user target...

Re: Attempting to Fix a VM (Login Shell and TTY Invisible After Update)

Reply #14
Some years back I didn't have success booting to console with kernel cmdline softlevel on OpenRC; perhaps it works now. Worst case, temporarily disable your login manager.