Manjaro Gnome system destroyed during routine update, and restored

General Discussion Rants and Raves
,
#1

This is a post about my experience restoring a Manjaro Gnome system that was ■■■■■■■ during a routine update. Maybe it will help someone. I'm new to Manjaro but experienced with linux (RedHat -> Gentoo -> Ubuntu -> Manjaro). During the update the white screen of death appeared with the announcement "Oh no! A problem has occurred and the system can't recover." Everything was frozen, even the drop to console mode, so there was no choice but to power off. I'm on a rather new Lenovo X1 Yoga laptop dual booting in UEFI with Windows 10 according to the excellent instructions here: [HowTo] Dual-boot Manjaro - Windows 10 - Step by Step. As suggested I have a second efi partition for the linux system but no second boot partition.

Searching the forums I found I'm not the first to encounter this screen. I had on hand an installation live usb stick so I used that to boot, chroot to the system using 'manjaro-chroot -a', and make backups. The warnings on older posts that 'manjaro-chroot-extended' is needed from AUR can apparently be ignored. Still it's necessary to choose '1' for the system listed '0', as written elsewhere.

The following steps were a downward spiral until I couldn't even boot the windows, yet all the diagnostics seemed to pass. 'pacman -Syyu' finished with "there is nothing to do" and efibootmgr showed all the entries in the right place. Looking closer, I saw that my kernel file in /boot/vmlinuz-5.4-x86_64 had a length of 0 bytes. I removed it and did pacman -S linux, which brought a new kernel (5.4.31-1-MANJARO) but no boot. I also noticed that /proc/cmdline listed BOOT_IMAGE=/boot/vmlinuz-x86_64 ... without the kernel version. I tried making a link to the new kernel but to no avail. I made a new initramfs with 'mkinitcpio -P', and still no boot.

Along the way the grub manu disappeared and the white screen came directly, and eventually even that was gone and I just got the Lenovo logo. I did find it was possible to log into Windows using the Boot menu (F12) on startup. With a focus on grub then, I erased the kernel link, redid the mkinitcpio, and did 'update-grub' and 'grub-install' from the chroot. Changing the line GRUB_TIMEOUT_STYLE from hidden to menu in /etc/default/grub was important to see the menu, and I think it should be default. I also removed the quiet from the kernel parameters so that I could see that it's doing something before the white screen appears.

I cannot point definitively to the crucial step but eventually the grub did work and I could boot both Manjaro and Windows from the menu. The Manjaro still went to the white screen but this time I was able to open a console. 'startx' brought a slightly different white screen and the log was helpful. There was an error "(EE) Failed to load module "fbdev" (module does not exist, 0)" and similarly for vesa. 'pacman -S xf86-video-fbdeb' and 'pacman -S xf86-video-vesa' brought the modules, followed by modprobe to load them. There was another error "(EE) open /dev/fb0: Permission denied". I changed permissions to rw. Still no gnome.

About this point I saw a post advising against upgrading to gnome-3.36 from the graphical environment, so from the console I did 'pacman -S xorg-server' and then 'pacman -S gnome', both of which brought new packages in spite of the earlier response from 'pacman -Syyu' in the chroot. At last, it's working again.

This is my first encounter with the white screen. My question to the maintainers is whether this is an unfortunate freak accident or a real vulnerability if gnome is updated from a running desktop. If so, it might make sense to issue a warning from the package manager. I'm on the stable branch: 'pacman-mirrors -G' > Stable.

mhwd-chroot package - is it maintained or obsolete?
#2

Or you could read the announcements, as is recommended. Though that might be a useful feature for the future.
Also since this isn't a request for help, I moved your post into a more appropriate category. Hope you don't mind.

3 Likes
#3

Is this a Gnome thing? I can't recall seeing anything like it.

Never heard of it

Found a mention of something similar but still - this is probably from deprecated toolset.
Found a package mhwd-chroot which is probably the one - it searches for roots and has a pretty advanced root mount.

You learn something every day - it's a tool I need a closer look at :slight_smile:

? - did you have any messages about invalid option in a .hook file?

What? Did you mix in something from another Archbased installation?

dracut comes to mind?

Usually on Arch based systems you can have several video packages installed - the system will pick the one best suited for your hardware.

If you want to have all the opensource xorg drivers - (it is not big packages) - install the package xorg-drivers. This could possibly prevent a failure to start Xorg - but I am not sure.

The pacman response is with respect to installed packages and at least the gnome is a meta package which pulls in other packages as well.

It is quite impossible it is an unfortunate freak accident - Gnome has come a long way since I used Gnome a couple of years ago - but your experience - coupled with other threads I have seen the past weeks tells me that Gnome is best updated by following this roadmap

  • disable all thirdparty extensions
  • logout
  • switch to TTY, login and update
#4

It is more of a freak accident I would say.

Your system was messed up big time. Specifically /boot and the kernels. This is nothing a gnome update would touch. And you have Windows installed too, which could mess up /boot/efi.

1 Like
#5

No problem for the change of category. I put it in newbies on the grounds of not knowing where else it should go.

#6

Thanks to all for the comments. Relief exceeds frustration at the moment but it's good to learn from these accidents. I'm trying to reply more or less in order of the comments above. We don't need to drag this on forever though. System is running :slight_smile:

white screen.

I did not take a picture of the white screen. I found one on this post:
"Oh no! Something has gone wrong" on boot, dual-boot with Windows 10
It was also in a dual boot situation but there were other cases. There are also two different messages. One says contact system administrator, and then there's nothing to do. The other offers a logout button and from there one can continue in the console. I don't know if it's from gnome or the Arch base. Just now I find an example from Reddit regarding Arch:
https://www.reddit.com/r/archlinux/comments/b9q2vc/oh_no_something_has_gone_wrong_cannot_boot_arch/

It was mhwd-, not manjaro-, correct. The standard version of manjaro-chroot worked fine for me, confirmed with findmnt.

For the kernel I didn't notice any notices of .hook or anything else. The update just froze in the middle.

What? Did you mix in something from another Archbased installation?

No. The laptop is new from January and there was never any other linux on it. I haven't done anything "creative".

Thanks for explanation on xorg-drivers and metapackage with respect to pacman. I agree completely with your protocol for upgrading gnome. It's pretty much what I did in the end. No one will search for that advice in advance though, only after things go wrong.

Your system was messed up big time.

Reconstructing the events, I think it was me who messed up the /boot/efi, not windows. At the beginning it just wasn't booting the kernel-less linux but the grub behaved fine. There was an error on the black screen about unexpected EOF in vmlinuz, I recall now. I started off just making things worse. The separate efi partitions probably saved the day.

I still have the pre-installed windows because I can't get the sound to work on the Thinkpad, but that's another story altogether...

#7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

Forum kindly sponsored by