Re: Towards a graphical installer?

[dftxbs3e]

On 5/12/20 9:09 AM, Pierre Neidhardt wrote:
> Errr... Sorry, I was distracted yesterday, the NLNet grant is actually
> for a graphical _package manager_, not an installer! :p
> 
> That said, I'm interested in helping with it too! :)
> 

Really?! We have that?? Wonderful!! That would be the YaST thing I was
talking about!!



signature.asc
Description: OpenPGP digital signature

Re: Towards a graphical installer?

[dftxbs3e]

On 5/12/20 8:10 AM, dftxbs3e wrote:
> 
> I was thinking that designing a good TUI installer would be sufficient,
> I find the latest Subiquity Ubuntu installer very beautiful and great!
> 
> Have a look: https://invidio.us/watch?v=Glyj4BjAhME
> 
> Git: https://github.com/CanonicalLtd/subiquity
> 
> Do you think there's really a point in doing GUI?
> 
> Also, if GUI, is there a way to do that with more minimalism while
> getting the desired features?
> 

Sorry for the second mail but I have another thought :

I am thinking since a while that GNU Guix is the perfect platform to
write something like OpenSUSE's YaST, with a good base and many
frontends such as TUI, GUI, web. It would be awesome.



signature.asc
Description: OpenPGP digital signature

Re: Towards a graphical installer?

[dftxbs3e]

On 5/11/20 3:27 PM, Mathieu Othacehe wrote:
> 
> Hello,
> 
> A way to move forward with the installer could be to propose an ISO
> image starting a desktop-environment by default. The attached patch
> modifies the installation image so that it starts a GNOME session. The
> installer is then automatically started, inside a gnome-terminal.
> 
> The resulting ISO image is bigger: 3.9G without compression and 1.7G
> with compression.
> 
> Now, I'm not sure this is something we want to merge as-is. Maybe, it's
> time to port the installer to a GTK3 application, or a Web
> application. As we already have something working, porting (gnu
> installer) to a new graphical backend, could be not so hard.
> 
> I don't think I'll have the bandwidth to do this anytime soon, but is
> someone is interested, I'm willing to help/review :).
> 
> Thanks,
> 
> Mathieu
> 

I was thinking that designing a good TUI installer would be sufficient,
I find the latest Subiquity Ubuntu installer very beautiful and great!

Have a look: https://invidio.us/watch?v=Glyj4BjAhME

Git: https://github.com/CanonicalLtd/subiquity

Do you think there's really a point in doing GUI?

Also, if GUI, is there a way to do that with more minimalism while
getting the desired features?



signature.asc
Description: OpenPGP digital signature

Re: GNU Guix ported to powerp64-linux-gnu

[dftxbs3e]

On 2/24/20 4:18 PM, Joshua Branson wrote:

> Awesome!  Do you use a raptor computer?
>
> https://www.raptorcs.com/content/base/products.html
Yes! :-)



signature.asc
Description: OpenPGP digital signature

GNU Guix ported to powerp64-linux-gnu

[dftxbs3e]

Hello!

Finally it succeeded. Thanks to everyone who has answered my countless
questions on the mailing list and IRC!

GNU Hello - /gnu/store/98wc63drnc5iwkcclls91iz181mmiv7c-hello-2.10
(natively built with: ./pre-inst-env guix build hello)

I used Gentoo (https://wiki.gentoo.org/wiki/Handbook:PPC64) as a base
PowerPC 64-bit big endian system. (precisely IBM POWER9)

source:

https://gitlab.com/lle-bout/guix - commit
f47e761a10675b05b07107035d5024618267a3ad (current master at time of writing)

bootstrap binaries:

https://gitlab.com/lle-bout/guix-bootstrap - commit
b017c0459bc65a53203eb056998be8abd7778e4a (current master at time of
writing) - currently it's unclear from which revision the bootstrap
binaries come from, a rebuild of all the binaries from the latest ported
guix's revision is pending.

How to build bootstrap binaries:

On a system where GNU Guix already works:

./pre-inst-env guix build --target=powerpc64-linux-gnu bootstrap-tarballs

Next steps are getting things to work on powerpc64le-linux-gnu (shouldnt
be too hard now) then rebase everything onto core-updates!

Leo




signature.asc
Description: OpenPGP digital signature

Re: powerpc64[le]-linux port progress

[dftxbs3e]

On 2/22/20 1:34 PM, Jan Nieuwenhuizen wrote:
> Have you tried building static gawk standalone and check it for that
> bash?  You could do something like
>
>grep -ao '/gnu/store/e*-bash' $(./pre-inst-env guix build -e '(@@ (gnu 
> packages make-bootstrap) %static-binaries)')
>
> On my x86_64-linux system, I get
>
>/gnu/store/-bash
Yes! I used the strings utility. I get two references to bash-static in
the store with 'e'. Speaking of which, do you know if it's possible
to be spawned into an environment where %static-binaries's gawk package
(and only that one) sources are extracted, patched and configured? So
that I can investigate the inclusion of bash-static comfortably.
> For the new Scheme-only bootstrap, I solved a similar problem for
> %bootstrap-mes by replacing the /gnu/store/eee* store-references with
> actual bootstrap file names; see `%bootstrap-mes-rewired' in
> core-updates 
> http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/commencement.scm?h=core-updates#n251
>
I hear, however that smells like a hack to me, I'd like to avoid
resorting to such unless absolutely necessary. How come it's not
possible to find where that bash-static reference is being inserted?



signature.asc
Description: OpenPGP digital signature

powerpc64[le]-linux port progress

[dftxbs3e]

Hello!

So here's my current tree: https://gitlab.com/lle-bout/guix - master branch

Bootstrap binaries are uploaded over LFS at:
https://gitlab.com/lle-bout/guix-bootstrap - master branch

The current issue is during 'glibc-intermediate' in
gnu/packages/commencement.scm

The statically linked gawk binary tries to execute:
execve("/gnu/store/-bash-static-5.0.7/bin/bash",
["sh", "-c", "test -d nptl"], 0x3fffd261ecc0 /* 57 vars */) = -1

According to Ludovic Courtes, store references with 'eee' characters
in them are removed store references. So I went and tried to strip the
reference to bash and replace it with `sh` so that either gawk or any of
its dependency can look up `sh` in PATH at bootstrap time (we do not
know any path yet). In the commit history, you can see I tried to patch
glibc and gawk, but that does not solve the problem. The final gawk
binary still contains a reference to bash-static, and I have no idea
where it comes from. Do note that during gawk build process, there's a
'set-shell-filename phase, that I removed in
gnu/packages/make-bootstrap.scm and instead replace every occurrence of
/bin/sh with `sh`. I would appreciate help here. Thank you



signature.asc
Description: OpenPGP digital signature

Re: New POWER9 machines for the Guix build farm?

[dftxbs3e]

On 12/9/19 1:19 AM, Chris Marusich wrote:

Tobias Geerinckx-Rice  writes:


Fellow Guix,

The Guix sysadmins are considering buying shiny hardware for the
ci.guix.gnu.org build farm, and it would be awesome if that included
our first POWER9 machine(s)!

However, few (if any) Guixers have any hands-on experience with this
architecture, let alone buying and installing whole systems. Some
remember a bad experience with a prominent vendor, and it would appear
that they're not alone[0].

There's also some concern that getting these machines up and running
will take significant effort.

So please, share your expertise and experience in this area! Ideally,
we need someone to volunteer to (help) set up any new POWER9 boxes and
later take care of them when needed.  It would certainly help justify
the multi-thousand-euro bill.

Kind regards,

T G-R

PS: For the shorter term, I've applied for an 8-core POWER9 LE
instance (with 16 GiB of RAM) for Guix at OSUOSL[1].  Assuming that
it's accepted, it should be available within a week.

[0]:
https://drewdevault.com/2019/09/23/RaptorCS-Blackbird-a-horror-story.html,
but read https://drewdevault.com/2019/10/10/RaptorCS-redemption.html
as well :-)
[1]: https://osuosl.org/services/powerdev/

I think it's a great idea.  To test the waters, someone could try using
one of these free VMs and see how Guix System does on them:

https://openpowerfoundation.org/minicloud-free-openpower-cloud/

First, bootstrap binaries have to be built for the hardware, anyway,
right?  Maybe someone can do that work on one of those free VMs?


That work is already done!

See: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=38459

Current issue is gcc-cross-boot0 not building.

See build log at: https://gitlab.com/lle-bout/guix/-/jobs/372934160

Re: New POWER9 machines for the Guix build farm?

[dftxbs3e]

Hello,

There is libre firmware being worked on, latest news say that it does 
work but some features are not implemented. I have not tested that 
firmware however.


There is a contest organized by RaptorCS to liberate the firmware: 
https://www.raptorcs.com/TALOSII/nic_fw_contest.php


And here's the ongoing work:

https://github.com/meklort/bcm5719-fw

https://wiki.raptorcs.com/wiki/BCM5719

An interesting thing to note is that 10Gbit network cards from the same 
vendor (Broadcom) are implemented fully with hardware ASICs and do not 
require firmware at all. So that's a work around to the problem. source: 
developer of the libre firmware.


dftxbs3e


On 11/29/19 1:50 PM, Marco van Hulten wrote:

Hello—

On 29 Nov 09:25 dftxbs3e wrote:

I'm really happy to hear this! I also do own a POWER9 machine.

I have a Talos II with 2x 8 SMT4 cores POWER9 DD2.2 CPUs (64 threads),
64GB of RAM and an AMD WX7100 GPU (amdgpu libre driver).

I run Fedora on it since more than a year now, it's been my main
workstation without any major issue.

It's great to hear of such an experience!  I have an amd64 server at
home that makes quite a bit of noise and, standing next to the server,
an amd64 workstation that makes even more noise, both of which are over
10 years old.  I am considering replacing both systems for a single
Talos II.

According to the mainboard specifications [1], Ethernet is driven by a
proprietary chip (Broadcom BCM5719).  Is there libre firmware that is
shown to work reliably?

I guess it should be because it is FSF-certified to Respect Your
Freedom, but could someone confirm this specifically for the network
interface?

[1]: https://wiki.raptorcs.com/wiki/Talos_II


I'm happy to provide assistance, I encourage GNU Guix developers to join
#talos-workstation on Freenode's IRC, we have a friendly active
community that is always happy to help on POWER9 matters.

Fantastic to see this work out!


The other free modern architecture, RISC-V, is that like a sort of
competitor of POWER9?  Or is it more like Talos II being the obvious
choice for a server (and workstation) because it is available now/more
established?

—Marco

Re: New POWER9 machines for the Guix build farm?

[dftxbs3e]

Hello,

I'm really happy to hear this! I also do own a POWER9 machine.

I have a Talos II with 2x 8 SMT4 cores POWER9 DD2.2 CPUs (64 threads), 
64GB of RAM and an AMD WX7100 GPU (amdgpu libre driver).


I run Fedora on it since more than a year now, it's been my main 
workstation without any major issue.


I'm happy to provide assistance, I encourage GNU Guix developers to join 
#talos-workstation on Freenode's IRC, we have a friendly active 
community that is always happy to help on POWER9 matters.


dftxbs3e

On 11/28/19 1:50 AM, Tobias Geerinckx-Rice wrote:

Fellow Guix,

The Guix sysadmins are considering buying shiny hardware for the 
ci.guix.gnu.org build farm, and it would be awesome if that included 
our first POWER9 machine(s)!


However, few (if any) Guixers have any hands-on experience with this 
architecture, let alone buying and installing whole systems. Some 
remember a bad experience with a prominent vendor, and it would appear 
that they're not alone[0].


There's also some concern that getting these machines up and running 
will take significant effort.


So please, share your expertise and experience in this area! Ideally, 
we need someone to volunteer to (help) set up any new POWER9 boxes and 
later take care of them when needed.  It would certainly help justify 
the multi-thousand-euro bill.


Kind regards,

T G-R

PS: For the shorter term, I've applied for an 8-core POWER9 LE 
instance (with 16 GiB of RAM) for Guix at OSUOSL[1].  Assuming that 
it's accepted, it should be available within a week.


[0]: 
https://drewdevault.com/2019/09/23/RaptorCS-Blackbird-a-horror-story.html, 
but read https://drewdevault.com/2019/10/10/RaptorCS-redemption.html 
as well :-)

[1]: https://osuosl.org/services/powerdev/

Re: State of the powerpc64le port

[dftxbs3e]

Hello,

For your information, I already did proceed to porting to 
powerpc64le-linux some time ago.


Here's where my work is : https://gitlab.com/lle-bout/guix

The `core-updates` branch contains the latest changes, you can also 
observe CI pipelines to get build logs for both GNU Guix itself 
(succeeds) and GNU Hello from within GNU Guix (fails). e.g. 
https://gitlab.com/lle-bout/guix/pipelines/94458238


I also host bootstrap binaries over Git LFS at 
https://gitlab.com/lle-bout/guix-bootstrap


I even set up Gitlab CI to build a container image so anyone can get to 
work quickly : registry.gitlab.com/lle-bout/guix:latest (updated on 
every commit to my modified `core-updates`)


What is missing now is that due to a change in the double precision 
floating point format in glibc >= 2.26, the bootstrap gcc (4.9.x) cannot 
build the latest glibc included in GNU Guix.


The solution would be to modify the bootstrap process so the bootstrap 
gcc is used this way :


1. Use gcc 4.9.x built with glibc 2.25 to build gcc >= 6.2 built with
   glibc 2.25
2. Use gcc >= 6.2 built with glibc 2.25 to build gcc >= 6.2 built with
   glibc >= 2.26

Then the final GCC can be used to build the rest of GNU Guix.

After this, everything should work fine.

On 11/19/19 1:07 AM, Jonathan Brielmaier wrote:

Hello fellow Guix hackers,

recently I just gave the powerpc64le-linux thing another try, as I'm
missing Guix to much on my main machine (POWER9)...

Work is happening on a personal branch. It still in a WIP state and
force-pushing can occur:
https://gitlab.com/jonsger/Guix/tree/wip-master-powerpc64le

As a first step we need the bootstrap-binaries for powerpc64le. This
became pretty simple now. Apply

   gnu: Let cross-gcc-arguments built for powerpc64le.

on a x86_64 system and run:
./pre-inst-env guix build --target=powerpc64le-linux-gnu bootstrap-binaries

I uploaded the resulting tarballs to my private web server. They can be
found here:
http://brielmaier.net/guix/bootstrap/powerpc64le-linux/

On a powerpc64le system you need one commit, in order to get guix
building from the git repo:

   WIP: gnu: Add bootstrap-binaries for 'powerpc64le-linux'.

When this succeeds you should be able to build packages. At the moment
`./pre-inst-env guix build hello` fails while building
gcc-cross-boot0-7.4.0. See the gcc-cross-boot0-7.4.0-buildlog.bz2
attachment.

Because of that, one is not able to install any packages yet, but
commands like `guix search` or `guix show` already working like a charm :)

So I wonder if we could already bring some of those commits to master or
core-updates :P

That's it for now
Jonathan

Re: IPv6 Guix

[dftxbs3e]

Alright, thank you.

On 8/30/19 2:00 PM, Ricardo Wurmus wrote:
> dftxbs3e  writes:
>
>> Could that be made into a TODO list?
> I asked them to do this, but there’s nothing more I can do about it.  I
> wouldn’t hold my breath as I know the networking team currently has
> other priorities.
>



signature.asc
Description: OpenPGP digital signature

Re: IPv6 Guix

[dftxbs3e]

Hello,

Could that be made into a TODO list?

Thanks

On 8/26/19 5:14 PM, Ricardo Wurmus wrote:
> Ricardo Wurmus  writes:
>
>> Ludovic Courtès  writes:
>>
>>> dftxbs3e  skribis:
>>>
>>>> It looks like ci.guix.gnu.org does not have  records.
>>> Ricardo, do you know if berlin is accessible over IPv6?  If it is, I
>>> agree we should add those  records.
>> I’m waiting for a response from the campus network team.  I asked them
>> to confirm if it’s possible to reach the server via IPv6 and to update
>> the firewall rules if it isn’t.
> The campus firewall doesn’t route IPv6 yet, so it’s not yet possible to
> access the server via its IPv6 address.  Sorry.
>



signature.asc
Description: OpenPGP digital signature

bootstrap guile version mismatch on core-updates

[dftxbs3e]

Hello,

It seems that guile2.2 is built by make-bootstrap.scm here:
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/make-bootstrap.scm?h=core-updates#n625

but guile2.0 is expected here:
https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/bootstrap.scm?h=core-updates#n373

For the purpose of my ongoing port to powerpc64le-linux-gnu, I applied
the attached patch, but obviously that one wont work with the previously
built tarballs for x86_64 etc. Things would have to be split in parts
somehow, for old bootstraps with version 2.0 and newer ones with version
2.2.

Thanks

diff --git a/gnu/packages/bootstrap.scm b/gnu/packages/bootstrap.scm
index d275c2867..c0b474a69 100644
--- a/gnu/packages/bootstrap.scm
+++ b/gnu/packages/bootstrap.scm
@ -384,8 +384,8 @@ or false to signal an error."
 (lambda (p)
   (format p "\
 #!~a
-export GUILE_SYSTEM_PATH=~a/share/guile/2.0
-export GUILE_SYSTEM_COMPILED_PATH=~a/lib/guile/2.0/ccache
+export GUILE_SYSTEM_PATH=~a/share/guile/2.2
+export GUILE_SYSTEM_COMPILED_PATH=~a/lib/guile/2.2/ccache
 exec -a \"~a0\" ~a \"~a@\"\n"
   bash out out dollar guile-real dollar)))
   (chmod guile   #o555)
@@ -400,8 +400,8 @@ cd $out
 ~a -dc < $GUILE_TARBALL | ~a xv
 
 # Use the bootstrap guile to create its own wrapper to set the load path.
-GUILE_SYSTEM_PATH=$out/share/guile/2.0 \
-GUILE_SYSTEM_COMPILED_PATH=$out/lib/guile/2.0/ccache \
+GUILE_SYSTEM_PATH=$out/share/guile/2.2 \
+GUILE_SYSTEM_COMPILED_PATH=$out/lib/guile/2.2/ccache \
 $out/bin/guile -c ~s $out ~a
 
 # Sanity check.



signature.asc
Description: OpenPGP digital signature

guile-ssh requirement on core-updates

[dftxbs3e]

Hello,

Now guile-ssh is required to compile GNU Guix (at least on
core-updates), but it's not specified in
https://git.savannah.gnu.org/cgit/guix.git/tree/README?h=core-updates

I suggest it gets added to avoid confusion to people who compile GNU
Guix without having GNU Guix already and having the ability to run `guix
environment guix`.

Thank you




signature.asc
Description: OpenPGP digital signature

IPv6 Guix

[dftxbs3e]

Hello,

It looks like ci.guix.gnu.org does not have  records.

I suggest they get added because IPv6-only networking is the future.

$ dig ci.guix.gnu.org 

; <<>> DiG 9.11.8-RedHat-9.11.8-1.fc30 <<>> ci.guix.gnu.org 
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4389
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;ci.guix.gnu.org.        IN    

;; AUTHORITY SECTION:
guix.gnu.org.        3595    IN    SOA    ns.guix.gnu.org.
hostmaster.guix.gnu.org. 2019080102 172800 900 1209600 3600

I checked all other domain names in

and they all have  records.

Now if anything is downloaded by GNU Guix during operation, domain names
should also have  records but I think ci.guix.gnu.org mirrors
everything?

Thanks




signature.asc
Description: OpenPGP digital signature

Re: Suggest another way of importing GNU Guix GPG key

[dftxbs3e]

Le 2019-07-13 20:29, Leo Famulari a écrit :

On Wed, Jul 03, 2019 at 02:13:12PM -0400, Leo Famulari wrote:

An update on this:

The initial plan is to add the Guix signing key to the new
abuse-resistant keyserver at . Once that has been 
done

we can update the manual and HACKING to point at this.


This didn't happen, but the instructions have been changed to suggest
fetching the key directly from Savannah [0]. Additionally, the docs
about where to put one's commit signing key have also been updated [1].

[0]
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=ffae5a7946912ffd69dd4b608576cf2d75931fb2

[1]
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=06e1ecbf17fee7fe513ad2808d8175fb3565ae3e


Hello,

https://guix.gnu.org/manual/en/html_node/Binary-Installation.html still 
recommends to download using keyservers.


Might want to update that as well.

Thank.

Suggest another way of importing GNU Guix GPG key

[dftxbs3e]

Hello,

SKS keyservers are currently under attack 
(https://gist.github.com/rjhansen/67ab921ffb4084c865b3618d6955275f) - 
the attack can cause a GPG client to freeze completely and mess the GPG 
installation completely.


I suggest GNU Guix proposes another way of importing the GPG keys so 
that users will not suffer from this problem.


There's another, newer, keyserver, proposed in this gist, that is run by 
new software that doesnt suffer from this attack. See: 
https://keys.openpgp.org/about/news#2019-06-12-launch


However, that keyserver is not replicated. You could either use that one 
or simply offer a download of the key over TLS with verification against 
installed CAs, as secure as this can get.


Regards

XFCE and ratpoison DE not working on GuixSD 1.0

[dftxbs3e]

Hello,

I have collected a bug report from the IRC user "wr";

They're running on VirtualBox, and they could not get XFCE and ratpoison 
DEs to work.


Attached log files!

Thanks.[0.00] Linux version 5.0.10-gnu (nixbld@) (gcc version 7.4.0 (GCC)) #1 
SMP 1
[0.00] Command line: 
BOOT_IMAGE=/gnu/store/0rblbwja216vhhrqj4150fizmhhq20sv-linux-libre-5.0.10/bzImage
 --root=cdf5f1b4-66b5-497d-b5a1-2bc6ea9dda58 
--system=/gnu/store/ssm9a2rlk52ckjlkn1mfrjffmrrn11ms-system 
--load=/gnu/store/ssm9a2rlk52ckjlkn1mfrjffmrrn11ms-system/boot quiet
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Hygon HygonGenuine
[0.00]   Centaur CentaurHauls
[0.00] CPU0: Hyper-Threading is disabled
[0.00] x86/fpu: x87 FPU will use FXSAVE
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009fbff] usable
[0.00] BIOS-e820: [mem 0x0009fc00-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000f-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x3ffe] usable
[0.00] BIOS-e820: [mem 0x3fff-0x3fff] ACPI data
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xfffc-0x] reserved
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.5 present.
[0.00] DMI: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 
12/01/2006
[0.00] Hypervisor detected: KVM
[0.00] kvm-clock: Using msrs 4b564d01 and 4b564d00
[0.01] kvm-clock: cpu 0, msr f578001, primary cpu clock
[0.01] kvm-clock: using sched offset of 569364172196 cycles
[0.31] clocksource: kvm-clock: mask: 0x max_cycles: 
0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[0.65] tsc: Detected 2666.354 MHz processor
[0.003343] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.003351] e820: remove [mem 0x000a-0x000f] usable
[0.003380] last_pfn = 0x3fff0 max_arch_pfn = 0x4
[0.003458] MTRR default type: uncachable
[0.003459] MTRR variable ranges disabled:
[0.003472] Disabled
[0.003493] x86/PAT: MTRRs disabled, skipping PAT initialization too.
[0.003497] CPU MTRRs all blank - virtualized system.
[0.003511] x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WB  WT  UC- UC  
[0.469986] check: Scanning 1 areas for low memory corruption
[0.470020] Base memory trampoline at [(ptrval)] 99000 size 24576
[0.470212] BRK [0x0f801000, 0x0f801fff] PGTABLE
[0.470250] BRK [0x0f802000, 0x0f802fff] PGTABLE
[0.470251] BRK [0x0f803000, 0x0f803fff] PGTABLE
[0.470322] BRK [0x0f804000, 0x0f804fff] PGTABLE
[0.470440] BRK [0x0f805000, 0x0f805fff] PGTABLE
[0.470511] RAMDISK: [mem 0x369a9000-0x374cbfff]
[0.470591] ACPI: Early table checksum verification disabled
[0.470923] ACPI: RSDP 0x000E 24 (v02 VBOX  )
[0.470958] ACPI: XSDT 0x3FFF0030 3C (v01 VBOX   VBOXXSDT 
0001 ASL  0061)
[0.471040] ACPI: FACP 0x3FFF00F0 F4 (v04 VBOX   VBOXFACP 
0001 ASL  0061)
[0.471140] ACPI: DSDT 0x3FFF0470 0022EA (v02 VBOX   VBOXBIOS 
0002 INTL 20160831)
[0.471201] ACPI: FACS 0x3FFF0200 40
[0.471257] ACPI: FACS 0x3FFF0200 40
[0.471313] ACPI: APIC 0x3FFF0240 54 (v02 VBOX   VBOXAPIC 
0001 ASL  0061)
[0.471370] ACPI: SSDT 0x3FFF02A0 0001CC (v01 VBOX   VBOXCPUT 
0002 INTL 20160831)
[0.471549] ACPI: Local APIC address 0xfee0
[0.472088] No NUMA configuration found
[0.472089] Faking a node at [mem 0x-0x3ffe]
[0.472112] NODE_DATA(0) allocated [mem 0x3ffec000-0x3ffe]
[0.472231] Zone ranges:
[0.472237]   DMA32[mem 0x1000-0x3ffe]
[0.472239]   Normal   empty
[0.472240]   Device   empty
[0.472245] Movable zone start for each node
[0.472246] Early memory node ranges
[0.472247]   node   0: [mem 0x1000-0x0009efff]
[0.472248]   node   0: [mem 0x0010-0x3ffe]
[0.472276] Zeroed struct page in unavailable ranges: 98 pages
[0.472277] Initmem setup node 0 [mem 0x1000-0x3ffe]
[0.472279] On node 0 totalpages: 262030
[0.472290]   DMA32 zone: 4096 pages used for memmap
[0.472291]   DMA32 zone: 21 pages reserved
[0.472292]   DMA32 zone: 262030 pages, LIFO batch:63
[0.480844] ACPI: PM-Timer IO Port: 0x4008
[0.480888] ACPI: Local APIC address 0xfee0
[0.481132] IOAPIC[0]: apic_id 1, version 32, address 0xfec0, GSI 0-23
[0.481179] ACPI: INT_SRC_OVR (bus 0 bus_irq 0