Possible not to use partitions?

English Install/Boot/Login
1

Is it at all possible to use not any partitions at all?

I know if I encrypted the entire device (e.g. /dev/sda) then grub won’t want to install complaining about having no place to embed itself. Although the LUKS offset is 4096 sectors I think, so it should really give 2MB of space, not sure.

Well given that that doesn’t work, what I want can’t work either. But supposing you didn’t use encryption of the main device.

Is it possible to create a physical volume for LVM without having any partition table on the device? I mean the PV would still need to be found. I don’t think there’s a measure for that. I don’t think it can work just like that.

But maybe there’s a way?

All that would really be required would be for the PV to have an offset that is pretty standard and allows it to be recognised, while allowing grub to install above that.

Same thing with Luks really. I don’t know why Grub can’t install there. Indeed LUKS creates a container 4096 sectors smaller than the device.

But the header might just be above it, meaning it doesn’t do much for ya.

If there was a provision for some space between. What is probably going on is that LUKS puts itself after the MBR but without any space, and Grub needs that space.

I don’t know, I would have to dig into it. Don’t feel like it.

Partitions have boot records too, after all. Right now if I want a fully encrypted system I have to … well.

Anyway.

2

On Fri, 06 May 2016 17:36:02 +0000, xen82a wrote:

> Same thing with Luks really. I don’t know why Grub can’t install there.
> Indeed LUKS creates a container 4096 sectors smaller than the device.

How would you expect the system to be able to access the encrypted
partition without having access to the software used to decrypt the
storage volume, given that the only place to store it would be in the
encrypted volume?

Catch-22.

To answer the core question - no, I don’t believe you can install without
partitions, because the hardware is expecting to look for a boot sector
in a partition table in order to get the system up and running.

If you use UEFI, it must have a partition to store the EFI-related
software on.

Jim

Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

3

The place to store it would be between LUKS header and payload; that is not really a problem (except someone would need to implement it). The real problem is, LUKS does not reserve sector 0 (header starts at the beginning of device), so you have no space for boot sector. Such device cannot be booted by BIOS.

4

Well that thing is already possible in grub2. It can decrypt LUKS. You can also give it a keyfile in the initrd, well, that’s what the initrd has in memory to decrypt the volume a second time, this time for the running system.

To answer the core question - no, I don’t believe you can install without
partitions, because the hardware is expecting to look for a boot sector
in a partition table in order to get the system up and running.

Well the goal would be to have a boot record without partitions. MBR code that gets executed (where grub is) is technically not part of the partition table, although it is part of the boot record.

So basically all is needed is the location of grub where it is always located, with enough room for code, and then the volume would need to start at sector 2048. Meaning, the LUKS header would need to be at sector 2048. You technically don’t need partitions, you just need code to be present at a specific starting byte.

And like I said grub can decrypt LUKS just fine.

Aye, if you cannot offset it into the close distance, then all hope is lost ;-).

Maybe it makes no sense to have any volume or container not start at the start of a container it is sitting in. After all, that is the whole idea of containers.

On Windows you can easily achieve it in another way, but that is because TrueCrypt also encrypts the partition table of a system encrypted disk.

You would just need the rather weird concept, perhaps, that the usable space of say /dev/sda starts at sector 2048.

Then grub would need to know to look for it there. That is all really.

I must say I consider the no-partitions-at-all-and-just-use-LVM setup to be superior to what you can do with TrueCrypt on windows.

5

LVM != LUKS. If unencrypted PV is acceptable, modern LVM reserves space for bootloader in PV, and there was patch posted to grub-devel to support embedding in this space.

6

Then you’d need to create a PV, VG, LV, and then LUKS inside of that, then your regular setup ;-).

I think not any tool has a problem with that. It’s just a bit convoluted ;-).

I mean, you can embed a PV within an LV right? You can definitely embed one in a LUKS container.

If LUKS could do the same it would be solved entirely. Thank you for your answers. Helpful pointers.

7

Thanks to you, I’ve updated the patch for recent versions of Grub :p.

https://lists.gnu.org/archive/html/grub-devel/2016-05/msg00010.html

Not tested on OpenSUSE (yet) but wouldn’t make a difference. Probably.

8

I tried to work with the Grub mailing list to update that patch, but apparently people didn’t like what I did.

Maybe I’ve been too disregarding of people’s wishes here (?) but the patch currently

  • needs more sanity checks on the bootloaderarea size (whether it is correct)
  • only checks for the existence of a PV, not of any VG contained or applied to it
  • escapes the filesystem check that will fail anyway
  • provides error messages for a PV that may exist in the first sector (sector 0)
  • is untested on partitions, because my system won’t work with trying to install on a partition anyway for some reason

Other than that, it just works™. But apparently, that’s not good enough. People stopped responding. I may have exhausted their patience with me.

Regards.