Last night, I ran an update as I normally do:
(https://cdn.discordapp.com/attachments/881323900796014602/1276044623185317898/image.png?ex=66c818a9&is=66c6c729&hm=79bea045112d73c17a76266a8b2bd23d83cce8aac7b02450bc3f089001aee9a9&)
After restarting the VM, I got this far before encountering a black screen:
(https://cdn.discordapp.com/attachments/881323900796014602/1276044745227112508/image.png?ex=66c818c7&is=66c6c747&hm=b79928c135de587fdd309e42c43075896724fb1d52c0f74ecf184eb2e45919a9&)
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:
(https://cdn.discordapp.com/attachments/881323900796014602/1276186419542364181/image.png?ex=66c89cb8&is=66c74b38&hm=1ed4f0c9eb68c145f98c6eb176da6e7fd41bcaaeb9c6fa7a000ce47d55b614f0&)
After reading this thread (https://www.reddit.com/r/archlinux/comments/14km18t/how_to_chroot_with_encrypted_btrfs_with_multiple/), I tried this instead:
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:
mount /dev/sda2 /mnt/fake_root/home
However, the real nightmare began after
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 :(
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.
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.
(https://cdn.discordapp.com/attachments/881323900796014602/1276244246164275367/image.png?ex=66c8d293&is=66c78113&hm=f049045aa90b396c474a664649cf19f2a2fe6aeee2371008e75e7ef335f03c3b&)
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
Do you still have the same symptom of some openrc output and then it stops ?
You could set:
/etc/rc.conf
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
termencoding | * Setting terminal encoding [UTF-8] ...
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/
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...
No, each init works differently.
I've piped the dmesg logs into a text file for review. I'll let you know if I find anything in there.
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.
I've been searching more, and encountered the following resources:
- https://wiki.archlinux.org/title/Systemd#Change_default_target_to_boot_into
- https://wiki.archlinux.org/title/OpenRC#Configuration
- https://github.com/OpenRC/openrc/blob/master/etc/rc.conf
- https://wiki.gentoo.org/wiki/OpenRC#Selecting_a_specific_runlevel_at_boot
I am now wondering if I need to change
rc_default_runlevel="default"
in rc.conf, to force TTY instead of graphical/default user target...
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.
I'll have to try that (former) option. I currently do not have a login/display manager installed.
Just reviewed how to use the softlevel parameter, to make sure I knew what I'm doing:
- https://wiki.gentoo.org/wiki/OpenRC#Selecting_a_specific_runlevel_at_boot
which then prompted me to check/see what runlevels are currently available for me to pick from:
(https://cdn.discordapp.com/attachments/702144830066655345/1281286535538409522/image.png?ex=66db2a93&is=66d9d913&hm=b5df4b61e61610cfed664abacdb3f4f8e04c7c43498c61a520c71865a8c46a6f&)
Now reviewing what service(s) are in each runlevel, to see if I screwed myself by adding a service that causes the issue. I wasn't able to find anything obvious last time, but am always open to re-checking (to be sure).
The strange thing, for me, is the fact that the screen goes black (and resizes itself) right after "termencoding start" appears onScreen. I'm wondering if there's a config file for me to review, that's referenced by the startup script for termencoding ...
On an unrelated note, I also can't see anything when switching into single-user mode.
Same issue as when I'm in TTY, sadly.
I never thought I say these words, but I now miss my TTY.
So, over 40 packages were updated tonight (pacman -Syu). And like the previous major update, the Linux kernel got upgraded to a newer version. This time, it seems that the kernel version upgrade helped. Though now, I have something else to look into...
(https://cdn.discordapp.com/attachments/881323900796014602/1281480096590331924/image.png?ex=66dbded7&is=66da8d57&hm=66994eb6579f72c30694a588a33a50895b8a80e5d5411dbb1ffd0d557491d5c2&)
I don't remember getting anything like this when TTY was last visible :o
Perhaps that's a product of me changing the verbosity for rc output...