Rapid Reads News

HOMEcorporateentertainmentresearchmiscwellnessathletics

User:0xMrRobot/Alienware m16 R1


User:0xMrRobot/Alienware m16 R1

This article describes how I configure my Arch Linux system for my gaming laptop. It has the following specs:

I will install Arch on the 2TB SSD with the following characteristics:

Save your changes, reboot and repeatedly press the to enter the one-time boot menu. Select your installation medium and boot from it. When the boot menu appears, select Arch Linux install medium.

The installation medium creates an Arch environment that runs in the computer's RAM, and you'll automatically be logged in as the root user. After logging in, you can unplug your USB drive.

In the new prompt, press to create a new partition. The program will interactively ask for more parameters. As an example, let's create the ESP:

Repeat the process for the root partition:

Finally, write your changes to the drive by pressing and confirming that you wish to proceed.

Before rebooting into my new system, I like to stay in the live environment a bit longer, in order to configure some things.

I do this because I never use them, since my fallback is linux-lts, and therefore the fallback initramfs is a waste of space in my case.

Since we're using UKIs, it's also possible to disable the generation of the files altogether, saving more space on the ESP. However, depending on the boot entries you might want to add, you can't remove them, so be careful.

Remember to edit the file paths to point to instead of .

First, ensure the configuration directory exists:

Then, add new configuration files, as desired. A few examples are listed below. The represents a value that you must get with the command within the parenthesis and manually substitute in the file (run the commands as root).

No boot entries are required, since we are using UKIs, which systemd-boot automatically recognizes.

However, you may wish to create boot entries for other purposes. Some examples can be found in my GitHub repository.

This setting will take effect after rebooting. If you want it to take effect immediately, run:

I reboot now because having a GUI will make the next steps much easier to follow.

After rebooting, repeatedly press the key to enter the firmware menu, go to Boot configuration and put systemd's entry at the top of the boot order. Save the changes and exit.

After logging in with your regular user account, connect to the internet and launch Plasma manually from the CLI.

Then, choose and install an AUR helper (I personally like yay):

systemd-boot will automatically create a new entry if an EFI binary is present at . To automate the creation and removal of this file in the ESP, you can use the following pacman hooks.

Flatpak can automatically detect installed packages that are no longer required. Periodically run the following command:

A GUI system monitor (Mission Center) was already installed, but it's also good to have one with a TUI. I like btop.

My personal bash_profile configuration can also be found in my GitHub repository.

Make sure only root has any access to this directory:

By default, shim will try to load an EFI file named . Although this can be overriden, it is more foolproof to rely on this default. Create the following script:

Remember to make it executable.

Edit and add the instruction below to automatically run this script after every systemd-boot upgrade:

sbctl will automatically keep track of signed files via pacman hooks. Import your custom keys and GUID:

By default, DKMS uses a MOK that it creates after installation. Create the following file to override this behaviour and make DKMS use your MOK instead:

This procedure allows the modules built to be loaded when restricted module loading is enabled. To verify if a module is loaded, you can use lsmod(8) or modinfo(8).

I personally use the manual method. First copy the keys into the ESP:

2. Add your custom key by navigating through the ESP;

Previously, I used a script loaded by , but I was having trouble with a logic race at login after configuring my windows VM with GPU passthrough (explained later in this page).

You need to perform the steps listed here before proceeding with any undervolting.

This setting is inside the "hidden" firmware menu. To access it, follow the steps below:

The details of the functions used can be read in Section 4.18 of the NVML API documentation.

This opens a new file with a text editor. Copy the contents below and save the file:

Run the script manually and test your configuration. Only after verifying that your system is stable (e.g. Heaven doesn't freeze/crash, no graphical glitches appear, etc.), enable the service so the settings are applied after every startup, if desired.

3. Configure dynamic hugepages to improve performance;

Remember to also configure the fstab.

In my case, the hugepage size is 2048 kB (2 MB), which is the default. Since I want to allocate a maximum of 16 GB to my VM, 16384 / 2 = 8192. I'll round up to 8200.

My CPU has 8 P-Cores (2 threads each) and 16 E-Cores (1 thread each). I allocate half of each group to the VM. My XML configuration for the VM looks like this:

Now, for maximum performance, I isolate these cores from the host, so they are exclusively used by the VM. For this, I used this solution:

7. Install windows;

Even though I don't do this anymore, I'll keep this section to host things I learned/found interesting that are specific to Windows.

Since Windows has a superiority complex, during installation it will create a boot entry in the firmware and place it as the first option. To fix this, wait until the installation is complete, reboot into the firmware and put systemd-boot as the first option again.

If you followed these instructions so far, then you are installing Windows after installing Arch. So, even though Windows is installed in a separate drive, it will use the ESP created during the installation of Arch. This is not necessarily a bad thing: systemd-boot will automatically create an entry for Windows because of this.

However, if you prefer to keep the 2 OS's completely physically separate (which isn't a bad idea), then boot into Windows, create a new ESP in Windows' drive and create new boot files with . This video by Chris Titus Tech shows how to do so. The TL;DW of it is:

1. Reduze Windows' partition size by ~128MB;

2. Use the freshly made empty space to create a new partition;

6. Unmount (unassign the letter of) the partition, so Windows doesn't remount it after rebooting;

7. Boot into Arch and delete the files added by Windows to Arch's ESP.

If you created a new ESP for Windows, you can use the same logic to mount it on Arch as well (I used as an example mount point):

The following stable voltage settings were discovered by empirical testing, using MSI Afterburner and this method.

Install Intel XTU. If it complains about VBS being turned on, disable it by opening , going to Local Computer Policy > Computer Configuration > Administrative Templates > System > Device Guard, double-clicking Turn on Virtualization Based Security, selecting Disabled, saving and rebooting.

After configuring all the settings you want, click the Save button and create a new profile, e.g. Undervolt. Then, go to Profiles, select your newly created profile and export it. A file will be created. If XTU for some reason changes the values for your settings, go to Profiles, select your profile, click Show Values and click Apply.

The voltage settings below were discovered by empirical testing, using Cinebench to stress the CPU. Other settings, like frequency and power limits, were based off of the official Intel specifications. Settings that I also changed in the "hidden" firmware menu are written in bold.

Test your system to check if it's stable or not. Only after doing this you should save and apply your settings permanently.

Even though XTU has an option in its settings to apply the settings across reboots, it might not automatically launch.

If this happens to you, there are a few solutions, presented here. Before using any of them, enable the Watchdog Timer in the firmware and check the Restore tuning after reboot box inside XTU's settings menu.

1. Using Windows Services

Press Win + R, run , look for , open its Properties tab and change the startup behaviour to Automatic (Delayed Start).

2. Using shell:startup

If the 1st solution isn't enough, press Win + R, run , copy or create a shortcut for the XTU executable and put it inside the folder that opened. This will force it to launch after every boot.

The downside of this method is that it launches the GUI, not just the background task, and you have to manually close it every time. But after doing so, XTU will run in the background, with your settings applied.

Windows is already pretty bloated on its own, and even though this laptop has plenty of computing power, that's not an excuse to add even more crap into the system.

This software is completely unnecessary. Instead of installing it, consider using AlienFX Tools (it can do more than AWCC, while occupying hundreds of times less storage space, literally).

Users of Windows Pro and above can use Group Policy to, among other things, run scripts at startup and shutdown time. This allows running a script that empties a specific folder automatically, similar to on Linux.

3. Go to Local Computer Policy > Computer Configuration > Windows Settings > Scripts (Startup/Shutdown) > Shutdown > Add > Add a Script > Browse. Close the File Explorer tab that just opened. This creates the folder, where the script will be stored;

4. Open Notepad as admin and create the following Batch script:

5. Follow Step 3, but instead of closing the Explorer tab, select the script, press OK and then press Apply. Test the script by saving unimportant data to the folder and rebooting.

This is necessary if you wish to boot your installation under Linux as a VM with QEMU/KVM. You can download the latest version from here.

Previous articleNext article

POPULAR CATEGORY

corporate

4923

entertainment

6155

research

2993

misc

6055

wellness

5040

athletics

6287