Re: [tboot-devel] [PATCH] 20_linux_tboot: efi logic was inverted

[Tony C. <tc...@re...>]

On 6/11/2022 1:41 PM, Timo Lindfors wrote:
> On Sat, 11 Jun 2022, Tony Camuso wrote:
>> OK, so something is going wrong with the information that tboot is
>> forwarding to the kernel launch.
>>
>> On the efi system, with "noefi" removed from the grub command line,
>> the system boots.
>>
>> With "noefi" in the grub command line, Device Mapper cannot find
>> the root and swap devices and drops to the dracut prompt.
>>
>> How can I determine what info efi is providing that tboot is not?
>>
>> Where can I instrument the code to gain that visibility?
> 
> I'm not too familiar with dracut but I'd imagine you can unpack the initramfs and investigate how it works. It might be easiest to spawn a shell at some point.
> 
> Can you reproduce the problem if you do a fresh install? What distribution is this? If you have easy steps to reproduce this I can try to take a look. I'm normally on Debian so will need good instructions for other distros :)
> 
> -Timo
> 

I'm using a RHEL-8.5 based on 5.14 kernel. CentOS 8.5 is the same thing.

You can probably reproduce it on a debian system with storage configured
as VROC RAID. You will need a motherboard and intel cpu that can implement
VROC RAID.

lenovo-st250v2 is the platform I'm using to reproduce the problem.

See...
https://www.intel.com/content/www/us/en/support/articles/000026106/memory-and-storage/ssd-software.html
https://www.intel.com/content/www/us/en/support/articles/000030445/memory-and-storage/ssd-management-tools.html

RAID info
====================================================================

# cat /proc/mdstat
Personalities : [raid0]
md126 : active raid0 sda[1] sdb[0]
       1855842304 blocks super external:/md127/0 128k chunks
       
md127 : inactive sda[1](S) sdb[0](S)
       10402 blocks super external:imsm
        
unused devices: <none>

# cat /etc/mdadm.conf
# mdadm.conf written out by anaconda
MAILADDR root
AUTO +imsm +1.x -all
ARRAY /dev/md/Volume0_0 UUID=8061c4cf:06de8a59:a9eefb7e:3edb011a
ARRAY /dev/md/imsm UUID=549c2ba4:1e03463b:d429e75b:398c67a3
---------------------------------------------------------------------

Physical Volume, Volume Group, and Logical Volume info
=====================================================================
# pvs
   PV           VG                     Fmt  Attr PSize  PFree
   /dev/md126p3 rhel_lenovo-st250v2-02 lvm2 a--  <1.73t    0

# vgs
   VG                     #PV #LV #SN Attr   VSize  VFree
   rhel_lenovo-st250v2-02   1   4   0 wz--n- <1.73t    0

# lvs
   LV   VG                     Attr       LSize
   home rhel_lenovo-st250v2-02 -wi-ao---- 500.00g
   root rhel_lenovo-st250v2-02 -wi-ao----  70.00g
   swap rhel_lenovo-st250v2-02 -wi-ao----  31.47g
   work rhel_lenovo-st250v2-02 -wi-ao----  <1.14t
-----------------------------------------------------------------------

By the time initramfs is running, it's too late, since the Device Mapper
cannot find the logical volumes.

*************
*   NOTE    *
*************
There are differences in the memmap that tboot hands off to the initramfs
with and without the "noefi" directive.

Failed with "noefi"
===================
TBOOT: get_highest_sized_ram: size 14e99600 -> base 62585000, size 24949000
   :                                                 ^^^^^^^^       ^^^^^^^^
TBOOT:  /swap console=ttyS0,115200N81 intel_iommu=on noefi
TBOOT: EFI memmap: memmap base: 0x69808, memmap size: 0x14a0
                                 ^^^^^^^               ^^^^^^

Successful boot with efi
========================
TBOOT: get_highest_sized_ram: size 14e99600 -> base 62045000 size 24789000
   :                                                 ^^^^^^^^      ^^^^^^^^
TBOOT:  /swap console=ttyS0,115200N81 intel_iommu=on
TBOOT: EFI memmap: memmap base: 0x69808, memmap size: 0x1b00
                                 ^^^^^^^               ^^^^^^