diff options
| author | Steph Enders <steph@senders.io> | 2024-03-07 15:17:29 -0500 |
|---|---|---|
| committer | Steph Enders <steph@senders.io> | 2024-03-07 15:17:29 -0500 |
| commit | 1f689fd039533801842ae241671f2437ddbe0044 (patch) | |
| tree | 50d3db88f2c7e676d6679696a101e6ae2b25448f /posts/manjaro-follow-up-breaking-things.html | |
| parent | 80f5dacf988b1cddd04eea6c4a6f70b165376764 (diff) | |
Copy old files and update build.sh to generate it all!
This is a huge messy commit but :) sue me. I'm not at work I can do
git badly for once!
Diffstat (limited to 'posts/manjaro-follow-up-breaking-things.html')
| -rw-r--r-- | posts/manjaro-follow-up-breaking-things.html | 99 |
1 files changed, 99 insertions, 0 deletions
diff --git a/posts/manjaro-follow-up-breaking-things.html b/posts/manjaro-follow-up-breaking-things.html new file mode 100644 index 0000000..c1a0c16 --- /dev/null +++ b/posts/manjaro-follow-up-breaking-things.html @@ -0,0 +1,99 @@ + +--post-date: 2021-01-05 +--type: blog + <article> + <h1>Manjaro Follow-up - Breaking things!</h1> + <p>I wanted to write a quick follow-up covering how I managed to break, + and then recover, everything when I went to remove my old debian + partition.</p> + <h2>Recap</h2> + <p>To recap: I installed Manjaro alongside a Debian/sid and Windows 10 + install. Each of those OSs were on their own SSDs. I went from a 128SSD + with Windows installed, to adding a 256 installing Debian. Years later I + split the Debian SSD into two parts - installing Manjaro on my new slice. + Since my last update I have been playing around with Manjaro and having + made my i3 keybindings for Kwin I've been pretty happy. But then I + started breaking things.</p> + <h2>Break stuff</h2> + <p>I broke my Manjaro by updating my Debian (apparently). To be honest + this is the one part I don't fully understand <i>why</i> it happened. + From what I could find online I didn't setup my system to handle two + separate Linux OS installs. But I was no longer able to boot directly + into Manjaro without using the initramfs failover boot option. I only + updated my Debian install because I was debugging something on my work + install, which both run Debian/sid. (Otherwise I would've used my + server which runs Debian/Stable). But considering I hadn't had any + need to boot back into Debian I decided to just get rid of it!</p> + <h2>GParted, Grub, Gotchas!</h2> + <p>I went in knowing I'd have to fix my Grub since I'd be + removing Debian, which was the OS that I configured when I first + dualbooted the machine, so I assumed they were linked somehow and I would + need to reinstall it. The process I followed was:</p> + <ul> + <li>Create a GParted Live USB</li> + <li>Launch GParted reconfigure my partitions</li> + <li>Open the terminal in the live USB and reinstall Grub</li> + </ul>The 3rd point being a bit of a "rest of the owl" I + wasn't sure what to expect. GParted thankfully warns you + "you're probably going to break stuff see our FAQ" which + had a section on reinstalling grub. Reading that the 3rd part became: + <ul> + <li>mount the linux OS</li> + <li>bind the live dirs that are needed: <code class='inline'>/dir /sys + /proc</code></li> + <li>chroot into the mounted folder</li> + <li>run <code class='inline'>grub-install <device></code></li> + </ul>But what I failed to realize (stupidly in hindsight) was the + "device" is the Master Boot Record (MBR) device. So in my case + Windows or <code class="inline">/dev/sdb</code>. I had assumed it was the + device of the linux install so I tried that and got notified my EFI boot + directory didn't look like an EFI partition... and from here it was + rabbit holes. + <h2>Where is my EFI partition?</h2> + <p>I have a fairly old Windows 7 install that has been upgraded to + Windows 10 during this whole journey. I've been meaning to reinstall + it (on a larger drive). But rather than having a few partitions on my + drive (typically having a boot partition) I just have the one (and a + recovery partition). Its marked as boot, and even mounted to <code class= + 'inline'>/boot/efi</code> I found when I was able to boot into Manjaro + again. But it made no sense to me. If I needed an EFI partition, why was + my efi pointed to the root of my Windows C drive? The rabbit hole + consisted of:</p> + <ul> + <li>Creating a 200MB Fat32 Boot partition</li> + <li>Mounting that as my efi-directory</li> + <li>Reinstalling grub (again on my Linux device)</li> + <li>Eventually getting it to boot straight into Manjaro</li> + <li>Modifying my <code class='inline'>/etc/fstab</code> to mount my + boot/efi to the new partition (oops)</li> + <li>Repeating the above steps 5 times hoping something would be + different</li> + <li>Eventually finding in a forum that grub should be on the + MBR...</li> + </ul> + <h2>The Fix and Final Steps</h2> + <p>The fix was to basically follow the steps above but use the MBR:</p> + <ul> + <li>Boot GParted Live USB</li> + <li>Properly configure any partitions (this case delete the + "EFI" partition)</li> + <li>Mount the linux device</li> + <li>Bind the necessary live dirs to the linux mount</li> + <li>Run grub-install to the MBR device</li> + <li>Reboot</li> + </ul>It was that misunderstanding about the MBR that sent me on a path, + but now I at least feel semi-confident in changing around my OSs knowing + how to fix Grub. But what bout the Fstab? + <p>Like all true movie monsters, my stupidity came back for the final + scare. I booted into Manjaro, from Grub! to have it crash on me. It + couldn't mount one of the devices! The deleted partition! I was in + the recover shell and was able to modify the Fstab to point back to the + correct boot/efi device. (Thankfully I was familiar with Fstab to begin + with). But editing two files in a super-low-res terminal is not my idea + of fun (okay, maybe it is).</p> + <h2>Conclusion</h2> + <p>One of my new years resolutions was to learn more about my system. So + lighting a fire I had to put out was a great way to get some more + knowledge on maintence for grub/dualbooting.</p> + </article> + |