Bad parameter to boot GuixSD in a VM

Bad parameter to boot GuixSD in a VM

[良ϖ]

Hi,

I've followed instructions on this page:
https://www.gnu.org/software/guix/manual/html_node/Installing-GuixSD-in-a-VM.html

Howeverpoint 3 ("Boot the USB installation image in an VM: ") gets:

qemu-system-x86_64: -net default: Invalid parameter 'default'

If I remove that parameter I get another error:

WARNING: Image format was not specified for
'guixsd-usb-install-0.12.0.x86_64-linux' and probing guessed raw.
         Automatically detecting the format is dangerous for raw
images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.

Any ideas how I could solve that? Thanks in advance,

piotr

Re: Bad parameter to boot GuixSD in a VM

[Ludovic Courtès]

Hello,

良ϖ <p.de.boisset@gmail.com> skribis:

> I've followed instructions on this page:
> https://www.gnu.org/software/guix/manual/html_node/Installing-GuixSD-in-a-VM.html
>
> Howeverpoint 3 ("Boot the USB installation image in an VM: ") gets:
>
> qemu-system-x86_64: -net default: Invalid parameter 'default'

This section should read:

  qemu-system-x86_64 -m 1024 -smp 1 \
    -net user -net nic,model=virtio -boot menu=on \
    -drive file=guixsd.img \
    -drive file=guixsd-usb-install-@value{VERSION}.@var{system}

(It’s a typo in the manual fixed in commit
d36b8457d04286b4db0543656eed69ae050ac783.)

> If I remove that parameter I get another error:
>
> WARNING: Image format was not specified for
> 'guixsd-usb-install-0.12.0.x86_64-linux' and probing guessed raw.
>          Automatically detecting the format is dangerous for raw
> images, write operations on block 0 will be restricted.
>          Specify the 'raw' format explicitly to remove the restrictions.

This is just a warning.

However, you really need networking support in the VM to install GuixSD.

HTH!

Ludo’.

Re: Bad parameter to boot GuixSD in a VM

[Miroslav Rovis]

[-- Attachment #1: Type: text/plain, Size: 4971 bytes --]

On 170410-14:50+0200, Ludovic Courtès wrote:
> Hello,
> 
> 良ϖ <p.de.boisset@gmail.com> skribis:
> 
> > I've followed instructions on this page:
> > https://www.gnu.org/software/guix/manual/html_node/Installing-GuixSD-in-a-VM.html
> >
> > Howeverpoint 3 ("Boot the USB installation image in an VM: ") gets:
> >
> > qemu-system-x86_64: -net default: Invalid parameter 'default'
> 
> This section should read:
> 
>   qemu-system-x86_64 -m 1024 -smp 1 \
>     -net user -net nic,model=virtio -boot menu=on \
>     -drive file=guixsd.img \
>     -drive file=guixsd-usb-install-@value{VERSION}.@var{system}
> 
> (It’s a typo in the manual fixed in commit
> d36b8457d04286b4db0543656eed69ae050ac783.)
> 
> > If I remove that parameter I get another error:
> >
> > WARNING: Image format was not specified for
> > 'guixsd-usb-install-0.12.0.x86_64-linux' and probing guessed raw.
> >          Automatically detecting the format is dangerous for raw
> > images, write operations on block 0 will be restricted.
> >          Specify the 'raw' format explicitly to remove the restrictions.
> 
> This is just a warning.
> 
> However, you really need networking support in the VM to install GuixSD.

Trying to understand the above (such as the manual in question
is probably where I'll link to below...), but...

..But I followed the guide to try and run Guix from VM:
https://www.gnu.org/software/guix/manual/html_node/Installing-GuixSD-in-a-VM.html#Installing-GuixSD-in-a-VM

and, this is from yesterday when I did my tentative installing and
running:

$ ls -ltrh guixsd.img
-rw-r--r-- 1 miro miro 193K 2017-04-10 04:45 guixsd.img
$

( created as the page says:
qemu-img create -f qcow2 guixsd.img 5G
)

And this is the script (installed in /usr/local/bin) that I used, and
will try and use again so the question is more complete:

=-=--===-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

#!/bin/sh
exec qemu-system-x86_64 \
		-m 1024 -smp 1 \
		-device virtio-net,netdev=internet \
		-netdev \
			bridge,br=br0,id=internet,helper=/usr/libexec/qemu-bridge-helper \
		-boot menu=on \
		-drive file=guixsd.img \
		-drive file=guixsd-usb-install-0.12.0.x86_64-linux \
		-monitor stdio

=-=--===-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

... (let me retry before sending this) ...

So, it goes like this:

$ GuixVM02.sh
WARNING: Image format was not specified for 'guixsd-usb-install-0.12.0.x86_64-linux' and probing guessed raw.
         Automatically detecting the format is dangerous for raw images, write operations on block 0 will be restricted.
         Specify the 'raw' format explicitly to remove the restrictions.
QEMU 2.8.0 monitor - type 'help' for more information
(qemu)

and I press Esc (not F12 like the manual says, or is that changed/corrected
now?, let me see, no it's not, it still says F12, and my Qemu said Esc), and I chose 2, like the manual says, and it is booting now...

But it's so slow...

I think I need to add "-enable kvm". That got the VM's of Devuan, Heads,
Refracta, Gentoo very fast.

But, even though, and I'll paste agin from the prompt of the host (the
host is my Gentoo machine):

(qemu) info network
virtio-net-pci.0: index=0,type=nic,model=virtio-net-pci,macaddr=52:54:00:12:34:56
 \ internet: index=0,type=tap,helper=/usr/libexec/qemu-bridge-helper,br=br0
(qemu)

[even though] the network is there, I still have, now I have to manually
copy (I mean: by typing):

root@gnu ~# ping www.gnu.org
ping: unknown host
root@gnu ~#

Previously I ran "ip a", nothing really shows... And afterwards I tried:

root@gnu ~# curl https://www.gnu.org
root@gnu ~# links https://www.gnu.org
root@gnu ~# elinks https://www.gnu.org
root@gnu ~# lynx https://www.gnu.org

but none of those seems to be installed.

In short, no network in the Guix guest...

And I was courious, why are you suggesting/recommending (in that manual)
the old:
 -net ...
instead of the new:
 -netdev ...
? The Qemu devs are firm that the new is better, IIUC.

Let me try another script:

=-=--===-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

#!/bin/sh
exec qemu-system-x86_64 \
		-machine type=q35,accel=kvm \
		-enable-kvm \
		-cpu host \
		-device virtio-net,netdev=internet \
		-netdev \
			bridge,br=br0,id=internet,helper=/usr/libexec/qemu-bridge-helper \
		-m 4196M \
		-monitor stdio \
		-boot menu=on \
		-drive file=guixsd.img \
		-drive file=guixsd-usb-install-0.12.0.x86_64-linux 

=-=--===-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Oh, yes! This is maybe 10 times faster!

But, still no network... Hmmmh!

It's similar to the already reported above, regarding the network, basically.

Also the guixsd hasn't changed in the least. Same size, same timestamp.
Untouched by my trials.

Any ideas what to try?

-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Bad parameter to boot GuixSD in a VM

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 3069 bytes --]

On Tue, Apr 11, 2017 at 10:38:44PM +0200, Miroslav Rovis wrote:

Hi, thanks for the detailed feedback!

In general, the instructions in the manual related to QEMU are the
simplest QEMU invocations that will work for basic use cases. They are
intended to be something that a person without QEMU experience can use
to boot GuixSD in a virtualized environment. We assume that users will
adapt these examples to their use case if they plan to virtualize GuixSD
in production.

> root@gnu ~# ping www.gnu.org
> ping: unknown host
> root@gnu ~#
>
> Previously I ran "ip a", nothing really shows... And afterwards I tried:
> 
> root@gnu ~# curl https://www.gnu.org
> root@gnu ~# links https://www.gnu.org
> root@gnu ~# elinks https://www.gnu.org
> root@gnu ~# lynx https://www.gnu.org
> 
> but none of those seems to be installed.
> 
> In short, no network in the Guix guest...

There is a built-in network client `guix download` that you could try.

There was (is?) a bug related to name resolution failures being cached
for too long in certain cases:

<https://bugs.gnu.org/22209>

So, I connect to a well-known IP address like 8.8.8.8 in order to test
the network.

As an aside, the unprivileged "user mode" QEMU networking system doesn't
support ICMP, so if you were using that, ping won't work.

> And I was courious, why are you suggesting/recommending (in that manual)
> the old:
>  -net ...
> instead of the new:
>  -netdev ...
> ? The Qemu devs are firm that the new is better, IIUC.

I looked into this previously, and I decided to keep the old '-net user'
syntax in the examples we provide.

My reason is that '-netdev user' requires the user to specify a unique
'id' parameter, while '-net user' does not.

Since both syntaxes provide the same "user mode network stack", I
thought that the older and simpler syntax was better for the examples in
the manual. Remember, these are supposed to be the simplest examples
that will boot GuixSD with a network connection.

Is there some limitation with '-net user' that we should consider for
the examples in the manual?

> Let me try another script:
> 
> =-=--===-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 
> #!/bin/sh
> exec qemu-system-x86_64 \
> 		-machine type=q35,accel=kvm \
> 		-enable-kvm \
> 		-cpu host \
> 		-device virtio-net,netdev=internet \
> 		-netdev \
> 			bridge,br=br0,id=internet,helper=/usr/libexec/qemu-bridge-helper \
> 		-m 4196M \
> 		-monitor stdio \
> 		-boot menu=on \
> 		-drive file=guixsd.img \
> 		-drive file=guixsd-usb-install-0.12.0.x86_64-linux 
> 
> =-=--===-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 
> Oh, yes! This is maybe 10 times faster!

Yes, KVM will do that :)

> But, still no network... Hmmmh!

Hm, I'm not sure what's wrong. I assume that the TAP device is properly
configured in your host system?

The nice thing about the user-mode QEMU networking is that it doesn't
require any special configuration on the host. But of course it's very
limited...

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Bad parameter to boot GuixSD in a VM

[Miroslav Rovis]

[-- Attachment #1: Type: text/plain, Size: 6261 bytes --]

A part reply (since I'm not sure to find time soon for more detailed
reply on some of the issues broght up, which I would very much like, but
not sure will be able to).

On 170411-21:00-0400, Leo Famulari wrote:
> On Tue, Apr 11, 2017 at 10:38:44PM +0200, Miroslav Rovis wrote:
> 
> Hi, thanks for the detailed feedback!
Your're most welcome. I'm really glad you find it useful. 

> In general, the instructions in the manual related to QEMU are the
> simplest QEMU invocations that will work for basic use cases. They are
> intended to be something that a person without QEMU experience can use
> to boot GuixSD in a virtualized environment. We assume that users will
> adapt these examples to their use case if they plan to virtualize GuixSD
> in production.
I see.

> 
> > root@gnu ~# ping www.gnu.org
> > ping: unknown host
> > root@gnu ~#
> >
> > Previously I ran "ip a", nothing really shows... And afterwards I tried:
> > 
> > root@gnu ~# curl https://www.gnu.org
> > root@gnu ~# links https://www.gnu.org
> > root@gnu ~# elinks https://www.gnu.org
> > root@gnu ~# lynx https://www.gnu.org
> > 
> > but none of those seems to be installed.
> > 
> > In short, no network in the Guix guest...
> 
> There is a built-in network client `guix download` that you could try.
I will, as soon as I find time to.

Mainly this `guix download` I have to leave for later... (That's the
part I'll possibly go back to, in the future. Possibly.)

> There was (is?) a bug related to name resolution failures being cached
> for too long in certain cases:
> 
> <https://bugs.gnu.org/22209>
Looked it up, but not enough to understand it more fully... yet.
(another part for later)

> So, I connect to a well-known IP address like 8.8.8.8 in order to test
> the network.
Oh, no, just not Schmoog the Schmoogle, pls. :-) I don't recommend the
Schmoog to anybody. My opinion. Freely disregard it of course. However,
few people can dispute that the Schmoog are the toughest surveillors on
the world, that Sergey and Larry Schmoog made most of their moneys out
of, essentially spying on everybody they could lay their tentacles on
their electronic communications of any kind, so essentially they're
spies, and they made their moneys with the aforesaid spying, and that
their (mostly unwilling and unwitting) payers are, essentially tax
payers via almost any, even almost every country's of the world secret
agencies, from NSA to China's SA (whichever the name of it)... So...

But again, I'm only reminding about the facts/claims aforementioned, and
anybody's opinion is free to differ. I'm done reminding. Moving on
(unless there should be a need to consider replies in regard).

> As an aside, the unprivileged "user mode" QEMU networking system doesn't
> support ICMP, so if you were using that, ping won't work.
> 
> > And I was courious, why are you suggesting/recommending (in that manual)
> > the old:
> >  -net ...
> > instead of the new:
> >  -netdev ...
> > ? The Qemu devs are firm that the new is better, IIUC.
> 
> I looked into this previously, and I decided to keep the old '-net user'
> syntax in the examples we provide.
> 
> My reason is that '-netdev user' requires the user to specify a unique
> 'id' parameter, while '-net user' does not.
May be. I'm not even advanced with Qemu... More below...

> Since both syntaxes provide the same "user mode network stack", I
> thought that the older and simpler syntax was better for the examples in
> the manual. Remember, these are supposed to be the simplest examples
> that will boot GuixSD with a network connection.
> 
> Is there some limitation with '-net user' that we should consider for
> the examples in the manual?
Not that I know of, but I did find, back a few months ago when I
dedicated hours upon hours for my first long reading of Qemu manual, and
wikis in various places about Qemu, that it was much better (the cited
reasons I don't remember clearly at this time) to use "-netdev ...".

> > Let me try another script:
> > 
> > =-=--===-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > 
> > #!/bin/sh
> > exec qemu-system-x86_64 \
> > 		-machine type=q35,accel=kvm \
> > 		-enable-kvm \
> > 		-cpu host \
> > 		-device virtio-net,netdev=internet \
> > 		-netdev \
> > 			bridge,br=br0,id=internet,helper=/usr/libexec/qemu-bridge-helper \
> > 		-m 4196M \
> > 		-monitor stdio \
> > 		-boot menu=on \
> > 		-drive file=guixsd.img \
> > 		-drive file=guixsd-usb-install-0.12.0.x86_64-linux 
> > 
> > =-=--===-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> > 
> > Oh, yes! This is maybe 10 times faster!
> 
> Yes, KVM will do that :)
> 
> > But, still no network... Hmmmh!
> 
> Hm, I'm not sure what's wrong. I assume that the TAP device is properly
> configured in your host system?
Yes it is. If it wasn't, how would I be able to connect to internet my
VMs running Devuan, Refracta, Tails, Gentoo, Heads (each in their time,
I run simple Qemu one at a time), if it wasn't...

> The nice thing about the user-mode QEMU networking is that it doesn't
> require any special configuration on the host. But of course it's very
> limited...
Yes it is, I remember that much. Actually now I'll tell the "more" which I
promised above.

I essentially created my scripts following various tutuorials and
copying btwn various scripts what got the previous ones running...  ;-)
Wow! how clever of me, how expertly done  ;) ;) ;) ;) 

And I actually wasn't able to get the use more networking! I think with
none or hardly one of the various VMs mentioned (and if I did with one
of the above, I don't remember which one it was anymore)...

I don't understand much at all (and maybe won't any time soon, nor later
either) on the programming side of it... But I do start those few VMs of
various kind (mentioned above) without much issues most of them these
days, and half a year ago, I wasn't able to, say, get the network
working on any of the ISOs I was trying back then...

I wish in some more time that I would learn more and be able to test for
good FOSS like Guix!

Regards!

-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Bad parameter to boot GuixSD in a VM

[Miroslav Rovis]

[-- Attachment #1: Type: text/plain, Size: 823 bytes --]

ERRATA

On 170412-13:13+0200, Miroslav Rovis wrote:
...
> On 170411-21:00-0400, Leo Famulari wrote:
> > On Tue, Apr 11, 2017 at 10:38:44PM +0200, Miroslav Rovis wrote:
...
> And I actually wasn't able to get the use more networking! I think with
> none or hardly one of the various VMs mentioned (and if I did with one
> of the above, I don't remember which one it was anymore)...

That's a typo. I meant to write:

And I actually wasn't able to get the user mode networking! ...

I meant the user mode networking or the slirp networking.

BTW, Leo, I just read a little here:
https://en.wikipedia.org/wiki/Slirp
which, IIUC is what you offer to users with "-net ...",
but no, I haven't found why the "-netdev ..." is much better.

-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Bad parameter to boot GuixSD in a VM

[Leo Famulari]

[-- Attachment #1: Type: text/plain, Size: 531 bytes --]

On Wed, Apr 12, 2017 at 01:13:29PM +0200, Miroslav Rovis wrote:
> On 170411-21:00-0400, Leo Famulari wrote:
> > Hm, I'm not sure what's wrong. I assume that the TAP device is properly
> > configured in your host system?
> Yes it is. If it wasn't, how would I be able to connect to internet my
> VMs running Devuan, Refracta, Tails, Gentoo, Heads (each in their time,
> I run simple Qemu one at a time), if it wasn't...

Okay, I'll try to find time today to try using a TAP device on my
system to see if I can reproduce your issue.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: Bad parameter to boot GuixSD in a VM

[Miroslav Rovis]

[-- Attachment #1: Type: text/plain, Size: 1091 bytes --]

On 170412-11:26-0400, Leo Famulari wrote:
> On Wed, Apr 12, 2017 at 01:13:29PM +0200, Miroslav Rovis wrote:
> > On 170411-21:00-0400, Leo Famulari wrote:
> > > Hm, I'm not sure what's wrong. I assume that the TAP device is properly
> > > configured in your host system?
> > Yes it is. If it wasn't, how would I be able to connect to internet my
> > VMs running Devuan, Refracta, Tails, Gentoo, Heads (each in their time,
> > I run simple Qemu one at a time), if it wasn't...
> 
> Okay, I'll try to find time today to try using a TAP device on my
> system to see if I can reproduce your issue.

Hasn't happened yet... I looked up another one or two times earlier, and
I checked right now:

https://www.gnu.org/software/guix/manual/html_node/Installing-GuixSD-in-a-VM.html#Installing-GuixSD-in-a-VM

It's still only slurp offered, I think...

But it's fine. FOSS holds no one under obligation. And I was just
wishful to see it done... Probably I have to be relinquishing immediate
hope about it now.

-- 
Miroslav Rovis
Zagreb, Croatia
https://www.CroatiaFidelis.hr

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]