On 2017-04-19 00:31, John Andersen wrote:

Why bother with a /boot partition any more? Is there any advantage these days?

Some times there is need, yes. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)

John Andersen wrote:

On April 18, 2017 6:37:17 PM PDT, "Carlos E. R." wrote:

...

...

Why bother with a /boot partition any more? Is there any advantage

On 2017-04-19 00:31, John Andersen wrote: these days?

Some times there is need, yes.

Name one.

I don't use a boot partition either, but maybe when the root filesystem is on LVM or encrypted or something like that? -- Per Jessen, Zürich (2.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

19.04.2017 12:47, Carlos E. R. пишет:

On 2017-04-19 09:25, Per Jessen wrote:

...

John Andersen wrote:

...

On April 18, 2017 6:37:17 PM PDT, "Carlos E. R." wrote:

...

...

Why bother with a /boot partition any more? Is there any advantage

On 2017-04-19 00:31, John Andersen wrote: these days?

Some times there is need, yes.

Name one.

I don't use a boot partition either, but maybe when the root filesystem is on LVM or encrypted or something like that?

Correct.

Wrong.

May also be needed with some RAID modes.

Wrong again.

Also I tried not too long ago to install Leap on XFS root without /boot, and I couldn't, grub failed.

That's correct, you cannot *install* GRUB on partition with XFS because XFS does not reserve the first sector for partition boot record. It does not mean you cannot install GRUB somewhere else (MBR, extended partition) and use it with /boot on XFS.

19.04.2017 21:25, Carlos E. R. пишет:

On 2017-04-19 19:17, Andrei Borzenkov wrote:

...

19.04.2017 12:47, Carlos E. R. пишет:

...

On 2017-04-19 09:25, Per Jessen wrote:

...

John Andersen wrote:

...

On April 18, 2017 6:37:17 PM PDT, "Carlos E. R." wrote:

...

On 2017-04-19 00:31, John Andersen wrote: > Why bother with a /boot partition any more? Is there any advantage these days?

Some times there is need, yes.

Name one.

I don't use a boot partition either, but maybe when the root filesystem is on LVM or encrypted or something like that?

Correct.

Wrong.

...

May also be needed with some RAID modes.

Wrong again.

Must be new feature in grub.

How can you boot from raid 5, if the kernel is distributed on 3 disks, can not be found as a contiguous block anywhere?

You install stage1.5 (a.k.a core.img) on every disk.

Similarly for LVM.

Ditto.

19.04.2017 23:03, Carlos E. R. пишет:

On 2017-04-19 20:44, Andrei Borzenkov wrote:

...

19.04.2017 21:25, Carlos E. R. пишет:

...

On 2017-04-19 19:17, Andrei Borzenkov wrote:

...

19.04.2017 12:47, Carlos E. R. пишет:

...

On 2017-04-19 09:25, Per Jessen wrote:

...

John Andersen wrote:

> On April 18, 2017 6:37:17 PM PDT, "Carlos E. R." > wrote: >> On 2017-04-19 00:31, John Andersen wrote: >>> Why bother with a /boot partition any more? Is there any advantage >> these days? >> >> Some times there is need, yes. > > Name one.

I don't use a boot partition either, but maybe when the root filesystem is on LVM or encrypted or something like that?

Correct.

Wrong.

...

May also be needed with some RAID modes.

Wrong again.

Must be new feature in grub.

How can you boot from raid 5, if the kernel is distributed on 3 disks, can not be found as a contiguous block anywhere?

You install stage1.5 (a.k.a core.img) on every disk.

...

Similarly for LVM.

Ditto.

And YaST does this automatically?

It does it in some cases; I do not know if it does it in every configuration. But this is also orthogonal to whether we need separate /boot or not.

On Thu, Apr 20, 2017 at 2:10 PM, Carlos E. R. wrote:

On 2017-04-20 05:15, Andrei Borzenkov wrote:

...

19.04.2017 23:03, Carlos E. R. пишет:

...

...

...

You install stage1.5 (a.k.a core.img) on every disk.

...

Similarly for LVM.

Ditto.

And YaST does this automatically?

It does it in some cases; I do not know if it does it in every configuration. But this is also orthogonal to whether we need separate /boot or not.

Well, if I'm going to install a new system with raid 5 or 6, my traditional knowhow says I have to install a separate /boot replicated on each disk, and run grub 3 or 4 times manually to install grub on all.

Instead, if I can go with no separate /boot and YaST handles it all correctly so that system will always boot regardless of what disk is missing, that's something very interesting to know ;-)

It does it at least for RAID1 (also multiple disks) and somebody recently reported that YaST did it also for RAID5; so yes, it works.

I don't mention LVM because I have never installed it.

That I do not know, but I do not remember seeing any code to handle LVM explicitly, so suspect YaST will not do it.

The other configuration I want is encrypted full disk without LVM. YaST does not support it, the procedure is manual. To avoid separate /boot, grub has to understand encryption and ask for the password early enough.

It understands it. I lost count of how many times I told you so. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 20/04/17 07:10 AM, Carlos E. R. wrote:

The other configuration I want is encrypted full disk without LVM. YaST does not support it, the procedure is manual. To avoid separate /boot, grub has to understand encryption and ask for the password early enough.

When you're doing RESCUE stuff, depending on what it was that necessitated the RESCUE, a separate /boot partition that may or may not be outside the LVM and/or may or may not be on a single drive of an array may or may not be useful. My life, my experience, my sysadmin-paranoia, the itching between my shoulder-blades and my cynicism about the economics of the technology of hard drives, as explained to me by the manager at the company tat I once took a drive in for 'recovery' all leads me to having a /boot on a REAL partition (that is, outside the LVM) on each drive or *ANY* kind of a RAID array. Even if I have to update them independently manually. Even if this is beyond anything YAST can assist with. One day I'll write up the gripe that manager explained to me, how it ties in with the the manufacturing process and the supposed handling of bad blocks, but crates a set of unnecessary failure modes of its own, why he saw it as impacting his business and why he saw it as causing unnecessary grief to consumers and small businesses alike. To be fair, SSDs probably cripple his business, but that's another matter. Given my druthers, I'd go for just about any form of encryption except the user-unfriendly double mounting modes of FUSE. Various ones have their own advantages and disadvantages. What you need to think about is whether the idea of an encryption system that works only when your machine is shut down is enough. I wonder about EncFS sometimes, the idea of having the encrypted files on a live system accessed via NFS but only decoded locally. Has anyone used this? By comparison, I use a Aegis Secure USB key from Apricorn. It's a 30G device and has admin as well as user level keys. Encryption is done by hardware and is !FAST! 30G is _just_ large enough to put a bootable Linux on, along with all the X stuff, fonts, man pages, drivers. However, as I've discussed before, what is it you want to focus on when encrypting, code or data? In a perfect world you'd have unlimited (portable) storage that doesn't degrade in speed with decryption. In reality ... what? Maybe you think that LUKS/FUSE is enough. As it happens, most of the machines I have access to have two USB ports accessible from the front. They are not always USB3 :-( Some machines don't have USB3 at all :-( :-( But two ports means that I can use on for my "system" USB (which for various systems might be 8G, 16G or 32G) and the other for my SecureKey, the latter being all DATA. YMMV The Apricorn devices aren't cheap. But if you need that kind of security, really need it in a way that most home users rarely do, then from a Corporate POV is not merely part of the cost of doing business, its cheaper than the risks associated with conventional USB sticks. Or even some forms of cloud storage. Apricorn have USB sticks from 4G (around $60) to 480G (around $400) in the same format. Of course they have portable drives, portable SSD and internal drives. https://www.apricorn.com/ I'm not associated with Apricorn in any way other than being a satisfied user. Maybe you think that LUKS is all you need, but maybe your corporate auditors don't. Something like an Aegis device with proper certification can address that. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 20/04/17 01:40 PM, Carlos E. R. wrote:

On 2017-04-20 15:44, Anton Aylward wrote:

...

However, as I've discussed before, what is it you want to focus on when encrypting, code or data? In a perfect world you'd have unlimited (portable) storage that doesn't degrade in speed with decryption. In reality ... what? Maybe you think that LUKS/FUSE is enough.

Data, but there is sensitive data spread on several directories. WiFi passwords somewhere on /etc, logs on /var, temporary files in /tmp, and others I forget. So the answer, for a laptop, is "all".

Don't forget SWAP! This is why I don't think simply encrypting partitions or files or directories is enough in this sort of context. You need an encrypted DISK. You need a HARDWARE ENCRYPTED DISK !!!

I don't care if it can be broken. The average burglar will not know how. If they want read the disk, they will have to sweat.

Once again I refer to the story about the the data thief that stole the laptop while it was active, while the owner was logged in and the encrypted volumes visible in the clear. Potable devices are not secure, or perhaps that should be phrased "they are not securable enough". -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am Samstag, 22. April 2017, 00:41:21 CEST schrieb Carlos E. R.:

On 2017-04-20 23:20, Anton Aylward wrote: [...]

...

You need a HARDWARE ENCRYPTED DISK !!!

Well, it does exist. It is a standard. But I have no idea how to enter the password when powering the laptop before the hard disk can be read at all.

It is done by the "BIOS". And there is no standard how the "BIOS" translates your key presses into the password that you can use with hdparm. So, if your computer dies and you have to move your disk to another computer, you will not be able to unlock it and all your data will be lost. This is unacceptable. Besides the "BIOS" may reduce your password strength and might even store it: https://jbeekman.nl/blog/2015/03/lenovo-thinkpad-hdd-password/ Luckily I was curious enough to check this before I activated the hardware encryption on my new SSD... Gruß Jan -- Colorless green ideas sleep furiously. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Am Samstag, 22. April 2017, 13:29:03 CEST schrieb Carlos E. R.:

On 2017-04-22 12:45, Jan Ritzerfeld wrote: [...]

...

It is done by the "BIOS".

How?

For Lenovo: http://monitor.espec.ws/files/lewnovo_password_399.pdf

I have not seen any option in the BIOS mentioning this feature, on several computers. Where to enable it?

[Reading the blog later, it appears that some BIOSES do have this feature]

IIRC I've seen that on Lenovos, Dells and HPs. Maybe only business or rugged models.

...

And there is no standard how the "BIOS" translates your key presses into the password that you can use with hdparm.

To use with hdparm it is the Linux keyboard drivers and maps, not the bios.

And then you can't use the BIOS to unlock the disk.

To activate the disk before booting with the bios would be the bios, the same keyboard native to the computer, which is used on the several bios screens. It is even better with UEFI, it seems.

It could but often it does not use the keyboard layout but scancodes.

...

So, if your computer dies and you have to move your disk to another computer, you will not be able to unlock it and all your data will be lost. This is unacceptable. You can boot with another disk, then enable the encrypted disk using hdparm in Linux.

If you know the algorithm and all other key used by the BIOS.

...

Besides the "BIOS" may reduce your password strength and might even store it: https://jbeekman.nl/blog/2015/03/lenovo-thinkpad-hdd-password/ Luckily I was curious enough to check this before I activated the hardware encryption on my new SSD...

Ah. The inability to access the disk refers to Lenovo and SSDs, not necessarily to all implementations.

It is not that specific to Lenovo and SSDs. HDDs use the same encryption standard and other manufactures also use scancodes: http://www.tomshardware.co.uk/forum/290824-32-password-dead-computer

Ant the blog author has written a tool to open the disk with hdparm.

According to the comments, the tool works only for some models.

The problem is (reading the blog) that the BIOS changes the password before sending it to the disk in a bios specific way for that computer.

Exactly.

And the second problem is that, the blog says, all SSD drives use encryption already without the user knowing. When the user enables it, what it does is place a password on top of the password (or something similar, read the article for correct details).

Well, I don't think that this a big problem.

Nasty.

You can use encryption safely only if you manage to, after setting it up in the bios, you can manage to access it using hdparm.

Yes. Gruß Jan -- Any system that depends on human reliability is unreliable. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 20/04/17 02:16 PM, John Andersen wrote:

On 04/20/2017 06:44 AM, Anton Aylward wrote:

...

What you need to think about is whether the idea of an encryption system that works only when your machine is shut down is enough.

Exactly. And usually that means its only worth while for a laptop that travels and may get lost/stolen, or media that can "walk away".

Let me qualify that: it is only worth while for a laptops that travels and may get lost/stolen WHILE SHUT DOWN. If the thief is ingenious enough to steal your laptop while logged in and the data is accessible in the clear and has the means to keep the laptop powered up then that is a very different scenario. See http://www.johnsandford.org/kidd04.html for a novelization of this scenario.

You are going to give up that encryption key like a blubbering school boy when they come with warrants and guns, so why pretend encryption protects anything on always-running spinning storage in your home or office server room?

The real difference between _their_ Stasi, "The Ministry for State Security" and _our_ Stasi, 'The Department of Homeland Security", is that we live in a more material rich society. We have (cholesterol rich) beef on the table, 40+ inch TVs, Graceland, Disneyland, cheap air travel (if you are willing to queue, be groped and stripped searched, and possibly dragged off kicking and screaming) and other consumer comforts, as well as the ability to bitch and complain about it all on the 'Net, in print and at the pub, just so long as you don't actually do anything.

I've used encryption (LUKS) on 13.2 on my traveling laptop for years and it never caused me any problem. I abandoned it when I did a fresh 42.2 install on SSD.

That reassures me immensely. When I travel, I remove the password protection from all my portable devices. I used to think that it would save a lot of hassle. It used to, yes. Now I'm getting asked why I don't use passwords...

The old disk is in a caddy, and I've occasionally plugged it in to a couple different distros to retrieve data, and it pops up asking for the decryption password each time just like it always did.

Yes, I do that with my old //etc and more, keep the DVDs with /home and so forth. Some RootFS live on LVM partitions. Now I have to figure out how to stop drakut/mkinitrd scanning them. Oh, right /etc/default/grub ... os-prober

(To relate to the topic title, I didn't try whole disk encryption, nor did I encrypt /boot or /root on that laptop, just /home and /data where source code and money things live).

-- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 19/04/17 19:25, Carlos E. R. wrote:

Must be new feature in grub.

How can you boot from raid 5, if the kernel is distributed on 3 disks, can not be found as a contiguous block anywhere?

Pretty standard. Grub2 is now a mini-operating-system in its own right (like emacs, it comes with a kitchen sink installed :-). Load the raid module into grub, and it will happily boot off a raid system (or lvm, or whatever, with the right modules), and it couldn't care where /, or /boot, are. You just need to make sure you use an initrd to boot, as user-space is required to assemble a raid array, and of course no initrd == no user space == no way to boot off modern linux raid. (That's for bios systems - uefi is different, don't ask me how as I haven't yet played with it.) The only way to boot off raid with no initrd is to use a mirror with a v0.9 or v1.0 superblock. Cheers, Wol -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 2017-04-19 01:54, L A Walsh wrote:

AH!... it has to be the initrd's...

Yes. You are installing using defaults, not "your way". -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)