Hi there,
just came to try and boot a VM using the Xen i've building under LFS
and saw this in the bootloader log after the boot had failed:
# cat /media/sda5/root/bootloader.3.log
Using to parse /boot/grub/grub.cfg
Traceback (most recent call last):
File "/usr/lib/xen/bin/pygrub", line 928, i
On Tue, 23 Jul 2019 at 03:43, YOUNG, MICHAEL A. wrote:
> > Yes - this looks like a Py 2/3 compatibility issue. This particular one
> > is related to
> > https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=ff915c8cacc264ae1380d51fea07267b8308d7ba
> >
> > However, I can't explain why python i
Firstly, want to say how happy I was to see the reliance on Python2 go,
not least, as a Linux From Scratch builder, where Python3 is now part
of the "core OS", one doesn't have to also install Python2, however,
I grabbed your master branch last night (cb70a26) to try things out and
still fell foul
On Thu, 11 Apr 2019 at 18:29, Wei Liu wrote:
>
> ...
> Sure. I will write a patch.
>
> Wei.
Couple of other things I noticed after posting the original observation,
that might be of use in patching the documentation
1)
The tools/Makefile has a bare PYTHON EnvVar that isn't seemingly
replaced by
On Mon, 15 Apr 2019 at 17:24, Wei Liu wrote:
>
> On Sat, Apr 13, 2019 at 11:17:48AM +0800, Kevin Buckley wrote:
> > On Thu, 11 Apr 2019 at 18:29, Wei Liu wrote:
> > >
> > > ...
> > > Sure. I will write a patch.
> > >
> > > Wei.
> >
> Oh wait, I don't think there is anything to fix there. Those sentences
> look repetitive but they do say different things: in tools case, it says
> "repos will be cloned"; in stubdom case, it says "external packages
> will be downloaded. So they do reflect correctly what will happen.
>
Let me na
On Wed, 17 Apr 2019 at 22:51, Wei Liu wrote:
>
>
> Frankly I'm not a big fan of this approach -- you can potentially get
> different toolchain depending on how you build stuff. I would rather
> just document that for hypervisor build either python is available or
> you should specify PYTHON= when
I am looking to build a Xen from a downloaded source tree at commit cb70a26
In the tools/Makefile, there is this target at Line 204
.PHONY: qemu-xen-dir-force-update
qemu-xen-dir-force-update: qemu-xen-dir-find
set -ex; \
if [ "$(QEMU_UPSTREAM_REVISION)" ]; then \
On Fri, 19 Apr 2019 at 14:07, Kevin Buckley
wrote:
>
> I am actually thinking of installing a Python 2 and making the link to
> the bare /usr/bin/python point to that, just to see if I can get things
> to build.
So I did that and the hypervisor, tools and docs were all built
and
On Fri, 19 Apr 2019 at 14:19, Kevin Buckley
wrote:
>
> I am looking to build a Xen from a downloaded source tree at commit cb70a26
>
> In the tools/Makefile, there is this target at Line 204
>
> .PHONY: qemu-xen-dir-force-update
> qemu-xen-dir-force-update: qemu-xen-dir-f
Issuing a "make world" clobbers four directories within the
source tree
doc/man[1,5,7,8}
as part of the "make clean"
Those directories don't appear to be re-created during the
"make dist" within my recent build.
As the toplevel Makefile has
make world:
$(MAKE) clean
$(MAKE) dist
I fo
Hi there,
as part of some instructions I knocked up a while ago, when
adding Xen 4.9.0 into a Linux Fron Scratch system, I had
identified a way to determine which dependency sources
would be pulled down if Xen was built without disabling the
stubdom module.
As a result of recently revisiting my i
Hello again,
despite having built a Xen 4.13 with just Python3 on a
Linux From Scratch system,
http://youvegotbuckleys.org.nz/LFS/LFS-BOOK.html
specifically
http://youvegotbuckleys.org.nz/LFS/LFS-BOOK.html#ch-xen
and booted into the Dom0 (Linux 5.5.3, GCC 9.2.0, Python 3.8.1)
without issue
On Thu, 2 Apr 2020 at 20:56, Andrew Cooper wrote:
>
> We've got a fix in staging
>
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commitdiff;h=e19b4b3b55f84e0cfcc02fe5d66965969a81c965
>
> It hasn't been backported to the 4.13 stable tree yet.
>
> ~Andrew
Bingo!
I guess I must have missed that whe
Following on from some previous observations on building Xen from
source a Linux From Scratch system, I have some more feedback
when using a more up-to-date Xen and the most recent LFS.
On the back of trying to build Xen 4.12.2 on an LFS 9.0 system,
I've hit an issue in the way that the Xen M4 pyt
On Wed, 22 Jan 2020 at 20:36, Andrew Cooper wrote:
>
> On 19/01/2020 06:17, Kevin Buckley wrote:
> > Any clues then, as to whether this is another Python3 hangover for Xen ?
>
> Xen 4.13 (now released) is the first version of Xen with any serious
> form Python 3 compatibili
Bit more on this:
I created a different VBD-backed VM, containing an Ubuntu 14045 install,
on a CentOS 6.10 host, with Xen 4.10, and a 4.9.127 kernel, where the VM
boots up fine.
Back in my LinuxFromScratch environment I still see the bootloader lig
error message as before
Using to parse /boot/
run_grub(file, entry, fs, incfg["args"])
File "/usr/lib/xen/bin/pygrub", line 625, in run_grub
g = Grub(file, fs)
File "/usr/lib/xen/bin/pygrub", line 249, in __init__
self.read_config(file, fs)
File "/usr/lib/xen/bin/pygrub", line 460, in read_config
self.cf.parse(buf)
File "/usr/lib/python3.7/site-packages/grub/GrubConf.py", line 401, in parse
title_match = re.match('^menuentry ["\'](.*?)["\'] (.*){', l)
File "/usr/lib/python3.7/re.py", line 173, in match
return _compile(pattern, flags).match(string)
TypeError: cannot use a string pattern on a bytes-like object
Hmmm?
This looks like something a bit harder to transpose into
a "bytes" paradigm.
Any ideas as to why my pythin3 Grub works in some cases but not
in others?
Kevin Buckley.
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
Looking to build 4.14.0 on an LFS 10.0 system, so with GCC 10.2.0.
The "all warnings being treated as errors" I'm sure, will have been
picked up by now, but the issue with the man pages is something
I have been seeing for a while now.
The configure options are a little idiosyncratic but I can't s
On Sun, 20 Dec 2020 at 10:54, Kevin Buckley
wrote:
>
> Looking to build 4.14.0 on an LFS 10.0 system, so with GCC 10.2.0.
>
> The "all warnings being treated as errors" I'm sure, will have been
> picked up by now, but the issue with the man pages is something
> I
20 matches
Mail list logo
