Re: [Qemu-devel] [RFC PATCH 0/3] acceptance tests: Test firmware checking debug console output

[Cleber Rosa]

On 10/3/18 11:59 AM, Laszlo Ersek wrote:
> On 10/03/18 17:20, Cleber Rosa wrote:
>> On 10/3/18 3:13 AM, Laszlo Ersek wrote:
>>> On 10/03/18 02:23, Cleber Rosa wrote:
>>>> On 9/28/18 6:51 AM, Laszlo Ersek wrote:
>>>
>>>>>   I'm not sure if Avocado provides disk image preparation utilities, but
>>>>>   perhaps (a) we could use the vvfat driver (*shudder*) or (b) we could
>>>>>   preformat a small image, and track it as a binary file in git.
>>>>>
>>>>
>>>> So far we've added support for generating ISO images (with pure Python).
>>>> I'm not sure if that's useful here.  We can think about trying to add
>>>> the same thing for vvfat.
>>>
>>> The ability to generate ISO images (natively at that!) seems useful.
>>> UEFI-readable ISO images need an extension on top: the ISO9660
>>> filesystem has to get the ElTorito extension, and the ElTorito boot
>>> image should be a FAT filesystem. Under UEFI, what's visible isn't the
>>> ISO9660 filesystem itself, but the contents of the embedded ElTorito
>>> boot image.
>>>
>>> In terms of shell utilities, this usually involves:
>>>
>>> - creating and populating the FAT filesystem image (with guestfish, or
>>>   with mkdosfs+mtools),
>>>
>>
>> Is FAT12 an option here?  The reason I ask is that there may be code
>> FAT12 capable code ready to be incorporated:
>>
>> https://github.com/clalancette/pyfat
> 
> Theoretically, I should answer "yes". For two reasons:
> 
> (1) In "13.3 File System Format", the UEFI-2.7 spec writes,
> 
> "[...] EFI encompasses the use of FAT32 for a system partition, and
> FAT12 or FAT16 for removable media. [...]"
> 
> (2) When invoking mkdosfs without the "-F" option, mkdosfs chooses the
> smallest FAT filesystem variant that can accommodate the requested size.
> We successfully format UEFI-readable ISO images that don't exceed e.g.
> 3MB in final size. This implies (and I have now actually checked, with
> "dosfsck -v") that their embedded ElTorito image is FAT12. edk2 has no
> trouble reading that.
> 
> 
> However... the maximum volume size for FAT12 appears to be 32 MB,
> according to wikipedia:
> 
>   https://en.wikipedia.org/wiki/File_Allocation_Table#FAT12
> 
> It doesn't look good for the long term. For example, I can imagine a
> test case where you place a kernel executable (containing a UEFI stub)
> and an initial ramdisk on the UEFI-readable ISO. Using the RHEL-7.5
> kernel and the matching initrd from my laptop as an example: that's
> already 6.2MB + 25MB.
> 
> So, technically, FAT12 should be fine; in practice, it could prove limiting.
> 

Nice, thanks for the detailed info.  I think it's safe to start with
that, and improve the original project with FAT16/32 support.

Regards,
- Cleber.

> [...]
> 
> Thanks!
> Laszlo
> 

-- 
Cleber Rosa
[ Sr Software Engineer - Virtualization Team - Red Hat ]
[ Avocado Test Framework - avocado-framework.github.io ]
[  7ABB 96EB 8B46 B94D 5E0F  E9BB 657E 8D33 A5F2 09F3  ]