Install on a ThinkPad X13s

So I made an archiso installation media for the qualcomm-based ThinkPad X13s.
And the other day I saw someone got EndeavourOS ARM installer working on the M1, so I figured it would also work for the ThinkPad! It did actually work, with a lot of finagling :wink:

Here is my writeup which is a work in progress:

Here’s a Demo of me booting a GNOME install with the eos grub background: Booting EndeavourOS ARM on ThinkPad X13s - YouTube


real nice… congrats on this :vulcan_salute:

1 Like

Nice work. I am impressed.

If I remember correctly, you also have a PineBook Pro. How does the ThinkPad X13 compare to PineBook Pro as far as response. Is it as quick or quicker?

Anyway, congrats with your project.


Looked at your first URL. You have a github repository set up, a GPG key, the whole enchilada !

It is faster, better build quality, and pricier than the Pinebook Pro, it is benchmark much closer to a recent-gen i5, and I think running linux instead of Windows 11 ARM unlocks even more performance.


For my edification, in step 11.IV and 11.V the Archlinux “generic” image is downloaded and installed. I did not see where the linux-aarch64 kernel was changed to something else. Is the linux-aarch64 kernel used in the final OS ?

I also have a couple of suggestions for your process if you are interested. I didn’t just throw them out there in this post, as I did not want to appear to be critiquing your work.


1 Like

It’s not the final version for sure, and I am open to feedback good or bad :slight_smile:

To answer your question, linux-aarch64 does not work for the X13s yet as support is still being mainlined. For now one can install from my github pacman “repo” the linux-x13s package which should be drop in replacement.

1 Like

The first suggestion is the pacstrap command. Here’s why.

In steps 11.iv and 11.v a rootfs is downloaded from the Archlinux arm repository as


Which isn’t exactly what is wanted. Sounds like your change kernels and possibly more.

Then in step 12.viii you add more packages as

pacman -Syu base linux-x13s x13s-firmware grub git vim arch-install-scripts efibootmgr networkmanager network-manager-applet dialog os-prober mtools dosfstools base-devel

This can be accomplished in one fell stroke using pacstrap.
Once the storage device is created and mounted, then instead of downloading an image from Archlinux ARM and installing the image with bsdtar, pacstrap can be run to install necessary packages from a file list. Here is an example:

In line 61 of the script

pacstrap -cGM MP - < $(pwd)/build-configs/pkglist-rpi.txt

MP is a mount point for the storage device so you could substitute /dev/sdb (notice, no partition number) which would be a uSD or whatever partitioned and formatted to your specifications.

pkglist-rpi.txt is the list of packages to install.

Here is how I would create the package list.
Run your current process through Step 11 or however far it takes to just get a bootable rootfs.
Then boot the rootfs. log in as root. then

pacman -Q > pkglist.txt

This will yield a temporary list of every package in the rootfs and would look like this snippet

attica 5.106.0-1
attr 2.5.1-3
audiocd-kio 23.04.2-1
audit 3.1.1-1
autoconf 2.71-4
automake 1.16.5-2
avahi 1:0.8+r22+gfd482a7-1

Not usable because it contains the version numbers

awk '{print $1}' pkglist.txt > pkglist-x13s.txt

Now you should have a permanent file with all the files in the rootfs minus the version numbers.
Insert a fat 32 Thumb drive to the computer, mount it, and copy the pkglist-x13s.txt to the thumb drive.

In a computer with a full OS copy the pkglist-x13s.txt where it can be easily edited.

Now add all the packages listed in Step 12.viii to the pkglist-x13s.txt file and substitute the drop in kernel and kernel-headers and any other subtitutions.

Go through the steps again but use pacstrap to install the packages instead of downloading the Archlinux ARM Generic image.

Then at the appropriate place, create your image you put on github.

May take a little tinkering, but should be doable. Just look at man pacstrap and check which options to use.

Just food for thought.



thank you for the interesting tips. I will try it out when I get some more free time

1 Like

@Pudge one issue i am having with grub bootloader is that when i run grub-mkconfig -o /boot/grub/grub.cfg it does not add a initrd /initramfs-linux.img line in my menuentry; I have to add that line manually which is a pain. Maybe it has something to do with dracut which is something I don’t have experience with.

1 Like

So far, Archlinx ARM and EnOS ARM is not installing dracut by default. Just my personal opinion that dracut doesn’t gain much for ARM. Every image is set up for a Standard Hardware by device which doesn’t change. Every RPi 4b is like every other RPi 4b (not really, but the minor hardware changes between Hardware versions don’t enter into the picture OS wise).

On the x86_64 side of things. If you randomly choose 10 EnOS users and looked at the hardware differences, you would probably end up with 10 different hardware combinations. That is when dracut shines. Again, just my subjective opinion based on my Linux experiences.


1 Like

So I updated the write-up, here is the new link (wish I could edit the original post):

Updates include:

  • bootloader (grub) instructions
  • pacstrap instead of installing via rootfs
  • remove redundant instructions that eos installer handles
1 Like

Nice. I edited your OP with the new tutorial URL. Please check it to make sure I did what you wanted.

Next question. Are you using a storage device (such as a uSD card) to create the image on then make the image file from there?


I don’t understand the question. I just forked an version of aarch64 archiso for the x13s. I think this works because this laptop is UEFI compatible. No need for uboot here.

When you run pacstrap, what is the target, a storage device (such as a uSD) or to memory?
Then when you create your distributed image, the source file would be the results of pacstrap and other configuration, and the target would be an img.xz or tar.zst file for distribution.

I hope that makes sense.


I think I understand. Would one of those compressed files be useful for you in eos development?
Right now I am targeting a partition on my nvme so a storage device.

I was going to mention using loop devices, but if you are targeting a partition on a nvme device, I don’t think it would reduce the time of the process enough to matter. So as Roseannadanna on Saturday Night Live used to say, “Never Mind”.


1 Like

Found this issue when using sway edition. FYI @Pudge

I had to refer this to Joe as I do not have write access to the Community Editions.

The pull request has been committed.

Thank You for your input on this, much appreciated.


1 Like