Compare commits
30 Commits
a4300e9cae
...
main
| Author | SHA1 | Date | |
|---|---|---|---|
|
0cce1c4c0f
|
|||
|
065f9ec0a8
|
|||
|
8f0b54dfc2
|
|||
|
05d51dd5fa
|
|||
|
3659922494
|
|||
| c2527199dc | |||
| 78b51dc746 | |||
| ecd5e95fec | |||
| bd8634020c | |||
| 0fb485c969 | |||
|
d9065103e0
|
|||
|
aa3f8c2504
|
|||
|
d3e5b9a800
|
|||
|
f0dbaca87c
|
|||
|
91f34770c1
|
|||
|
06abe75055
|
|||
|
03c0db35d6
|
|||
|
bab0091893
|
|||
|
2cce75fd7b
|
|||
|
5393d68bf9
|
|||
|
1ba800207b
|
|||
|
92ee37573f
|
|||
|
7a44089e18
|
|||
|
eba0d35f98
|
|||
|
4133b18cca
|
|||
|
b9ce376b7f
|
|||
|
ec1cc58137
|
|||
|
30b9fe7514
|
|||
|
1a8f0f758f
|
|||
|
1d24911d98
|
93
Arch.md
93
Arch.md
@@ -3,5 +3,94 @@ tags:
|
||||
- Arch
|
||||
---
|
||||
|
||||
[[Setup]]
|
||||
[[Local Host Names]]
|
||||
- [Arch Setup](ArchSetup.md)
|
||||
- [Local Host Names](LocalHostNames.md)
|
||||
|
||||
## Package Management
|
||||
### pacman
|
||||
#### Info
|
||||
- The package manager for Arch distributions
|
||||
- Graphical Software Management tools are not compatible and the command line must be used
|
||||
- It's worth checking the [Arch News](https://archlinux.org/news/) before running an update, or if you have any issues with an update. The Arch maintainers will always put known update issues there and how to resolve them.
|
||||
- Due to the fast moving pace of Arch you should aim to update your system at least once per week
|
||||
- It shouldn't be a problem if you take longer, but it helps minimize risk.
|
||||
- It's usually smart to not do system updates right before you need the computer for an important task.
|
||||
- [System Snapshots](ArchSetup.md#bootable-system-snapshots) can help reduce this issue by having the option to just rollback
|
||||
|
||||
#### Usage
|
||||
- Packages are installed with `pacman -S <package>`
|
||||
- `pacman -Syu` will update all the software on your system
|
||||
- `pacman -Rs <package>` will uninstall a package and its otherwise unused dependencies
|
||||
- `pacman -Qdtq | pacman -Rns -` will remove orphaned packages (was installed as a dependency but not longer needed as one)
|
||||
- Check [this wiki page](https://wiki.archlinux.org/title/Pacman/Tips_and_tricks) for more tips
|
||||
|
||||
### pacnew
|
||||
Sometimes while updating you system you may get a warning about a ".pacnew" file being created.
|
||||
This is because when a package updates it's default configuration file but you have changed the current config file to something other than the default pacman cannot automatically replace it with the new one.
|
||||
|
||||
So will keep your current config as it is and create a `/path/to/config/file.pacnew` file wth the new config.
|
||||
|
||||
Since sometimes updates bring new features that need to be configured, you should address this right away:
|
||||
|
||||
|
||||
1. Run `vimdiff /path/to/config/file /path/to/config/file.pacnew` To view the differances between the files
|
||||
- This requires the `vim` package installed
|
||||
2. Edit the current config as needed to add what is missing, either directly in vimdiff or with your text editor of choice.
|
||||
3. Once you are happy you should delete the .pacnew file.
|
||||
|
||||
### yay
|
||||
- yay is a wrapper for pacman and uses pacman for normal package management
|
||||
- yay additionally will automate the proccess of installing and updating packages from the [AUR](https://wiki.archlinux.org/title/Aur)
|
||||
- It functions the same but `yay` is a shortcut for `yay -Syu` (to update the system)
|
||||
- Software from `aur` should not automatically be trusted (see below)
|
||||
- yay will ask if you want to "view diffs" when installing or updating, this is a quick way to check the pkgbuild and the differences to the new pkgbuild when updating
|
||||
|
||||
### Arch User Repository
|
||||
The AUR is a collection of packages uploaded and maintained by the Arch community, and not the offical Arch maintainers.
|
||||
It is a great resource as an easy way to install software not provided in the main Arch repos, but it is worth noting that anyone can upload anything, and there have been known cases of people uploading malware.
|
||||
|
||||
The nice thing is that the entire package format (known as the pkgbuild) is accessbale and human readable.
|
||||
This does mean that any issues are eventually caught, but as with any case of downloading software off the internet, sticking to well known packages with lots of eyes on them is usually a good idea.
|
||||
It is also a good idea to inspect the pkgbuild yourself, especially pay attention to the URLs within the file and ensure they are pointing to the correct place.
|
||||
|
||||
Packages in the AUR are not offically supported or considered by the Arch Maintainers when pushing updates, so if anything on your system will break from an update, it's more likely to be an AUR package.
|
||||
|
||||
## System Recovery
|
||||
### Snapshot Usage
|
||||
For setup see [Snapshot Setup](ArchSetup.md#bootable-system-snapshots).
|
||||
|
||||
When you preform a system update a snapshots should automatically be created.
|
||||
You can also manually create snapshots from the timeshift program.
|
||||
In either case they can be booted into from GRUB, or activated in timeshift (see below).
|
||||
|
||||
If you boot into a snapshot or otherwise want to use a snapshot, first open timeshift and `restore` the snapshot you want to use (or are booted into) and then reboot.
|
||||
This will properly restore the system to that snapshot.
|
||||
|
||||
### Chroot
|
||||
In the case where a system is no longer bootable, it is possible to access and hopfully repair the system.
|
||||
|
||||
1. Create an Arch or Endeavour install media (Endeavour media has the bonus of being able to open a web browser at the time time)
|
||||
2. Boot into the USB (you will need to disable secure boot if enabled)
|
||||
3. From the console run `lsblk` to get a list of device and partition names names (sda, nvme0n1, ect with a trailing number for the partition number)
|
||||
4. Determine your system partitions and mount them manually, in the case of Endeavour's btrfs install it would be done like so:
|
||||
1. `mount -o subvol=@ /dev/nvme0n1p2 /mnt` (adjust to your actual disk name if different)
|
||||
2. `mount -o subvol=@home /dev/nvme0n1p2 /mnt/home`
|
||||
3. `arch-chroot /mnt`
|
||||
4. `mount /efi` or `mount /boot/efi` depending on where your efi partition is
|
||||
5. Begin to fix issues.
|
||||
|
||||
### Possible Issues
|
||||
#### Broken GRUB
|
||||
Sometimes you GRUB install can get messed up or removed, most commonly from Windows overwriting it.
|
||||
|
||||
Note: replace `esp` with the location of your efi partition (commonly `/efi` or `/boot/efi`)
|
||||
|
||||
First check if `grubx64.efi` still exists under `esp/EFI/...`, if it does, either delete it, or skip step 1
|
||||
|
||||
1. Reinstall GRUB with `grub-install --target=x86_64-efi --efi-directory=esp --bootloader-id=GRUB`
|
||||
- If you are using secure boot with shim you will need to install GRUB with the needed modules per https://wiki.archlinux.org/title/GRUB#Shim-lock
|
||||
- Then remember to resign GRUB with `sbsign --key /path/to/MOK.key --cert /path/to/MOK.crt --output esp/EFI/BOOT/grubx64.efi esp/EFI/BOOT/grubx64.efi`
|
||||
2. Regenerate the GRUB config with `grub-mkconfig -o /boot/grub/grub.cfg`
|
||||
|
||||
#### Broken Kernel/initramfs
|
||||
If GRUB loads but the kernel or initramfs don't and snapshots are not available you can reinstall the kernel (and regernate the initramfs) with `pacman -S linux`
|
||||
|
||||
38
ArchSetup.md
Normal file
38
ArchSetup.md
Normal file
@@ -0,0 +1,38 @@
|
||||
Links:
|
||||
[Arch](Arch.md)
|
||||
|
||||
## Secure Boot
|
||||
If setting up secure boot with EndeavourOS, don't use the preset grub. do it from scratch.
|
||||
The wiki is wrong and your ${GRUB_MODULES} needs to be in ""
|
||||
### Steps
|
||||
1. [Install grub following the shim-lock info ](https://wiki.archlinux.org/title/GRUB#Shim-lock)
|
||||
- If you do not have any drives with a ZFS filesystem, you should exclude the zfs* modules (As they require the ZFS [DKMS](https://wiki.archlinux.org/title/DKMS) Module)
|
||||
2. Move `grubx64.efi` into the `esp/EFI/BOOT` directory and ensure is has that name.
|
||||
- `esp` being your efi directory, usually `/efi` or `/boot/efi`
|
||||
3. [Follow the steps to setup shim](https://wiki.archlinux.org/title/Secure_Boot#Set_up_shim) (shim with key), including the mkinicpio hook to automatically sign the kernel on update.
|
||||
- If you are using EndeavourOS, you will need to install `mkinitcpio` and uninstall `dracut` and `eos-dracut`
|
||||
4. [Generate the GRUB config file](https://wiki.archlinux.org/title/GRUB#Generate_the_main_configuration_file)
|
||||
- If you are wanting to dual boot, install `os-prober` and uncomment `GRUB_DISABLE_OS_PROBER=false` in `/etc/default/grub` then regenerate the config
|
||||
5. Enable Secure Boot and import your MOK.cer into shim's MOK list.
|
||||
|
||||
**Note:** If you ever re-install the GRUB `grubx64.efi` file (to get a newer version of GRUB for example), make sure to do so with the modules as described above, and you will need to re-sign the file with `sbsign`.
|
||||
|
||||
## Bootable System Snapshots
|
||||
### Setup
|
||||
**Note:** For the below to work Arch must be installed on a btrfs filesystem with seperate root (@) and home (@home) subvolumes. (This is the default for EndeavourOS when you select btrfs.) And you must be using GRUB as your bootloader.
|
||||
|
||||
1. Install the following packages:
|
||||
- `btrfs-progs` - Utilies for btrfs
|
||||
- `grub-btrfs` - automatically adds Snapshots to the GRUB menu
|
||||
- `timeshift` - creates and manages snapshots
|
||||
- `inotify-tools` - used by grub-btrfs to spot new snapshots
|
||||
2. Open timeshift and go through the setup, I recommend not including @home in snapshots.
|
||||
3. Run `sudo systemctl edit --full grub-btrfsd` and adjust the `ExecStart=` line to be `ExecStart=/usr/bin/grub-btrfsd --syslog --timeshift-auto`
|
||||
4. Enable grub-btrfs with `sudo systemctl enable --now grub-btrfsd`
|
||||
5. Install `timeshift-autosnap` from the AUR
|
||||
6. Edit the timeshift-autosnap config as desired, but be sure to disable it updating GRUB and that will conflict with `grub-btrfs`
|
||||
|
||||
Note: If you want Timeshift's scheduled shapshots to happen you need to either enable cron with `sudo systemctl enable --now cronie.service`. Or install `timeshift-systemd-timer` from the AUR and enable the timers with `sudo systemctl enable --now timeshift-boot.timer && sudo systemctl enable --now timeshift-hourly.timer`
|
||||
|
||||
### Usage
|
||||
See [Snapshot Usage](Arch.md#snapshot-usage)
|
||||
44
BootToWindows.md
Normal file
44
BootToWindows.md
Normal file
@@ -0,0 +1,44 @@
|
||||
# Setup Boot to Windows
|
||||
In a dual boot setup where the default boot is Linux, you may want to be able to directly reboot into Windows without having to manually interrupt your bootloader (like GRUB) or your UEFI boot priority.
|
||||
|
||||
## From Linux
|
||||
1. `efibootmgr` will be required, so install that from your distro's package manager.
|
||||
2. Create the file `/usr/local/bin/boot-windows` and put the following script into it: (source: Bazzite windows-boot script)
|
||||
|
||||
```sh
|
||||
#!/bin/bash
|
||||
# Look up the boot number for Windows in the EFI records
|
||||
boot_number=$(echo $(efibootmgr) | grep -Po "(?<=Boot)\S{4}(?=( |\* )Windows)" | head -n1)
|
||||
|
||||
# Check that Windows EFI entry was found
|
||||
if [ -z "$boot_number" ]; then
|
||||
echo "Cannot find Windows boot in EFI, exiting"
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Set the next boot to be Windows and reboot the machine
|
||||
sudo efibootmgr -n "${boot_number}" && reboot
|
||||
```
|
||||
3. Run `sudo chmod +x /usr/local/bin/boot-windows` to make the script executable.
|
||||
4. To let `sudo efibootmgr` run without needing a password add the file `/etc/sudoers.d/efibootmgr-config` with the following text: (source: Bazzite)
|
||||
```
|
||||
%wheel ALL=(root) NOPASSWD: /usr/sbin/efibootmgr
|
||||
```
|
||||
5. Optionally create a button in your desktop environment that will run that script when clicked.
|
||||
|
||||
Note: if running this script does work but you have to manually trigger a reboot, you may need to edit the last part of the last line to be `sudo reboot` instead of just `reboot`
|
||||
|
||||
## From Windows
|
||||
If you want to be able to reboot back into windows from windows without changing the boot order you will need to do the below:
|
||||
|
||||
1. Navigate to a Folder like your Documents folder or somewhere else out of the way.
|
||||
2. Ensure you have enabled viewing file extensions, and create a new "Text Document" but rename it to `reboot-to-windows.bat`
|
||||
3. Right-click on the file and Open in Notepad (or your text editor of choice) and add the following lines:
|
||||
```
|
||||
bcdedit /set {fwbootmgr} bootsequence {bootmgr}
|
||||
shutdown /r /t 0
|
||||
```
|
||||
4. Save and close the file, then right-click on it and `More Options -> Create a Shortcut` to it.
|
||||
5. Right-click the shortcut and click Properties. Then click `Advanced...` and check "Run as administrator"
|
||||
6. Click OK and OK to exit out of those menus.
|
||||
7. Rename that shortcut and move it as you please. When you run that shortcut you should reboot back into windows.
|
||||
@@ -4,43 +4,46 @@ tags:
|
||||
- Bazzite
|
||||
---
|
||||
|
||||
Make sure you can connect to the share using hostname.local. see [[Local Host Names]]
|
||||
## Important Notes
|
||||
1. Make sure you can connect to the share using hostname.local. see [Local Host Names](LocalHostNames.md)
|
||||
2. **If changing location of the scripts** you need to update the script name to match the path exactly
|
||||
3. Replace `<server-name>` everywhere below with the name of your server
|
||||
4. If running [Bazzite](Bazzite.md), becuase of how fedora immutable distros are setup you need to use `/var/mnt`. the actual path is `/var/mnt` and `/mnt` is just linked to it.
|
||||
|
||||
**if changing location of the scripts** you need to update the script name to match the path exactly
|
||||
|
||||
Create a file called `.tardis-creds` in your home dir and set it so it's only readable by you like before.
|
||||
## Create systemd mount file
|
||||
Create a file called `.<server-name>-creds` in your home dir and set it so it's only readable by you like before.
|
||||
Put
|
||||
|
||||
```
|
||||
username=tess
|
||||
password=tess`
|
||||
username=<username>
|
||||
password=<password>
|
||||
```
|
||||
|
||||
in the file
|
||||
|
||||
create the file `/etc/systemd/system/mnt-tardis.mount`
|
||||
create the file `/etc/systemd/system/mnt-<servername>.mount`
|
||||
(this will be mounted to `/mnt/<server-name>`)
|
||||
|
||||
In the file put the below:
|
||||
|
||||
|
||||
|
||||
```
|
||||
[Unit]
|
||||
Description=Mount SMB share Tardis
|
||||
Description=Mount SMB share <server-name>
|
||||
# We require network connection before proceeding.
|
||||
Requires=network-online.target
|
||||
After=network-online.target systemd-resolved.service
|
||||
Wants=network-online.target systemd-resolved.service
|
||||
|
||||
Mount] #
|
||||
[Mount]
|
||||
"What" is what will be mounted. ie our NAS SMB share
|
||||
What=//tardis.local/files
|
||||
What=//<server-name>.local/<shared-folder>
|
||||
# "Where" is where it will be mounted in the filesystem
|
||||
Where=/var/mnt/tardis
|
||||
Where=/mnt/<server-name>
|
||||
Type=cifs
|
||||
# Let the mounted filesystem be read/write-able
|
||||
# Let the mounted filesystem be owned by the 'tess' user/group
|
||||
# Use the specified credential file for the connection
|
||||
Options=rw,uid=<uid>,gid=<gid>,nofail,credentials=/home/**username**/.tardis-creds
|
||||
Options=rw,uid=<uid>,gid=<gid>,nofail,credentials=/home/**username**/.<server-name>-creds
|
||||
# Lets quit trying after 30 seconds
|
||||
TimeoutSec=30
|
||||
|
||||
@@ -54,44 +57,46 @@ They will probably both be 1000 (so `uid=1000,gid=1000`), but you can check wit
|
||||
|
||||
This is telling systemd how to mount your drive.
|
||||
|
||||
Now create the automount file `/etc/systemd/system/mnt-tardis.automount`
|
||||
## Create systemd automount file
|
||||
Now create the automount file `/etc/systemd/system/mnt-<server-name>.automount`
|
||||
In that file put:
|
||||
|
||||
```
|
||||
[Unit]
|
||||
Description=Automount SMB share Tardis
|
||||
Description=Automount SMB share <server-name>
|
||||
|
||||
[Automount]
|
||||
# Adjust mount location to match yours.
|
||||
Where=/mnt/tardis
|
||||
Where=/mnt/<server-name>
|
||||
|
||||
[Install]
|
||||
WantedBy=multi-user.target`
|
||||
```
|
||||
|
||||
## Test and Apply configuration
|
||||
Now we want to make the directory it will be mounting to
|
||||
`sudo mkdir /mnt/tardis`
|
||||
`sudo mkdir /mnt/<server-name>`
|
||||
|
||||
Then we reload systemd
|
||||
`sudo systemctl daemon-reload`
|
||||
|
||||
First we start the .mount, and check for errors
|
||||
```
|
||||
sudo systemctl start mnt-tardis.mount
|
||||
systemctl status var-mnt-tardis.mount
|
||||
sudo systemctl start mnt-<server-name>.mount
|
||||
systemctl status mnt-<server-name>.mount
|
||||
```
|
||||
Then if there's no issues we can stop the normal mount and enable automount
|
||||
|
||||
```
|
||||
sudo systemctl stop mnt-tardis.mount
|
||||
sudo systemctl enable --now var-mnt-tardis.automount
|
||||
sudo systemctl stop mnt-<server-name>.mount
|
||||
sudo systemctl enable --now mnt-<server-name>.automount
|
||||
```
|
||||
(`enable` means we are telling it to run on boot, and `--now` it telling it to also start it now)
|
||||
|
||||
We could just enable the normal mount and have it mount on boot, but automount will mean it will only connect to the samba drive when we try to access it.
|
||||
|
||||
now we should see it show up under `/mnt/tardis`
|
||||
Now we should see it show up under `/mnt/<server-name>`
|
||||
And if we reboot it should show up still.
|
||||
|
||||
## Additional Notes
|
||||
For reference Aiden based it off of [This](https://www.reddit.com/r/SteamDeck/comments/ymjnjy/mounting_smb_shares_with_systemd/) this post, just modified to this situation and me
|
||||
|
||||
if running [[Bazzite]], becuase of how fedora immutable distros are setup you need to use `/var/mnt`. the actual path is `/var/mnt` and `/mnt` is just linked to it.
|
||||
34
CreatingBootMedia.md
Normal file
34
CreatingBootMedia.md
Normal file
@@ -0,0 +1,34 @@
|
||||
# How to create an install media
|
||||
## From Windows
|
||||
1. Install [rufus](https://rufus.ie)
|
||||
2. Select the desired device **ensure it is the correct device, all data will be DELETED**
|
||||
3. On the right side click `SELECT` and select the desired .iso file
|
||||
4. Re-verify correct device and click `START`
|
||||
Note, for linux iso files select dd mode when prompted.
|
||||
|
||||
## From Linux
|
||||
### For linux .iso
|
||||
1. use `lsblk` or other methods to determine correct device, such as `sda`
|
||||
2. **Ensure it is the correct device, all data will be DELETED**
|
||||
3. Ensure the device is not mounted
|
||||
4. run `sudo pv -Y -o /dev/sda /path/to/iso` where `sda` is the desired storage device
|
||||
|
||||
### For Windows install .iso
|
||||
1. use `lsblk` or other methods to determine correct device, such as `sda`
|
||||
2. **Ensure it is the correct device, all data will be DELETED**
|
||||
3. Ensure the device is not mounted
|
||||
4. run `sudo wipefs -a /dev/sda` where sda is the desired device **all data will be deleted**
|
||||
5. Use a partition tool such as `cfdisk` to create 2 partitions, the first one will be 2GB big, the other will use the rest of the space.
|
||||
6. Assuming the disk is sda (replace to match yours) run
|
||||
- `sudo mkfs.fat -F 32 /dev/sda1`
|
||||
- `sudo mkfs.exfat /dev/sda2` exfat-utils may need to be installed
|
||||
7. Mount the iso file to access it
|
||||
1. `sudo mkdir /media/windows-iso`
|
||||
2. `sudo mount /path/to/iso /media/windows-iso`
|
||||
8. Mount both partitions
|
||||
1. `sudo mkdir /media/win-boot && sudo mkdir /media/win-data`
|
||||
2. `sudo mount /dev/sda1 /media/win-boot && sudo mount /dev/sda2 /media/win-data`
|
||||
9. Copy everything from `/media/windows-iso` **except** for `sources` folder to `/media/win-boot`
|
||||
10. Create a `sources` in `/media/win-boot` and copy over `/media/windows-iso/sources/boot.wim` into it.
|
||||
11. Copy everything from `/media/windows-iso/` into `/media/win-data`
|
||||
12. Unmount everything, USB should now function as a windows install media
|
||||
12
Debian.md
Normal file
12
Debian.md
Normal file
@@ -0,0 +1,12 @@
|
||||
---
|
||||
tags:
|
||||
- Debian
|
||||
---
|
||||
|
||||
## Package Management
|
||||
### apt
|
||||
- The package manager for Debian-based distros such as Ubuntu and Mint
|
||||
- Graphical Software Management tools such as KDE Discover and GNOME Software are compatible
|
||||
- Packages are installed with `apt install <package>` and uninstalled with `apt remove <package>`
|
||||
- `apt update` will pull the latest information to know what packages have new versions
|
||||
- `apt upgrade` will then update your system and installed programs
|
||||
48
Distros.md
48
Distros.md
@@ -3,16 +3,46 @@ tags:
|
||||
- Arch
|
||||
- Bazzite
|
||||
- Debian
|
||||
- Fedora
|
||||
---
|
||||
[[Arch]]
|
||||
- EndeavourOS
|
||||
## Distro List:
|
||||
### [Arch](Arch.md)
|
||||
- Installed from scratch, without an installer program
|
||||
- Rolling Release
|
||||
- The latest versions of software, drivers, ect possible available
|
||||
- Less time for changes to be tested, so more risk of breaking changes
|
||||
- Fixes are usually pushed out quickly
|
||||
- The [ArchWiki](https://wiki.archlinux.org/) is an amazing resource
|
||||
|
||||
[[Bazzite]]
|
||||
- Fedora
|
||||
### [Bazzite](Bazzite.md)
|
||||
- Fedora-based
|
||||
- Gaming focused
|
||||
- immutable OS
|
||||
- [Immutable OS](PackageManagement.md#immutable-os)
|
||||
|
||||
[[Debian]]
|
||||
- Server focused
|
||||
- Stable
|
||||
- Older versions
|
||||
### [Debian](Debian.md)
|
||||
- Stable Release
|
||||
- New stable release every 2 years and it thoughly tested.
|
||||
- Extremely resistant to breaking changes
|
||||
- A favorite for Servers due to this
|
||||
- Will never have the lastest version of any software
|
||||
- Security and Bugfix patches are still brought regularly
|
||||
|
||||
### EndeavourOS
|
||||
- Arch-based
|
||||
- Is nearly identical to Arch
|
||||
- Unlike Arch it has a nice installer to set the OS up for you
|
||||
|
||||
### [Fedora](Fedora.md)
|
||||
- Stable Release
|
||||
- New stable release every 6 months
|
||||
- Usually a good balance between something like Debian and Arch
|
||||
- Relatively recent software and well tested together
|
||||
- Commonly used for non-windows Enterprise Desktops
|
||||
|
||||
## Rolling Release vs Stable Release
|
||||
Rolling Release distros will package updates for any software and send it out to be updated on your system as soon as they determine it is good to go.
|
||||
|
||||
Whereas a Stable Release distros will accumulate new versions of software, testing them all together before pushing all the updates together at once and a new "version" of the OS.
|
||||
|
||||
For desktop use Rolling Release is perfectly good and can be nice in the sense you don't have to wait for a new version of your OS to get the lastest update for your software.
|
||||
But stable release distros have the advatage of getting more time to test to catch and fix any weird problems a new update may have.
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
the ability to use hostname.local is managed by avahi
|
||||
To use a configured avahi, avahi-daemon.service needs to be running and port udp 5353 needs to be open in your firewall
|
||||
|
||||
needs to be set up to [[Connecting to samba shares (tardis)]]
|
||||
needs to be set up to [Connecting to samba shares (tardis)](ConnectingSMBShares.md)
|
||||
78
PackageManagement.md
Normal file
78
PackageManagement.md
Normal file
@@ -0,0 +1,78 @@
|
||||
---
|
||||
tags:
|
||||
- Arch
|
||||
- Debian
|
||||
- Bazzite
|
||||
---
|
||||
|
||||
# Installing Software on Linux
|
||||
## Package Management
|
||||
### Windows
|
||||
In windows usually software is installed by going to that software's website, downloading and running the installer, and programs are responsible for keeping themselves up to date.
|
||||
### Linux
|
||||
In Linux you should almost always install software through an official repository. Usually the maintainers of a linux distribution will maintain an official repository of software (including everything from system libraries and utilities to graphical applications), that can be downloaded and installed.
|
||||
### Package Manager
|
||||
Instead of manually downloading, installing updating individual software packages, your system will have a Package Manager, which does exactly that.
|
||||
|
||||
You tell it what software you want, it'll download it and all its dependencies and install them. That also means you can tell your package manager to update and it'll manage making sure all your software is up to date, without programs have to individually manage it themselves. Traditionally you interacted with these package managers through the command line, but people have made graphical front ends for some of them, which allow you to browse and install software, and update your system through them.
|
||||
|
||||
#### Examples
|
||||
- ##### [apt](Debian.md#apt)
|
||||
- ##### [pacman](Arch.md#pacman)
|
||||
- ##### flatpak
|
||||
- Unlike other package managers, flatpak is built to work on any linux distribution and installs software entirely seperate from your system
|
||||
- Graphical Software Management tools such as KDE Discover, GNOME and Bazaar Software are compatible.
|
||||
- Flatpak programs can be installed system-wide or just for a single user.
|
||||
- There have been no known cases of malware from flathub, but the usual disclaimers of downloading programs applies.
|
||||
- Flatpak packages are often maintained by community members.
|
||||
- "Verified" only means that the developers of that software are the ones maintaining that package.
|
||||
|
||||
### Graphical Package Management
|
||||
There are a number of graphical programs that allow you to install, update and otherwise manage the software on your computer.
|
||||
|
||||
They still use your package manager to preform actions under the hood, but they provide a nice graphical interface to do so.
|
||||
|
||||
#### Discover
|
||||
Discover by KDE is the graphical software manager for KDE Plasma Desktop.
|
||||
|
||||
Adding Flatpak support and the Flathub software repository may be desirable for desktop users, especially on a distribution like debian where all the software tends to stay on older versions for the sake of absolute stability.
|
||||
There is also a number of programs that may not be packaged by your linux distribution, and may only be available through flathub.
|
||||
|
||||
You can add Flatpak support and the Flathub repository with the following steps (tested on debian 13):
|
||||
|
||||
1. Open Discover and select the Settings tab
|
||||
2. At the bottom under "Missing Backends" click the install button next to the "Integrates Flatpak Applications into Discover"
|
||||
3. Once the install is complete you can close and reopen Discover.
|
||||
4. At the top of settings you should now see "Add Flathub" on the top-right, if not log out and back in. Click this button.
|
||||
5. Log out and back in, or restart. You should now see flatpak apps, and have the option to install the flatpak version of exisiting apps.
|
||||
6. If you wish, under settings you can select "Make Default" next to Flatpak, to always install from flatpak when available.
|
||||
|
||||
Note: Flathub packages are not verified for usability or security by the debian maintainers. This is usually not any issue, but something to be aware of. See [above](#flatpak) for more info.
|
||||
|
||||
## Immutable OS
|
||||
There are now some Linux Distrobutions which are refered to as "Immutable"
|
||||
|
||||
What this means is that base system is a fixed, unchangeable thing. Which means you can't install software in the same way.
|
||||
|
||||
You can picture you system exisiting as 3 layers:
|
||||
### 1. System Layer
|
||||
The system is the base layer which includes all the software that runs your Operating Systems.
|
||||
In immutable systems, this layer is a fixed unchangeable thing.
|
||||
This means when you have a system update, the entire new system layer is downloaded and swapped in to replace your current one on the next reboot.
|
||||
- This ensures system updates are very clean, and it means the old system layer can be kept around, and used if there is something wrong with the new version.
|
||||
|
||||
Normally new software is installed directly to the system, but that is not possible in this case, since the System Layer cannot be edited. This is where the next two layers come from.
|
||||
### 2. Package Layer
|
||||
Usually software can be installed in the User Layer (see below), but sometimes software needs to be install onto the system itself, such as programs the interact directly with hardware.
|
||||
|
||||
In this case packages can be installed on top of the Base System in this layer.
|
||||
Packages installed here integrated tightly with the system and do add complexity, so if a program will work fine installed with other local options, then that should be chosen.
|
||||
But there are cases where this is the correct and best option.
|
||||
|
||||
On Bazzite programs are installed this way with `rpm-ostree install <package>`
|
||||
And it will install Fedora packages.
|
||||
|
||||
### 3. User Layer
|
||||
The User "layer" is everything that is installed and changed by each individual user and will all be contained to within their `/home/<username>` directory.
|
||||
For the most part in immutable systems, additional software will be installed here.
|
||||
Package managers such as [flatpak](#flatpak) (Graphical programs) and Brew (Command-line programs) will install programs locally.
|
||||
17
Setup.md
17
Setup.md
@@ -1,17 +0,0 @@
|
||||
Links:
|
||||
[[Arch]]
|
||||
|
||||
### Secure Boot
|
||||
If setting up secure boot with EndeavourOS, don't use the preset grub. do it from scratch.
|
||||
The wiki is wrong and your ${GRUB_MODULES} needs to be in ""
|
||||
#### Steps
|
||||
1. [Install grub following the shim-lock info ](https://wiki.archlinux.org/title/GRUB#Shim-lock)
|
||||
- If you do not have any drives with a ZFS filesystem, you should exclude the zfs* modules (As they require the ZFS [DKMS](https://wiki.archlinux.org/title/DKMS) Module)
|
||||
2. Move `grubx64.efi` into the `esp/EFI/BOOT` directory and ensure is has that name.
|
||||
3. [Follow the steps to setup shim](https://wiki.archlinux.org/title/Secure_Boot#Set_up_shim) (shim with key), including the mkinicpio hook to automatically sign the kernel on update.
|
||||
- If you are using EndeavourOS, you will need to install `mkinitcpio` and uninstall `dracut` and `eos-dracut`
|
||||
4. [Generate the GRUB config file](https://wiki.archlinux.org/title/GRUB#Generate_the_main_configuration_file)
|
||||
- If you are wanting to dual boot, install `os-prober` and uncomment `GRUB_DISABLE_OS_PROBER=false` in `/etc/default/grub` then regenerate the config
|
||||
5. Enable Secure Boot and import your MOK.cer into shim's MOK list.
|
||||
|
||||
**Note:** If you ever re-install the GRUB `grubx64.efi` file (to get a newer version of GRUB for example), make sure to do so with the modules as described above, and you will need to re-sign the file with `sbsign`.
|
||||
Reference in New Issue
Block a user