Login failure after adding self to vboxusers group

Installed virtualbox in OS tumbleweed

On opening the app, I was greeted by this message:

You are not a member of the “vboxusers” group. Please add yourself to this group before starting Virtualbox. Do it using Yast/Security and Users/User and Group management. Don’t forget to re-login with user account!

I did as suggested, opened /Security and Users/User and Group management. I didn’t immediately see how I was supposed to add myself to the vboxusers group. Exploring YAST, I hit the authentication tab and was greeted by a host of error and warning messages. I closed those out and headed back to “User and Group management.” where after a couple of minutes, I twigged - I think - how to add myself to the vboxusers group. I hit “OK” and closed YAST.

But my system was now thoroughly borked - black screen, no GUI.

I re-booted, but was greeted by:

[Failed] Failed to start X Display Manager

Welcome to openSUSE Tumbleweed 20250605 - Kernel 6.15.0-1-default (tty1)

Couldn’t login to the tty1 console - credentials not accepted

How do I get my system back?

PS: I dual boot with Ubuntu so I can get access to all my system files from therein

Hi, welcome here.

I think your user is no longer a member of the users group. Login as root and do:
usermod -aG users <your_username_here>
Next, reboot and see if it is fixed

You probably have a broken “/etc/passwd” or perhaps a broken “/etc/group”. I’m not sure how you did that.

You can try looking at those file from your Ubuntu system, and see if you can spot the problem.

@knurpht These days in tumbleweed it’s username group not users, unless it’s an old setup…

I stand corrected. For the 1st user indeed is

Hi knurpht,

Thanks for the prompt response

How do I login as root? I’ve tried offering “root” as the “user” in the tty1-console, but on hitting ENTER, the console simply puts up the “login ”-prompt again. Is this because I haven’t got a password for “root” set-up?

See also my response to mrickert (post 2)

You should have a password for root, if not separate, then try your user’s password. Otherwise you might be able to use a live USB.

Thanks for responding nrickert

Had a look at /etc/passwd in both Ubuntu (20.04) and T’weed

My username in both systems is “azed”

Ubuntu:

azed:x:1000:1000:Stephen Hamer,:/home/azed:/bin/bash

T’weed:

azed:x:1000:100:Stephen Hamer:/home/azed:/bin/bash

Also had a look at /etc/groups:

Ubuntu:

“azed” is a member of these groups:

root
adm
dialout
cdrom
sudo
audio
dip
video
plugdev
lpadmin
lxd
sambashare

There is also an azed group:

azed:x:1000:

T’weed:
“azed” is a member of these groups:

video
audio

There is no azed group in T’weed

In both systems there is a “users” group (same syntax in both systems):

users:x:100:

Hope this helps

There should be 3 commas after “Stephen Hamer” in the Ubuntu /etc/passwd-line. I.e., it should read

azed:x:1000:100:Stephen Hamer,:/home/azed:/bin/bash

Your forum s’ware did some editing

The system doesn’t invite a p/w when i try to login with my usual username “azed” or as root

I seem to have deleted myself as a user.

How do I edit myself back in?

I still have my install DVD. From memory, it offers a “rescue” mode. How would I proceed from there?

Not much help, actually.

The problem could be an improperly terminated line somewhere.

This looks to be because multiple commas might have a meaning in markdown, or it could be an implementation decision that multiple commas are syntantically invalid in written language, and you used ‘quote’ formatting rather than ‘preformatted text’.

Using preformatted text formatting leaves the text unmodified:

azed:x:1000:1000:Stephen Hamer,,,:/home/azed:/bin/bash

The preformatted text button in the editor (</>) will give you this formatting, or you can use markdown syntax to insert it (which is what I did above).

Just FYI. :slight_smile:

Mmm, This is weird. No commas at all:

knurpht@Lenovo-P16:~> grep beheer /etc/passwd
beheerder:x:1000:1000:Beheerder:/home/beheerder:/bin/bash
knurpht@Lenovo-P16:~> grep 1000 /etc/group
beheerder:!:1000:
knurpht@Lenovo-P16:~> 

OK, having slept on the problem, I think this is the way forward:

If you set up the root partition with Btrfs during the installation, Snapper—preconfigured for doing rollbacks of YaST or Zypper changes—will automatically be installed. Every time you start a YaST module or a Zypper transaction, two snapshots are created: a “pre-snapshot” capturing the state of the file system before the start of the module and a “post-snapshot” after the module has been finished (my emphasis).

Using the YaST Snapper module or the snapper command line tool, you can undo the changes made by YaST/Zypper by restoring files from the “pre-snapshot” (my emphasis again). Comparing two snapshots the tools also allow you to see which files have been changed. You can also display the differences between two versions of a file (diff).

From here:

https://doc.opensuse.org/documentation/leap/reference/html/book-reference/cha-snapper.html#sec-snapper-undo

My thinking here is that, using YAST, I’ve (inadvertently) made system wide changes to my set-up (I suspect to the PAM-authentication system). There isn’t going to be a simple solution to this problem: I need to carry out some form of BTRFS “roll-back”. But happily, and as detailed above, when YAST was opened y’day, it will have made a snapshot of the existing state of my system. This should enable me to “undo” my inadvertent changes.

I’m hoping to be able to chroot into my system from the rescue system aboard my original install DVD, using something like this method:

https://www.suse.com/support/kb/doc/?id=000018770

I will then use snapper to revert the mistaken changes made by YAST y’day, via the method detailed in section 3.2.1 of the first source linked-to above

Does that sound like a plan?

Comments / advice welcome

I’ll let you know how I get on

PS: I’ve got a bad feeling that if the above doesn’t work… I. am. f*cked

I doubt that too. If the changes made are unclear, I’d reinstall and not make the same mistake again. :smile:
Don’t worry about that in itself, it has happened to all of us, in my case not just once

Also, since YaST is being deprecated, once you recover, you can easily add yourself to the vboxusers group from the terminal, entering:

sudo usermod -aG vboxusers <your user name>

The great Tumbleweed system rescue attempt

Introduction

Loaded my old DVD install disc (“Tumbleweed snapshot 20170414”) into my removable optical drive and re-booted

Interrupted the boot with F12 to access the drive selection screen. Selected my optical drive and hit “Enter” to boot the rescue disc.

Arrived at the install disc grub-screen (whatever). 4 options: Install, Upgrade, (Something else), and “More”. Using the arrow-keys and “Enter”, chose “More”, then, from the new screen, “System Rescue” - the top option.

The system rescue boot started. Chose “English UK” from the language list offered. Landed in a console (no graphical user-interface in the Rescue environment). Logged-in as “root” at the rescue-login prompt - no password required, just hit “Enter”. The system put up a message: “Have a lot of fun…” and the prompt changed to a root prompt “#”

Setting-up the chroot

Got a list of available partitions:

# lsblk

nmve0n1			931.5G
	nmve0n1p1	542M
	nmve0n1p2	204.8G
	nmve0n1p3	12.3G
	nmve0n1p4	122.9G
	nmve0n1p5	204.8G
	nmve0n1p6	200.0G
	nmve0n1p7	186.3G

The TW system partition is nmve0n1p6

Mounted it:

# mount /dev/nmve0n1p6 /mnt

Checked that I had mounted the right partition (ahem, just to make sure)

#ls /mnt

“root”, “boot”, and “home” were all listed (among many other folders)

Bind-mounted various necessary folders:

# for i in proc sys dev run; do mount --rbind /$i /mnt/$i ; done

I also mounted my EFI partition on /mnt/boot/efi.

# mount /dev/nmve0n1p1 /mnt/boot/efi
  • probably not necessary, but it’s what I do when restoring grub and it couldn’t do any harm (er, could it?)

I then attempted to chroot into the TW system partition

# chroot /mnt

And that’s when everything fell apart. The command returned “Segmentation fault (core dump)”

From Wikipedia:

In computing, a segmentation fault (often shortened to segfault) or access violation is a failure condition raised by hardware with memory protection, notifying an operating system (OS) the software has attempted to access a restricted area of memory (a memory access violation). On standard x86 computers, this is a form of general protection fault.

Wikipedia adds:

The operating system kernel will, in response, usually perform some corrective action, generally passing the fault on to the offending process by sending the process a signal. Processes can in some cases install a custom signal handler, allowing them to recover on their own,[1] but otherwise the OS default signal handler is used, generally causing abnormal termination of the process (a program crash), and sometimes a core dump.

In a nutshell, the system returns a segfault if a process tries to access memory without the proper authorization. Thus, not only could I not login to my system (even as root), I couldn’t chroot into it either.

Came out of the chroot

# exit

Dismantling the chroot

Tried dismantling what I’d built, but even that was difficult

# umount /mnt/proc

returned:

Umount: /mnt/proc is busy
(In some cases useful information about the processes using the device is found by lsof (88) or fuser (1)

Ditto, sys, dev, and run

[Query: does this behaviour indicate that the chroot had some effect?]

The rescue system didn’t have access to lsof, but “fuser -vm /mnt/proc” returned things like:

USER	PID	ACCESS	COMMAND
root	kernel	mount	/proc
root	1	f....	systemd
root	1792	f....	systemd-journal	

And so on

Tried killing these processes:

# kill -9 1792

but other processes took their place

In the end, I resorted to:

# umount -f /mnt/proc

which didn’t work, and then

# umount -l /mnt/proc

which did

Concluded with:

umount /mnt/boot/efi

and:

umount /mnt

I then repeated the chroot-process, missing out the “mount /dev/nvme0n1p1 /mnt/boot/efi” step, but, of course I got the same result


Final Thoughts

Disappointed that I didn’t get beyond the chroot. I was planning to revert the changes to the system brought about by YAST using snapper starting with:

snapper list -t pre-post

To get a list of (pre YAST / Zypper use) YaST and Zypper snapshots. See this previously-posted link (section 3.2.1 “Undoing YaST and Zypper changes”)

https://www.suse.com/support/kb/doc/?id=000018770

But, as knurpht foretold (above), it seems that my system is too damaged to permit this.

Not as bad as a drive-failure. I haven’t lost any work or data.

Still grieves me though (sniff) [Cue sound of “The Last Post” playing in the distance] I installed OS Tumbleweed on my custom Quiet PC desktop back in the Spring of 2017 (sniff), and it’s given excellent service for almost all of the last 8 years (sniff). Only last May, I transferred the system to a bigger drive using btrfs-replace (what a hairy experience that was!)

Can I rebuild? Of course I can.

Full disclosure: The episode that precipitated the demise of my system began with me poking about in the authentication tab of YAST/Security and Users/User and Group management. As soon as I opened the tab, the system started putting up warnings about “problems”, but I didn’t heed those warnings; I closed them out (this was very foolish of me). I then started messing with the authorisation settings for samba (I was trying, here, to deal - off the cuff - with a problem that had nothing to do with my initial reason for opening YAST). I can’t remember what I did now, but I hit “OK” (whatever) to implement my changes (this was even more foolish of me). Almost immediately, - Elmore Leonard says you should never write this - “all Hell broke lose”. A flurry of increasingly desperate sounding error-messages appeared on my screen, concluding with one that read: “Abandoning all hope…” The rest you know.

Yes, I was stupid, but I still think this system-behaviour needs looking into: it shouldn’t be this easy to totally bork your system.

Thank you for indulging me by reading all this