UEFI and Grub - 1st Boot fails; 2nd works

[Snowhog]

Since I'm not experienced with linux...Another requirement was that I must be able to use encryption from the get-go (I think it's important).

Why? Unless you do or are going to be operating your PC in a totally open environment -- people other than you will have access to your PC -- you don't need to have an encrypted /home directory.

[zeron00]

Why? Unless you do or are going to be operating your PC in a totally open environment -- people other than you will have access to your PC -- you don't need to have an encrypted /home directory.

It's common sense, in my opinion. You wouldn't leave your laptop unencrypted, would you? A stationary home computer is a bit more secure than a laptop, but it's still vulnerable. People other than you may get access to your computer even if you're keeping it at home. A burglar may get into your house (even if it's unlikely it's not impossible) or your computer can get seized by authorities (for example by a request from IFPI, or some other RIAA-like organization -- few people don't use torrent today) or some other unlikely thing may happen... It's not inconceivable. Better safe than sorry!

It's not just /home that is encrypted, but everything except /boot. I'm using dm-crypt/LUKS over LVM.

[Snowhog]

The level of security one incorporates should be balanced against the actual risk one can expect to encounter. I know SteveRiley will have more to say on that. But, to each their own.

[zeron00]

The level of security one incorporates should be balanced against the actual risk one can expect to encounter.

I agree! That's why I'm not using anything more advanced than this.
Opinions may differ on what constitutes "balance" in any specific circumstances. 4 years ago my computer was seized by the Swedish police because I downloaded music files. They had no trouble accessing my unprotected windows harddrive and the music found on it was later used as evidence against me at the trial. It's just one example of the "actual risks" that must be taken into account.

[SteveRiley]

Opinions may differ on what constitutes "balance" in any specific circumstances. 4 years ago my computer was seized by the Swedish police because I downloaded music files. They had no trouble accessing my unprotected windows harddrive and the music found on it was later used as evidence against me at the trial. It's just one example of the "actual risks" that must be taken into account.

Well, if you're using your computer for illegal activities, then I suppose encryption might be necessary. You didn't specifiy whether the music you downloaded was copyrighted, so I won't make any presumptions here. I know that many governments over-react and are wont to consider all forms of music download as crimes; alas, the subtleties of public domain and fair use tend to be overlooked or ignored.

It's common sense, in my opinion. You wouldn't leave your laptop unencrypted, would you? A stationary home computer is a bit more secure than a laptop, but it's still vulnerable. People other than you may get access to your computer even if you're keeping it at home. A burglar may get into your house (even if it's unlikely it's not impossible) or your computer can get seized by authorities (for example by a request from IFPI, or some other RIAA-like organization -- few people don't use torrent today) or some other unlikely thing may happen... It's not inconceivable. Better safe than sorry!

The reason Snowhog mentioned I'd have something to say with respect to encryption is because he's familiar with my typical recommendation -- and that's to avoid using it. I'm a security engineer, and I've concluded that encrypting home computers creates far more risk. Encrypted volumes are notoriously difficult to debug, they're fragile (relying, as they do, on a single easy-to-misplace key), and they do nothing to protect you from malware that can access your computer while running under your user account or as root.

Volume encryption is a useful defense against theft of a computer or hard drive (when the machine is hiberated or powered off, but not when sleeping or in standby). File encryption is a useful defense against interception of individual files in transit or at rest. If you feel encryption is important, don't encrypt the entire /home subdirectory but instead use a file encryption tool and encrypt only the files/subdirectories that make sense. This is a better way to approach risk mitigation.

It's not just /home that is encrypted, but everything except /boot. I'm using dm-crypt/LUKS over LVM.

I have zero experience with LVM and LUKS. So to the extent that your problems might be at least partially related to your use of these technologies, I won't have any guidance for you.

I understand this. Although it's nice when it's pretty! And when it's tuned and all the errors and other stuff that can cause problem has been dealt with I see no reason not to use the graphical boot.

The reason to always avoid graphical boot is this: when a boot fails, people immediately begin searching Google for clues. Invariably, they find suggestions that apply to older versions of Kubuntu or Ubuntu, or suggestions that apply to completely different distributions. They valiantly attempt a blizzard of command line activity without completely understanding what's going on. And then, when their systems are far more broken than before, they become frustrated and give up. Having a text-only boot all the time ensures that you're immediately informed not only when something goes bad, but also what went bad. It helps you guide you toward more immediate and proper troubleshooting.

I'm not implying that this is the problem in your case -- that you understand how to use these encryption tools displays you possess knowledge beyond an absolute beginner.

I mean graphical mode. As soon as I type in my passphrase (in the text mode) and press 'enter' a few lines of messages appear (too quickly to read) and graphical KDM login screen is suddenly there. I've switched from LightDM back to KDM because it looks better. But before I made the changes you suggested the 1st boot didn't get so far. It didn't even display the screen where I type my passphrase, much less the login screen.

I read about plymouth in this thread but I don't really understand what it is, except that it has something to do with the graphical boot. Could it be what was causing the problem in the first place? After all, I don't experience this problem with the text boot, only with the graphical boot.

The changes I had you make in post #6 should have resulted in a pure text-mode boot, without any automatic switching to graphical mode after login. Can you please verify the behavior you're seeting?

[zeron00]

I'm a security engineer, and I've concluded that encrypting home computers creates far more risk.

More risk than your sensitive data falling into the wrong hands?

Encrypted volumes are notoriously difficult to debug, they're fragile (relying, as they do, on a single easy-to-misplace key), and they do nothing to protect you from malware that can access your computer while running under your user account or as root.

Yes, difficult to debug. But nothing is perfect and some convenience must be sacrificed for the sake of security. As to the malware, that is not what encryption is for. For this kind of protection there are antivirus programs (not that they protect against all malware but they do protect against some). And as long as we're on the subject, I've seen some discussions about viruses and linux -- there are far fewer viruses attacking linux systems than there are for windows, and some people are of the opinion that it's not necessary to install antivirus software on linux, because even the viruses that are designed for it can't easily get acces to other parts of the system than the user's home directory. But other people say that since there are some malware for linux and since it's possible for a malware to gain control (using something they call "privilege escalation" -- I don't know what it is) it's still prudent to install an antivirus.

Volume encryption is a useful defense against theft of a computer or hard drive (when the machine is hiberated or powered off, but not when sleeping or in standby).

Yes, I know that the computer must be turned off for it to have any effect. But I don't know the difference between "sleeping" and "hibernating".

If you feel encryption is important, don't encrypt the entire /home subdirectory but instead use a file encryption tool and encrypt only the files/subdirectories that make sense. This is a better way to approach risk mitigation.

A good advice. But I don't know enough about linux to decide which files/directories are vulnerable and which aren't. Also, such solution creates extra work, since most applications aren't equipped to deal with encrypted files -- a file must be manually decrypted first, then modified, and then manually encrypted anew. And who knows how many breadcrumbs a program leaves behind.

I have zero experience with LVM and LUKS. So to the extent that your problems might be at least partially related to your use of these technologies, I won't have any guidance for you.

I understand and appreciate your effort. But I don't think that encryption is at fault here. An older installation that is similar to this one in everything is working fine with encryption. The difference is in UEFI. But I don't think that UEFI is entirely to blame either. More on it in a bit.

The reason to always avoid graphical boot is this: when a boot fails, people immediately begin searching Google for clues. Invariably, they find suggestions that apply to older versions of Kubuntu or Ubuntu, or suggestions that apply to completely different distributions. They valiantly attempt a blizzard of command line activity without completely understanding what's going on.

I tried to search google as well. But I didn't find any clues to my problem and, therefore, didn't attempt "a blizzard of command line activity".

Having a text-only boot all the time ensures that you're immediately informed not only when something goes bad, but also what went bad. It helps you guide you toward more immediate and proper troubleshooting.

This makes sense. Even though most people don't understand anything from the messages appearing on the screen during text-mode boot.

...that you understand how to use these encryption tools displays you possess knowledge beyond an absolute beginner.

Well, not an absolute beginner, but a beginner nonetheless. I actually tried to do manual encryption as it's described in several tutorials found on the net. I failed!

The changes I had you make in post #6 should have resulted in a pure text-mode boot, without any automatic switching to graphical mode after login. Can you please verify the behavior you're seeting?

Yes. I keep my computer powered off when I'm not using it, and so have had several reboots since I made those changes. The process takes me directly to graphical login screen (KDM) after I type my passphrase. I don't have to login in text mode and I don't have to start any graphical interface manually.


That article you linked to is interesting. I only understand parts of it but some of the thing in it caught my attention. Here's one (the emphasis is mine):

GRUB 2 also supports passing this graphical boot screen through to the kernel at boot time as a pre-initialized linear framebuffer ("set gfxpayload=keep"). This enables the Linux kernel to start up in the preferred graphics video mode, instead of the traditional behavior of starting up in text mode and modesetting the video output afterwards. This is used by default as of Ubuntu 11.04, unless the graphics hardware is blacklisted or the previous boot failed. In Ubuntu 11.10, this is also disabled in recovery mode.

And here is another:

In the default case, there is no video handling in the initramfs. [...] If cryptsetup is installed, however, as is the case whenever ecryptfs-encrypted home directories are selected at install time, framebuffer handling is included in the initramfs.

Both these passages seem relevant. Also, there are other parts of the article that feel like they're relevant, but I don't understand what is explained in them. And I don't know what to do with this information either.

[Guest]

similar problem here

Hi guys,

don't know if it's related to UEFI or not, but since last Moun-update, i have a very similar problem with my kubuntu 12.10. (nothing encypted)

first boot runs until writing Kubuntu 12.10 appears and the dots are working...
then text-console tty1 with login for machine.

hardware reset on case brings me to grub, where i can chose (ubuntu, ubuntu advanced, memtest etc.) if i go for ubuntu/kubuntu, then on the writing Kubuntu 12.10 with the dots appears something like i'm checking all files...
1-2 mins later restart back to grub, if i chose kbuntu again it starts normal.

so far i have done the adjustments to /etc/default/grub and the tty1 as mentioned above.


i've seen some messages while booting, if i was fast enough, it was something like winblinds - failure and while 12.10 (dots) something like kvm disabled by bios.

sorry for my bad english - if you can help: my knowledge with linux is, that i can follow orders which are given step by step

thx
ed

*edit* i switched back to former kernel and everything is working well so far.

[zeron00]

Update.

The upgrade to 13.04 has corrected this error.

The changes I had you make in post #6 should have resulted in a pure text-mode boot, without any automatic switching to graphical mode after login. Can you please verify the behavior you're seeting?

As soon as I upgraded to 13.04 the boot process started going in the way you expected: text login and no graphical interface until I type startx. After a while I decided to try the graphical login, so I undid the changes you advised in post #6 and voilà -- everything works as it should! With encryption and graphical login all the way.