Saturday, July 12, 2025

How I Rescued My Jellyfin Admin Account After a Bizarre Startup Glitch

Date: July 13, 2025  
Environment: Linux Mint running Jellyfin server  

Background
Environment: Linux Mint running Jellyfin server
Access methods in use:
◦ Local LAN access on port 8096
Symptom:
Remote access via Tailscale VPN and DuckDNS dynamic DNS
◦ Quick Connect (device approval) still worked
◦ Manual login at http://<your-server>:8096 always returned "invalid
username or password"

The Story

I’ve spent countless evenings tinkering with my Jellyfin media server, but nothing prepared me for the eight-hour rabbit hole I fell into today. This morning, I tried to log in to manage my libraries—and got an “invalid username or password” message, even though nothing else had changed. Here’s the story of how I chased phantom users, battled locked-out wizards, and finally exorcised the gremlins from my setup.

The Day It All Broke

I woke up, poured my coffee, and navigated to http://my-server:8096. Instead of the familiar dashboard, I was greeted by the awkward sight of the setup wizard—only rather than resetting it, Jellyfin skipped straight to the login screen. My one and only admin account wouldn’t accept its own credentials.  

- Quick Connect on my phone still worked (it approved new sessions just fine), but  
- Manual login always spit back “invalid username or password.”  

No error messages in the logs, no disk space warnings, no sudden system updates—just a lockout of my sole admin account.

Wild Goose Chases (and FFmpeg)

First, I assumed the password database was corrupted. Boldly, I opened the SQLite file and ran:

`sql
UPDATE Users SET Password='MyPlainPassword' WHERE Username='AdminUser';`

No dice. My login still failed. That’s when I realized—Jellyfin hashes everything.  

Next, I dug into the Jellyfin CLI, hoping it could export or reset hashes. It returned only inscrutable IDs, no way to reseed my password.  

At my wit’s end, I installed FFmpeg on a hunch from a forum thread suggesting missing media dependencies can cause cascade failures. I rebooted, retried the login—still locked out.

The Breakthrough in the Logs

Frustration mounting, I ran the live log stream:

`bash
journalctl -u jellyfin -f`

During a login attempt, I finally saw it:

> DbUpdateConcurrencyException  
> The database operation was expected to affect 1 row(s), but actually affected 0 row(s).

In plain English: Jellyfin tried to update my admin record…but couldn’t find it. Something in the database didn’t match the server’s memory of its own users.

Exorcising the Phantom User

1. Reset the Wizard Flag
My interrupted setup had marked the wizard “completed,” so I forced it back on in /etc/jellyfin/system.xml:

`xml
<IsStartupWizardCompleted>false</IsStartupWizardCompleted>`

Restarted Jellyfin. The wizard reappeared—great—but still refused my admin credentials due to the same concurrency error.

2. Hunt Down the Stub Record
I stopped the service, opened the database, and listed users:

`bash
sudo systemctl stop jellyfin
sqlite3 /var/lib/jellyfin/data/jellyfin.db "SELECT Username FROM Users;"`

I found two entries:  
1. My real admin account  
2. A ghostly stub user left behind by the half-built wizard

3. Delete the Stub
With one line, I banished the phantom:

`sql
DELETE FROM Users WHERE Username='TempHashUser';`

4. Restart and Triumph
`bash
sudo systemctl start jellyfin`

This time, the setup wizard accepted my admin username and password without complaint. I breezed through library setup, and all my media appeared exactly as before.

Cleaning Up & Lessons Learned

1. Sanitize your config: I double-checked system.xml for leftover <Password> tags or test flags—nothing sensitive remained.  
2. Verify integrity:  
   `bash
   sqlite3 /var/lib/jellyfin/data/jellyfin.db "PRAGMA integrity_check;"

→ ok
   `  
3. Test remote access: Tailscale and DuckDNS login still worked over mobile data.  

Key takeaways:

- Quick Connect can mask deeper auth failures.  
- A single stub user in the DB can block the entire wizard.  
- Jellyfin hashes credentials—don’t try plaintext injection.  
- Real-time logs (journalctl -f) are your best friend for hidden errors.  
- Always back up both your database and config before major surgery.

Final Thoughts

Eight hours felt like forever, but walking through every twist—wrong turns included—gave me an intimate understanding of Jellyfin’s inner workings. Now, when I grab my popcorn and fire up my Plex-kill­er server, I do so with total confidence that my admin account is bulletproof.

May this tale save you from sleepless nights and blind password strikes. If your Jellyfin ever locks you out, remember: the ghost in your DB could be the key to getting back in.  

Happy streaming! 🎬✨

Wednesday, July 9, 2025

Linux Mint Install on Sony VAIO SVP11216PXB - Replacing Windows and installing Linux as sole OS

Linux Mint XFCE install and boot recovery guide tailored for a Sony VAIO:
Note - This should work on Ubuntu and other Ubuntu based Distros.
---
📦 Linux Mint XFCE Installation + Bootloop Recovery Guide (Sony VAIO)

🖥️ System Setup Summary
- Laptop: Sony VAIO (UEFI-capable, boot quirks present)
- Distro: Linux Mint XFCE
- Boot mode: UEFI
- Disk layout (Manual Partitioning):
  - /dev/sda1 → EFI partition (512MB, FAT32, mount point: /boot/efi)
  - /dev/sda2 → Root (50–100GB, ext4, mount point: /)
  - /dev/sda3 → Home (remaining space, ext4, mount point: /home)
  - /dev/sda4 → Swap (8–16GB, type: swap)
---

🧰 Installation Steps with Manual Partitioning

1. Boot Mint XFCE Live USB in UEFI mode
- Enter BIOS and ensure:
  - Boot Mode: UEFI
  - Secure Boot: Disabled
- Select UEFI: USB Name from boot menu

2. Launch Installer & Choose Manual Partitioning
- Select “Something else” when prompted for installation type

3. Create/Mount the Partitions
In the partition editor:
- EFI partition:  
  - Select /dev/sda1  
  - Format: FAT32  
  - Mount point: /boot/efi  
  - Boot flag: esp

- Root partition:  
  - Select /dev/sda2  
  - Format: ext4  
  - Mount point: /  
  - Use as system root

- Home partition:  
  - Select /dev/sda3  
  - Format: ext4  
  - Mount point: /home  
  - Stores user data

- Swap partition:  
  - Select /dev/sda4  
  - Use as swap area  
  - No mount point required

> 💡 Set EFI partition as the installation target for bootloader when prompted.

4. Proceed with Installation
- Username, hostname, password set as usual
- Wait for installer to complete and reboot when prompted

From there, we encountered the bootloop and performed the advanced recovery steps

---
🛠️ Linux Mint XFCE Installation & Bootloop Recovery on Sony VAIO
---
⚠️ Issue Overview
After a fresh Mint install, the system entered a bootloop, stuck at the VAIO splash screen, never reaching GRUB. EFI variables appeared inaccessible, and boot entries weren't sticking. 
---
🧪 Initial Diagnostics & Partition Discovery
Commands used from live USB:
`bash
lsblk -f # To see partitions and types
sudo blkid # To confirm partition labels and types`
Identified:
- sda1 as EFI
- sda2 as root (/)
- sda3 as home (/home)
- sda4 as swap
---
🧱 Attempted GRUB Reinstallation

Chroot Process:
`bash
sudo mount /dev/sda2 /mnt
sudo mount /dev/sda1 /mnt/boot/efi
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt`

GRUB Install & Update:
`bash
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=GRUB
update-grub`

Sony VAIO Quirk Handling:
`bash
mkdir -p /boot/efi/EFI/Boot
cp /boot/efi/EFI/GRUB/grubx64.efi /boot/efi/EFI/Boot/bootx64.efi`

Outcome: GRUB still not detected on boot due to suspected NVRAM lock.

---
🧰 Boot Repair Attempt
`bash
sudo add-apt-repository ppa:yannubuntu/boot-repair
sudo apt update
sudo apt install boot-repair
boot-repair`

Result:  
- Error: "EFI variables are not supported on this system"
- Confirmed /sys/firmware/efi and /sys/firmware/efi/efivars were populated
- This confirmed UEFI boot but likely firmware lock on EFI variable writing
---
🚀 Successful Fix via rEFInd

Installed rEFInd from live session:
`bash
sudo apt install refind
sudo refind-install --usedefault /dev/sda1`

Verified:
- refind_x64.efi in /boot/efi/EFI/refind/
- bootx64.efi in /boot/efi/EFI/Boot/

Reboot Result:
- rEFInd screen appeared
- Manual selection of grubx64.efi booted Linux Mint successfully
---
🧼 Post-Boot Cleanup & Config Update
Once inside Mint XFCE:
`bash
sudo update-grub # Refresh GRUB config`

Note: refind-mkconfig not available via apt; rEFInd autodetection works or can be manually edited in refind.conf.
---
✅ Final Boot Health Status
- System boots via rEFInd reliably
- GRUB is functional when launched via rEFInd
- No persistent bootloop
- NVRAM still locked, but bypassed successfully via fallback bootloader path
---

Hope this guide helps anyone who needs this. I just spent 5 hours troubleshooting this.