Hacker News Reader

Comment by aiur3la | Hacker News Reader

> ... I find the boot time compelling enough (~23sec until login, plus 2sec to open the browser) that I do not need this.

I think something is slowing down your boot, I get faster boot on a 2008 thinkpad running the same OS.

OT: systemd was supposed to improve boot performance but it has actually become much worse. Upstart on a weak chromebook boots in under 2 sec, why shouldn't your current generation thinkpad with a fast SSD match that?

View on HN

I find it curious that you care about boot-times. I use macbooks and just close and reopen the lid. Waking from this sleep takes less than a second usually.

My average uptime is about 22 days until I reboot for an update or something.

I used Linux for years, and I understood that in 2008 sleep/resume on notebooks didn't properly work, but now we have 2017 - 9 years later!

I don't really care about boot times, but as a tech guy 23 seconds sounds like an error to me and I want to find it and fix it :)

Also, old laptops with dieing batteries (or new ones with always-on sensors such as fingerprint readers) have some leakage during sleep so it may be better to turn them off if you are not going to use them for a few days.

edit: resume/suspend in linux works just fine and has done so for many years (in response to eltoozero)

I have disabled the UEFI Network Stack (updated the article to reflect this) and now the BIOS boot time is down to ~2seconds :) !

Mac is my daily driver for this very reason, I'm a consultant and I need to frequently grab and go.

I've had Linux on mobile for ages and have yet to have reliable sleep/wake behavior on a dozen machines over the years.

Sleep on Linux works reliably if you run it inside a Mac VM though, FWIW! ;)

Important difference: sleep usually works and is fast. What often does not work is hibernation (recover from disc)

...which is crucial since you don't want to lose your data when closing the lid. (Non-tech-term is on purpose here, since users shouldn't need to know about the difference. Also I believe OSX uses a hybrid approach).

You do not loose your data with both methods as power is used for suspend to RAM.

BTW: OSX has not a "pure" suspend to disc anymore and the default method is suspend to RAM when closing the lid

Parent poster stated "What often does not work is hibernation (recover from disc)".

Which means the user loses data.

Parent poster was me and you do not loose data. Instead it just does not go into hibernation in my case :)

According to a comment in the post it fails when the swap partition is encrypted. However why enable swap with 16 GB of RAM? I've been running without swap for almost 3 years and never had any trouble. If I start approaching the limit I'll buy another 16 GB.

The comment also talks about suspend to disc.

Exactly, the comment in your blog is "suspension to disk does not work if your swap partition is encrypted. This is due to how Ubuntu encrypts your home (ecryptfs) but not due to Linux itself."

I was reporting that.

I use whole drive encryption to protect data in the event I leave my old X220 (Fedora) on the bus.

I don't mind boot times in the 20s range (X220/Fedora/cheapo SSD) too much, but I do need to close down/reboot a couple of times a day otherwise no point in encryption.

> but I do need to close down/reboot a couple of times a day otherwise no point in encryption.

Given, I'm not a Linux user, but I don't understand this at all.

On Windows, encrypted is encrypted-- the lock screen is exactly as secure as the login screen. Are you saying that in Linux the lock screen is easily-bypassed? So you have to keep your computer logged-out when you're in a place it might get stolen?

> On Windows, encrypted is encrypted

Wasn't there a recent story about how Windows is storing keys so that it can wake up in the middle of the night and apply updates? I thought that the conclusion was that locked isn't as secure as logged out.

I believe that would be 'encrypt my home drive' on Linux, then you basically log out to protect files. Not sure though.

What I'm not understanding is why logging out or rebooting is required to keep a computer with full disk encryption secure. That's certainly not the case on competing OSes like Windows.

Usually in Linux the system is installed on an encrypted filesystem (cryptsetup, LUKS). Only kernel and so called initrd image (early boot stuff) is outside the encryption. The disk is opened at very early stage in boot when just about the kernel is loaded. Thus, the encryption is open whenever the operating system is running. Everything is of course still transparently encrypted on disk but the "lock" is open. One must shut down the computer to close the filesystem's encryption.

"Then click Install Now, and follow the rest of the instructions until you get to the “Who are you?” page. Make sure to choose a strong password — if someone steals your laptop while it’s suspended, this password is all that comes between the attacker and your data. And make sure that “Require my password to log in” is checked, and that “Log in automatically” is not checked. There is no reason to check “Encrypt my home folder” here, because you’re already encrypting your entire disk."

Above quote is from the section titled 'How to encrypt your disk in Linux' on the page at

https://theintercept.com/2015/04/27/encrypting-laptop-like-m...

I'm just a bit confused about how Windows can remove keys without messing up file handles &c when suspending to RAM.

The level of security I have now is adequate to my purpose but certainly something for others to take into consideration. Thanks for posting.

Would be nice to have a faster one, yes :) ... some recommendations?

Just fyi: I measure boot time from the time I press the power button. The BIOS logo appears a staggering 8sec or something although the BIOS fast boot is enabled. (Maybe the sync with NSA or something ;))

8 seconds for the BIOS sounds ridiculous; that should take less than a second. Check that you've booted and shut down successfully on the prior boot; with those, the boot should take much less time. (On an improper shutdown, the BIOS may do some extra work that takes longer.) Also check that you don't have some option enabled to make it wait around a while for a keyboard key.

For the Linux portion of your boot, try running "systemd-analyze plot > /tmp/boot.svg" and looking at that. (Also note that "kernel" includes any time spent waiting in the initramfs for you to type your disk encryption passphrase.)

Unsurprisingly UEFI didn't change much about vendor firmware shittiness. There's also still firmware around which just takes 5-10 seconds of black screen before doing shit.

I haven't tested any of these myself, but this page contains some great suggestions:

https://askubuntu.com/questions/10290/how-do-i-improve-boot-...

The initial boot delay is VERY annoying. I wish libreboot was supported on my laptop, then I could ditch lenovos ancient BIOS (and the NSA ping) once and for all:

https://libreboot.org/docs/hcl/#supported_laptops_x86intel

Check that PXE boot is disabled.

When I disabled UEFI Network Stack ipv4 and ipv6 it is indeed much faster: just ~2seconds

Oh yeah, with Arch linux and some tweaking I got under 10 seconds on my X240. But I switched to Fedora, which is still under 20 seconds.

I don't think this is a problem with systemd. On Archilinux using it - it's quite simple to get < 5s boot times.

Reply on news.ycombinator.com