diff --git a/docs/changing-init.md b/docs/changing-init.md index 438b1cd..c9aa14f 100644 --- a/docs/changing-init.md +++ b/docs/changing-init.md @@ -1,7 +1,7 @@ --- title: Changing init layout: default -nav_order: 9 +nav_order: 10 --- # Changing init on an installed system @@ -13,6 +13,14 @@ installation. > **Warning:** Switching init is for advanced users. In general, a fresh > installation is safer. Keep a bootable Artix LiveUSB handy in case > something goes wrong. +> +> OpenRC has known conflicts with Dinit on Antergos NeXT. If switching to +> OpenRC fails, the recommended course of action is to reinstall the ISO +> and use Dinit. A fresh install with Dinit is simpler and more reliable +> than troubleshooting a broken init migration. Tutorials on using Dinit +> are available on the Artix Linux wiki and in the Dinit documentation. + + ## Overview diff --git a/docs/ci.md b/docs/ci.md index 5a4a297..4a1d72e 100644 --- a/docs/ci.md +++ b/docs/ci.md @@ -1,7 +1,7 @@ --- title: CI/CD layout: default -nav_order: 6 +nav_order: 7 --- # CI/CD Pipeline @@ -48,6 +48,6 @@ Separate workflow in the [antergos-packages](https://github.com/Antergos-NeXT/an ## Safety notes -- CI does NOT run on push — only manual dispatch. This prevents accidental ISO floods. +- CI does NOT run on push — only manual dispatch. This prevents unintended ISO builds. - Internet Archive upload uses a unique identifier per run, so re-running CI won't overwrite a previous release. - Both `IA_ACCESS_KEY` and `IA_SECRET_KEY` must be set as repo secrets for the upload step to succeed. diff --git a/docs/desktop-environments.md b/docs/desktop-environments.md index f018063..edfe382 100644 --- a/docs/desktop-environments.md +++ b/docs/desktop-environments.md @@ -1,7 +1,7 @@ --- title: Desktop Environments layout: default -nav_order: 8 +nav_order: 9 --- # Desktop Environments diff --git a/docs/development.md b/docs/development.md index 228e19f..ea26ba6 100644 --- a/docs/development.md +++ b/docs/development.md @@ -1,7 +1,7 @@ --- title: Development layout: default -nav_order: 7 +nav_order: 8 --- # Development @@ -73,7 +73,17 @@ If `$COMPRESSION` is unset in `profile.yaml`, `mksquashfs` produces a sparse zer ### Calamares module precedence -`/etc/calamares/modules/` overrides `/usr/share/calamares/modules/`. Live-overlay online/offline directories override both. +`/etc/calamares/modules/` overrides `/usr/share/calamares/modules/`. The `calamares-next` launcher copies the online settings file to `/etc/calamares/settings.conf`, and the `modules-search: [ local ]` directive in that file resolves modules from `/etc/calamares/modules/`. Module configs placed in `calamares-online/modules/` are not used directly during installation — only `calamares/modules/` is consulted. + +### GRUB config overwrite must be enabled + +The Artix `grub` package ships a default `/etc/default/grub` file. When Calamares's `grubcfg` module runs during installation, this file already exists on the target system. With `overwrite: false`, the module reads the existing file and only modifies `GRUB_CMDLINE_LINUX_DEFAULT` and `GRUB_DISTRIBUTOR` — all other keys from the `defaults` block (including `GRUB_THEME` and `GRUB_TERMINAL_OUTPUT`) are silently ignored. + +The active configuration at `live-overlay/etc/calamares/modules/grubcfg.conf` **must** set `overwrite: true` to replace Artix's shipped defaults with the distribution's intended values. Without this, the installed system will use the bare Artix GRUB configuration with no theme. + +### `GRUB_TERMINAL_OUTPUT` must be "gfxterm" for themed GRUB + +Setting `GRUB_TERMINAL_OUTPUT: "console"` in `grubcfg.conf` forces GRUB into text mode and disables the graphical theme. The theme requires `GRUB_TERMINAL_OUTPUT: "gfxterm"` to render. ### Live-overlay is not overlay-mounted diff --git a/docs/dinit.md b/docs/dinit.md index 3769c99..88dc76f 100644 --- a/docs/dinit.md +++ b/docs/dinit.md @@ -7,9 +7,9 @@ nav_order: 2 # Dinit -**Dinit** is a modern init system designed for speed and correctness. Written in C++, it focuses on parallel service startup and dependency management without the bloat of systemd or the complexity of S6. **Dinit is the default init system in Antergos NeXT.** +**Dinit** is a modern init system designed for speed and correctness. Written in C++, it focuses on parallel service startup and dependency management. **Dinit is the default init system in Antergos NeXT.** -Dinit's design philosophy is to be a "better than OpenRC but simpler than S6" middle ground. It handles dependencies automatically (like systemd) but stays out of your way (like OpenRC). Services are defined in declarative config files, not shell scripts. +Dinit handles dependencies automatically through declarative configuration files, avoiding the complexity of shell-script-based service definitions. ## Key concepts @@ -55,7 +55,7 @@ depends-on = network ## Where services live - **System services**: `/etc/dinit.d/` (config) — enabled via symlinks in `/etc/dinit.d/boot.d/` -- **User services**: similar structure under user's config directory (for `dinit-user-serve`) +- **User services**: similar structure under the user's config directory (for `dinit-user-spawn`) - **Boot-enabling**: `dinitctl enable ` creates a symlink in `boot.d/` Service files use a simple key-value syntax. The `type` can be: @@ -119,15 +119,11 @@ Dinit's `add_user_svc_dinit` in Calamares attempts to create `boot.d/` symlinks On Antergos NeXT, `artix-pipewire-launcher` is patched to support dinit. If pipewire isn't starting, verify the launcher script at `/usr/bin/artix-pipewire-launcher` includes dinit in its supported init list. The XDG autostart entry at `/etc/xdg/autostart/pipewire.desktop` handles starting pipewire on login. -## Should you use it? +## When to use Dinit -Pick Dinit if: -- You want the fastest possible boot -- You like declarative config (INI-like syntax) -- You want automatic dependency resolution -- You're fine with a newer, actively developed init system +Dinit is suitable for users who want fast boot times and automatic dependency resolution without managing shell-script-based service files. It is the default init in Antergos NeXT and requires no additional configuration. -Stick with OpenRC if you prefer shell scripts and a longer track record. +Users migrating from systemd will find Dinit's declarative service files familiar. Users accustomed to OpenRC or Runit may prefer to switch — see [Changing init](changing-init) for instructions. ## Learn more diff --git a/docs/init-systems.md b/docs/init-systems.md index 1e0d064..1f3f876 100644 --- a/docs/init-systems.md +++ b/docs/init-systems.md @@ -1,17 +1,17 @@ --- title: Init Systems layout: default -nav_order: 3 +nav_order: 4 has_children: true --- # Init Systems -An **init system** is PID 1 — the first process that runs when your computer boots. It starts everything else: filesystems, networking, display manager, services. Think of it as a foreman: it doesn't do the work itself, but it makes sure everything happens in the right order. +An **init system** is PID 1 — the first process started by the kernel during boot. It is responsible for initializing the system: mounting filesystems, starting networking, launching services, and managing the display manager. All other processes descend from PID 1. -Antergos NeXT ships with **Dinit** as its default init system. The pages below describe the major init systems available on Artix Linux for educational purposes. If you want to switch init on an installed system, see [Changing init](changing-init). +Antergos NeXT ships with **Dinit** as its default init system. The pages below describe the major init systems available on Artix Linux. To switch init on an installed system, see [Changing init](changing-init). -## The inits +## Available init systems | Init | Philosophy | Complexity | Speed | Used by | |------|-----------|------------|-------|---------| @@ -20,23 +20,14 @@ Antergos NeXT ships with **Dinit** as its default init system. The pages below d | [Runit](runit) | Minimal, supervision-based, Unix-like | Low | Very fast | Void Linux, AntiX | | [S6](s6) | Full supervision suite, modular | Medium-High | Very fast | Artix, embedded systems | -## Choosing an init - -| If you want... | Pick... | -|----------------|---------| -| The fastest boot, automatic dependency resolution | Dinit | -| Something familiar, well-documented, simple | OpenRC | -| The simplest supervision-based approach | Runit | -| The most powerful non-systemd init with full supervision | S6 | - -## What they all have in common +## Shared characteristics - **No systemd** — all four are independent implementations -- **Service scripts** — services are configured via files in `/etc/` +- **Service files** — services are configured via files in `/etc/` - **Runlevels** — groups of services that start together under different conditions -- **Plain-text logging** — logs go to `/var/log/`, not `journalctl` +- **Plain-text logging** — logs are written to `/var/log/` -## Key differences +## Comparison | Aspect | Dinit | OpenRC | Runit | S6 | |--------|-------|--------|-------|-----| @@ -46,17 +37,6 @@ Antergos NeXT ships with **Dinit** as its default init system. The pages below d | Logging | None built-in | syslog | Per-service (optional) | Per-service (s6-log) | | Init script | None needed | `/etc/init.d/` | `/etc/runit/1/2/3` | s6-linux-init | -## Learning Linux with init systems +## Switching init after installation -If you're new to Linux, init systems are one of the best ways to understand how your OS works under the hood: - -- **Processes** — PID 1, service trees, process supervision -- **Boot order** — what needs to start before what -- **Dependencies** — why NetworkManager needs dbus, why dbus needs udev -- **Runlevels** — why your system behaves differently in single-user vs normal boot - -The best part? If you break something with services, you can always fix it by re-enabling or starting it manually. Service management is much simpler than kernel config or package management. - -## Switching init after install - -Artix provides a [switching init guide](https://wiki.artixlinux.org/Main/SwitchInit) that also works on Antergos NeXT. The process involves installing the new init's packages, configuring its services, and updating the bootloader. +See [Changing init](changing-init) for step-by-step instructions on switching to OpenRC, Runit, or S6 on an installed system. diff --git a/docs/installer.md b/docs/installer.md index 15242e5..e46ad5c 100644 --- a/docs/installer.md +++ b/docs/installer.md @@ -1,7 +1,7 @@ --- title: Installer layout: default -nav_order: 4 +nav_order: 5 --- # Calamares Installer @@ -72,6 +72,18 @@ Implemented as a separate `packagechooser` instance with `method: legacy`. "No D Custom branding lives in the `calamares-branding-antergos-next` package, installed to `/etc/calamares/branding/default/`. The `componentName` in `branding.desc` must match its directory name — this is enforced by Calamares (see `Branding.cpp`). +## GRUB configuration + +The installation sequence runs `grubcfg` before `bootloader`. The `grubcfg` module writes `/etc/default/grub` on the target system; the `bootloader` module then runs `grub-install` and `grub-mkconfig -o /boot/grub/grub.cfg`. + +The Artix `grub` package ships its own default `/etc/default/grub`. Because this file exists on the target at module runtime, the module's `defaults` block is only applied when `overwrite` is set to `true`. The `grubcfg.conf` at `live-overlay/etc/calamares/modules/grubcfg.conf` therefore sets `overwrite: true` to ensure `GRUB_THEME`, `GRUB_TERMINAL_OUTPUT`, and `GRUB_DISTRIBUTOR` are written. + +`GRUB_TERMINAL_OUTPUT` must be `"gfxterm"` for the GRUB theme to render; `"console"` disables graphical output and prevents theme loading. + +## Bootloader target detection + +The `bootloader` module auto-detects the GRUB target architecture using the system's EFI bitness and CPU type. For UEFI x86_64, it installs with `--target=x86_64-efi`. For Legacy BIOS boots, it falls back to `--target=i386-pc`. There is no configuration key to override this — a system booted in BIOS mode will always receive an i386-pc bootloader. + ## Launcher The `calamares-next` script (`/usr/bin/calamares-next`) handles the installer boot flow: @@ -81,4 +93,6 @@ The `calamares-next` script (`/usr/bin/calamares-next`) handles the installer bo 3. **Configuration** — copies `calamares-online/settings.conf` to `/etc/calamares/settings.conf` 4. **Launch** — runs `calamares` with the online config +During installation, the launcher monitors pacman activity and saves the package installation log to `~/pacman-install.log`. No terminal windows are opened to display progress. + Launched via the desktop entry in the live session: `Exec=sudo -E calamares-next`. diff --git a/docs/launcher.md b/docs/launcher.md index d37ebf8..e659ffe 100644 --- a/docs/launcher.md +++ b/docs/launcher.md @@ -1,19 +1,19 @@ --- title: Launcher layout: default -nav_order: 10 +nav_order: 11 --- # Calamares Launcher -The `calamares-next` script (`calamares-next.sh`) handles the installer boot flow. It's installed by `calamares-branding-antergos-next` to `/usr/bin/calamares-next`. +The `calamares-next` script (`calamares-next.sh`) handles the installer boot flow. It is installed by the `calamares-branding-antergos-next` package to `/usr/bin/calamares-next`. ## Boot flow -1. **Notice** — explains why the so-called "Offline Install" was removed (it wasn't actually offline) -2. **Welcome** — branded splash screen with an "Install" button -3. **Configuration** — copies `calamares-online/settings.conf` to `/etc/calamares/settings.conf` -4. **Launch** — runs `calamares` with the online config +1. **Notice** — displays a YAD information dialog explaining why the offline install mode was removed +2. **Welcome** — presents a branded splash screen with a single "Install" button +3. **Configuration** — copies `calamares-online/settings.conf` to `/etc/calamares/settings.conf` after removing any existing file (the removal is necessary to prevent `cp` from following symlinks) +4. **Launch** — runs `calamares -D8` with the online config; debug output is redirected to a log file at `~/antergos-install.log` ## Desktop entry @@ -25,9 +25,17 @@ Exec=sudo -E calamares-next `sudo -E` preserves environment variables (`WAYLAND_DISPLAY`, `XDG_CURRENT_DESKTOP`, etc.) when launched from the SDDM session. Without it, Calamares may not detect the display server correctly. +## Module config resolution + +The online settings file specifies `modules-search: [ local ]`, which resolves to the directory containing the settings file itself. After `SetConfig()` copies the file to `/etc/calamares/settings.conf`, modules are loaded from `/etc/calamares/modules/`. The `calamares-online/modules/` directory in the live-overlay is not used as a module source during installation — its contents exist only as a reference; the active module configs are those under `calamares/modules/`. + +## Pacman log capture + +During installation, the launcher polls for the existence of a pacman log file within the chroot (at `/tmp/calamares-root-*/var/log/pacman.log`). When detected, a copy is written to `~/pacman-install.log`. No terminal windows are opened to display installation progress. + ## Installer flow -The launcher shows a YAD info notice explaining the removal of the offline mode, then presents a branded splash with a single "Install" button. Calamares launches in online mode with the DE selector. +The launcher shows a YAD info notice explaining the removal of the offline mode, then presents a branded splash with a single "Install" button. Calamares launches in online mode with the desktop environment selector. ## Config switching @@ -43,8 +51,10 @@ The live-overlay includes `calamares-config-switcher.desktop` with `NoDisplay=tr ## Module configs -Configs live in `live-overlay/etc/calamares-online/modules/`: +Configs live in `live-overlay/etc/calamares/modules/`: - `packagechooser_dm.conf` — display manager selector using `method: netinstall-select` - `initcpiocfg.conf` — mkinitcpio configuration - `services-artix.conf` — service enablement via `artix-service` +- `grubcfg.conf` — GRUB default configuration (`/etc/default/grub`) +- `bootloader.conf` — bootloader installation parameters diff --git a/docs/openrc.md b/docs/openrc.md index 56411ed..effe22f 100644 --- a/docs/openrc.md +++ b/docs/openrc.md @@ -7,23 +7,20 @@ nav_order: 1 # OpenRC -**OpenRC** is a traditional init system used by Gentoo, Artix Linux, Devuan, Alpine Linux, and other non-systemd distros. It's proven, well-maintained, and about as simple as an init system can get while still being feature-rich. +**OpenRC** is a traditional init system used by Gentoo, Artix Linux, Devuan, Alpine Linux, and other non-systemd distributions. It is well-established, actively maintained, and provides a balance of simplicity and feature completeness. > **Note:** Earlier Antergos NeXT builds shipped OpenRC as an install-time option but it had issues with service enabling on installed systems. If you want to use OpenRC on Antergos NeXT, see [Changing init](changing-init) for manual setup instructions. -## systemd vs OpenRC at a glance +## Comparison with systemd -| | systemd | OpenRC | -|---|---|---| -| Philosophy | "One tool to rule them all" | "Do one thing well (Unix way)" | -| Logs | `journalctl` (binary logs) | Plain text files in `/var/log/` | -| Service mgmt | `systemctl start/stop/enable` | `rc-service start/stop`, `rc-update add/del` | -| Dependency | Parallel + automatic | Manual or explicit `need/use/before/after` | -| Config files | `.service` units (INI-like) | Shell scripts in `/etc/init.d/` | -| Size | ~80+ binaries, 500k+ lines | ~15 binaries, ~30k lines | -| Scope | PID 1 + logind + resolved + timedated + networkd + ... | Just PID 1 | - -OpenRC is used by Gentoo, Artix Linux, Devuan, Alpine Linux, and other non-systemd distros. It's not as mainstream as systemd, but it's proven and well-maintained. +| Feature | systemd | OpenRC | +|---------|--------|--------| +| Log storage | Binary journal (`journalctl`) | Plain text files (`/var/log/`) | +| Service control | `systemctl start/stop/enable` | `rc-service start/stop`, `rc-update add/del` | +| Dependency handling | Automatic, parallel | Manual (`need`/`use`/`before`/`after`) | +| Configuration format | `.service` unit files (INI-like) | Shell scripts (`/etc/init.d/`) | +| Binary footprint | ~80+ binaries | ~15 binaries | +| Scope | Init + logind + resolved + timedated + networkd + more | Init only | ## What changes for you as a user? @@ -70,28 +67,32 @@ Runlevels in OpenRC work like directories under `/etc/runlevels/`: └── shutdown # Shutdown services ``` -## Why did Antergos NeXT switch? +## Rationale for non-systemd -Three reasons: +Antergos NeXT uses Dinit as its init system. The switch away from systemd was motivated by three factors: -1. **systemd grew beyond an init system** — it now owns logind, resolved, timedated, networkd, homed, and more. It's no longer just PID 1. It's a full OS management suite with a scope that keeps expanding. +1. **Scope expansion** — systemd has grown beyond process supervision to include logind, resolved, timedated, networkd, homed, and other subsystems. This consolidates OS management into a single project with an expanding scope. -2. **systemd dropped SysV compatibility** — version 260 (March 2026) removed `systemd-sysv-generator`, `rc-local.service`, and all legacy compatibility code. If your distro isn't 100% systemd-native, it breaks. +2. **SysV compatibility removal** — systemd 260 (March 2026) removed `systemd-sysv-generator`, `rc-local.service`, and related legacy compatibility code, breaking distributions that were not fully systemd-native. -3. **systemd's age verification PR** — [#40954](https://github.com/systemd/systemd/pull/40954) (merged Mar 2026) added `birthDate` fields to userdb JSON for age verification compliance. Optional today, precedent tomorrow. We don't want our OS to ask for your age. +3. **Age verification (PR [#40954](https://github.com/systemd/systemd/pull/40954))** — merged March 2026, this added `birthDate` fields to userdb JSON for age verification compliance. While optional at the time of writing, the precedent raises concerns about future requirements. -OpenRC doesn't do any of that. It starts services and gets out of the way. +## When to use OpenRC -## Will things break? +OpenRC is suitable for users who want a well-documented, traditional init system with explicit dependency management. Its shell-script-based service files are straightforward to write and debug. Users migrating from Gentoo, Alpine, or Devuan will find OpenRC familiar. -Probably not. Most desktop software doesn't care about the init system. Browsers, editors, games, media players — they all work the same. +OpenRC does not include built-in process supervision. Users who want automatic service restart on crash should consider Runit or S6 instead. -Things that **do** care about systemd and won't work: -- `systemctl`, `journalctl`, `loginctl`, `timedatectl` — obviously -- GNOME (it dropped non-systemd support) -- Any `.service` file you try to run directly (they're systemd-native) +## Compatibility -But everything you actually use day-to-day? Works fine. And if you need to check logs, they're in `/var/log/messages` — plain text, no `journalctl` required. +Most desktop software is agnostic to the init system. Browsers, editors, games, and media players function identically regardless of what manages PID 1. + +Software that does depend on systemd and will not function: +- `systemctl`, `journalctl`, `loginctl`, `timedatectl` +- GNOME (dropped non-systemd support upstream) +- Native `.service` unit files (systemd-only format) + +Logs are written to plain text files under `/var/log/messages` and can be read with any text viewer. ## Learning more diff --git a/docs/overlays.md b/docs/overlays.md index 66ab2ad..6d12b87 100644 --- a/docs/overlays.md +++ b/docs/overlays.md @@ -1,7 +1,7 @@ --- title: Overlays layout: default -nav_order: 11 +nav_order: 12 has_children: true --- diff --git a/docs/packages.md b/docs/packages.md index f949299..c8c0636 100644 --- a/docs/packages.md +++ b/docs/packages.md @@ -1,7 +1,7 @@ --- title: Packages layout: default -nav_order: 5 +nav_order: 6 --- # Custom Packages diff --git a/docs/runit.md b/docs/runit.md index 843e764..580fde4 100644 --- a/docs/runit.md +++ b/docs/runit.md @@ -92,18 +92,11 @@ exec svlogd -tt /var/log/sshd | Boot speed | Fast | Very fast | | Complexity | Low | Low | -## Should you use it? +## When to use Runit -Pick Runit if: -- You want the simplest possible supervision system -- You like the daemontools model (one script per service) -- You want auto-restart on crash -- You're coming from Void Linux and want the same experience +Runit is suitable for users who want a minimal supervision-based init with automatic service restart on crash. Its service model (one executable `run` script per service) is straightforward and requires no dependency declarations. -Stick with OpenRC if: -- You need dependency management -- You prefer shell scripts with start/stop/status functions -- You want something more mainstream +Users coming from Void Linux will find Runit familiar. For users who need dependency management between services, OpenRC or Dinit may be more appropriate. ## Learn more diff --git a/docs/s6.md b/docs/s6.md index 96f9775..33ca8c6 100644 --- a/docs/s6.md +++ b/docs/s6.md @@ -104,19 +104,11 @@ s6-svc -u /run/service/sshd | Complexity | Low | Medium-High | | Flexibility | Moderate | Very high (modular) | -## Should you use it? +## When to use S6 -Pick S6 if: -- You want the most powerful non-systemd init -- You need dependency-based service management -- You like the idea of a compiled service database -- You value process supervision and auto-restart -- You're comfortable with a steeper learning curve +S6 is suitable for advanced users who want full process supervision with dependency-based service management and per-service logging. It offers the most features of any non-systemd init but has a steeper learning curve than OpenRC or Runit. -Stick with OpenRC if: -- You want something simple and well-documented -- You need shell-script-based services you can debug easily -- You don't need process supervision or dependency resolution +Users who need supervision, logging, and dependency resolution without systemd will find S6 the most capable option. Users who prefer simplicity may prefer OpenRC or Dinit. ## Learn more diff --git a/docs/system-requirements.md b/docs/system-requirements.md new file mode 100644 index 0000000..b070579 --- /dev/null +++ b/docs/system-requirements.md @@ -0,0 +1,39 @@ +--- +title: System Requirements +layout: default +nav_order: 3 +--- + +# System Requirements + +## Minimum + +- **CPU**: Any 64-bit x86 processor, 2 or more cores +- **RAM**: 4 GB (sufficient for desktop use with a web browser open) +- **Storage**: 30 GB available space +- **GPU**: OpenGL 2.0 capable integrated or discrete graphics +- **Display**: 1024×768 resolution +- **Firmware**: UEFI (recommended), Legacy BIOS supported + +## Recommended + +- **CPU**: Quad-core 64-bit x86 or better +- **RAM**: 8 GB +- **Storage**: 64 GB or larger SSD +- **GPU**: Any modern GPU with open-source drivers (AMD, Intel) or NVIDIA with proprietary drivers +- **Display**: 1920×1080 or higher, 16:9 aspect ratio recommended +- **Firmware**: UEFI + +## Notes + +### RAM usage + +A fresh KDE Plasma 6 session with the Antergos NeXT theme uses approximately 1.5 GB of RAM at idle. This accounts for the desktop shell, background services (NetworkManager, CUPS, Bluetooth, cronie, syslog-ng, pipewire), and the compositor. Opening a web browser adds roughly 500 MB–1 GB depending on tabs. + +### Display aspect ratio + +The default Plasma theme uses icon assets designed for widescreen displays. On 4:3 or narrower aspect ratios, some panel icons may clip. The GRUB theme (Layan) also targets 16:9 and may appear misaligned on narrower displays. + +### GPU acceleration + +Wayland compositing benefits from GPU acceleration. Systems without a supported GPU fall back to software rendering via LLVMpipe, which increases CPU load and reduces responsiveness. Install the proprietary NVIDIA driver from the Artix `system` repository if using an NVIDIA GPU. diff --git a/docs/wallpapers.md b/docs/wallpapers.md index cf3766a..4695ec6 100644 --- a/docs/wallpapers.md +++ b/docs/wallpapers.md @@ -1,7 +1,7 @@ --- title: Wallpapers layout: default -nav_order: 12 +nav_order: 13 --- # Wallpapers diff --git a/iso-profiles/antergos/live-overlay/etc/calamares/modules/bootloader.conf b/iso-profiles/antergos/live-overlay/etc/calamares/modules/bootloader.conf index 4413b38..f39e8dc 100644 --- a/iso-profiles/antergos/live-overlay/etc/calamares/modules/bootloader.conf +++ b/iso-profiles/antergos/live-overlay/etc/calamares/modules/bootloader.conf @@ -14,7 +14,7 @@ efiBootMgr: "efibootmgr" installEFIFallback: true -efiBootloaderId: "Antergos" +efiBootloaderId: "Antergos NeXT" # installHybridGRUB: false diff --git a/iso-profiles/antergos/live-overlay/etc/calamares/modules/grubcfg.conf b/iso-profiles/antergos/live-overlay/etc/calamares/modules/grubcfg.conf index c9da362..9c5dc68 100644 --- a/iso-profiles/antergos/live-overlay/etc/calamares/modules/grubcfg.conf +++ b/iso-profiles/antergos/live-overlay/etc/calamares/modules/grubcfg.conf @@ -1,7 +1,7 @@ # SPDX-FileCopyrightText: no # SPDX-License-Identifier: CC0-1.0 --- -overwrite: false +overwrite: true prefer_grub_d: false @@ -12,8 +12,9 @@ kernel_params: [ "quiet" ] defaults: GRUB_TIMEOUT: 5 GRUB_DEFAULT: "saved" + GRUB_DISTRIBUTOR: "Antergos NeXT" GRUB_DISABLE_SUBMENU: true - GRUB_TERMINAL_OUTPUT: "console" + GRUB_TERMINAL_OUTPUT: "gfxterm" GRUB_DISABLE_RECOVERY: true GRUB_THEME: "/usr/share/grub/themes/antergos/theme.txt"