Re: [gentoo-user] boot problems

[J. Roeleveld]

On Sunday, May 04, 2014 09:03:08 PM Stefan G. Weichinger wrote:
> Am 04.05.2014 20:40, schrieb J. Roeleveld:
> > On Sunday, May 04, 2014 03:07:28 PM Stefan G. Weichinger wrote:
> >> 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.
> I think you would have to use files on top of ZFS ... but I am not
> up-to-date in that area.
>
> People run KVM-hosts with storage on ZFS ... nice with the snapshots etc ...

Does KVM support running snapshots?
Eg. also storing the memory and registers?
I have not found any indication that KVM supports that.

Without that, KVM is useless to me.


> > 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.
> Yes, this is for UEFI booting, thanks.
>
> I tried to migrate to GPT/BIOS-booting today but failed. It seems my
> mainboard/BIOS has problems detecting that ... I vaguely remember this
> from trying it back then.

I thought the MBR info that's possible with GPT would make it possible with 
any BIOS?
Provided the /boot partition is early enough on the disk.

> So I am back on a freshly partitioned and formatted SSD with plain old
> MBR now.
>
> I also wanted to partition the SSD according to the Erase Block Size of
> 6144 kB by this way ... dunno if this is still needed or has any real
> speed benefits.

Again, I would expect current tools should do that automagically?

> Maybe I take another approach to migrate to UEFI/GPT in the next days,
> now that I have my rsynced filesystems at hand (I got rid of more LVs
> and stuff so it gets pretty slim now).

Less LVs is simpler. More is more flexible.

> > 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)
>
> Yep. LABELs are human readable ... big advantage.

I would like LABELs to be supported directly by the kernel.

> > See the partitioning on my server above.
> > It boots using BIOS as I haven't been able to boot Xen using UEFI yet.
>
> So then the EFI partition is useless ...

True, but I leave it there as repartitioning requires extended downtime. And I 
do occasionally test new versions to see if I can get it to work.

> > 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.
>
> ... if your BIOS isn't crappy ;-)

Try updating? :)

Seriously, do you have the following:

***
# man gdisk
artemis ~ # gdisk -l /dev/sda
GPT fdisk (gdisk) version 0.8.8

Partition table scan:
  MBR: protective

***

That last line of what I copied is the bit that should make it possible.

Also, the /boot partition needs to have the mbr-boot flag (or whatever it's 
called) enabled.

--
Joost