EOMA68 Development Boards

[Louis Pearson]

lkcl, the developer of eoma68 is offering to send some early boards out to
people who
will be helping to port OS's to eoma68. I'm posting this here to see if
anyone is
interested in getting one of these to bring GuixSD to the eoma68. I
personally don't
know much about uboot, guix, or porting linux, so it would probably be a
poor decision
for me to get one. I am extremely interested in seeing GuixSD running on an
eoma68
though.

If there is anyone is interested I'll bring this up on the eoma68
(arm-netbook) mailing
list.

Re: Planning for the next release

[Ludovic Courtès]

Hello Guix!

An update on the release that never comes.  ;-)

The main remaining item is merging UEFI support in ‘version-0.13.0’:
.

The “Noteworthy bug fixes” section of ‘NEWS’ also needs to be improved.

Not a release blocker, but a kind of general blocker: we have a ‘guix
offload’ bug for which we need more testers and hackers to get better
debugging info: .

Help welcome on all these fronts!

Ludo’.

Re: EOMA68 Development Boards

[Mathieu Othacehe]

Hi Louis,

> If there is anyone is interested I'll bring this up on the eoma68
> (arm-netbook) mailing
> list.

I'm currently reworking GuixSD bootloader API. I think it would be great
to continue this work by porting GuixSD to an open-hardware platform.

So I'm definitely interested in getting one of these boards !

Thank,

Mathieu

Re: Planning for the next release

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hello Guix!
>
> An update on the release that never comes.  ;-)
>
> The main remaining item is merging UEFI support in ‘version-0.13.0’:
> .
>
> The “Noteworthy bug fixes” section of ‘NEWS’ also needs to be improved.

I’ll try to take care of this tonight.

> Not a release blocker, but a kind of general blocker: we have a ‘guix
> offload’ bug for which we need more testers and hackers to get better
> debugging info: .

I’ll try to give this a try either tonight or tomorrow.

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Planning for the next release

[Ludovic Courtès]

Hi!

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:
>
>> Hello Guix!
>>
>> An update on the release that never comes.  ;-)
>>
>> The main remaining item is merging UEFI support in ‘version-0.13.0’:
>> .

Marius already fixed this one.

>> The “Noteworthy bug fixes” section of ‘NEWS’ also needs to be improved.
>
> I’ll try to take care of this tonight.
>
>> Not a release blocker, but a kind of general blocker: we have a ‘guix
>> offload’ bug for which we need more testers and hackers to get better
>> debugging info: .
>
> I’ll try to give this a try either tonight or tomorrow.

Great!

Regardless of what happens with #26976, I can run “make release” and
upload the tarballs tomorrow, and presumably send out the announcement
on Monday.

How does that sound?

Thanks,
Ludo’.

Re: EOMA68 Development Boards

[Ludovic Courtès]

Hi Louis & Mathieu,

Mathieu Othacehe  skribis:

>> If there is anyone is interested I'll bring this up on the eoma68
>> (arm-netbook) mailing
>> list.
>
> I'm currently reworking GuixSD bootloader API. I think it would be great
> to continue this work by porting GuixSD to an open-hardware platform.
>
> So I'm definitely interested in getting one of these boards !

+1!  Mathieu has taken the lead on revamping bootloader support in
GuixSD to allow it to support multiple bootloaders, notably with the
goal of support U-Boot (used on most ARM boards), so it would make sense
for Mathieu to have a development board.  A couple of other people have
also contributed to this area, in particular Danny, who might also be
interested.

Thanks,
Ludo’.

Re: EOMA68 Development Boards

[Danny Milosavljevic]

Hi,

On Sat, 20 May 2017 14:21:04 +0200
l...@gnu.org (Ludovic Courtès) wrote:
> for Mathieu to have a development board.  A couple of other people have
> also contributed to this area, in particular Danny, who might also be
> interested.

Yes, I am interested.

Re: Planning for the next release

[Ludovic Courtès]

Hi again!

I build the installation image with from commit
96afb480f8165a315a69b1dd3a031e053044d3b2:

  ./pre-inst-env guix system disk-image --image-size=1.2G 
gnu/system/install.scm -K

and then ran QEMU on that image:

  qemu-system-x86_64 -enable-kvm -serial stdio \
-net nic,model=virtio -net user /tmp/t.qcow

but that failed with:

--8<---cut here---start->8---
[0.664746] RAMDISK: Couldn't find valid RAM disk image starting at 0.
[0.665664] List of all partitions:
[0.666117] 0100   65536 ram0 
[0.666118]  (driver?)
[0.666865] 0101   65536 ram1 
[0.666865]  (driver?)
[0.667602] 0102   65536 ram2 
[0.667602]  (driver?)
[0.668354] 0103   65536 ram3 
[0.668355]  (driver?)
[0.669062] 0104   65536 ram4 
[0.669063]  (driver?)
[0.669931] 0105   65536 ram5 
[0.669932]  (driver?)
[0.670675] 0106   65536 ram6 
[0.670675]  (driver?)
[0.671383] 0107   65536 ram7 
[0.671384]  (driver?)
[0.673712] 0108   65536 ram8 
[0.673716]  (driver?)
[0.675340] 0109   65536 ram9 
[0.675341]  (driver?)
[0.676810] 010a   65536 ram10 
[0.676812]  (driver?)
[0.677862] 010b   65536 ram11 
[0.677863]  (driver?)
[0.678739] 010c   65536 ram12 
[0.678740]  (driver?)
[0.679441] 010d   65536 ram13 
[0.679441]  (driver?)
[0.680144] 010e   65536 ram14 
[0.680145]  (driver?)
[0.680902] 010f   65536 ram15 
[0.680903]  (driver?)
[0.681675] 0800 1258291 sda 
[0.681676]  driver: sd
[0.682435]   0801 1207091 sda1 897ff0a1-01
[0.682436] 
[0.683158]   0802   40960 sda2 897ff0a1-02
[0.683159] 
[0.683872] 0b00 1048575 sr0 
[0.683873]  driver: sr
[0.684558] No filesystem could mount root, tried: 
[0.684559]  ext3
[0.685052]  ext2
[0.685253]  ext4
[0.685449]  vfat
[0.685645] 
[0.686013] Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(1,0)
[0.686831] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-gnu #1
[0.687689] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
[0.690057] Call Trace:
[0.690475]  dump_stack+0x63/0x90
[0.690970]  panic+0xe4/0x22d
[0.691426]  mount_block_root+0x27c/0x2bf
[0.692042]  mount_root+0x65/0x68
[0.692424]  prepare_namespace+0x16a/0x1a2
[0.692872]  kernel_init_freeable+0x1f3/0x21c
[0.693348]  ? rest_init+0x80/0x80
[0.693720]  kernel_init+0xe/0x100
[0.694069]  ret_from_fork+0x2c/0x40
[0.694548] Kernel Offset: 0x2f00 from 0x8100 (relocation 
range: 0x8000-0xbfff)
[0.695494] ---[ end Kernel panic - not syncing: VFS: Unable to mount root 
fs on unknown-block(1,0)
--8<---cut here---end--->8---

Likewise, “make check-system TESTS=basic” fails like this:

--8<---cut here---start->8---
environment variable `PATH' set to 
`/gnu/store/445x4k15v3mlym7n0i1irqyiih0hxr1f-qemu-minimal-2.9.0/bin:/gnu/store/ddpg6rlr5f3xv8fjh8812ll9g584x51z-parted-3.2/sbin:/gnu/store/bdzxdpdw25k8v6lz54clz42bilx47srj-grub-2.02/bin:/gnu/store/bdzxdpdw25k8v6lz54clz42bilx47srj-grub-2.02/sbin:/gnu/store/jh49klm0gkns071jsa8f9jr7g3cdlfwz-e2fsprogs-1.43.4/bin:/gnu/store/jh49klm0gkns071jsa8f9jr7g3cdlfwz-e2fsprogs-1.43.4/sbin:/gnu/store/82kq5zzq9d7rsq0d9rjppp3528p4cg72-dosfstools-4.1/sbin:/gnu/store/z763jk8lkragpz2qr2wbrz946lgalx2h-sed-4.4/bin:/gnu/store/87sj03j9kwzhl9zr76gs2i8ill86ki95-grep-3.0/bin:/gnu/store/6908gy3pws0ccys49ni98idwnicchlr2-coreutils-8.26/bin:/gnu/store/gdgrzf1y15scqwk1yzm51dc40g29vad9-findutils-4.6.0/bin:/gnu/store/55r4yg5iw9zh2j3zvzc6272k5xn4yxg4-gawk-4.1.4/bin'
creating partition table with 2 partitions...
parted: invalid option -- '1'
parted: invalid option -- '9'
parted: invalid option -- '9'
parted: invalid option -- '2'
parted: invalid option -- '2'
parted: invalid option -- '9'
parted: invalid option -- '4'
parted: invalid option -- '4'
parted: invalid option -- 'B'
parted: invalid option -- '1'
parted: invalid option -- '9'
parted: invalid option -- '9'
parted: invalid option -- '2'
parted: invalid option -- '2'
parted: invalid option -- '4'
parted: invalid option -- '3'
parted: invalid option -- '2'
parted: invalid option -- 'B'
Usage: parted [-hlmsv] [-a] [DEVICE [COMMAND [PARAMETERS]]...]
ERROR: In procedure scm-error:
ERROR: failed to create partition table

Entering a new prompt.  Type `,bt' for a backtrace or `,q' to continue.
[1.032767] Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x
--8<---cut here---end--->8---

Any ideas what could be wrong?

Thanks in advance,  :-)
Ludo’.

Re: EOMA68 Development Boards

[Pjotr Prins]

If it leads to a small form server it will also be interesting for
hosting secure mail. VPS on closed hardware has at least one downside
;)

Pj.

On Sat, May 20, 2017 at 03:04:24PM +0200, Danny Milosavljevic wrote:
> Hi,
> 
> On Sat, 20 May 2017 14:21:04 +0200
> l...@gnu.org (Ludovic Court??s) wrote:
> > for Mathieu to have a development board.  A couple of other people have
> > also contributed to this area, in particular Danny, who might also be
> > interested.
> 
> Yes, I am interested.
> 

-- 

Re: Planning for the next release

[Marius Bakke]

Ludovic Courtès  writes:

> Hi again!
>
> I build the installation image with from commit
> 96afb480f8165a315a69b1dd3a031e053044d3b2:
>
>   ./pre-inst-env guix system disk-image --image-size=1.2G 
> gnu/system/install.scm -K
>
> and then ran QEMU on that image:
>
>   qemu-system-x86_64 -enable-kvm -serial stdio \
> -net nic,model=virtio -net user /tmp/t.qcow
>
> but that failed with:
>
> --8<---cut here---start->8---
> [0.664746] RAMDISK: Couldn't find valid RAM disk image starting at 0.
> [0.665664] List of all partitions:
> [0.666117] 0100   65536 ram0 
> [0.666118]  (driver?)
> [0.666865] 0101   65536 ram1 
> [0.666865]  (driver?)
> [0.667602] 0102   65536 ram2 
> [0.667602]  (driver?)
> [0.668354] 0103   65536 ram3 
> [0.668355]  (driver?)
> [0.669062] 0104   65536 ram4 
> [0.669063]  (driver?)
> [0.669931] 0105   65536 ram5 
> [0.669932]  (driver?)
> [0.670675] 0106   65536 ram6 
> [0.670675]  (driver?)
> [0.671383] 0107   65536 ram7 
> [0.671384]  (driver?)
> [0.673712] 0108   65536 ram8 
> [0.673716]  (driver?)
> [0.675340] 0109   65536 ram9 
> [0.675341]  (driver?)
> [0.676810] 010a   65536 ram10 
> [0.676812]  (driver?)
> [0.677862] 010b   65536 ram11 
> [0.677863]  (driver?)
> [0.678739] 010c   65536 ram12 
> [0.678740]  (driver?)
> [0.679441] 010d   65536 ram13 
> [0.679441]  (driver?)
> [0.680144] 010e   65536 ram14 
> [0.680145]  (driver?)
> [0.680902] 010f   65536 ram15 
> [0.680903]  (driver?)
> [0.681675] 0800 1258291 sda 
> [0.681676]  driver: sd
> [0.682435]   0801 1207091 sda1 897ff0a1-01
> [0.682436] 
> [0.683158]   0802   40960 sda2 897ff0a1-02
> [0.683159] 
> [0.683872] 0b00 1048575 sr0 
> [0.683873]  driver: sr
> [0.684558] No filesystem could mount root, tried: 
> [0.684559]  ext3
> [0.685052]  ext2
> [0.685253]  ext4
> [0.685449]  vfat
> [0.685645] 
> [0.686013] Kernel panic - not syncing: VFS: Unable to mount root fs on 
> unknown-block(1,0)
> [0.686831] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-gnu #1
> [0.687689] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
> [0.690057] Call Trace:
> [0.690475]  dump_stack+0x63/0x90
> [0.690970]  panic+0xe4/0x22d
> [0.691426]  mount_block_root+0x27c/0x2bf
> [0.692042]  mount_root+0x65/0x68
> [0.692424]  prepare_namespace+0x16a/0x1a2
> [0.692872]  kernel_init_freeable+0x1f3/0x21c
> [0.693348]  ? rest_init+0x80/0x80
> [0.693720]  kernel_init+0xe/0x100
> [0.694069]  ret_from_fork+0x2c/0x40
> [0.694548] Kernel Offset: 0x2f00 from 0x8100 (relocation 
> range: 0x8000-0xbfff)
> [0.695494] ---[ end Kernel panic - not syncing: VFS: Unable to mount root 
> fs on unknown-block(1,0)
> --8<---cut here---end--->8---

It looks like the initrd is becoming obese. Adding "-m 168M" makes it
boot (qemu defaults to 128MiB). Not sure what to do about it.

> Likewise, “make check-system TESTS=basic” fails like this:
>
> --8<---cut here---start->8---
> environment variable `PATH' set to 
> `/gnu/store/445x4k15v3mlym7n0i1irqyiih0hxr1f-qemu-minimal-2.9.0/bin:/gnu/store/ddpg6rlr5f3xv8fjh8812ll9g584x51z-parted-3.2/sbin:/gnu/store/bdzxdpdw25k8v6lz54clz42bilx47srj-grub-2.02/bin:/gnu/store/bdzxdpdw25k8v6lz54clz42bilx47srj-grub-2.02/sbin:/gnu/store/jh49klm0gkns071jsa8f9jr7g3cdlfwz-e2fsprogs-1.43.4/bin:/gnu/store/jh49klm0gkns071jsa8f9jr7g3cdlfwz-e2fsprogs-1.43.4/sbin:/gnu/store/82kq5zzq9d7rsq0d9rjppp3528p4cg72-dosfstools-4.1/sbin:/gnu/store/z763jk8lkragpz2qr2wbrz946lgalx2h-sed-4.4/bin:/gnu/store/87sj03j9kwzhl9zr76gs2i8ill86ki95-grep-3.0/bin:/gnu/store/6908gy3pws0ccys49ni98idwnicchlr2-coreutils-8.26/bin:/gnu/store/gdgrzf1y15scqwk1yzm51dc40g29vad9-findutils-4.6.0/bin:/gnu/store/55r4yg5iw9zh2j3zvzc6272k5xn4yxg4-gawk-4.1.4/bin'
> creating partition table with 2 partitions...
> parted: invalid option -- '1'
> parted: invalid option -- '9'
> parted: invalid option -- '9'
> parted: invalid option -- '2'
> parted: invalid option -- '2'
> parted: invalid option -- '9'
> parted: invalid option -- '4'
> parted: invalid option -- '4'
> parted: invalid option -- 'B'
> parted: invalid option -- '1'
> parted: invalid option -- '9'
> parted: invalid option -- '9'
> parted: invalid option -- '2'
> parted: invalid option -- '2'
> parted: invalid option -- '4'
> parted: invalid option -- '3'
> parted: invalid option -- '2'
> parted: invalid option -- 'B'
> Usage: parted [-hlmsv] [-a] [DEVICE [COMMAND [PARAMETERS]]...]
> ERROR: In procedure scm-error:
> ERROR: f

Switching to Artifex Ghostscript

[Leo Famulari]

The subject of the two Ghostscripts came up last October, but we didn't
really discuss it:

https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00598.html

The canonical Ghostscript is developed by Artifex Software Inc:

https://ghostscript.com/

We package GNU Ghostscript, which is a fork of Artifex's Ghostscript:

https://www.gnu.org/software/ghostscript/

Both programs are distributed under the AGPL, as far as I can tell. But
Artifex Ghostscript is actively developed, which I think is very
important for C software that is designed to handle untrusted input.

If you are curious where Ghostscript is used, try this:

$ guix graph --type=reverse-package ghostscript | dot -Tsvg > /tmp/graph.svg


signature.asc
Description: PGP signature

Re: Planning for the next release

[Marius Bakke]

Marius Bakke  writes:

> Anyway, the problem is that the parted script gets a negative size for
> TESTS=basic:
>
> creating partition table with 2 partitions... 
> 
> DEBUG: (mkpart primary ext2 1048576B -19922944B set 1 boot on mkpart primary 
> ext2 -19922432B 22020608B set 2 esp on)
>
> The attached commit fixes it; although there are other default sizes in
> (gnu system vm) that may need adjustment after
> ecf5d5376979fadd971559367bf553df89fcc62b.
>
> Currently running *all* system tests, but it's going to take a while!

All passed except nss-mdns, but it doesn't seem related. Is the below
patch good enough, or should we preemptively increase the other default
disk values in (gnu system vm) as well?

> From 4b012ae4a9be9b6fe566dc003197c740e5e35a86 Mon Sep 17 00:00:00 2001
> From: Marius Bakke 
> Date: Sat, 20 May 2017 21:28:20 +0200
> Subject: [PATCH] vm: Increase default disk sizes to account for ESP partition.
>
> Fixes a test regression introduced by 
> ecf5d5376979fadd971559367bf553df89fcc62b.
>
> * gnu/system/vm.scm (system-qemu-image/shared-store-script): 30MiB -> 70MiB.
> ---
>  gnu/system/vm.scm | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/gnu/system/vm.scm b/gnu/system/vm.scm
> index d282ba557..ad5e6b75b 100644
> --- a/gnu/system/vm.scm
> +++ b/gnu/system/vm.scm
> @@ -499,7 +499,7 @@ with '-virtfs' options for the host file systems listed 
> in SHARED-FS."
>  (mappings '())
>  full-boot?
>  (disk-image-size
> - (* (if full-boot? 500 30)
> + (* (if full-boot? 500 70)
>  (expt 2 20
>"Return a derivation that builds a script to run a virtual machine image of
>  OS that shares its store with the host.


signature.asc
Description: PGP signature

Re: Planning for the next release

[Ricardo Wurmus]

Ludovic Courtès  writes:

> Hello Guix!
>
> An update on the release that never comes.  ;-)
[…]

> The “Noteworthy bug fixes” section of ‘NEWS’ also needs to be improved.

I just pushed commit 402f241da, which fills that section a bit.  Thank
you for the many bug fixes that I’ve combed through just now!

-- 
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Planning for the next release

[Ricardo Wurmus]

Ludovic Courtès  writes:

>>> Not a release blocker, but a kind of general blocker: we have a ‘guix
>>> offload’ bug for which we need more testers and hackers to get better
>>> debugging info: .
>>
>> I’ll try to give this a try either tonight or tomorrow.
>
> Great!
>
> Regardless of what happens with #26976, I can run “make release” and
> upload the tarballs tomorrow, and presumably send out the announcement
> on Monday.
>
> How does that sound?

That sounds good!

Should this bug be mentioned somewhere (in the release tarball) as a
known issue with 0.13.0?

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

Re: Switching to Artifex Ghostscript

[Marius Bakke]

Leo Famulari  writes:

> The subject of the two Ghostscripts came up last October, but we didn't
> really discuss it:
>
> https://lists.gnu.org/archive/html/guix-devel/2016-10/msg00598.html
>
> The canonical Ghostscript is developed by Artifex Software Inc:
>
> https://ghostscript.com/
>
> We package GNU Ghostscript, which is a fork of Artifex's Ghostscript:
>
> https://www.gnu.org/software/ghostscript/
>
> Both programs are distributed under the AGPL, as far as I can tell. But
> Artifex Ghostscript is actively developed, which I think is very
> important for C software that is designed to handle untrusted input.

Thanks for bringing this up. GNU Ghostscript seemed to go
mostly-inactive[0] after Artifex changed to AGPL in 2013[1]. The latest
"upstream" release is 9.21[2], we have 9.14.0 (from 2014!).

I'm in favor of switching to the active fork.

[0] https://ftp.gnu.org/gnu/ghostscript/
[1] https://en.wikipedia.org/wiki/Ghostscript#History
[2] https://github.com/ArtifexSoftware/ghostpdl-downloads/releases


signature.asc
Description: PGP signature

Re: Planning for the next release

[Ludovic Courtès]

Ricardo Wurmus  skribis:

> Ludovic Courtès  writes:
>
 Not a release blocker, but a kind of general blocker: we have a ‘guix
 offload’ bug for which we need more testers and hackers to get better
 debugging info: .
>>>
>>> I’ll try to give this a try either tonight or tomorrow.
>>
>> Great!
>>
>> Regardless of what happens with #26976, I can run “make release” and
>> upload the tarballs tomorrow, and presumably send out the announcement
>> on Monday.
>>
>> How does that sound?
>
> That sounds good!
>
> Should this bug be mentioned somewhere (in the release tarball) as a
> known issue with 0.13.0?

I don’t know, maybe not.

Ludo’.

Re: Planning for the next release

[Ludovic Courtès]

Hi!

Marius Bakke  skribis:

> Ludovic Courtès  writes:
>
>> Hi again!
>>
>> I build the installation image with from commit
>> 96afb480f8165a315a69b1dd3a031e053044d3b2:
>>
>>   ./pre-inst-env guix system disk-image --image-size=1.2G 
>> gnu/system/install.scm -K
>>
>> and then ran QEMU on that image:
>>
>>   qemu-system-x86_64 -enable-kvm -serial stdio \
>> -net nic,model=virtio -net user /tmp/t.qcow
>>
>> but that failed with:
>>
>> --8<---cut here---start->8---
>> [0.664746] RAMDISK: Couldn't find valid RAM disk image starting at 0.
>> [0.665664] List of all partitions:
>> [0.666117] 0100   65536 ram0 
>> [0.666118]  (driver?)
>> [0.666865] 0101   65536 ram1 
>> [0.666865]  (driver?)
>> [0.667602] 0102   65536 ram2 
>> [0.667602]  (driver?)
>> [0.668354] 0103   65536 ram3 
>> [0.668355]  (driver?)
>> [0.669062] 0104   65536 ram4 
>> [0.669063]  (driver?)
>> [0.669931] 0105   65536 ram5 
>> [0.669932]  (driver?)
>> [0.670675] 0106   65536 ram6 
>> [0.670675]  (driver?)
>> [0.671383] 0107   65536 ram7 
>> [0.671384]  (driver?)
>> [0.673712] 0108   65536 ram8 
>> [0.673716]  (driver?)
>> [0.675340] 0109   65536 ram9 
>> [0.675341]  (driver?)
>> [0.676810] 010a   65536 ram10 
>> [0.676812]  (driver?)
>> [0.677862] 010b   65536 ram11 
>> [0.677863]  (driver?)
>> [0.678739] 010c   65536 ram12 
>> [0.678740]  (driver?)
>> [0.679441] 010d   65536 ram13 
>> [0.679441]  (driver?)
>> [0.680144] 010e   65536 ram14 
>> [0.680145]  (driver?)
>> [0.680902] 010f   65536 ram15 
>> [0.680903]  (driver?)
>> [0.681675] 0800 1258291 sda 
>> [0.681676]  driver: sd
>> [0.682435]   0801 1207091 sda1 897ff0a1-01
>> [0.682436] 
>> [0.683158]   0802   40960 sda2 897ff0a1-02
>> [0.683159] 
>> [0.683872] 0b00 1048575 sr0 
>> [0.683873]  driver: sr
>> [0.684558] No filesystem could mount root, tried: 
>> [0.684559]  ext3
>> [0.685052]  ext2
>> [0.685253]  ext4
>> [0.685449]  vfat
>> [0.685645] 
>> [0.686013] Kernel panic - not syncing: VFS: Unable to mount root fs on 
>> unknown-block(1,0)
>> [0.686831] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.11.0-gnu #1
>> [0.687689] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
>> rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
>> [0.690057] Call Trace:
>> [0.690475]  dump_stack+0x63/0x90
>> [0.690970]  panic+0xe4/0x22d
>> [0.691426]  mount_block_root+0x27c/0x2bf
>> [0.692042]  mount_root+0x65/0x68
>> [0.692424]  prepare_namespace+0x16a/0x1a2
>> [0.692872]  kernel_init_freeable+0x1f3/0x21c
>> [0.693348]  ? rest_init+0x80/0x80
>> [0.693720]  kernel_init+0xe/0x100
>> [0.694069]  ret_from_fork+0x2c/0x40
>> [0.694548] Kernel Offset: 0x2f00 from 0x8100 (relocation 
>> range: 0x8000-0xbfff)
>> [0.695494] ---[ end Kernel panic - not syncing: VFS: Unable to mount 
>> root fs on unknown-block(1,0)
>> --8<---cut here---end--->8---
>
> It looks like the initrd is becoming obese. Adding "-m 168M" makes it
> boot (qemu defaults to 128MiB). Not sure what to do about it.

Oh, that didn’t come to mind.  I’m pretty sure this is because we’re
pulling dynamically-linked stuff that bring in glibc and co.  I’ll take
a look tomorrow if nobody beats me.

>> Likewise, “make check-system TESTS=basic” fails like this:
>>
>> --8<---cut here---start->8---
>> environment variable `PATH' set to 
>> `/gnu/store/445x4k15v3mlym7n0i1irqyiih0hxr1f-qemu-minimal-2.9.0/bin:/gnu/store/ddpg6rlr5f3xv8fjh8812ll9g584x51z-parted-3.2/sbin:/gnu/store/bdzxdpdw25k8v6lz54clz42bilx47srj-grub-2.02/bin:/gnu/store/bdzxdpdw25k8v6lz54clz42bilx47srj-grub-2.02/sbin:/gnu/store/jh49klm0gkns071jsa8f9jr7g3cdlfwz-e2fsprogs-1.43.4/bin:/gnu/store/jh49klm0gkns071jsa8f9jr7g3cdlfwz-e2fsprogs-1.43.4/sbin:/gnu/store/82kq5zzq9d7rsq0d9rjppp3528p4cg72-dosfstools-4.1/sbin:/gnu/store/z763jk8lkragpz2qr2wbrz946lgalx2h-sed-4.4/bin:/gnu/store/87sj03j9kwzhl9zr76gs2i8ill86ki95-grep-3.0/bin:/gnu/store/6908gy3pws0ccys49ni98idwnicchlr2-coreutils-8.26/bin:/gnu/store/gdgrzf1y15scqwk1yzm51dc40g29vad9-findutils-4.6.0/bin:/gnu/store/55r4yg5iw9zh2j3zvzc6272k5xn4yxg4-gawk-4.1.4/bin'
>> creating partition table with 2 partitions...
>> parted: invalid option -- '1'
>> parted: invalid option -- '9'
>> parted: invalid option -- '9'
>> parted: invalid option -- '2'
>> parted: invalid option -- '2'
>> parted: invalid option -- '9'
>> parted: invalid option -- '4'
>> parted: invalid option -- '4'
>> parted: invalid option -- 'B'
>> parted: invalid option -- '1'
>> parted: invalid option -- '9'
>> parted: inval

Re: Planning for the next release

[Ludovic Courtès]

l...@gnu.org (Ludovic Courtès) skribis:

>> It looks like the initrd is becoming obese. Adding "-m 168M" makes it
>> boot (qemu defaults to 128MiB). Not sure what to do about it.
>
> Oh, that didn’t come to mind.  I’m pretty sure this is because we’re
> pulling dynamically-linked stuff that bring in glibc and co.  I’ll take
> a look tomorrow if nobody beats me.

That was unionfs-fuse.  Fixed in
9f8d6eb24a5f193683076e16ffb68da18a537140!

Ludo’.