Re: [PULL SUBSYSTEM qemu-pseries] pseries: Update SLOF firmware image

[Alexey Kardashevskiy]

On 19/02/2020 18:18, Cédric Le Goater wrote:
> On 2/19/20 7:44 AM, Alexey Kardashevskiy wrote:
>>
>>
>> On 19/02/2020 12:20, Alexey Kardashevskiy wrote:
>>>
>>>
>>> On 18/02/2020 23:59, Cédric Le Goater wrote:
>>>> On 2/18/20 1:48 PM, Cédric Le Goater wrote:
>>>>> On 2/18/20 10:40 AM, Cédric Le Goater wrote:
>>>>>> On 2/18/20 10:10 AM, Alexey Kardashevskiy wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 18/02/2020 20:05, Alexey Kardashevskiy wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 18/02/2020 18:12, Cédric Le Goater wrote:
>>>>>>>>> On 2/18/20 1:30 AM, Alexey Kardashevskiy wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 17/02/2020 20:48, Cédric Le Goater wrote:
>>>>>>>>>>> On 2/17/20 3:12 AM, Alexey Kardashevskiy wrote:
>>>>>>>>>>>> The following changes since commit 
>>>>>>>>>>>> 05943fb4ca41f626078014c0327781815c6584c5:
>>>>>>>>>>>>
>>>>>>>>>>>>   ppc: free 'fdt' after reset the machine (2020-02-17 11:27:23 
>>>>>>>>>>>> +1100)
>>>>>>>>>>>>
>>>>>>>>>>>> are available in the Git repository at:
>>>>>>>>>>>>
>>>>>>>>>>>>   address@hidden:aik/qemu.git tags/qemu-slof-20200217
>>>>>>>>>>>>
>>>>>>>>>>>> for you to fetch changes up to 
>>>>>>>>>>>> ea9a03e5aa023c5391bab5259898475d0298aac2:
>>>>>>>>>>>>
>>>>>>>>>>>>   pseries: Update SLOF firmware image (2020-02-17 13:08:59 +1100)
>>>>>>>>>>>>
>>>>>>>>>>>> ----------------------------------------------------------------
>>>>>>>>>>>> Alexey Kardashevskiy (1):
>>>>>>>>>>>>       pseries: Update SLOF firmware image
>>>>>>>>>>>>
>>>>>>>>>>>>  pc-bios/README   |   2 +-
>>>>>>>>>>>>  pc-bios/slof.bin | Bin 931032 -> 968560 bytes
>>>>>>>>>>>>  roms/SLOF        |   2 +-
>>>>>>>>>>>>  3 files changed, 2 insertions(+), 2 deletions(-)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> *** Note: this is not for master, this is for pseries
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Hello Alexey,
>>>>>>>>>>>
>>>>>>>>>>> QEMU fails to boot from disk. See below.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> It does boot mine (fedora 30, ubuntu 18.04), see below. I believe I
>>>>>>>>>> could have broken something but I need more detail. Thanks,
>>>>>>>>>
>>>>>>>>> fedora31 boots but not ubuntu 19.10. Could it be GRUB version 2.04 ? 
>>>>>>>>
>>>>>>>>
>>>>>>>> No, not that either:
>>>>>>>
>>>>>>>
>>>>>>> but it might be because of power9 - I only tried power8, rsyncing the
>>>>>>> image to a p9 machine now...
>>>>>>
>>>>>> Here is the disk : 
>>>>>>
>>>>>> Disk /dev/sda: 50 GiB, 53687091200 bytes, 104857600 sectors
>>>>>> Disk model: QEMU HARDDISK   
>>>>>> Units: sectors of 1 * 512 = 512 bytes
>>>>>> Sector size (logical/physical): 512 bytes / 512 bytes
>>>>>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>>>>>> Disklabel type: gpt
>>>>>> Disk identifier: 27DCE458-231A-4981-9FF1-983F87C2902D
>>>>>>
>>>>>> Device         Start       End   Sectors Size Type
>>>>>> /dev/sda1       2048     16383     14336   7M PowerPC PReP boot
>>>>>> /dev/sda2      16384 100679679 100663296  48G Linux filesystem
>>>>>> /dev/sda3  100679680 104857566   4177887   2G Linux swap
>>>>>>
>>>>>>
>>>>>> GPT ? 
>>>>>
>>>>> For the failure, I bisected up to :
>>>>>
>>>>> f12149908705 ("ext2: Read all 64bit of inode number")
>>>>
>>>> Here is a possible fix for it. I did some RPN on my hp28s in the past 
>>>> but I am not forth fluent.
>>>
>>>
>>> you basically zeroed the top bits by shifting them too far right :)
>>>
>>> The proper fix I think is:
>>>
>>> -  32 lshift or
>>> +  20 lshift or
>>>
>>> I keep forgetting it is all in hex. Can you please give it a try? My
>>> 128GB disk does not expose this problem somehow. Thanks,
>>
>> Better try this one please:
>>
>> https://github.com/aik/SLOF/tree/ext4
> Tested with the same image. Looks good. 


Thanks for testing. But it is still bizarre behaviour, why do we end up
there anyway...


>> What I still do not understand is why GRUB is using ext2 from SLOF, it
>> should parse ext4 itself :-/
> 
> Here is the fs information.
> 
> 
> Filesystem volume name:   <none>
> Last mounted on:          /
> Filesystem UUID:          8d53f6b4-ffc2-4d8f-bd09-67ac97d7b0c5
> Filesystem magic number:  0xEF53
> Filesystem revision #:    1 (dynamic)
> Filesystem features:      has_journal ext_attr resize_inode dir_index 
> filetype needs_recovery extent flex_bg sparse_super large_file huge_file 
> uninit_bg dir_nlink extra_isize


huh, this one does not have 64bit like mine, I blindly assumed that by
2020 everything would be using that. Well that explains the bug. And
yours also has uninit_bg (the whole idea of this flag is not obvious but
ok).


> Filesystem flags:         unsigned_directory_hash 
> Default mount options:    user_xattr acl
> Filesystem state:         clean
> Errors behavior:          Continue
> Filesystem OS type:       Linux
> Inode count:              3127296
> Block count:              12582912
> Reserved block count:     552210
> Free blocks:              7907437
> Free inodes:              2863361
> First block:              0
> Block size:               4096
> Fragment size:            4096


Mine here has:
Group descriptor size:    64

so there is no "hi" part and this is what my fix now handles (0x32 vs.
0x20 was not the problem actually).

Did you do this on purpose or the installer did it? :)

Anyway, I'd like to get this particular disk image to understand why on
earth it is using the ext2 package from SLOF. Thanks,


> Reserved GDT blocks:      1021
> Blocks per group:         32768
> Fragments per group:      32768
> Inodes per group:         8144
> Inode blocks per group:   509
> Flex block group size:    16
> Filesystem created:       Wed Dec 14 15:40:55 2016
> Last mount time:          Wed Feb 19 08:06:52 2020
> Last write time:          Wed Feb 19 08:06:46 2020
> Mount count:              1863
> Maximum mount count:      -1
> Last checked:             Fri Nov 23 19:09:13 2018
> Check interval:           0 (<none>)
> Lifetime writes:          883 GB
> Reserved blocks uid:      0 (user root)
> Reserved blocks gid:      0 (group root)
> First inode:              11
> Inode size:             256
> Required extra isize:     28
> Desired extra isize:      28
> Journal inode:            8
> Default directory hash:   half_md4
> Directory Hash Seed:      f7cb5863-4885-47b6-b24b-369df6a3b1a4
> Journal backup:           inode blocks
> Journal features:         journal_incompat_revoke
> Journal size:             128M
> Journal length:           32768
> Journal sequence:         0x0004beb2
> 
> Thanks,
> 
> C.
> 
>>
>>>
>>>
>>>>
>>>> "slash not found" is still there though. 
>>
>>
>> Yeah I see these but they are harmless as far as I can tell.
>>
>>
>>
>>>>
>>>> Cheers,
>>>>
>>>> C.
>>>>
>>>>
>>>> From 92dc9f6dc7c6434419306d5a382adb42169b712a Mon Sep 17 00:00:00 2001
>>>> From: =?UTF-8?q?C=C3=A9dric=20Le=20Goater?= <address@hidden>
>>>> Date: Tue, 18 Feb 2020 13:54:54 +0100
>>>> Subject: [PATCH] ext2: Fix 64bit inode number
>>>> MIME-Version: 1.0
>>>> Content-Type: text/plain; charset=UTF-8
>>>> Content-Transfer-Encoding: 8bit
>>>>
>>>> Fixes: f12149908705 ("ext2: Read all 64bit of inode number")
>>>> Signed-off-by: Cédric Le Goater <address@hidden>
>>>> ---
>>>>  slof/fs/packages/ext2-files.fs | 2 +-
>>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>>
>>>> diff --git a/slof/fs/packages/ext2-files.fs 
>>>> b/slof/fs/packages/ext2-files.fs
>>>> index b6a7880bd88e..f1d9fdfd67e2 100644
>>>> --- a/slof/fs/packages/ext2-files.fs
>>>> +++ b/slof/fs/packages/ext2-files.fs
>>>> @@ -152,7 +152,7 @@ CONSTANT /ext4-ee
>>>>    dup
>>>>    8 + l@-le               \ reads bg_inode_table_lo
>>>>    swap 28 + l@-le         \ reads bg_inode_table_hi
>>>> -  32 lshift or
>>>> +  32 rshift or
>>>>    block-size @ *          \ # in group, inode table
>>>>    swap inode-size @ * + xlsplit seek drop  inode @ inode-size @ read drop
>>>>  ;
>>>>
>>>
>>
> 

-- 
Alexey