[Pkg-xen-devel] Bug#922033: Bug#922033: xen: driver domain does not work
Hans van Kranenburg
hans at knorrie.org
Sat Feb 16 21:36:00 GMT 2019
On 2/16/19 1:41 PM, Hans van Kranenburg wrote:
> On 2/16/19 4:26 AM, Marek Marczykowski-Górecki wrote:
>> On Wed, Feb 13, 2019 at 02:27:18AM +0100, Hans van Kranenburg wrote:
>>> Creating new binary packages etc... is not an option anymore during the
>>> Buster freeze.
>>
>> Ok, I can carry myself a startup script calling actual xl directly. But
>> one thing would be very useful to have in buster - avoid starting
>> dom0 related services in guest. Otherwise even package installation
>> fails (if you happen to have the same version of xen packages in dom0
>> and domU). Would the below patch be acceptable?
>
> That's a good one yes. There's some optimization of checks already been
> done in branch wip.testme [1], e.g. [2], but those checks would indeed
> still not result in a noop in a domU. Nice find!
>
> I'll add your change later today, and resend it for review. I think the
> warning is not necessary, since a warning points at something that you
> should fix. This should just noop.
Actually, while looking at this again...
In the init script, we already have...
capability_check()
{
[ -e "/proc/xen/capabilities" ] || return 1
grep -q "control_d" /proc/xen/capabilities || return 1
return 0
}
...which gets called like this...
capability_check
case "$?" in
0) ;;
*) log_end_msg 255; exit ;;
esac
Looking at /proc/xen/capabilities and seeing if there's control_d inside
seems to be a more common way to check if this is a dom0.
It does log_end_msg 255 and 255 seems to be warning.
The upstream init script has...
# run this script only in dom0:
# no capabilities file in xenlinux domU kernel
# empty capabilities file in pv_ops domU kernel
if test -f /proc/xen/capabilities && \
! grep -q "control_d" /proc/xen/capabilities ; then
exit 0
fi
...which also doesn't look really good, since this exit 0 doesn't happen
when /proc/xen/capabilities does *not* exist, and the first domU I'm
looking inside here doesn't have it.
Can you show what happens exactly when 'package installation fails'?
> In domU:
> -# cat /sys/hypervisor/uuid
> d5ad9b8c-b230-4bba-a74d-04049d090a36
>
> In dom0:
> -# cat /sys/hypervisor/uuid
> 00000000-0000-0000-0000-000000000000
>
> Thanks,
> Hans
>
> [1] https://salsa.debian.org/xen-team/debian-xen/commits/wip.testme
> [2]
> https://salsa.debian.org/xen-team/debian-xen/commit/30c9a3c54332f34c515143b261514a04e1e1d13c
>
>> -----8<-----
>>
>> From: =?UTF-8?q?Marek=20Marczykowski-G=C3=B3recki?=
>> <marmarek at invisiblethingslab.com>
>> Subject: [PATCH] Do not start dom0 services if running inside domU
>>
>> Signed-off-by: Marek Marczykowski-Górecki <marmarek at invisiblethingslab.com>
>> ---
>> debian/xen-utils-common.xen.init | 5 +++++
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/debian/xen-utils-common.xen.init b/debian/xen-utils-common.xen.init
>> index 4b793d5ac2..d73e827514 100644
>> --- a/debian/xen-utils-common.xen.init
>> +++ b/debian/xen-utils-common.xen.init
>> @@ -26,6 +26,11 @@ if [ $? -ne 0 ]; then
>> exit 0
>> fi
>>
>> +if grep -q '[^0-]' /sys/hypervisor/uuid; then
>> + log_warning_msg "Xen guest detected"
>> + exit 0
>> +fi
>> +
>> XENCONSOLED="$ROOT"/bin/xenconsoled
>> XENCONSOLED_PIDFILE="/var/run/xenconsoled.pid"
>> XENSTORED="$ROOT"/bin/xenstored
>>
>
More information about the Pkg-xen-devel
mailing list