[Nix-dev] Fwd: Grub problem: external pointer tables not supported

[Roger Qiu]

A while back when I was trying to do the whole encrypted ZFS root, the info
on Grub seemed to show that it didn't support loading ZFS as a booting
device. So it needed a separate boot partition (which I setup as a
soft-raided ext4). Later I moved to using gummiboot and uefi however that
apparently didn't support soft raid, so I just manually cloned the fat32
boot partition which contained the gummiboot uefi application, kernel and
initramfs. The initramfs had a zfs driver so it could load zfs root at
stage 2 boot phase.

So grub has improved, and has zfs root support? That's great! However you
still need a fat32 partition for uefi support. I'm guessing this is still
where your grub code since uefi can't mount zfs or deal with luks.
On 24/01/2017 3:09 PM, "Tomasz Czyż" <tomasz.czyz at gmail.com> wrote:

> Roger,
>
>
> I got it from my grub.cfg config file. It looks like that's how you access
> "root" zfs volume.
>
> If I have
>
> /
> /volume1
> /volume2
>
> in grub I could access it
>
> $disk/@/
> $disk/volume1/
> $disk/volume2/
>
> Looks like just a convention but didn't dive into it.
>
> btw, just to clarify my setup, currently I have /boot and /nix/store on
> the same zfs volume and works, looks like only one directory is affected by
> hardlinks/too many files issue.
>
> Thanks,
> Tom
>
> 2017-01-24 3:43 GMT+00:00 Roger Qiu <roger.qiu at matrix.ai>:
>
>> Btw what is the `@` symbol mean in your `ls` examples? I've never seen
>> that. The grub rescue allows yo use `ls hd (0,1)/...` with no `@`.
>> On 24/01/2017 12:52 PM, "Tomasz Czyż" <tomasz.czyz at gmail.com> wrote:
>>
>>> It looks like I hit some ZFS feature that it's not supported by grub
>>> module.
>>>
>>> How I found that?
>>> In grub, you can list files in zfs volumes by doing ``ls $drive/@/home``
>>> etc.
>>> I could list ``ls $drive/@/nix`` or ``ls $drive/@/nix/var`` but not ``ls
>>> $drive/@/nix/store`` where I kept the kernels.
>>>
>>> I found some explanations about lot's of files and lot's of hardlinks
>>> (nix store had at that time more than 130G and probably triggered the
>>> feature).
>>>
>>> nix-collect-garbage -d didn't help.
>>>
>>> I solved the problem by using boot.loader.grub.copyKernels = true;
>>>
>>> Kernels were copied to the same volume but to /boot where there is
>>> smaller number of files and worked perfectly.
>>>
>>>
>>> 2017-01-23 16:44 GMT+00:00 Tomasz Czyż <tomasz.czyz at gmail.com>:
>>>
>>>>
>>>>
>>>> 2017-01-23 16:15 GMT+00:00 Roger Qiu <roger.qiu at matrix.ai>:
>>>>
>>>>> Hey,
>>>>>
>>>>> Changing nixos generations won't affect the grub boot partition, that
>>>>> only changes which nixos kernel and initramfs image gets booted.
>>>>>
>>>> Because all boot options are not working one of my guesses is that in
>>>> new nix version, wrong config was generated when I did system update which
>>>> broke all options.
>>>>
>>>>> This looks like an error in the Grub partition. Maybe you recently
>>>>> updated it or changed it, or the partition got corrupted.
>>>>>
>>>> It's possible, I tried to boot from USB, do ``nixos-install
>>>> --no-root-passwd`` to reinstall the system, but I'm not sure how to force
>>>> grub/uefi partition recreation/reinstalling, any idea? Should I just format
>>>> it and will be recreated?
>>>>
>>>>> This is why other operating systems tend to make their /boot
>>>>> read-only...
>>>>>
>>>>> If you can't get into the OS, then you can try booting off a USB, and
>>>>> then edit the boot partition. Or run the uefi terminal app (but this one
>>>>> never worked for me). If you had cloned/raided boot partitions you can try
>>>>> changing the uefi image to boot from in your uefi settings (access it like
>>>>> BIOS).
>>>>>
>>>> I tried that, but I'm not sure what to change. I tried to reinstall
>>>> grub on EFI partition but I'm not sure how to do that, is regular
>>>> grub-install stuff way to go (I thought I had some issues with that and I
>>>> tried nixos-install after that).
>>>>
>>>>> Currently I have 2 uefi boot partitions cloned, but one failed so I've
>>>>> been booting off the other one.
>>>>>
>>>> Nice one, I think I'll try to do something like that.
>>>>
>>>> Thanks Roger.
>>>>
>>>>> Thanks,
>>>>> Roger
>>>>> On 23/01/2017 10:48 PM, "Tomasz Czyż" <to <tomasz.czyz at gmail.com>
>>>>>
>>>>
>>>>
>>>>> masz.czyz at gmail.com <tomasz.czyz at gmail.com>> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> recently my grub said this to me after I restarted computer:
>>>>>>
>>>>>> Error: external pointer tables not supported
>>>>>> Error: you need to load the kernel first.
>>>>>>
>>>>>> Every option I select with nix (also past generations) shows me this
>>>>>> message.
>>>>>>
>>>>>> I updated the system to 17.03pre99792.c311871 on 2016-12-23 and
>>>>>> restarted it before multiple times (and worked). I don't remember if I did
>>>>>> other updates, but this is what's grub menu shows me.
>>>>>>
>>>>>> My disk layout is: EFI boot partition for grub, next partition is
>>>>>> encrypted luks volume and ZFS on top of it.
>>>>>>
>>>>>> This setup worked for me for 1.5 year now without any issue.
>>>>>>
>>>>>> Anybody is aware of any changes to grub/zfs recently or had same
>>>>>> issue?
>>>>>> Any suggestions how I can recover from it or what can be wrong?
>>>>>>
>>>>>> Tom
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> nix-dev mailing list
>>>>>> nix-dev at lists.science.uu.nl
>>>>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>>>>
>>>>>>
>>>>
>>>>
>>>> --
>>>> Tomasz Czyż
>>>>
>>>
>>>
>>>
>>> --
>>> Tomasz Czyż
>>>
>>> _______________________________________________
>>> nix-dev mailing list
>>> nix-dev at lists.science.uu.nl
>>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>>
>>>
>
>
> --
> Tomasz Czyż
>
>
>
> --
> Tomasz Czyż
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.science.uu.nl/pipermail/nix-dev/attachments/20170124/5f4ead9e/attachment-0001.html>