After some learning and with the help of the community I managed to get a tuxonice, systemd, efi stubbed version of gentoo to boot on a uefi-gpt machine with secureboot off. My current problem is that, at boot, I get a message:

4.927839 TuxOnIce no image found

which freezes for about 20 long seconds, before continuing and yielding me the password prompt. Now, I don't think this is normal -systemd is supposed to be fast, after all- so what does anybody has any idea on what I might have done wrong?

On a second note, I suppose I must leave secureboot set to off. Just to know, is there any way around this? What consequences might this have for security, if any?

EDIT:

I am also having problems with the wireless configuration. I configured support in the kernel, I copied the firmware iwlwifi-7260-7.ucode into /lib/firmware, I emerged dhcp and wpa-supplicant, I edited /etc/conf.d/net to:

I'm afraid I can't help you with your most immediate problems, but I can say something about this....

zongo wrote:

On a second note, I suppose I must leave secureboot set to off. Just to know, is there any way around this? What consequences might this have for security, if any?

Assuming your firmware supports Secure Boot, you can enable it with just about any Linux distribution, including Gentoo. (In theory; my Gentoo system's firmware doesn't support Secure Boot.) For information, I recommend you check:

My rEFInd Secure Boot documentation. This page describes how to set up Secure Boot with rEFInd specifically. It's therefore a little more specific than the previous page, but less applicable to boot loaders/managers other than rEFInd.

In brief, the process will be:

Install with Secure Boot disabled and be sure everything works.

Place a signed copy of PreLoader.efi or shim.efi file on the ESP, in the directory that holds your boot loader/manager. Also place the HashTool.efi or MokManager.efi binary in that directory.

If you use shim:

Prepare your personal Secure Boot key.

Sign your kernels and your boot loader(s) with your Secure Boot key. Note that, because of Gentoo's binary nature, you must sign these components. (If you were using a binary distribution like Fedora, these items could be signed by the distribution maintainer, which would simplify things.)

Copy your public key to the ESP.

Use efibootmgr (or bcfg in an EFI shell or bcdedit in Windows) to register PreLoader.efi or shim.efi with the firmware and set it as the default boot program.

Reboot. You should see HashTool.efi or MokManager.efi appear. Use it to register your boot loader(s), and perhaps your kernel(s) (PreLoader.efi/HashTool.efi) or load your Secure Boot public key into the MOK list (shim.efi/MokManager.efi).

Exit from HashTool.efi or MokManager.efi. At this point, the computer may reboot, hang, or continue into your boot loader/manager. When you reboot (automatically or manually), though, Secure Boot should be active and Linux should boot with it.

Note that this procedure is the simpler one that involves shim or PreLoader. It's also possible to replace the Microsoft keys in your firmware with your own local keys, in which case you can probably do away with shim/PreLoader. This task is more complex to set up, but it gives you extra protection in that if malware signed with the Microsoft key is ever released, and if you're using your own key instead, such malware won't run on your computer.

Note that there are differences in how the various boot loaders/managers work. For instance, the last I checked, gummiboot was useless with shim, but it worked fine with PreLoader. (This may have changed with post-0.2 versions of shim, though.) Some versions of GRUB 2 will boot only signed kernels, but other versions will boot anything, which partially defeats the purpose of Secure Boot. ELILO and (AFAIK) SYSLINUX will load any kernel, but rEFInd honors Secure Boot (and will work with either shim or PreLoader).

As to the security issues, Secure Boot is intended mainly to protect against pre-boot malware. Such malware can theoretically affect any platform -- for instance, it could set up a virtual environment (similar to Xen) that would be very difficult for an OS running in it to detect, then intercept I/O to gather data or damage the system. As a practical matter, though, I don't know how common such malware is, or whether any of it can be installed from Linux, so it could be that Linux-only computers are relatively safe. You might want to check with a security site to get an idea of how important this threat is. Of course, even if Linux is unaffected by such things today, that might not be true next week, next month, or next year.

Secure Boot's benefits can extend up the software chain, if the kernel and subsequent tools care to take advantage of it. For instance, a signed kernel might choose to load only signed kernel modules, which can protect the computer against malware in kernel modules. (An unsigned kernel could do the same thing, of course, but you can't trust an unsigned kernel, so what's the point?) I don't know of any real-world attacks on Linux that use compromised kernel modules, though. The last I heard, Fedora was taking steps to harden itself against such attacks, but most other distributions aren't doing this. AFAIK, there's no explicit support for this in Gentoo. I expect that such hardening will become more common as all the kinks get ironed out of the Linux Secure Boot support, but for the moment it's pretty rare.

Wow. You just blew me away. I need some time to fetch me the necessary background and chew on this. It is great to know that Secure Boot can actually be so useful. Oh, and thank you for your very detailed answer!

two things: not tux on ice but my gentoo stub kernel is significantly slower starting systemd compared to openrc with a long pause that provokes fearful expletives.
I was a coward and caved in and used networkmanager instead of gentoo scripts. Never tried the scripts with systemd._________________Defund the FCC.

two things: not tux on ice but my gentoo stub kernel is significantly slower starting systemd compared to openrc with a long pause that provokes fearful expletives.
I was a coward and caved in and used networkmanager instead of gentoo scripts. Never tried the scripts with systemd.

and I noticed that, after the message "TuxOnIce No Image Found" (which, according to the non-threatening color, is apparently not an error) there is an error message (bold, red, looking at me like Sauron's eye) regarding my wireless setup: "iwlwifi request for firmware file iwlwifi-7260-7.ucode failed".

So I am actually suspecting that this other message was the cause of the long boot delay, and connected with my other problem, the wireless setup. Now I will try to understand why the firmware, which I downloaded from here http://wireless.kernel.org/en/users/Drivers/iwlwifi iwlwifi-7260-ucode-22.1.7.0.tgz, unzipped and copied into /lib/firmware, is not detected. Maybe I have simply to change the name of the file?

EDIT
The firmware file name is correct. Do I have to set permissions in certain way?

I also considered using networkmanager, but then I still have to emerge gnome, for which I need an Internet connection. Which means that I would have to do that from a chrooted environment, but for some reason that does not feel kosher to me.

then keeps me up to date. I don't edit the firmware this installs which wastes some megabytes but caters to a tendency to experiment with hardware. Do you have the license?

Code:

ifconfig -a

what interface names appear? eth0 is the legacy (kernel) name for wired interfaces; wlan0 is the legacy (kernel) name for wireless interfaces; systemd/udev renames interfaces unless prevented from doing so

Code:

ifconfig

what interfaces are up?
best wpa_supplicant driver is -Dnl80211_________________Defund the FCC.

I did not copy the license (according to the wireless.kernel.org site I had the impression that this was redundant), and I used a wrong driver name - (-Diwlwifi... I misunderstood something there). Still, after the corrections, nothing.

It could be that one of the necessary drivers is not loading. I just realized that my newest laptop uses the same Wi-Fi chipset as yours. It's running Ubuntu, and I needed to compile a 3.12.6 kernel, include certain modules, and add the firmware file you mentioned. The output of that command on my system is:

If yours is lacking any of these modules, perhaps they haven't been built -- I had to activate one kernel module that wasn't being built by default. (I don't recall which one it was, though.) If that doesn't help, maybe you'll see some clues in dmesg, as in:

all the rest is unticked. From which I conclude that I have the iwlwifi, mac80211 and cfg80211 built in the kernel (and not as loadable modules) while iwlmvm, being the submodule required from the wireless chip we have, should shadow iwlwifi in kernel/module behaviour. Or at least I hope.

which is why I am puzzled - I manually copied the firmware file myself in order to get the latest available, because I read somewhere that the earlier version were appeared to be buggy.

I will try to compile the drivers as modules, and see what happens...

EDIT

ok, so I am flapping my penguin chick's wings in the right direction, albeit very clumsily (for a penguin).
After recompiling the kernel with the aforementioned drivers as modules, my boot process - which took ages before, because of the iwlwifi problem - now is blindingly fast. On the other hand, my lsmod did NOT change, and the dmesg | grep iwl is not returning ANYTHING at all. So I conclude that I am not loading those modules at all. Why?

'<M > Intel Wireless WiFi DVM Firmware support' may cause confusion; '[* ] enable powersave by default' was a problem years ago, may still be; '[*] cfg80211 wireless extensions compatibility' may be needed even though nl80211 is in use; rfkill may prove useful.
after building modules run

Code:

lsmod | wgetpaste

post the url returned. The results should fit with those reported by srs :

Quote:

iwlmvm
mac80211
iwlwifi
cfg80211
mac80211

if different, interesting ..
in the installed gentoo; run through modprobing each; if any are not present ... ;

Thanks to everybody who helped me with this. I am a newbie and the way is still long, but I can already say the satisfaction of achieving through understanding and with the help of the community is sweet. Now I can emerge natively and just have to compile GNOME...

EDIT

That was too early. Dhcp works, but resolv.conf does not get updated.
I see my gentoo machine on the wireless hot spot status, with an alleged ipv4 address, while ifconfig returns an ipv6 address.
Resolv.conf reads:

Code:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN

Which sounds like "ALL YOUR BASES ARE BELONG TO US". Dang, I supposed the DNS info would automatically fetched by the dhcp (I emerged dhclient). Is this a trivial mistake on my part, or a new systemd feature?