ArchLabs 2018.12 Release


and how to get it running if it isn’t.


Thank you AL-team for your great work with this release!
Even a Linux beginner like myself can use this distribution and learn a lot on the way. I use it because it is minimalistic yet configurable.


Glad that you like it @Signe


The ArchLabs installer works great (as I mentioned in earlier msgs). However, today I tried to install ArchLabs on my secondary SSD and the installer FAILS! I tried twice. With and without a separate /boot partition. The installer halts at “Installing and setting up grub in /boot”. It just hangs forever. I have no idea why. All seems to go well until this fade. Any ideas? @admins


I don’t think this is the case, lately with some recent updates to either grub, lvm, or something have caused grub-mkconfig to take a very long time when /run/udev and /run/lvm aren’t mounted in the chroot environment. Obviously we do this in the installer however sometimes the mounting fails for whatever reason.

Currently the installer only mounts these locations for UEFI systems, as far as I was aware grub on BIOS reads/writes to/from the MBR so I didn’t think they were needed.

When the above system mounts aren’t setup in the chroot it throws some warnings like

warning: grub-probe failed probing device '/dev/sdXX' - timeout after 10000ms

If you want to validate that this is what’s happening and see the timeouts as they happen, open /usr/bin/archlabs-installer and edit line ~2221

# change this line
chrun "${BCMDS[$BOOTLDR]}" 2>$ERR

# to this
chrun "${BCMDS[$BOOTLDR]}" # 2>$ERR

Once you make the edit run the installer again and run through as you normally would, now when you reach the bootloader install part it will spit out all it’s errors/warnings, if you could post what they are or a picture it would help me figure out what the issue is.

I’m certain that if you left it to finish, everything would be fine. That being said, it isn’t ideal to have to wait 10 seconds per partition to timeout during the final stages of the install.

Another solution would be to not choose grub, systemd-boot and syslinux are perfectly viable options that shouldn’t have this issue.

For example, here’s the setup for grub, syslinux and systemd-boot in the installer. You tell me which look less/more error prone

    # grub has by far the worst setup of the three however
    # the configuration is shorter due to grub-mkconfig


    if [[ $SYS == 'BIOS' ]]; then
        if [[ $BOOT_DEVICE == "" ]]; then
            select_device 'boot' || return 1
        BCMDS[grub]="${BCMDS[grub]} --target=i386-pc $BOOT_DEVICE &&
              grub-mkconfig -o /boot/grub/grub.cfg"
        if [[ $ROOT_PART == */dev/mapper/* && ! $LVM && ! $LUKS_PASS ]]; then
            luks_pass "$_LuksOpen" "" || return 1

        # the mount mess is needed for os-prober to work properly in the chroot
        BCMDS[grub]="mkdir -p /run/udev && mkdir -p /run/lvm &&
              mount --bind /hostrun/udev /run/udev &&
              mount --bind /hostrun/lvm /run/lvm &&
              ${BCMDS[grub]} --efi-directory=${BMNTS[UEFI-grub]} --bootloader-id=$DIST &&
              grub-mkconfig -o /boot/grub/grub.cfg &&
              umount /run/udev && umount /run/lvm"

    return 0




Thank you for this very informative text. Tomorrow I’ll try again with the suggested change in the installer. I’ll let you know what happens. You write you’re sure it would have finished in the end. Well, I waited more than 10 minutes and it still hung. On my first SSD everything works fine. We’ll see what happens tomorrow. Thanks again. BTW, both drives are MBR based.


Ok sweet.

Perhaps there is something else going on other than what I originally thought.


New user here, been trying to get ArchLabs installed on my laptop for a good portion of today; first issue was with the LUKS setup having an unspecified char limit and me trying to use an 80~ some char passphrase, resulting in unknown passphrase during encryption. Got by that with a smaller passphrase.

Second issue has been with software options, all I can make out in about a dozen attempts is if I pick something relying on kdebase-runtime (which was moved from Arch’s extra repo to the AUR about 4~ months ago) it fails to find the package and causes the rest of the packages to skip (including DE/WM), so the only thing installed ends up being core & base-devel packages.


Grabbbing the screen is a little difficult from the CLI, so I wrote down some of the messages I got.

  • failed to connect to lvmetad, falling back to device scanning
  • it starts scanning… /dev/sda1 /dev/sda2 /dev/sda3 /dev/sda4 /dev/sdb1 /dev/sdb2 etc…
    ALL devices are not initialized in udev database even after waiting xxx seconds
  • after this, it starts over, so it’s looping :slight_smile:

OK, I’ll do it the Arch way. I mounted the partitions manually, fstab was OK, I changed root (arch-chroot)
grub-install --target-i386-pc /dev/sdb2 did not work. "File system ‘ext2’ does not support embedding (I’m sure that the partition was formatted as ext4 and NOT ext2)
So I installed grub in the main MBR of /dev/sdb. that worked.
After this: grub-mkconfig -o /boot/grub/grub.cfg <-- the SAME LOOP; devices not initialized.

I guess that if I boot from a normal plain Arch USB I will be able to install grub.cfg
I might try this after this message. I thought you would like to know what happens.

UPDATE: plain Arch has the same problem. I cannot install grub on /dev/sdb2 and grub-mkconfig does not work either. On my main SSD (/dev/sda?) I run plain Arch


I see, my mistake.

For grub on BIOS (legacy boot) it only takes devices not partitions, because it needs to write to the MBR.

Yea, some recent changes seemed to have caused this.

Looks like you need to do the same mount mess in the chroot in order for it to complete, try this.

First before entering the chroot mount these

# using /mnt as the root mount for the system

# sometimes these don't exist in the live system
mkdir -p /run/lvm
mkdir -p /run/udev

# dirs we can access once chrooted
mkdir -p /mnt/hostrun/lvm
mkdir -p /mnt/hostrun/udev

# mount /run/lvm and /run/udev
mount --bind /run/lvm /mnt/hostrun/lvm
mount --bind /run/udev /mnt/hostrun/udev

# if all goes well, chroot in
arch-chroot /mnt

# same in the chroot
mkdir -p /run/udev
mkdir -p /run/lvm
mount --bind /hostrun/udev /run/udev
mount --bind /hostrun/lvm /run/lvm

# standard grub BIOS on /dev/sdb
grub-install --target-i386-pc /dev/sdb
grub-mkconfig -o /boot/grub/grub.cfg

# don't forget to unmount them before exiting the chroot
umount /run/udev
umount /run/lvm

# leave chroot

Let me know if this fixes the looping issue.

Arch install fails on "grub ... --target-i386-pc" , and boots into a grub prompt

The limit is 63 characters. I apologize that it wasn’t made clear.

I don’t think I’m alone in saying that a ~80 char passphrase seems like a bit much considering you’ll be entering it every boot (possibly twice).

Regarding the second issue, upstream packaging issues are out of our control.
If an official package (core, extra, community) relies on a package that no longer exists in the official repos like with kdebase-runtime then it should be reported to the packager upstream.


That’s insane. I agree with you @natemaia, I’m not sure I would want to type in a 63+ character pass phrase, even once. And forgive my ignorance of using luks, but don’t you have to use that same passphrase if you log out in order to get back to the DE? Just asking…

  • mount /run/lvm and /run/udev

  • mount --bind /run/lvm /mnt/hostrun/lvm
    -mount --bind /run/udev /mnt/hostrun/udev

  • if all goes well, chroot in
    arch-chroot /mnt

mount --bind (…) both don’t work. I forgot to write down the error msg. Sorry.
arch-chroot /mnt <-- /mnt is not a mountpoint ! (huh?) OK, never seen this.
I rebooted the plain arch usb stick, mounted the partitions in /mnt and /mnt/boot and followed your instructions again. This time it worked. No errors. grub-mkconfig gave some non fatal msgs but created the grub.cfg fine. It’s all a mess, really. ArchLabs installs perfectly fine on my main SSD. I give up. It’s not worth the hassle. Install went smooth as butter on /dev/sdb if I didn’t choose grub (syslinux). Thanks for all the extended information!


All is well, I simply installed afterwards without ticking any KDE/QT options in the installer. Just wanted to say something since I couldn’t find anything in the forums on why it was booting into a more-or-less base install without any packages.

As for reporting upstream, a little bit of digging showed that Arch has been dropping a lot of QT4 based packages, with kdebase-runtime being dropped all the way back in August. Other distros seem to have dropped these QT4 applications during install or continue to offer it by hosting in their own repos.

As for the passphrase, it’s just a typical password with an added short rhyme of less-than 10 words. It’s only during boot, takes less than 5 seconds and I’m only rebooting maybe 2-4 times a month since I usually just put my machine to sleep. I agree that 63 characters is plenty, but I would hardly call it insane or a bit much considering how humanly easy it is to remember and input a password like that, regardless of size. The advised keyfile size for LUKS is 512 chars for a little perspective.


I am far from a linux expert, but i much appreciate the AL CLI installer! Someone who is put off by a little reading and answering a few basic questions should probably take that as a sign they’d be happier starting with Mint or the like rather than Arch with a minimal desktop.

I liked the live startup, but good points have been made here. Without it i can install Openbox, etc with no other “leftovers.” I’ve tried others that used gnome or xfce as their live environment, selected my chosen DE and installed, only to find those “live” things i didn’t want still in my system.

Great work guys. The more i use AL, the more i see your reasoning and appreciate the work that goes into it!


I don’t know why someone would be. It’s not like we are asking for an essay to be written!! :smiley:

Thanks man!


With lots of requests concerning issues somehow on the last release, (any releases basically), I guess that inxi should be on AL iso by defaults, it would help pin point issues hardware related.

Just my 2 cents here.

From another recent post from another member, inxi can be installed on the AUR this way after updates in terminal;

sudo pacman -Scc
sudo pacman -Syyu
baph S- inxi


Installed. Finally. Let`s see how things work out, or not. :wink:


Well… Fingers crossed for ya, I suppose.


Hopefully it did.