View previous topic :: View next topic |
Author |
Message |
vik1 n00b
Joined: 21 Apr 2010 Posts: 14
|
Posted: Tue Jul 23, 2013 1:34 am Post subject: [Solved] EFI Boot with efibootmgr can't login |
|
|
I successfully booted Gentoo using my selection in the UEFI, but I get a login prompt that I can never login to. If I press enter I get a login prompt of "Welcome to Darkstar" which seems odd since I've named my machine something different. Then, if I try to login as root it just says password incorrect. Here's the steps I took:
- Booted into UEFI mode from an Archlinux USB.
- Ran parted, set the label to gpt, created a fat32 /boot partition for my EFI stuff, then my regular partitions.
- Pulled in gentoo-sources-3.10.1 and compiled with no initrd. make, make install, make modules_install, then copied the kernel binary to /boot/EFI/Boot/boot64.efi.
- Setup everything like normal but skipped the part for bootloader.
- ran
Code: | efibootmgr -c -g -d /dev/sda -p 1 -L "Gentoo" -l '\EFI\Boot\bootx64.efi' -u root=/dev/sda2 ro |
ran and noticed a BOOT0000 Gentoo...
rebooted and got a prompt I can never login to. I keep getting password incorrect after setting it multiple times from my rescue disk.
rebooted into Archlinux, mounted my drives, chroot'd, then noticed that there were no log files under /var/log. any ideas?
Last edited by vik1 on Mon Aug 12, 2013 3:25 pm; edited 1 time in total |
|
Back to top |
|
|
thoughtform l33t
Joined: 24 May 2004 Posts: 600
|
Posted: Tue Jul 23, 2013 4:27 am Post subject: |
|
|
why are you mounting root read only?
do you have any other .efi files in /dev/sda1? |
|
Back to top |
|
|
vik1 n00b
Joined: 21 Apr 2010 Posts: 14
|
|
Back to top |
|
|
thoughtform l33t
Joined: 24 May 2004 Posts: 600
|
Posted: Tue Jul 23, 2013 5:50 am Post subject: |
|
|
Did you specify your root option in the kernel stub loader? |
|
Back to top |
|
|
vik1 n00b
Joined: 21 Apr 2010 Posts: 14
|
Posted: Tue Jul 23, 2013 1:55 pm Post subject: |
|
|
No because when I created the EFI boot entry I passed in the root= method there. This is where I deviated from the uefi gentoo wiki guide because I did not want to hardcode my options. The point of this being that I can create a rescue entry in my UEFI where I pass "single" into my kernel options as well as the normal default entry. Mentioned here: https://wiki.archlinux.org/index.php/UEFI_Bootloaders#Using_efibootmgr_entry
The "-u root=/dev/sda2 ro" seemed to work OK when I print out efibootmgr -v, but maybe I need to try it like this: https://bbs.archlinux.org/viewtopic.php?id=147965. |
|
Back to top |
|
|
srs5694 Guru
Joined: 08 Mar 2004 Posts: 434 Location: Woonsocket, RI
|
Posted: Tue Jul 23, 2013 3:37 pm Post subject: Re: EFI Boot with efibootmgr can't login |
|
|
vik1 wrote: | [list]
[*]Pulled in gentoo-sources-3.10.1 and compiled with no initrd. make, make install, make modules_install, then copied the kernel binary to /boot/EFI/Boot/boot64.efi.
[*]Setup everything like normal but skipped the part for bootloader.
[*]ran Code: | efibootmgr -c -g -d /dev/sda -p 1 -L "Gentoo" -l '\EFI\Boot\bootx64.efi' -u root=/dev/sda2 ro |
|
I'm not sure what's causing your login problems, but your boot loader configuration is a sort of "belt and suspenders" approach that introduces some ambiguity about how you're actually launching the kernel:
- Most EFI implementations boot the EFI/BOOT/bootx64.efi boot loader as a fallback -- that is, if nothing else is entered in NVRAM, that boot loader is launched. This is useful in case the EFI is buggy or if the NVRAM entries are erased for some reason. Note that in this fallback configuration, options generally are not passed to the boot loader, so it's not a very useful way to launch a Linux kernel unless boot options are built into the kernel.
- Using efibootmgr to add a boot entry adds it to the NVRAM list. Using this method, you can add boot options, such as the options passed to a Linux kernel.
Chances are you're launching with those boot options via the second path, but it's conceivable that you're not; if your firmware is "amnesiac" and loses its NVRAM entries or if there's a typo or some other problem, the system might be booting via the first method. I recommend creating an EFI/gentoo directory and placing the kernel there with a more obvious name, such as "vmlinuz-{version}.efi". You should then be able to create an entry with efibootmgr. You should also remove the old entry that refers to EFI/BOOT/bootx64.efi, as well as that boot file itself. (Alternatively, you could put something else in the fallback position.) If you can't boot with the new name, then you know there's something wrong with your setup and it's trying to launch using the fallback path, in which case that might have been the case all along.
More broadly, using the EFI stub loader directly is a bit tricky. IMHO, it's better to start by using gummiboot or my own rEFInd. These are both boot managers that are easy to reconfigure. You can set boot options on a boot-by-boot basis, and they don't require boot options themselves, so even if you launch via the fallback filename, they'll work. Both launch kernels by using the EFI stub loader, so you can switch to that method once you work out how to do it with gummiboot or rEFInd, if you like. (IMHO, using gummiboot or rEFInd in the long term is preferable because it's easier to add new kernels, modify options on a boot-time basis, etc.) |
|
Back to top |
|
|
vik1 n00b
Joined: 21 Apr 2010 Posts: 14
|
Posted: Tue Jul 23, 2013 4:23 pm Post subject: |
|
|
Thank you for the information! It seems like it could be utilizing the fallback; I do not even have kernel logs under /var/log so that would definitely make sense. What's odd though is that when I tried passing root=UUID=..., the kernel panicked due to me not having an initrd and you know how the kernel team refused to implement this functionality w/o an initrd. When I changed it to root=/dev/sda2 the kernel no longer panicked so that seems to indicate that kernel was receiving the arguments I passed in. I'll try your suggestion and let you know how it goes...
Before attempting this method, I had read that there were various problems with kernel 3.10.1 and rEFInd on the Archlinux forums so I figured I'd try the more direct approach. Have you had any problems with rEFInd and this kernel version? Thank you for writing rEFInd BTW.
I compressed the kernel image with lzma compression. Do you think that might be the problem? If you want I'll paste my kernel config. |
|
Back to top |
|
|
DONAHUE Watchman
Joined: 09 Dec 2006 Posts: 7651 Location: Goose Creek SC
|
Posted: Tue Jul 23, 2013 4:57 pm Post subject: |
|
|
https://wiki.gentoo.org/wiki/EFI_stub_kernel which works, accurately states:
Quote: | For GPT systems, using root=PARTUUID=... might be preferable. To find out, you can use gdisk:
gdisk /dev/sda
Command (? for help): i
Partition number (1-5): 2
Partition unique GUID: (pass the ID that is shown here to the kernel)
Command (? for help): q
Note
The partition's UUID is distinct from the filesystem's UUID. |
_________________ Defund the FCC. |
|
Back to top |
|
|
srs5694 Guru
Joined: 08 Mar 2004 Posts: 434 Location: Woonsocket, RI
|
Posted: Tue Jul 23, 2013 6:24 pm Post subject: |
|
|
vik1 wrote: | Before attempting this method, I had read that there were various problems with kernel 3.10.1 and rEFInd on the Archlinux forums so I figured I'd try the more direct approach. Have you had any problems with rEFInd and this kernel version? Thank you for writing rEFInd BTW. |
I'm unaware of any problems with 3.10.1 (or anything in the 3.10 series) and rEFInd specifically; however, there have been problems with EFI stub loaders since 3.7. These problems are mostly confined to Lenovo computers, and they occur with a wide variety of boot managers (loosely defined), including rEFInd, gummiboot, EFI shells, and EFIs' built-in boot managers. These problems are sporadic and have proved difficult to diagnose. You're almost certainly not experiencing this problem, though, because the symptom is that the kernel refuses to boot -- once selected in the boot manager, nothing happens. This isn't the symptom you're experiencing. Of course, because of its sporadic nature, you might experience this symptom if you change your boot loader, but it's better to try and fail than to not try at all.
Quote: | I compressed the kernel image with lzma compression. Do you think that might be the problem? If you want I'll paste my kernel config. |
No, the problem is not your use of LZMA compression. If that were at fault, I'd expect the kernel to fail to boot at all. Your kernel is booting but you're experiencing problems once booted. That suggests either a configuration problem in Linux itself or a problem in passing the right options to the kernel (say, improperly telling it to use the wrong root filesystem). |
|
Back to top |
|
|
vik1 n00b
Joined: 21 Apr 2010 Posts: 14
|
Posted: Mon Aug 12, 2013 3:26 pm Post subject: Update |
|
|
I ended up just utilizing Grub2 since I was familiar with it. Problem solved. |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|