That worked
Sadly, nope. Still hangs.
Does it work if you boot the fallback image?
Nope, but something different. Now after long enough waiting after the same target basic system it will start spamming this.
Should hopefully give some insight.
you should be able to check the boot logs and see if it gives you some hints as to what could be going on.
I do see that you have the same webcam as me!!
I see something with systemd-cryptsetup trying to do something. Did you comment out this line in your grub config again
#GRUB_ENABLE_CRYPTODISK=y
Then regenerate your grub config again?
grub-mkconfig -o /boot/grub/grub.cfg
I saw you mention that in another similar post. It wouldn’t return anything, if I’m thinking of the same command.
I did, but forgot the generate. I’ll try again
Same result, bar it now being line 485. Same line contents.
Day two, going to just read through all the documentation I can to at least try understand what should be happening here. Thought occured to me though, I’m only mounting /mnt and /mnt/efi with /dev/nvme0n1p2 and p1 respectively when I liveUSB in and make changes. Should I be mounting boot to something too or does that not matter here?
That’s all you should have to mount because in your fstab there are only two file systems which were setup during the installation.
UUID=74E8-6578 /efi vfat defaults,noatime 0 2
UUID=ae3cb8f6-3d67-44a0-8de7-5090a5e016c5 / ext4 defaults,noatime 0 1
Well there goes that easy option. Hmm.
I’m also at this point wondering about the boot log. I know it’s making one now at least, though I’m not sure about getting to it. When I get to that last picture of boot attempts I can’t type anything.
I’ll setup a test vm with uefi boot and systemd-boot to see if I can convert it to grub.
1 Like
Thanks man. In the meantime, I found someone with what might be the same issue and the solution being this explanation:
The message that you ask about (
Reached target Basic System) is output by systemd when the basic system is booted – this can be followed by starting the GUI and various system services. See thebootup(7)man page for more information about the boot sequence.
Got the manual page up for it now https://man.archlinux.org/man/bootup.7.en
Read a further comment
The other virtual consoles are not usable at that point, because the step “Started Login Service” has not been reached yet. That’s why Alt+F2 won’t work.
That would explain not being able to get to the logs so easily.
Looking around some more, I’m seeing some people say it could be to do with the gpu in the gui booting, which I can somehow believe given my nvidia card has given me nothing but problems with my install so far.
One mentions a fix by changing AHCI to IDE, but I don’t really know what it means nor want to mess with it till I’m sure it’s something worth trying.
uefi boot seems to react a bit different on a vm, still trying to figure that out. From your screenshot it’s still stuck at loading your root partition, so the tty’s won’t work. If it was a gpu setting then it would have already tried loading the graphical environment and you would have been able to switch to a tty.
So useful for later, I have the the following set as a boot option for my Nvidia gpu, so you should probably set it in your grub config as well. but this won’t solve your current problem.
nvidia_drm.modeset=1
1 Like
And that just goes in the bottom of the default/grub file, yes?
As the last setting at the end: GRUB_CMDLINE_LINUX_DEFAULT
I just noticed this warning when regenerating my config
Warning: os-prober will not be executed to detect other bootable partitions.
Systems on them will not be added to the GRUB boot configuration.
Check GRUB_DISABLE_OS_PROBER documentation entry.
Looking into it, I don’t think it’s important to this, but I’m not going to pretend I fully understand it and thought it worth a mention. Especially since it seems to be a bit of a contentious option.
I do have a windows install on a separate drive, so it’s not completely irrelevant, but I don’t imagine that’ll affect this.
Tried installing and running os-prober since there seemed no harm in that. It returns
grub-probe: error: cannot find a GRUB drive for /dev/sdb1. Check your device.map.
Which is interesting. Relevant? I don’t know, but I’m just looking at whatever I can find and sharing the results in case any of you notice something wrong in it.