You are not logged in.
You need to boot the installed system and press "e" when the systemd-boot menu (with the "BunsenLabs" entry) shows up.
Offline
Bearded_Blunder wrote:frankly dd for Windows is more reliable than either
Yes, I already linked to that earlier in the thread
And yes, Rufus should work if "DD" [sic] mode is selected but I have grown rather bored of posting that particular gem
Apologies I only caught the reference to the Win 10 Linux Subsystem, missed the DD for windows reference.
Inadequate excuse "I've been drinking!"
Blessed is he who expecteth nothing, for he shall not be disappointed...
If there's an obscure or silly way to break it, but you don't know what.. Just ask me
Offline
You need to boot the installed system and press "e" when the systemd-boot menu (with the "BunsenLabs" entry) shows up.
I've done that and it still won't let me in! I've certainly had a time. Thanks so much for the help.
Offline
I'm not sure what you mean by "won't let me in", the init=/bin/bash kernel command line parameter should boot you to a passwordless root shell from which you can find the username (and create a new one if needed) and reset the password.
To summarise: press "e" with the boot menu entry for your installed system highlighted then add the parameter to the end of the options line so that it looks like this:
options root=/dev/sda2 ro init=/bin/bash
Then press <Return> to boot the modified entry.
Once in the root shell, remount the filesystem read-write:
mount -o remount,rw /
Find the username:
ls /home
If none are listed [1] the `adduser` command will create a new user.
Reset the user password with:
passwd $user
Replace $user with the actual username.
Once this is done, issue `reboot` and log in to the new system as normal.
[1] If there are no users then something went badly wrong with the installation and that should probably be investigated further.
Offline
Also, we could check the networking command outputs requested in this post if they are run from the live session to see how the addresses are assigned for the working connection.
I've never known networking to fail after a chroot so I would be interested to dig further 8)
Offline
Sorry I forgot to post my solution:
I reinstalled but went back and hit "Continue without bootloader" This allowed it to go through the "Add users and Passwords step". After that everything went well
Offline
^ OK, that's great, thanks for posting back.
If you wanted, you could change back to GRUB now by using:
sudo rm /boot/efi/EFI/BOOT/BOOTX64.EFI
sudo apt update && sudo apt install grub-efi-amd64
sudo grub-install /dev/sda
sudo grub-mkconfig -o /boot/grub/grub.cfg
The first `rm` command will be needed if you ever delete BunsenLabs because there is a chance that your motherboard will only boot that .efi loader, this would make it impossible to install & boot any other operating systems.
If you decide to instead stick with systemd-boot (it's what I use for my Debian systems) then consider removing the "/boot/efi" line from /etc/fstab (or adding "noauto" to the options) to prevent it from being mounted at boot — this will protect the delicate FAT filesystem on the EFI system partition.
The disadvantage of this approach is that the ESP must be manually mounted for the systemd-boot configuration files to be changed.
Offline