On 2/20/20 2:50 AM, Alexey Kardashevskiy wrote:
>
>
> 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:
>>>>>>>>>>>>>
>>>>>>>>>>>>> g...@github.com: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? :)
I don't remember. I think I have kept the same disk image since 14.04
and did some fs resize.
> Anyway, I'd like to get this particular disk image to understand why on
> earth it is using the ext2 package from SLOF. Thanks,
Sure.
Thanks,
C.
>
>> 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?= <c...@kaod.org>
>>>>> 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 <c...@kaod.org>
>>>>> ---
>>>>> 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
>>>>> ;
>>>>>
>>>>
>>>
>>
>
