Oh. Maybe thats my issue

Debian's got a sudo group, not a wheel group.

EDIT: Oh, I see what you mean. Arch might use the wheel group and Debian the sudo group, and if he just copied his Arch sudoers file over his Debian one, it would reference the wheel group and wouldn't work.

googles

Yeah, Arch has wheel.

https://linuxopsys.com/topics/add-user-to-sudoers-in-arch-linux

EDIT2: I bet he tried to add his user account explicitly to /etc/sudoers rather than just adding the account to the sudo group and just got the syntax wrong in one way or another, as the syntax of sudoers isn't terribly intuitive.

Offtopic, but I had no use for desktop files in general, as I launch stuff from the command line, but I finally discovered a wonderful use for them. Steam creates a desktop file for Steam games it installs. Steam itself is...not all that amazing as a launcher. Gives you the last five games launched in a contextual menu from a tray icon, and a list of games you can search through in the client interface after you bring up the window and move to the Library tab. However, you can set up rofi to use desktop files as completions (one sets it up to complete on "drun"), and then rofi can act as your Steam game launcher, which is great. I can just whack a keystroke to invoke rofi, and then type a few characters of the game I want and whack enter, and rofi will prioritize by last-invoked. Really nice not having to slog through the Steam interface.

They tell you in the installer, I didn't read it either.

I don't think it actually corrupted the SSD, perhaps a module is missing or such, and that's why it goes into emergency mode. Have you tried mounting the drive from say, a live usb?

Arch will go into emergency mode whenever it can't mount a volume in fstab on boot. If the drive is formatted as NTFS, I've had this exact problem. I think it has to do with windows marking the drive as dirty. I didn't bother figuring out what the problem was, I just stopped trying to mount an NTFS drive on boot. Maybe you'd have better luck using the ntfs-3g driver?

Can you see the drive in Debian? Like, does it show up in lsblk output, which doesn't rely on there being anything on the drive? If not, it may have failed. Like, not something that Arch did.

On the Debian installer when it gets to entering the password when you create the user, you just skip the first password page (leave it empty) and enter your password on the next page. This adds you to the sudoers group. I've found this out the hard way.

I’ve added myself to sudo but I keep getting “kicked out” when I start a new shell.

Group permissions from the /etc/group file get assigned at login. Each process will inherit group memberships from its parent.

You can see them for a process (self being the current process) in:

$ grep ^Groups: /proc/self/status

The gids there correspond to the gids in /etc/group.

That's why the need to log out the user in question after adding the user to a group, unless you're gonna use sg or similar to add that gid and then have all your new processes started by that process that you just started with the new gid.

You'll see this with all user memberships in groups on Linux. It's not behavior specific to Debian or specific to membership in the wheel or sudo group.

All right. Hmm.

I'd still probably try booting up with the external drive disconnected -- should be an easy test -- and seeing if the pre-GRUB delay doesn't show up. If either the BIOS or GRUB is trying to talk to the drive and it's taking a while to respond because it's having problems, something which I have certainly seen many a (well, rotational) drive do, that might account for the delay.