The Linux Thread - The Autist's OS of Choice

you just said to run the commands. you never specified what arguments to use, or how to determine exactly which arguments to use. because you can't.
I assumed I was talking with white men that understand how a cli works, and understand I didn't just give a list of commands you run with no arguments.
 
  • Like
Reactions: Zeftax
I assumed I was talking with white men that understand how a cli works, and understand I didn't just give a list of commands you run with no arguments.
you literally just did. if someone really wanted to follow your "guide" they would first have to spend half an hour learning how the various commands work and have to restart from scratch three times because they didn't know a very basic practice like making an efi partition that isn't 50gb in size.
 
you literally just did. if someone really wanted to follow your "guide" they would first have to spend half an hour learning how the various commands work and have to restart from scratch three times because they didn't know a very basic practice like making an efi partition that isn't 50gb in size.
Are people coming to the Linux sperging thread on the kiwifarms looking for a guide to install arch?

😂
 
you literally just did. if someone really wanted to follow your "guide" they would first have to spend half an hour learning how the various commands work and have to restart from scratch three times because they didn't know a very basic practice like making an efi partition that isn't 50gb in size.
Many people already linked to the wiki, it gives both the arguments to use with the commands and the recommended partition sizes based on your disk size, as well as many other considerations. Lurker never referred to it as a list of commands, it was obviously a list of steps to show just how few there are in the base install.
 
$fdisk
fdisk: bad usage
Try 'fdisk --help' for more information.
$mkfs
mkfs: no device specified
Try 'mkfs --help' for more information.
$ mount the filesytems
mount: filesytems: mount point does not exist.
dmesg(1) may have more information after failed mount system call.
...
The responses to the commands are literally telling you what to do next.

I say this to interns and Jr programmers all the time, READ what the prompt is saying smarty pants.

Probably a couple times a week I have to run a program that's cli I haven't "learned" and do fine. You learn the Unix philosophy, the pipe, the shell and the standard way most of the cli operates. You read the output of the commands. It's standard operating procedure to run a command with no arguments to have it tell you how to use it. Learn that. Not fdisk.
 
you literally just did. if someone really wanted to follow your "guide" they would first have to spend half an hour learning how the various commands work and have to restart from scratch three times because they didn't know a very basic practice like making an efi partition that isn't 50gb in size.
No wonder your shit got compromised
 
Speaking of EFI partitions, how come that Windows can fit it's entire bootloader, with separate languages and whatnot, on a 100MB partition, GRUB can overwrite it without resizing when installing something like Debian or Mint with dual booting, but Arch requires you to make it at least 1GB? And archinstall will refuse to put systemd-boot on that 100MB partition for dual booting and will demand that you do a clean wipe?

Seriously, what's the point of having archinstall if you have to do everything that every other distro guides you through manually, and everyone will tell you to do so instead of, you know, making archinstall on par with Debian's installer in terms of features?
 
Speaking of EFI partitions, how come that Windows can fit it's entire bootloader, with separate languages and whatnot, on a 100MB partition, GRUB can overwrite it without resizing when installing something like Debian or Mint with dual booting, but Arch requires you to make it at least 1GB? And archinstall will refuse to put systemd-boot on that 100MB partition for dual booting and will demand that you do a clean wipe?

Seriously, what's the point of having archinstall if you have to do everything that every other distro guides you through manually, and everyone will tell you to do so instead of, you know, making archinstall on par with Debian's installer in terms of features?
systemd-boot can't reach into EXT4 or whatever linux filesystems you use, that means the kernel goes onto the EFI system partition. It's going to be tight with just 100MB especially when you have giant initramfs and firmware binaries in there these days, not to mention a different initramfs for each backup kernel. Systemd-boot was previously called gummiboot, a minimalist bootloader that just uses the stock EFI protocols to hand control over to the Linux EFI stub, its a lot smaller than grub that does the proper Linux boot protocol thing optionally. I still stick to Grub because I know what I'm doing and don't care for initramfs initialization.

For windows, its just bootmgfw.efi reaching into an NTFS partition (with its own builtin drivers) to load winload.efi and then ntoskrnl.exe.

There is nothing stopping you from installing systemd-boot on another partition, ending up with 2 different EFI system partitions. A non-retarded UEFI BIOS should still allow you to pick the right bootloader to use if you want to dual boot.
 
thank god people like slave power have been filtered

stop trying to convince him
1740994791503.png
I guess they should rewrite this disclaimer to warn that Arch is hostile to anyone who's not an expert at it, and if you can't get it installed you should fuck off and use a different distro. Very misleading to have this as the first thing on their page.
There is nothing stopping you from installing systemd-boot on another partition
Huh, yeah technically that would work even if it's by the end of the Windows partitions wouldn't it. And technically archinstall could handle this layout, even if it required pre-partitioning the drive beforehand. Never thought about multibooting from a single drive that way.
 
There is nothing stopping you from installing systemd-boot on another partition, ending up with 2 different EFI system partitions. A non-retarded UEFI BIOS should still allow you to pick the right bootloader to use if you want to dual boot.
Yes but why doesn't archinstall just install the grub stub + a setup with a proper BY GOD ext3/4 /boot partition and then whatever mix of LVM/cryptsetup/ZFS you decide you want to do with the rest of the free space on your disk? Preferably, after giving you the choice to resize any existing NTFS partitions so you actually have space on your disk?

And don't pretend it's for 'security' reasons. As if you carry your laptop to the toilet with a Kensington lock strapped around your neck.

This isn't hard. Debian has been doing it for what, at least the last fifteen years or so, if not much longer?
 
Speaking of EFI partitions, how come that Windows can fit it's entire bootloader, with separate languages and whatnot, on a 100MB partition
Technically it can't. There was a problem where one kb#### update would always fail to install because the the efi partition was too small, despite that being the default partition side set by the OS installer. Then you have to shrink your os partition by 50mb and recreate the efi partition using the commandline
 
Yes but why doesn't archinstall just install the grub stub + a setup with a proper BY GOD ext3/4 /boot partition and then whatever mix of LVM/cryptsetup/ZFS you decide you want to do with the rest of the free space on your disk? Preferably, after giving you the choice to resize any existing NTFS partitions so you actually have space on your disk?
I use gentoo, so I can't say I know what Arch maintainers are aiming for. The nice part about grub is definitely being able to reach into other filesystems to poke around if the system doesn't boot since it has its own filesystem drivers. I put a 4GB EFI filesystem for my own setup, good enough to also dump in whatever BIOS update files there, along with a backup boot option like SystemRescueCD in case I fuck up bad.

The old school "PC BIOS" grub was directly installed into the HDD Master Boot Record or partition boot sector, and it could jump into an EXT4/XFS filesystem to load the rest of grub and the kernel, so there wasn't any need for a separate /boot or /boot/efi partition.

Gummiboot and systemd-boot is seen as a lightweight alternative to grub, especially since grub is GPLv3, which brings in a whole host of other legal issues for secure boot good boys (and the raison d'être for shim). Systemd-boot doesn't support any form of scripting or probing, its just a kernel boot parameter text file and the kernel itself, everything is handled by the kernel EFI stub.

Grub supports secureboot, but the grub.cfg and initramfs file aren't verified (unless you pull in the grub gnupg signing modules) since the EFI protocol only defines signatures as attached to EFI binaries, making it a possible attack vector, albeit contrived if someone already has physical or root access to the machine.

There is also a newer systemd "UKI" where the systemd-boot + kernel command line + microcode update + initramfs + firmware is combined into a single EFI binary and signed for secure boot. It's fine if you're doing a traditional distro where everything is shipped as is from upstream, but a pain in the ass for users since you can't easily modify the kernel parameters anymore or even load custom built kernel modules if module signing is enforced.
 
Technically it can't. There was a problem where one kb#### update would always fail to install because the the efi partition was too small, despite that being the default partition side set by the OS installer. Then you have to shrink your os partition by 50mb and recreate the efi partition using the commandline
That wasn't due to the EFI partition, but due to the recovery partition. I know because I encountered it, tried to repartition my drive to make a new one and recover disk space from the old one, but I used gparted and that somehow fucked it up where it would inexplicably crash on startup. I had to reinstall the OS but kept the old SSD, then someday replugged it into a ThinkPad. It managed to somehow bring itself back to life and worked perfectly fine, but I don't want to reformat that drive given the fuckery that Win10 install went through and still refused to die. From older LTSC, to newer LTSC, to Pro, to repartitioning fuckup and magical resurrection. It deserves to live on.
 
Back