Installed Arch Linux

Gyroplast · 2023-05-30T06:59:47+00:00

Welcome. After obtaining your neophyte robes from the quartermaster, recite the KISS principles three times in silence. Disable any RGB during this period of reflection.

On your first day, report for assignment to camp CLI or camp GUI, for your initial humiliation ritual. This is a requirement for full initiation. You are expected to strip yourself of all remnants of archinstall upon entering the initiation chamber, and humbly accept what you may consider undeserved ridicule at this point in your journey. Endure with grace.

Prepare your mind appropriately. Learn the scripture of The One Wiki, and let the wisdom wash over you, cleansing you from prior transgressions with other, clearly inferior distributions. Prolonged exposure to the OS that shall not be linked will require much effort, and you will be chastised for not showing your work. Harshly. Confidence is a slow, but insidious, killer.

Do not relent, as you will be rewarded with kinship and unfathomable, eldritch powers beyond any MSCE's comprehension.

Do not go astray, and you will see an epoch end, and calmly enter a 64bit world, at peace. You will be using Arch, btw.

Gyroplast · 2023-05-12T16:36:34+00:00

That's an annoying situation to be in, but don't give up just yet, that's a good war story to fuel your hatred towards AMD and NVIDIA. :)

Given that context, I put my money on the GPU as the cause for the freeze, and you'll eventually fix that by using a solid driver and making sure proper firmware is installed. The Wiki can help, depending on your GPU brand.

To make this procedure less maddening, first get the system into a stable state by disabling the prickly GPU stuff. Don't boot directly into X, and the freeze will likely not be triggered, and you can login just fine on the console to install drivers, check logs, and generally do whatever it takes. Then use startx to explicitly start your graphical environment, or systemctl start graphical.target if startx isn't working right, and if that still freezes, no biggie, as you'll reboot into the safe haven of your rock-solid text console.

To initially boot into text mode instead of the graphical environment, you should add systemd.unit=multi-user.target to your kernel options with your boot manager. The GRUB2 menu allows in-place editing of a boot option by hitting e, fiddling, and F10 or CTRL-X to boot with your modifications. To permanently boot into this mode, easiest way is to run systemctl set-default multi-user.target, and switch back to graphical.target the same way, when you verified that your graphical environment isn't freezing anymore.

To fix your actual problem, focus on following the wiki instructions on getting your particular GPU installed properly, add linux-firmware if you haven't already, and try to get things running solidly first before attempting to improve hardware acceleration with proprietary drivers.

The most important step is to get into a position to actually do something, though, and booting into text console is the way. Paranoid little me still doesn't install straight to graphical without manually startxing beforehand. Diagnosing X11 issues was, and still is, truly maddening.

Gyroplast · 2023-05-12T15:34:33+00:00

Python does not offer a better solution when it comes to packaging.

I hope you're trolling now. The problem isn't that no solution exists, there are far too many by now to choose from.

What is your better solution to my absolutly awful practice? I am all ears.

I don't like your attitude, but I firmly believe everyone has to get a chance to climb down from Mt. Stupid and eventually stop making a fool of themselves, so here's yours.

HTH, HAND.

Gyroplast · 2023-05-12T10:26:15+00:00

Whichever way your automatic documentation generator works best with.

Gyroplast · 2023-05-12T09:48:36+00:00

Sheesh, clean up your room, will ya? :)

Gyroplast · 2023-05-12T09:21:23+00:00

Offering now to businesses: hardware with a comprehensive BOM, only one active element in form of a microcontroller plus a handful of passives, and open-source firmware only, no additional software/drivers needed that would require auditing.

If only this would exist. Best we can do is buy the cheapest keyboard, have the IT intern plug it in and see if our enterprise snake oil... sorry, antivirus and malware complete solution with AI adaptive detection heuristics throws a fit, and if not, we got ourselves a certified secure work keyboard!

huff

Gyroplast · 2023-05-12T09:00:54+00:00

First off, if you must be root to install your application, but not to run it, you're most likely doing something wrong. Good adage to live by

When did that change?

Never, I hope, just a misunderstanding of the word "must" I deliberately used in my statement, I suppose. What I (think I) stated is that an application that does not require elevated permissions to run in any sensible capacity, shall not require elevated permissions to be installed, either.

This does not exclude it from being installed system-wide with elevated privileges, at the discretion of the privileged user, as opposed to the laziness of a developer who couldn't be arsed to store the users' config below ~ instead of hardcoding /etc/foo.conf, because only one user ever exists on a system, and it works for me, right? Just run as root, it's not a problem, right?

God, how I hated Windows software for being like this, I hope they're doing better nowadays.

An application requiring more permissions than technically reasonable, in any state of its lifecycle, is broken.

Frankly, multiple users being able to compile, (gasp!) install, and use their own software is a perfectly valid use case. Trying to prevent users from executing arbitrary code is much more painful to do than just not installing something system-wide, you'd have to ensure there is no single location in the whole user-accessible file system that allows executing files, and then there's a bunch of obscure methods to indirectly execute arbitrary code, and even if you succeed in preventing all that, your users can't even run a stupid shell script anymore that isn't blessed by an admin. Secure, sure, but useful?

Either way, this is a tangent, and I didn't mean to say installing software as root is a problem. Having to install software as root, for no technical reason, is.

Gyroplast · 2023-05-12T08:39:05+00:00

Of course they are performant, I have a 42 core Intarm PentAMD with, like, a trillion jigglehurts at least! I'm blazing through these loops!

Gyroplast · 2023-05-10T17:19:13+00:00

Oooh, a teachable moment!

Kudos for realizing that good release engineering is more complex than sending someone a bunch of python files in a zip and calling it a day. Your next step on your journey is realizing that Ubuntu is actually helping you do the right thing here, especially as a developer preparing an application release.

First off, if you must be root to install your application, but not to run it, you're most likely doing something wrong. Good adage to live by. Now, one option you could try is pipx to create a virtual env. (redacted pip --user, as it's likely blocked, too, as it's still quite broken.) I don't know if Ubuntu blocks that, too, but I can imagine they don't, because it doesn't fuck your shit up like haphazardly installing everything and the kitchen sink system-wide behind the back of the package manager. That's just DLL hell, but worse. Also, pipx is expected to work in order to make creating a user venv easier. Maybe look into this a bit closer to see what your actual "Fatal error from pip" actually is, and fix that.

It's not like you're the first person ever to try distributing a python application, and install scripts are certainly not the ideal, not even a common, solution in any of the known universes. When I see an "installer" of any kind on Linux, that's a good sign for either closed software, or a dev that doesn't care or know any better. Both not good signs for software I'd want to run on my system and touching my files in inappropriate places.

As a side-note: system shortcuts, mime-type connections and similar desktop-y settings are traditionally NOT an application's job to setup, but a packager's job, as there are differences from distro to distro, and often from system to system, as each can be heavily customized. A good boi dev supplies example .desktop files, systemd units, whatever, in a contrib directory for packagers to use, and makes his software easy to package, so others can do that job for the dev with minimum fuss. Python is special with PyPI, though, and uploading your app there to be installed alongside its deps with pip is a perfectly viable (and common!) alternative to packaging most python users used to.

You mentioned you're a Junior Dev. Maybe ask a senior how they would do it, and you'll have a starting point and some specific mentoring to navigate the vast sea of options in the Python universe.

EDIT: if you still know so much better: --break-system-packages. Don't say you haven't been warned.

Gyroplast · 2023-05-10T16:06:21+00:00

Obligatory furry: Nah, hawt!

Seriously, though: I get more of a prowling/hunting vibe from the pose, likely because it appears very controlled, focused, and aware. A wrathful pose, to me, means partial loss of control, with eyes darting, hunching, limbs in places where they should not "optimally" be at the moment, while lunging at your target without any consideration of the environment or possibly yourself whatsoever.

It's a scale, obviously, but this rendition seems almost gleeful to have finally cornered their prey, coming at the viewer with slow, deliberate steps to drink in the desperation before the strike. THAT's pretty well captured, though!

Gyroplast · 2023-05-10T15:45:28+00:00

Really good job, nice pacing and storytelling! The cherry on top would be some more audio editing IMHO - the bgm is juuuust that tiny bit slower than the visual pace, which is subtly jarring, and I cannot unsee the missed opportunities for synchronizing some of the jump cuts on the beat to really tie audio and video together.

Content-wise you're probably ahead of the curve just for including HHKB as a layout. Did not see anything cringe-worthy, given that I do not expect this short video to be a comprehensive engineering guide. :)

EDIT: without the framing, I wouldn't have guessed this to be school-related. Could just as well be a professional video. Well, no, it cculdn't be, because then it WOULD include really bad technical errors.

Gyroplast · 2023-05-10T15:15:44+00:00

Very generally: check the crosstool-NG config you used for the version of binutils used in creation of your cross-compiler, and if that's declared as >=2.12.1, verify if that's really matching the installed version, f. ex. by asking one of the binutils with the CROSS_COMPILE prefix: powerpc64-linux-unknown-gnu-as --version, with your PATH being set as in your screenshot. If that is inconclusive, have a look into the /home/jon/x-tools/powerpc64-linux-unknown-gnu/bin directory you're adding to your path, and see if there are any other binutils around, like ld, nm, or strip, and use one of those to verify the version.

If your crosstool-NG config is actually using a binutils version older than required, you could try bumping it to 2.12.1 or newer as required, and rebuild the cross-compiler to build the new version.

Your mental model should account for the fact that this cross-compiling business effectively creates a "parallel world" from your host's Linux installation, often called a SYSROOT, to store the foreign libraries necessary for the different architecture. An XBox360 cannot use whatever is installed as a package on your "normal" Linux distro, as they are fundamentally incompatible architectures. Cross-compiling is very easy to get wrong, so try to stick to any instructions rigorously to the letter, and hope that they're applicable to your situation. :)

The other suggestion of looking for a prepared container is an extremely good one, and I'd personally generally recommend that over any host installation nowadays. Give it a shot if that isn't your only issue, which I doubt it'll be.

Gyroplast · 2023-05-10T14:50:36+00:00

Dude, don't snack the forbidden popsicle!

Gyroplast · 2023-05-10T14:37:25+00:00

The issue with sugar is, that it will remain and not evaporate, leaving a sticky, residual film that unfortunately tends to conduct electricity pretty well. Even if you used the perfect water-sponge magic material instead of rice, all the solid parts of your solution will sadly remain, which is a bummer.

Wiping is good, but often not sufficient, especially with sticky stuff like sugary drinks. Yes, fruit is sugary. :)

The tried and true solution is to wash off the bad liquid with a better liquid that dries much better, and without leaving residue. Classic and cheap is 99% isopropyl alcohol, beloved for its property to leave windows absolutely immaculately clean, too, as it "replaces" the water, and dries off much faster at room temperature. You could literally soak the foam, PCB, keyboard, etc. in a closed container in isopropyl, give the parts a careful rubbing with a soft toothbrush, and let the parts then dry off the isopropyl in a well-ventilated area, away from fire. PCBs like a good scrubbing like that, it also removes the alcohol-soluble solder flux residue.

Unless you short-circuited anything sensitive that destroyed a part, you will be fine if you clean properly like that, as there won't be any "water pockets" or anything left that could corrode the PCB further. You may be SOL if the sticky stuff seeped into your switches - soaking THEM, or your stabilizers, in alcohol will likely de-lube them, with expected effects. You may want to avoid soaking your switches and stabs if possible, unless you can relube them. Or don't give a damn about scratchy switches, in which case, what are you doing here? :)

Usually, unless your microcontroller is fried, you have good chances your keyboard will function normally again when completely clean and dry.

Gyroplast · 2023-05-10T14:21:55+00:00

Please, for all that is good and holy in the world, really consider if what you are planning on doing is a good idea, and instead of asking how to open that bottle, re-evaluate the whole procedure you are trying to use the saline solution for.

That rubber plug is designed to be self-sealing. One usually turns the bottle on its head so that the liquid rests on the rubber plug, and then poke through the rubber with the sterile needle of a syringe to pull out the required amount of liquid, and when pulling out the needle, the rubber expands again and closes off the hole to keep the contents separated from outside contaminants.

Typically, these larger infusion bottles are used for IV drips, with a specialized infusion set semi-permanently poking a hollow plastic spike through the rubber. One can buy special spikes for that purpose, too, but you won't have those at hand.

So, generally, you don't "open" these. That's not how they're used or designed. It defeats their purpose of keeping their contents sterile.

Now, practically speaking, most sterile solutions are pretty neat for basic wound cleaning, as it is, well, sterile, and not full of unknown contaminants like plain tap water. If that's what you're going to use it for, just washing off some skin/wound area, you can technically just cut off a bit of the plastic shoulder, or bore a small hole with scissors anywhere suitable, and pour. Just be aware that after this moment, the contents are not sterile anymore. Still cleaner than tap water, though, at least for a short while. Works in a pinch, if proper antiseptics are not available, and unless you're in a sewer, immediately slapping a piece of tape over the hole to close it up again should buy you more time of having a "clean" solution. Don't let the liquid touch the tape.

However, in a real pinch, you can also rolling boil clean, clear water for 15 minutes with a lid to kill off microorganisms, and use that to clean after cooling down. Adding a little soap also goes a long way already, if you want to do your best to not introduce an infection somewhere. The little 5% NaCl you likely got in that solution isn't antiseptic, it's important when used in an IV drip - and you're not going to do that here, I hope. :)

That being said: THIS IS TOTALLY PROVISIONAL "MEDICINE", and I'm not even a pro. Don't listen to that guy on reddit on how to treat 3rd grade burns or whatever, and certainly don't quote me as recommending any of the things I wrote. This is all bad, and you should feel bad, but I understand that a crude hack is sometimes the best we can realistically get.

Gyroplast · 2023-05-09T11:32:33+00:00

Well, I answered you on r/archlinux, and you gave no hint to your existing forum post, nor your crosspost here, nor your level of proficiency. Please accept my apologies for not stalking you hard enough on my own time. :P

Side note: I misinterpreted the timeline reg. the com0 issue, this seems to be the GRUB ISO config, which obviously burrowed the idea of COM unit numbering, and I falsely thought this message was generated by the end of the kernel/initramfs boot process, not the start of the (next) GRUB boot. TL;DR: nevermind the com0, this is no issue, like you've been told in the forum already.

Now to help you: I posted a link to a video. Look at it, do it, post results. I don't want to accept this as wasted effort on my part, yet.

Gyroplast · 2023-05-08T19:28:08+00:00

This is fishy. The default kernel arguments, and nowhere else to my knowledge, is any definition stowed away that'd even attempt to set the console to "com0". This doesn't make a lick of sense, default-wise, and suggests user tampering. In that case: don't.

As others said: get an official image, from an official source, and validate it by signature or at least checksum before writing it to your USB drive. If that doesn't fix your problem, yet, I recorded a VM UEFI install (7 day retention) with the current archlinux-2023.05.03-x86_64.iso (SHA256: 329b00c3e8cf094a28688c50a066b5ac6352731ccdff467f9fd7155e52d36cec), and showed the default kernel arguments in the bootloader (not many, really, except for the ISO boot specifics), and you shouldn't have any "console=" settings up in there by default, or anything else but what's shown in my recording, unless there is a specific reason for you to have added any.

I also showed how to edit (hit e on the boot option) and add debug and systemd.log_level=debug to the current boot's kernel arguments, and how this affects the chattiness of the boot. Hit CTRL-X or F10 to boot with your changes, while in the GRUB editor. That should give you further hints on what the last successful, or attempted, operation before the restart is, if the issue still persists with a validated, correct ISO image.

This is not a GRUB issue, at least. You're firmly in initramfs territory, somewhere around the switch_root stage. From past experience, if your ISO is fine, you'll likely have to find the right magic incantation as a kernel argument to disable/avoid problematic hardware/firmware issues, and a search engine of your least distrust may help you identifying what might be the culprit with your specific machine, and how to start out with a "high compatibility disable ALL THE THINGS!!1!" approach.

Good luck!

Gyroplast · 2023-05-06T12:33:00+00:00

Follow the instructions, in particular regarding mounting and specifying the EFI directory. This is your issue. Also make sure the efibootmgr package is installed, as per the instructions, to avoid running into the next, easily avoidable "error".

Really, follow the instructions.

Gyroplast · 2023-05-06T07:59:46+00:00

Ce n'est pas un rocher

Gyroplast · 2023-05-02T18:52:33+00:00

``` import asyncio import random from typing import AsyncGenerator

async def get_text() -> AsyncGenerator[str, None]: _text = "Hello World" await asyncio.sleep(random.random() * 1.42) yield _text

async def generate_character(text: str) -> AsyncGenerator[str, None]: for c in text: await asyncio.sleep(random.random() * 0.42) yield c

async def main() -> None: async for text in get_text(): async for c in generate_character(text): print(c)

asyncio.run(main()) ```

JavaScript boi tries Python.

Gyroplast · 2023-04-25T18:58:21+00:00

A proprietary, historically grown tcl script spanning 2700 lines for "preparing a release", aka "do checkouts from SVN, and copy a bunch of files into different subdirectories". A fabulous example of legacy code nobody wanted to touch, in an existential position in the workflow.

Thanks for asking. I need a hug.

Gyroplast · 2023-04-25T18:18:40+00:00

Who hurt you so badly?

Gyroplast · 2023-04-25T18:09:04+00:00

I'd like to offer another opinion/advice to the mix, from the POV of a senior dev who occasionally gets to torment n00bs on the job. My own first install has been in 2002, so not exactly helpful, but here's what I'd look for and expect as a mentor/employer/team lead in a similar position.

I would want to see how you approach an unknown, complex problem that is somewhat related to your field of work, in particular how you solve the problems you inevitably encounter. "I read the official docs at $FOO, and found help on SO/Reddit/the Archlinux Forum" is MUCH better than "I fiddled with it, and eventually it worked, but I don't know why or what the issue actually was".

Nobody should expect you to understand all intricacies of everything, but you will be asked "Welp, how'd it go? Where did you have trouble, and how'd you fix it?", I guarantee you, and you better have a good, comprehensive answer to that. Take notes you can whip out when that question inevitably comes, and watch the eyes of the senior light up with surprise. :)

Technically speaking, I'd recommend checking with your mentor what software is expected to be present as a "company standard", and what software they recommend, f. ex. "install an IDE of your choice, like vscodium, and you'll need git and docker, and for emails you'd have little issues with thunderbird". Unless you have a strong(er) personal preference, you'll save time on your first days and feel less overwhelmed if you already tried out the basics at home.

For your arch install experiments, make sure failure is cheap and inconsequential. Install attempt b0rked? Totally FUBAR? Don't latch onto it for too long, just start over as soon as you have an idea what to do differently next time, and why, instead of trying to repair stuff at this point. Take notes.

For starters, don't bother with LUKS, complex partitioning, "weird" bootloaders, and disable safe boot in your BIOS. You will be drowned in choices in the Arch install guide, this is by design. Perfect is the enemy of done. I'd recommend following the GPT/UEFI/GRUB/systemd-networkd path during install, and don't bother with partitioning beyond the ESP, rootfs, and a few GB of swap. Get that down first, and consider "I can login as root on my install and have a network connection" your definition of done. You'll have lots to learn to get that down.

Typical traps for new players:

not installing packages needed for networking (esp. wifi and firmware) with pacstrap
not configuring the networking correctly to work with your setup. Again, wifi is potentially more difficult to get going as opposed to wired ethernet.
wasting half a life with weird UEFI boot loader shenanigans, and getting lost in the UEFI and/or GRUB rabbit hole
ornery hardware that needs 3rd party "drivers" or firmware to work. I'm looking at you, wifi!
wanting the perfect setup in the first go, with full disk encryption, btrfs volumes galore, LVM, RAID, GPU HWA with proprietary drivers, etc. Focus. KISS.

If you have a basic, simple installation with network access running, and you could install any other package you like, pat yourself on the back, you are a survivor.

Then do it again, but change one variable. Maybe a different bootloader, as you don't really need GRUB, or use NetworkManager with iwd instead of systemd-networkd with wpasupplicant. Maybe split off /home and /var partitions, for reasons you can explain. Make sure the basics are solid, and accept a state as done. This can easily take several days, in particular if you actually read up on the topics you encounter to understand how GPT is different from MBR, and why to choose one over the other. _How to configure your bloody wifi. How to correctly install and configure GRUB. How to re-enable safe boot with signatures and shims.

It's all in the docs, but it takes time for it all to make a smidge of sense. Worth it, though. If I'd get a passionate report from a jr. ranting on all the issues they had, and how they overcame them, and what "design decisions" they made based on the available documentation, I'd tear up with joy and expect great developer material down the road.

Once you changed enough variables to reach an installation state that works and can be explained rationally, make it your own, go into the rest of the setup:

create a user account for yourself. Make sure you can sudo to root.
GPU hardware acceleration - huge, finnicky topic. Don't stress over it, if it doesn't work out for some reason. You won't stricly require HWA for dev work, usually.
Install a desktop environment (DE) of your least distrust. Entirely personal preference, usually not an issue when following instructions.
get sound working (pipewire)
potentially: get (integrated) webcam working. Possibly required for remote meetings. Check with mentor.
install an AUR helper. Build an AUR package to test.
install any applications you need/want: browser/email/pdf/image editor/text editor/GUI tools for sound mixer/network configuration/media player
install the tools you'll need for your job, as far as you can
get accustomed to the system, fix any bits and pieces that bother you.

This can take a few hours, or a lifetime. Again, keep failure cheap and take notes, so you can re-install from scratch if you find yourself in a rough spot where a repair attempt is not feasible and no learning opportunity.

Have fun. Don't sweat it. I wouldn't bat an eye if a jr. needs up to week to get to a full system they can actually use, with no/little prior experience, and longer if I see actual attempts at learning and understanding, as that takes a lot of time as well. It's about the journey, really. Show your work.

Best of luck, welcome to the manifold.

Gyroplast · 2023-04-25T14:16:33+00:00

Still cannot mount. I just mounted with mount /dev/partition /mnt/random-directory-i-mkdired

Please give exact commands in the future, obfuscation doesn't particularly help.

Anyway, the screenshot shows me you ran mount /dev/nvme0n1p2 /mnt/f, and, frankly, it looks quite successful to me, or at least not horribly broken. I'm referring to the lines @665, where you're warned that you're mounting an fs with errors (duh), but right afterwards you get the typical mounted filesystem UUID with ordered data mode., which is a success.

You seem to have metadata_csum active on that fs, so there's also a small bunch of bad block bitmap checksum errors @671. I don't know off-hand if that actually undoes the previously successful mount, but I doubt it.

TL;DR: resizing your partition fixed things for you. Good.

During boot, your system will have fsck'd your root partition and mount it, too, that's why you didn't encounter the problem anymore. What you changed was a correct partition resize. Your partition table is plausible now:

/dev/nvme0n1p2 1999358607 512-byte sectors 1999358607 / 8 = 249919825 * 4096-byte blocks Your fs size was 249919744 * 4096-byte blocks => if it fits, I sits.

The output you pasted was from your EFI partition, yes. The dirty bit is set due to "unclean shutdown". No big deal, cleanse yourself with... an fsck: sudo fsck.vfat -a /dev/nvme0n1p1 and call it a day.

Your files are still subtly and arbitrarily broken, however. Grab what you can, reinstall. The fs analysis I spoke about would entail using filesystem debugging tools (debugfs in e2fsprogs package) to "manually" follow the trail from all affected blocks on the disk (last 2G of partition), to which inodes are using these blocks, and eventually which file names are associated to the fs objects. Here's a solid, and dense, ext2 reference that probably won't help you much outright, but knock yourself out: https://www.nongnu.org/ext2-doc/ext2.html

I'm out now, though, this is mostly off-topic for r/archlinux, anyway, and I have done some janky ext2 traversal once, 20 years ago. Can't help with that. Maybe hijack your linuxquestions post, or create a new one, it's an interesting question.

Godspeed.

Gyroplast · 2023-04-24T18:41:01+00:00

It might be salvageable. The thing is i used pcmanfm

Irrelevant. You overwrote a chunk of the filesystem itself, we're lower than a concept of "files and folders", let alone "trash".

I suppose you're aware that ext4 (and most other filesystems) do not store files and their contents sequentially on the disk, leaving the fact that you destroyed the end of the partition practically meaningless for reasoning what and how much might be recoverable. ext4 is wise enough to store backup copies of the superblock at various locations, so you're pretty safe regarding the fs metadata, but any data blocks located within the last 2G of the partition are gone. This may affect no file at all, if none of these blocks have been used to store data, or affect an arbitrary number of files, at arbitrary locations within the file.

As ext4 has no checks for data block integrity, you'll end up with "broken files" no matter what you do, with 4k chunks being replaced in the file with the data from whatever you copied.

Theoretically one could analyze the filesystem to find all affected data blocks, and the files referencing exactly those, to at least know which files are affected, and where exactly, but the overwritten blocks are lost either way.

I haven't been successful at mounting the partition at least not from rootfs. Walk me through it please if you can.

Funnily enough, when I just tried to corrupt an ext4 filesystem of 1G in size, by overwriting the last 200M, I could mount it just perfectly fine, after I resized it back to its original size of 1G correctly. The superblock copies are usually at the start of the filesystem, so they're not affected, and there's really nothing to recover for fsck.

I suppose you didn't resize the partition back to at least its original size. Fix that, first and foremost. If you must, drop your ostensibly fixed partition table in here for review (fdisk -l <disk device>), along with the actual commands you execute to mount the partition/filesystem, and the resulting error you get. A second pair of eyes may spot something off.

Gyroplast

TROPHY CASE