Since you’re using btrfs, there is likely another subfolder under /mnt. ll /mnt will tell you this, but the drive isn’t still mounted from the other day. When you’re mounting the EFI partition, you’re going to want to mount it to that folder, and not /mnt itself (/mnt/root/boot/efi, instead of /mnt/boot/efi) same for the binds (/dev, /proc, /run, etc)
Could you send me the output of lsblk -no FSTYPE /dev/sda3 and ll /mnt?
Apologies, I think I got a bit ahead of myself in the description.
Once you’ve determined which partition is which (in your case, /dev/sda1 does appear to be the EFI partition, and /dev/sda3 appears to be your root partition), you need to mount them in this order
mount /dev/sda3 /mnt
mount /dev/sda1 /mnt/boot/efi
That’s alright, I’ll do my best to walk you through it.
Your drive contains multiple partitions (/dev/sda1 through /dev/sda3).
One of these drives is going to be your EFI partition. This is what your system can read before linux boots, your BIOS can’t understand ext4 / btrfs / etc, but it can understand fat32.
If you run lsblk -no FSTYPE /dev/sda1 it should return vfat if that’s your EFI partition. That’s what we’re going to mount to /mnt/boot/efi
I’m assuming that /dev/sda3 is your data partition, e.g. where your linux install is. You can find the filesystem format the same way as your EFI partition.
Edit: After determining which partition is which, you’re going to want to mount the root partition, and then the EFI partition
mount /dev/sda3 /mnt
mount /dev/sda1 /mnt/boot/efi
Unix systems have theology of “everything is a file”, all devices and system interfaces are mounted as files. As such, to be able to properly chroot into an offline install, we need to make binds from our running system to the offline system. That’s what’s achieved by running for i in /dev /dev/pts /proc /sys /run; do sudo mount -B $i /mnt$i; done
This is just a simple loop that mounts /dev, /dev/pts, /proc, /sys, and /run to your offline install. You’re going to want to either add /sys/firmware/efi/efivars to that list, or mount it (with -B, which is shorthand for --bind, not a normal mount).
Once you’ve done this, you should be able to successfully chroot into /mnt (or /mnt/root if running btrfs)
At this point, you should be able to run your grub repair commands.
I’m doing my morning scroll before I start my day, so I can’t delve too deep, but this is the article I always reference when I have to do repairs
https://askubuntu.com/a/831241
#1 thing I noticed in your image is that lsblk only shows you partitions, and doesn’t mount them. You probably want /dev/sda3 mounted at /mnt
The only thing from the article you want to modify is using
mount -B /sys/firmware/efi/efivars /mnt/sys/efi/efivars, I believe the functionality changed since that article was written and that’s what worked for me
Additionally, if you drive is formatted as btrfs instead of ext4, once you mount your drive your root will most likely be at /mnt/admin or similar. Mount subdirectories to that folder instead of /mnt
If you have questions lmk and I’ll get back to you at some point today
SFC has worked numerous times for me, usually for botched updates. Haven’t used it in a long time after leaving tech support
This got me to finally move away from Edge. Only thing I’m wishing comes soon is native PWA support. The addon is so janky and my biggest gripe about using Firefox, but I can put up with it since I’ve now got vertical tabs and multiple profiles
I took a peek in a recycling bin last time I was at Target and saw a handful of vapes in there, this would be a good place to start.
I ripped one on a pew during a Christmas eve service once
Frankly both of these maps are deceptive (though the top one is albeit more so). The dot gets colored the primary color in that region, and visually makes the Democrats seem way more dominant when it’s much more bipartisan. A gradient would make this map better
This is just a theory, I don’t have knowledge of the inner-workings of either Linux or Windows (beyond the basics). While Microsoft has been packing tons of telemetry in their OS since Windows 10, I think they fucked up the I/O stack somewhere along the way. Windows used to run well enough on HDDs, but can barely boot now.
This is most easily highlighted by using a disk drive. I was trying to read a DVD a while ago and noticed my whole system was locked up on a very modern system. Just having the drive plugged in would prevent windows from opening anything if already on, or getting past the spinner on boot.
The same wasn’t observed on Linux. It took a bit to mount the DVD, but at no point did it lock up my system until it was removed. I used to use CDs and DVDs all the time on XP and 7 without this happening, so I only can suspect that they messed up something with I/O and has gone unnoticed because of their willingness to ignore the issues with the belief they’re being caused by telemetry
I would check out the inovelli switches. Not exactly inexpensive, but definitely home assistant friendly
Actively going through this rn, could use it
While the implementation of an A/B update system wouldn’t be drag and drop from Android to a different OS, they absolutely could implement the same idea to prevent this issue.
The likely reason as to why is storage space, you need two copies of the system, while only one is running at a time. They probably put as little space into these infotainment systems as possible.
If they put more in new models, they’d then have to support two methods of updating the system. It’s easier to tell the customer on the rare occasion that an error does happen “oops we made a fucky wucky it’s on you to fix it”
Glad to hear it worked! I edited the comment in case anybody stumbles across it with the same issue
It’s not “best practice”, but a compromised key is a compromised key whether that key is used to connect 1 or 100 computers to a server. No, I can’t shut off access to exactly one machine, I do not however have any difficulty in shutting off access to every machine and replacing it with a new key. Your system and my system are no different with a single compromised key.
If I had 100 computers that I had to change identity files on each time it was compromised, and my keys were being compromised often, I would see a benefit from using multiple different keys.
Quit acting like I’ve left the front door to my house open when the door is locked but my roommate and I share the same key.
This is actually quite handy, I’ve got a yubikey already and didn’t know they could be used for ssh
Again, I know it’s not amazing security but it’s not inherently bad. The key (actually encrypted), if (not when) compromised would provide the same level of access to my system as having two keys with one compromised. Assuming I’m an all knowing wizard and can smell when a key is compromised, I can log in remotely and replace the old key with a freshly generated one. More likely however is that if anybody was going to actually do something with my compromised key, they’d clear my authorized_keys file and replace it with a key I don’t have access to. Don’t kid yourself into thinking having multiple keys suddenly makes you 10x more secure.
What’s more likely is someone finds my flashdrive on the ground, goes “oh boy free flashdrive full of Linux ISOs and recovery tools!” And proceeds to wipe it and use it for their own shit, while I regenerate a new key when I notice it missing.
Interesting, both of my F40 installs with btrfs only have a root folder, but it looks like yours has created separate ones for /, /home, and /boot. run
ll /mnt/boot; ll /mnt/home; ll /mnt/rootso I can take a quick look at where things are located. My best guess is that sda1 gets mounted to /mnt/boot, while everything else (/dev, /sys, etc) gets mounted to /mnt/root