Hello, ive been on AL 2018.1 for a while now and after i bumped into some issues with my SSD i got a new one and attempted to install a newer version of archlabs, both 2018.5 and 2018.6 that i found on Sourceforge. When i boot from the USB i am presented with the familiar GUI but everything is frozen and i have to go to a different TTY, log in as liveuser and kill the running X server and then it reloads and works. Now when i get around to installing all goes well until it installs GRUB and says i need to change a line in /etc/default/grub to yes, which it was put on just uncommented. I then generated the GRUB again but it seems that i just get thrown into Grub Rescue immediately. I am trying to install 2018.5 AL with fully encrypted root partition on an NVME M.2 SSD 128GB using a 512M EFI partition and the rest as ext4 root partition. Anyone know why i get the GRUB error?
EDIT: I also have a 8GB Swap partition.
It seems to work just fine when starting the install iso in VirtualBox. Would this indicate a hardware issue?
possibly, I’m not sure what the state of NVME boot is.
The issue regarding grub, do you get actual grub rescue immediately when booting (no menu)
If so you’ll need to reinstall grub, not sure if your familiar with
I also attempted to reinstall to a normal SSD so i dont think the NVME disk is the issue as i got the same problems there.
I booted up the live-USB again and mounted the encrypted root partition and the boot partition then used arch-chroot to poke around inside. the boot folder which the boot partition was mounted to only contained the EFI folder and not any GRUB folder. I then just doublechecked the cryptdisk option in /etc/default/grub was set to yes and ran grub-install and then grub-mkconfig to it ( with the instructions found on Arch Linux GRUB Wiki ).
Then after rebooting again i was presented with only a CLI view which said grub> and if i pressed tab it would show me alot of commands.
Yea that is indeed grub rescue.
During install, before mounting did you open the encrypted partition with the LUKS menu option?
I’m just wondering if that could even be the cause, apologies for lack of knowledge in this area, LUKS/LVM have been a problem in the installer off and on for some people and I have yet to find solutions (or even problems) for some
I did open it with the LUKS menu option in the installer yes. Can i find an installer log somewhere to see where it goes wrong?
Yes, the main log and answer files are
- /tmp/answer – storage for answers to each question (wiped with every question)
- /tmp/mopts – mount options
- /tmp/errlog – holds output from stderr or
2>/tmp/errlog (constantly checked by error checker)
- /tmp/log – hold bash xtrace output or
exec 3>| /tmp/log (only if
-d,--debug is used)
However your best bet is to use the
--debug option with the installer, this will also open a seperate terminal where the log will be tailed as you step through the installer, so you can check what variables, checks, etc. are set to.
To run it simply open a terminal and run
sudo /installer/installer -d
Afterwards, once finished the install, don’t reboot. Copy/Paste
/tmp/log and post either here, or some kind of fileshare. It’s a large file with mostly useless debug but I should be able to tell where it’s failing.
Would you be interested in just testing a new iso build? In the last bit I’ve set up and ‘unstable/testing’ repo and all the recent changes are there, including a large amount of work to the installer. If you are interested I can make a fresh build and link you and iso.
I have yet to push these changes live as not enough testing has been done, however a release shouldn’t be too far away
Sure i can test the new iso out! Just send me a link and ill get on it as quick as i can Will also post the debug and log results after in case something fails
Here is the link to the current testing iso, some minor bugs in the installer have been since building, but it will auto update before launching
Waiting to hear any issues,
As the first attempt failed at the mounting part of the install, i will now
freshly format the drive before starting the installer and see if it will make a
difference. Installer is begun with the -d option.
Process has gone as follows:
System Keymap: US
List devices to make sure it recognises my drive.
I then partition the drive using the automated partitioning, it created a 512M
partition and one 111.3G.
Listing devices reveal my device properly partitioned.
I pick LUKS Encryption using the automated encryption, selecting the 111.3G
partition which will be my root partition. For this attempt ill pick a different
name for the encrypted partition, for now ill just go for the name test and the
Encrypting worked without any issues. Pressing back to get out of the encryption menu does not work on the first try and i have to press it twice.
I verify that the encrypted partition is there and opened with the list devices menu option.
It shows up as /dev/mapper/test.
In the mount meny it shows up with the name crypttest, which i assume is what is
causing this process to go wrong. It adds crypt infront of what should only be
named test. I select crypttest and format it as ext4 with the no mount options. It
seems the formatter doesnt recognise whether or not the partition has been
formatted as it tells me the process is complete when the debug window shows its
used the wrong name for the formatting.
This step is impossible to get past, and encryption seems to be the issue here. I
can re-encrypt it with the name that the installer would recognise but it is an
issue that should be fixed as it breaks all installs needing encryption.
Here is a tiny part of the debug window.
- [[ -n ‘’ ]]
- return 1
- mount crypttest /mnt/install
- local errmsg=
- (( 0 == 1 ))
- return 0
- conf_mnt crypttest /mnt/install
- local part=crypttest
- local mntpnt=/mnt/install
- grep -q /mnt/install
- infobox ‘Mount Status’ ‘\nMount Failed!\n\n’ 0 0
And the formatting part.
- mkfs.ext4 -q crypttest
- local errmsg=
- (( 0 == 1 ))
- return 0
I assume the issue lies in the part of the installer where it detects encrypted partitions and automatically adds “crypt” infront of the name. After looking a bit at the installer code, without having a very large understanding of it, perhaps there is some wrong formatting at that part so instead of looking for a previously saved variable it puts in crypt instead?
Thank you for the detailed response, super helpful
A substitution of
crypt -> /dev/mapper/ in
find_pts() was failing, causing the partiton name to have
crypt prefixed to it.
The double return when trying to exit
luks_menu() was caused by
luks_show() calling back to the menu when it should just return cleanly.
Both should be fixed and I’ve done a minor version bump to the installer package so just closing the installer and re-opening should have it update, I’m just doing a test run myself right now but all seems well so far.
You can also view the commit here if curious
EDIT: After finishing install, not so great… dumped to grub rescue, will need to find out whats happening during the bootloader / mkinitcpio stages. Should be a simple fix once found, I have to get back to work, tonight I’ll throw full attention on it and fix remaining issues. Any more testing to find where the grub.cfg or mkinitcpio is failing is also greatly appreciated, regardless thank you very much for the help so far.
Will do some more testing tonight ! Guessing we are in different time-zones though as it is already 8:13 PM here
I seem to not be getting a GRUB menu at all… Just tries loading into other drives on my computer so will install Arch Linux real quick and see if the problem for that is my drive or GRUB, will edit this comment as i continue.
EDIT 1: I installed anarchy-linux ( previously Arch-Anywhere ) just to get it up fast and here GRUB works just fine. Will dig out the grub config files and the mkinitcpio file, plus the partitioning type and see if there are any differences.
EDIT 2: I dug out the grub folder from the boot partition, the /etc/default/grub and the /etc/mkinitcpio.conf. Gonna have a look over them now and see if i see anything standing out, but dont have a chance to compare it with the files from the ArchLabs install currently.
EDIT 3: The files can be found here https://drive.google.com/open?id=1sLwagsPvOI6_YZX1D9AYw5kFqz2lIKv_
When running through the installer i get to the point where i select the bootlader, GRUB, and when installing it the installer itself throws two lines on the top that it cannot find two files during a cp command. I am guessing it is these two files/commands its looking for. When checking the folder i can see that the files in question simply does not exist.
- cp -fa /mnt/install/boot/efi/EFI/Archlabs/grubx64.efi /mnt/install/boot/efi/EFI/Boot/grubx64.efi
- cp -fa /mnt/install/boot/efi/EFI/Boot/grubx64.efi /mnt/install/boot/efi/EFI/Boot/bootx64.efi
EDIT 1: I see now that it is attempting to copy files from the new bootfolder, to the same folder. Guessing that isnt how its supposed to act.
Believe the problem there is using
-a in the
I don’t think that’s the cause of this issue, that step copying the grub efi stub, is just a fix for some firmware that requires bootloaders to be in a folder called boot.
The problem persists, I need to work backwards from grub rescue as I’m not getting much from the debug log, but I’ve been tied up at work and doing a bathroom renovation at home so it will have to wait a couple more days.
Will keep posted and apologies for the delay
I was thinking of workarounds to install the new version for me… Today i reinstalled the 2017.12 version and was thinking, if i deleted everything in the root partition without formatting it, and then installed the 2016.5/6 onto that partition without formatting the working boot partition, would that work?
I have an update on my last post. I attempted my idea but it seems it didnt quite work out. I installed the previous version (2017.12) and then booted up a USB with the 2018.6 installer. After that i manually unlocked the cryptroot and mounted it to a folder i just named test. i then went into the test folder and did
rm -rf * and made sure everything was gone. This was done as to avoid reformatting the drive since that would change the UUID, effectively breaking the boot partition i gained from the 2017.12 install. After that i manually mounted the cryptroot to /mnt/install and updates the installer and skipped right on to the unpack archlabs step which told me it would unpack to
/dev/mapper/cryptroot and the bootloader to
blank. It unpacked quite nicely, told me a few directories and files didnt exist and then it finished up and i rebooted hoping it would work, but alas i was only given a message that it could not find the /new_root UUID and ended up with a
Apologies for the delays on this, last week I have been just swamped with work and doing a renovation on our house’s only bathroom so I haven’t been able to really do anything with regards to getting the installation issue fixed. This week I have much more time and should be able to get it all sorted and have a new testing package out.
Have you attempted a repair directly from grub_rescue/rootfs?
Thanks for bearing with the lack of progress
Hello again! I have been on vacation for a while now and just returned! How is the work on the bootloader going? I have alot of time for testing this weekend