Re: [gentoo-user] boot problems

[J. Roeleveld]

On Sunday, May 04, 2014 03:07:28 PM Stefan G. Weichinger wrote:
> Am 04.05.2014 12:49, schrieb J. Roeleveld:
> > I wouldn't use the stripe/mirror support in LVM as I don't think it is
> > used
> > often and I feel that functionality doesn't belong in LVM.
> > If you want to move it all into a single layer, I would suggest ZFS
> > instead.
> Oh, yes, I like ZFS and its features and used it in some cases already.
> But I didn't yet take the step to set up ZFS-root on my work machines.

I haven't yet, but it's on the list of items to look into at some point.
I'd like to know if, with ZFS, it is possible to create block-devices like LVs 
which I can then attach to VMs. Or if I have to use files instead.

> >> And then you get into issues with block sizes and stuff, where I always
> >> wonder why *I* have to type all these parameters ... why doesn't modern
> >> software just come with this knowledge inside?
> >>
> >>  .... you know
> >>
> >> *sigh* ;-)
> >
> > I agree, and I feel that has actually improved over time with modern tools
> > defaulting to 4k sectors.
>
> Yes, but it always feels like "I missed something" when you look at the
> various layers: partitioning at correct sectors, RAIDs with their
> parameters, creating PVs with PEs aligned ... and then the filesystems.
> I never get the feeling that I really did it right from the base to the
> top.

True, but if all the tools are working correctly, it all should cascade down 
when getting the "sector" sizes from the previous layer.
Not sure if this actually works.

I think it does as I get the following on my server:
***
# gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sda: 11718749184 sectors, 5.5 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 936FDBE4-A736-41CF-B9A5-51069940D3DB
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 11718749150
Partitions will be aligned on 2048-sector boundaries
Total free space is 2014 sectors (1007.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048          411647   200.0 MiB   EF00  EFI System
   2          411648         2101247   825.0 MiB   8300  Linux filesystem
   3         2101248     11718749150   5.5 TiB     8E00  Linux LVM

***

That's a hardware raid device with 4 * 3TB disks with raid-6.
I don't like the fact that a 2nd disk-failure can kill a raid-10 when both 
disks are in the same mirror-set.

gdisk automatically aligns on 2048 sector boundaries, that is more then enough 
for the 4k-sectors and the block/stripe sizes employed by the raid-controller.

> > Then it should work, provided you have all the required drivers inside
> > your
> > kernel and not as modules.
> > I also believe an initramfs is needed when using LABELs for the root-fs.
>
> Interesting. I don't really care if I have an initramfs or not, as long
> as things work ... The feature with LABELs is nice for preparing
> installations in VMs and then move it to physical hardware (eg.
> /dev/vda1 then becomes /dev/sda1 or /dev/md0 and booting fails).

UUIDs, I believe, do work natively. And those are stored inside the partition 
itself. Which means they should also work. But are not as easy to locate. (eg. 
you don't specify them yourself)

> > At the moment, I don't see, from a simple user perspective, any real
> > difference between booting using UEFI and BIOS/MBR.
>
> UEFI is one thing, GPT partitioning another. Being able to have more
> than the 4 primary partitions of MBR looks good to me ...
>
> I will see where my motivation leads to ;-)

See the partitioning on my server above.
It boots using BIOS as I haven't been able to boot Xen using UEFI yet.

Support should be there now, but not been able to test that yet.
GPT is supported by grub-1 (and grub2) and with the MBR-support inside GPT, 
booting works from BIOS/MBR.

--
Joost