avoiding X sounds great. but i guess then it's probably a lot of work.
unless you just go native! :)
As usual for me, i have longterm plans for that usecase :-)
drawterm supposes one Plan9 machine and one machine with any other OS +
drawterm.
I would like to have Plan9 in Xen with a support of peripherals as much as
possible, and without X.
Linux (or something similar) has to be minimal Dom0
On
> Plan9 was working in an X session.
> But since Xen 4.10.x the framebuffer support stoped to work, i don't know
> why, it seems only VNC is supported now.
> But Xen framebuffer uses Qemu, so i was anyway going to reimplement the
> graphic output via DRM.
why not use drawterm instead?
You are welcome, i hope it helps.
Can i ask, why do you want to migrate from Xen to Qemu?
I am triyint to do the opposite, to use Xen only without any part of Qemu.
Some time ago i made support of Xen keyboard and framebuffer, and full
Plan9 was working in an X session.
But since Xen 4.10.x the fr
Thanks for your response, and apologies for the delay in replying.
I was thinking if it would also be possible to migrate the current
Plan 9 setup that is used with Xen to Qemu.
Thanks.
On Mon, Jul 8, 2019 at 10:53 AM Alexander Sychev wrote:
>
> Hi,
>
> Xen now looks for a section with name '__xe
Hi,
Xen now looks for a section with name '__xen_guest' starting from a second
section.
A simple workaround is to make two '__xen_guest' sections (with a small
patch of xenelf.c):
diff -r xen/mkfile xen2/mkfile
105c107,108
< ./xenelf.$cputype $target.elf $target __xen_guest ''$XENELF''
---
I had Plan 9 running on Xen 7.5. After upgrading to Xen 8.0 Plan 9
won't boot any more.
I get a 'No bootable device' message displayed.
The system was previously setup by someone else.
If I can, I would like to try and make it run on Xen 8.0.
Any tips would be much appreciated.
