maximbaz/dotfiles

The "Configuring custom repo" part of install.sh doesn't work well.

1m-N00b opened this issue · 16 comments

1m-N00b commented

Hi. Your arch-secure-boot, yubikey-touch-detector and configuration (dotfiles) are very much what I'm looking for, so I tried them out in VirtualBox.

Process

  1. loadkeys jp106(Cuz im japanese)
  2. pacman -Sy git
  3. git clone https://github.com/maximbaz/dotfiles.git
  4. cd dofiles
  5. ./install.sh

Problem

I got an error as shown in the following image.
So I read the relevant part of install.sh and /mnt/var/cache/pacman/maximbaz-local is created in line 163.
The hostname was initially a test. So the process was passed to else, but it didn't work.
Then I set the hostname to maximbaz, but with the same error.

Enviroment

Host OS:Arch Linux x86_64
Virtualbox: Version 6.1.14

maximbaz commented

Hello! Glad you like them. Thanks for letting me know, unfortunately I'm not testing install.sh script as often as setup* ones, so I think in this case I simply got a typo. Could I ask you to try again now and see if you will have success now (you can use hostname test)?

I'm also curious how it will go with boot config on virtualbox, as I'm using direct UEFI boot, do let me know if you stumble on any other issues!

1m-N00b commented

Hi, thanks for the quick response. I missed it too, it took me a while to install package. Sorry for the delay.

Apparently, as you can see in this image.
arch-chroot doesn't work after making the secureboot key.

maximbaz commented

Do you have a picture of the error itself?

I'm thinking how to best handle this situation, there are two possible cases:

  • arch-secure-boot initial-setup failed because it couldn't enroll keys (so secure boot will not work)
  • arch-secure-boot initial-setup failed because it couldn't generate or add EFI file to boot (in which case even if install.sh can finish, you will not be able to reboot into a working OS

If it's just the first case, I think it's reasonable to make installation not abort, and let the user just fix secure boot afterwards.

But if it's the second case, then it's good that install.sh crashes, because you will not get a bootable OS afterwards anyway.

If you can test, please replace:

arch-chroot /mnt arch-secure-boot initial-setup

With:

arch-chroot /mnt arch-secure-boot generate-keys
arch-chroot /mnt arch-secure-boot generate-efi
arch-chroot /mnt arch-secure-boot add-efi
arch-chroot /mnt arch-secure-boot enroll-keys

And see on which step if fails. Only the last step is something you can fix later, so technically you can even make last step like this:

arch-chroot /mnt arch-secure-boot enroll-keys || true
1m-N00b commented

Sorry for the delay.

The output looks like this
The db.key doesn't seem to be working properly.
After that, I rewrote the part of install.sh like this, and when I tried to run it, I found an error on enroll.
So I'm going to try it without secureboot for now.

maximbaz commented

Thanks for confirming, exactly, just skip the enroll-keys for now and I will in turn update install.sh script to make sure that step is optional 👍

Do let me know if you experience any other strange things, or in general if you have any questions or feedback 😉

lamtt77 commented

Hi, thanks for awesome auto arch deployment scripts! I had the same issue with enroll-keys when testing with Esxi Vmware 6.7 (it said that user mode can not update efi variable) and already resolved by skipped that step (was not aware of || true option so patched arch-secure-boot instead. Now everything seems to be working well. Just a note that you could use pacserve to cache and speed up repo downloading process. It was a bit slow with maximbaz-repo.

A noob question: now I can see all of snapshots at /.snapshots folder. How could I test a previous snapshot? If I reboot, it will go directly to luks password authentication step and I could not find a way to trigger boot menu. Thanks.

lamtt77 commented

Please ignore my above question. I think that I figured out the issue due to my Esxi instance set Cdrom default to FS0 so the script recovery.nsh would fail to lookup available snapshots. This can be fixed by either 1) Change recovery.nsh or 2) Remove the Cdrom from that vm. After that just go to EFI shell and run recovery.nsh. Snapshot is so great :)

1m-N00b commented

I commented out the secureboot part and ran it, and the installation script worked, and I rebooted it as comment, but it didn't work. This is how it is recognized in the bootmanager,
I think the top CDROM is ArchISO and the second one was created.
but I cannot boot even if I select it.
I tried to boot on the Virtualbox except for ArchISO, but EFI Shell stands up with error!

maximbaz commented

Hey guys! I have pushed arch-secure-boot v1.2.3 which should contain the workaround for the secure boot thing.

@1m-N00b commenting out the whole arch-secure-boot initial-setup is not working because that command also configures proper boot EFI entries... But if you try now, I think install.sh should work for you without modification! Let me know if it doesn't.

@lamtt77 glad you like the scripts and managed to get a working setup! Could you give me a hint about pacserve? It seems like it will only help if you have a machine in your LAN with some packages already downloaded, but if you don't, then it will still require you to download the packages from internet?

Interesting catch about FS0, I didn't expect this, good to know, I added a quick note about this in arch-secure-boot README 👍

1m-N00b commented

Thank you for the change.
The installation itself went well.
But the release of /dev/sda1 fails like this.
Looking at install.sh, it looks like the first password is the luks password, but for some reason it doesn't work.
By the way, the password is 1 because it is a test.

I also considered the keymap discrepancies due to language differences, but the positions of the US(English) and JIS(Japanese) keys are the same.

I'll try again later. Good night

maximbaz commented

It's the same password that is being used for luks and for user (see here). Hmmm, I've never seen such error, and quick search doesn't reveal any easy hints... Consider maybe trying a longer password, like "helloworld"? I'm sure we will be able to get to the bottom of this! 😉

lamtt77 commented

@maximbaz Yes, pacserve uses mainly from within your LAN, though it could serve via public internet as well. In my case, my classic Arch i3 / Xorg / urxvt setup would run pacserve as detailed from Arch Wiki, and then:

  1. rsync your repo (maximbaz-repo) to pacserve-repo/maximbaz
  2. For any failed installation step (as the being mention enroll-keys issue), I would rsync all cache pkgs at /var/cache/pacman/pkg to pacserve-repo/pkg
  3. Add the following line to install.sh script (right before running pacstrap, and I would use this repo only for installation time):
    sed -i '1i Server = http://<YOUR_URL>:15678/pkg' /etc/pacman.d/mirrorlist

With that, I have reduced installation time to 5-6 mins (from 20-25 mins), very useful if you have any issues when updating the scripts. And pacman just simply move on to next server in the mirrorlist if your local pacserve repo does not have any pkgs.

The snapshot did immediately save me when I made a mistake of removing override file from sudoers.d. I was locked out totally because I did not setup root password yet. And current_snapshot - 1 worked really well!

Question: in the recovery EFI, how do you mount to your Btrfs volume in order to repair the above screnario in the event we do not have any working snapshots? Thanks.

  • 👍1
lamtt77 commented

But the release of /dev/sda1 fails like this.
@1m-N00b You may want to disable/remove YubiKey and USBGuard services and try again?

maximbaz commented

Thank you, very interesting idea with pacserve, I will play with it 👍

The snapshot did immediately save me when I made a mistake of removing override file from sudoers.d. I was locked out totally because I did not setup root password yet. And current_snapshot - 1 worked really well!

Cool, so you have already tested out the recovery procedure for real! Glad to hear that it worked for you! 🙂

Question: in the recovery EFI, how do you mount to your Btrfs volume in order to repair the above screnario in the event we do not have any working snapshots? Thanks.

Hmmm good question 🤔 I don't think you can do anything from recovery EFI shell itself, but you can recover if you are at least booted into initramfs, from where you can manually unlock LUKS and mount btrfs subvolume. I will check, I am pretty sure our recovery.nsh can be extended to have a custom cmdline, to boot into if all other hope is lost, will look into it when I get a bit of time 👍

lamtt77 commented

@maximbaz I have just tried and it was quite strait-forward, like it 👍

1) Boot with archiso
2) Run the following comands:
   cryptsetup luksOpen /dev/sda1 luks > Enter your password
   mount /dev/mapper/luks /mnt
1m-N00b commented

It's the same password that is being used for luks and for user (see here). Hmmm, I've never seen such error, and quick search doesn't reveal any easy hints... Consider maybe trying a longer password, like "helloworld"? I'm sure we will be able to get to the bottom of this! 😉

Sorry for late.
I was able to launch it successfully.
Thank you so much and good luck great dotfiles and some tool 👍