GNU bug report logs -
#29281
[PATCH] system: vm: Use linux-libre for system-disk-image.
Previous Next
Reported by: Mathieu Othacehe <m.othacehe <at> gmail.com>
Date: Mon, 13 Nov 2017 07:23:02 UTC
Severity: normal
Tags: patch
Done: Mathieu Othacehe <m.othacehe <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 29281 in the body.
You can then email your comments to 29281 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
guix-patches <at> gnu.org
:
bug#29281
; Package
guix-patches
.
(Mon, 13 Nov 2017 07:23:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Mathieu Othacehe <m.othacehe <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
guix-patches <at> gnu.org
.
(Mon, 13 Nov 2017 07:23:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
* gnu/system/vm.scm (system-disk-image): Use linux-libre instead of user
defined kernel that may not be emulable and/or function with base-initrd.
---
gnu/system/vm.scm | 1 +
1 file changed, 1 insertion(+)
diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
index 44246083b..c55df3013 100644
--- a/gnu/system/vm.scm
+++ b/gnu/system/vm.scm
@@ -422,6 +422,7 @@ to USB sticks meant to be read-only."
;; Since this is meant to be used on real hardware, don't
;; install QEMU networking or anything like that. Assume USB
;; mass storage devices (usb-storage.ko) are available.
+ (kernel linux-libre)
(initrd (lambda (file-systems . rest)
(apply base-initrd file-systems
#:volatile-root? #t
--
2.15.0
Information forwarded
to
guix-patches <at> gnu.org
:
bug#29281
; Package
guix-patches
.
(Mon, 13 Nov 2017 09:39:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 29281 <at> debbugs.gnu.org (full text, mbox):
Hi,
Mathieu Othacehe <m.othacehe <at> gmail.com> skribis:
> * gnu/system/vm.scm (system-disk-image): Use linux-libre instead of user
> defined kernel that may not be emulable and/or function with base-initrd.
I would rather not override ‘linux-libre’. I find it quite useful to be
able to ‘guix system vm’ with a custom kernel; that’s one of the things
one might want to test in a VM before rebooting.
What was the use case and rationale for you?
Thanks,
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#29281
; Package
guix-patches
.
(Mon, 13 Nov 2017 09:50:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 29281 <at> debbugs.gnu.org (full text, mbox):
Hi Ludo,
> What was the use case and rationale for you?
The problematic use case was to try to produce a GuixSD arm installer
for beaglebone black. The kernel linux-libre-arm-omap2plus I'm planning
to use can't be used in qemu.
Plus, I'd like to use a raw-initrd because linux-libre-arm-omap2plus is
quite a light kernel configuration. As system-disk-image asks for
base-initrd, the required modules won't be find during image
construction with omap kernel.
Do you have another idea on how to overcome this issue ?
Thanks for the quick review,
Mathieu
Information forwarded
to
guix-patches <at> gnu.org
:
bug#29281
; Package
guix-patches
.
(Mon, 13 Nov 2017 10:24:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 29281 <at> debbugs.gnu.org (full text, mbox):
Hello,
Mathieu Othacehe <m.othacehe <at> gmail.com> skribis:
>> What was the use case and rationale for you?
>
> The problematic use case was to try to produce a GuixSD arm installer
> for beaglebone black. The kernel linux-libre-arm-omap2plus I'm planning
> to use can't be used in qemu.
Oh, why is that? You mean qemu-system-arm running natively on the BBB,
right?
> Plus, I'd like to use a raw-initrd because linux-libre-arm-omap2plus is
> quite a light kernel configuration. As system-disk-image asks for
> base-initrd, the required modules won't be find during image
> construction with omap kernel.
Perhaps we should change ‘system-disk-image’ to use a more minimalistic
initrd since all it needs is those virtio* drivers?
Thanks for explaining!
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#29281
; Package
guix-patches
.
(Mon, 13 Nov 2017 10:48:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 29281 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>
> Oh, why is that? You mean qemu-system-arm running natively on the BBB,
> right?
>
Yes, when running qemu-system-arm you have only a limited set of available
machines (qemu-system-arm -M help).
BBB isn't one of them, but as there are only about 50 emulable machines, it
will be the case for many other boards :(
In a future patch, I'll adapt "load-in-linux-vm" to use "-M virt" for
qemu-system-arm because contrary to most boards,
it works well with linux-libre, allows up to 8 CPU, virtio (see
https://wiki.qemu.org/Documentation/Platforms/ARM) ...
However, I don't think qemu virt machine will boot with every specific arm
kernel a user might end up using
on his target.
Perhaps we should change ‘system-disk-image’ to use a more minimalistic
> initrd since all it needs is those virtio* drivers?
>
That would be an option for the initrd, but the kernel problem above
remains :)
Thanks !
2017-11-13 11:23 GMT+01:00 Ludovic Courtès <ludo <at> gnu.org>:
> Hello,
>
> Mathieu Othacehe <m.othacehe <at> gmail.com> skribis:
>
> >> What was the use case and rationale for you?
> >
> > The problematic use case was to try to produce a GuixSD arm installer
> > for beaglebone black. The kernel linux-libre-arm-omap2plus I'm planning
> > to use can't be used in qemu.
>
> Oh, why is that? You mean qemu-system-arm running natively on the BBB,
> right?
>
> > Plus, I'd like to use a raw-initrd because linux-libre-arm-omap2plus is
> > quite a light kernel configuration. As system-disk-image asks for
> > base-initrd, the required modules won't be find during image
> > construction with omap kernel.
>
> Perhaps we should change ‘system-disk-image’ to use a more minimalistic
> initrd since all it needs is those virtio* drivers?
>
> Thanks for explaining!
>
> Ludo’.
>
[Message part 2 (text/html, inline)]
Information forwarded
to
guix-patches <at> gnu.org
:
bug#29281
; Package
guix-patches
.
(Mon, 13 Nov 2017 10:55:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 29281 <at> debbugs.gnu.org (full text, mbox):
Mathieu Othacehe <m.othacehe <at> gmail.com> skribis:
>>
>> Oh, why is that? You mean qemu-system-arm running natively on the BBB,
>> right?
>>
>
> Yes, when running qemu-system-arm you have only a limited set of available
> machines (qemu-system-arm -M help).
> BBB isn't one of them, but as there are only about 50 emulable machines, it
> will be the case for many other boards :(
So the kernel you built doesn’t boot at all in “qemu-system-arm -M virt”?
> In a future patch, I'll adapt "load-in-linux-vm" to use "-M virt" for
> qemu-system-arm because contrary to most boards,
> it works well with linux-libre, allows up to 8 CPU, virtio (see
> https://wiki.qemu.org/Documentation/Platforms/ARM) ...
OK.
> However, I don't think qemu virt machine will boot with every specific arm
> kernel a user might end up using
> on his target.
I see.
> Perhaps we should change ‘system-disk-image’ to use a more minimalistic
>> initrd since all it needs is those virtio* drivers?
>>
>
> That would be an option for the initrd, but the kernel problem above
> remains :)
Right.
I can’t think of a good solution right now. Perhaps we could simply
hard-code ARM-specific code?
(operating-system
(inherit os)
(kernel (if targeting-arm?
linux-libre-arm
(operating-system-kernel os)))
;; …
)
In practice ‘targeting-arm?’ could be checking (%current-system) and
(%current-target-system), which is not entirely correct but good enough,
or, better yet, use that ‘let-system’ construct I sent you recently to
determine the actual target system.
Thoughts?
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#29281
; Package
guix-patches
.
(Mon, 13 Nov 2017 11:55:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 29281 <at> debbugs.gnu.org (full text, mbox):
> So the kernel you built doesn’t boot at all in “qemu-system-arm -M virt”?
Nope it does not with this command :
--8<---------------cut here---------------start------------->8---
qemu-system-arm -M virt -kernel
/gnu/store/13jqdcykaarbxzwxnryqinljcjh3k75g-linux-libre-arm-omap2plus-4.13.4/zImage
-nographic
--8<---------------cut here---------------end--------------->8---
> In practice ‘targeting-arm?’ could be checking (%current-system) and
> (%current-target-system), which is not entirely correct but good enough,
> or, better yet, use that ‘let-system’ construct I sent you recently to
> determine the actual target system.
>
> Thoughts?
Sure it seems like a good idea, until we find better ! I'll try to setup
let-system and propose an updated patch.
Thanks for your help :)
Mathieu
Information forwarded
to
guix-patches <at> gnu.org
:
bug#29281
; Package
guix-patches
.
(Mon, 13 Nov 2017 13:48:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 29281 <at> debbugs.gnu.org (full text, mbox):
Mathieu Othacehe <m.othacehe <at> gmail.com> skribis:
>> So the kernel you built doesn’t boot at all in “qemu-system-arm -M virt”?
>
> Nope it does not with this command :
>
> qemu-system-arm -M virt -kernel
> /gnu/store/13jqdcykaarbxzwxnryqinljcjh3k75g-linux-libre-arm-omap2plus-4.13.4/zImage
> -nographic
Oh, ARM is weird. :-)
>> In practice ‘targeting-arm?’ could be checking (%current-system) and
>> (%current-target-system), which is not entirely correct but good enough,
>> or, better yet, use that ‘let-system’ construct I sent you recently to
>> determine the actual target system.
>>
>> Thoughts?
>
> Sure it seems like a good idea, until we find better ! I'll try to setup
> let-system and propose an updated patch.
I can polish the ‘let-system’ bits, because maybe that wasn’t fully
baked. I’ll send it to guix-patches ASAP so you can review. Sounds
good?
Thanks,
Ludo’.
Information forwarded
to
guix-patches <at> gnu.org
:
bug#29281
; Package
guix-patches
.
(Mon, 13 Nov 2017 14:23:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 29281 <at> debbugs.gnu.org (full text, mbox):
> I can polish the ‘let-system’ bits, because maybe that wasn’t fully
> baked. I’ll send it to guix-patches ASAP so you can review. Sounds
> good?
Sounds perfect !
Mathieu
bug closed, send any further explanations to
29281 <at> debbugs.gnu.org and Mathieu Othacehe <m.othacehe <at> gmail.com>
Request was from
Mathieu Othacehe <m.othacehe <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Wed, 29 Nov 2017 15:33:01 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 28 Dec 2017 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 6 years and 92 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.