Re: [Xen-devel] Pygrub on ARM64

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Thu, 2016-02-25 at 11:12 +0000, Ian Campbell wrote:
> On Thu, 2016-02-25 at 10:53 +0000, Ian Campbell wrote:
> > On Thu, 2016-02-25 at 10:47 +0000, Ian Campbell wrote:
> > > 
> > > > 
> > > > CentOS's first partition is fat to boot on efi systems, but it only
> > > > contains the grub efi binary. All the other partitions are xfs.
> > > > Does
> > > > pygrub support it?
> > > 
> > > I don't know, but pygrub is normally pretty vocal in these situations
> > > if it
> > > doesn't ("cannot find partition" style message), here it is
> > > apparently
> > > just
> > > silently hanging, which is pretty odd.
> > 
> > Here is what I get though:
> > 
> > # wget http://mirror.centos.org/altarch/7/isos/aarch64/CentOS-7-aarch64
> > .i
> > mg.xz
> > # xz -d CentOS-7-aarch64.img.xz
> > # pygrub CentOS-7-aarch64.img 
> > Traceback (most recent call last):
> >   File "/usr/local/bin/pygrub", line 926, in <module>
> >     raise RuntimeError, "Unable to find partition containing kernel"
> > RuntimeError: Unable to find partition containing kernel
> > 
> > Which is much more like what I would normally expect (and matches your
> > description of the image layout  think).
> > 
> > That was on a random x86_64 test box because that was all I had to
> > hand,
> > but I'd be pretty surprised if something like this behaved very
> > differently on arm64. 
> 
> But running on both arm32 arm64 it does indeed spin taking 100% of the
> CPU.
> 
> My guess would be a bug in the file system parsing code, perhaps
> something
> to do with alignment, which results in an infinite loop. The libfsimage
> backends originally came from grub (1/legacy) and is therefore only
> really
> has history on x86.
> 
> We certainly test pygrub on arm32 regularly, and I am sure it must have
> worked on arm64 when I was adding arm64 support to osstest (which is
> _still_ pending h/w to go into the colo!), so the basics (i..e simple
> partition tables with ext* partitions) must be ok, so I would hazzard a
> stab in the dark that the issue is in one of the things specific to these
> images, i.e. either the FAT or the XFS backend (if there even is an XFS
> backend, I didn't check).

Given:

# fdisk -l ./CentOS-7-aarch64.img 
WARNING: fdisk GPT support is currently new, and therefore in an experimental 
phase. Use at your own discretion.

Disk ./CentOS-7-aarch64.img: 12.9 GB, 12884901888 bytes, 25165824 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt


#         Start          End    Size  Type            Name
 1         2048       206847    100M  EFI System      EFI System Partition
 2       206848      1026047    400M  Linux filesyste Linux filesystem
 3      1026048      5122047      2G  Linux swap      Linux swap
 4      5122048     24373247    9.2G  Linux filesyste Linux filesystem

I see

    # python
    Python 2.7.5 (default, Nov 26 2015, 23:01:14) 
    [GCC 4.8.5 20150623 (Red Hat 4.8.5-4)] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> import fsimage
    >>> N = <xxxx>
    >>> fs = fsimage.open("CentOS-7-aarch64.img", N*512, "")

succeed for N = 2048 (ESP), fail (as expected) with "Operation not
supported" for N=1026048 (Swap) and hang for both N=206848 and N=5122048,
i.e. the two XFS filesystems in the image hang.

I'm afraid someone is probably going to have to dig
into tools/libfsimage/xfs/fsys_xfs.c to figure out what is going wrong. It
would probably be easiest (IMHO) to take Python out of the picture by
writing a simple main.c which uses libfsimage directly to open one of the
partitions (hardcoded offsets etc) and then use gdb on it to see why/where
it hangs.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel