bug#41063: emacs-guix: unrecognized keyword error

[Ludovic Courtès]

Hi Christopher,

Christopher Howard  skribis:

> If I attempt to install a package in emacs-guix, process dies with
> error
>
> '''
> scheme@(emacs-guix)> (process-package-actions "/var/guix/profiles/per-
> user/christopher/guix-profile" #:install '((139934396296288 "out"))
> #:upgrade '() #:remove '() #:use-substitutes? #t #:dry-run? #f)
> The process begins ...
> The following package will be installed:
>pioneers 15.5
>
> emacs-guix/actions.scm:118:8: In procedure process-package-actions:
> Unrecognized keyword: #:use-substitutes?

This probably has to do with this API change:

  
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=65ffb9388c1c3d870cb07e4cb3ef12c9ac06a161

I see it’s already reported upstream:

  https://gitlab.com/emacs-guix/emacs-guix/-/issues/18

Thanks,
Ludo’.

bug#41038: gcc creates binaries that don't find their shared libraries

[Ludovic Courtès]

Hi Danny,

Danny Milosavljevic  skribis:

> I remember being tripped up by this when I started using Guix.  It is 
> annoying.
>
> I wonder if it's possible to instruct gcc (or ld, I guess) to automatically
> add rpath to where it found the respective library.  That's really what we
> expect to happen in Guix.

See the comment at the top of ld-wrapper.in.  I tried hard to avoid
having a wrapper at all but came to the conclusion that this was the
best we could do (it’s already better than what Nixpkgs did/does, which
is to wrap the whole compiler).

Thanks,
Ludo’.

bug#40981: Graphical installer tests sometimes hang.

[Ludovic Courtès]

Hi!

Mathieu Othacehe  skribis:

>> I'll keep looking!
>
> Ok, getting closer. Here's a suspect part of Shepherd strace log:
>
> [pid 1] stat("/etc/localtime", {st_mode=S_IFREG|0444, st_size=2298, ...}) 
> = 0
> [pid 1] write(9, "shepherd[1]: changing HTTP/HTTPS"..., 86) = 86
> [pid 1] getpgid(194)= 194
> [pid 1] kill(-194, SIGTERM) = 0
>
>
> I think the problem is introduced by commit
> 1e7a91d21f1cc5d02697680e19e3878ff8565710 in Shepherd.

OK, but the trace above is “as expected”, isn’t it?

> "(getpgid ") returns 0, and calling "(kill 0 SIGTERM)"
> kills all processes.

What made you think of this scenario?

I don’t think getpgid(2) can return 0.  Or am I missing something?
Since guix-dameon doesn’t actually daemonize, getpgid(pid) = pid.

Running this (in a VM) works fine:

  while herd set-http-proxy guix-daemon foo ; do : ; done

Thanks for debugging!

Ludo’.

bug#40981: Graphical installer tests sometimes hang.

[Mathieu Othacehe]

Hey!

> OK, but the trace above is “as expected”, isn’t it?

Oh sorry, I pasted the wrong part! Here's the part where getpgid returns
zero and the full log in attachment:

--8<---cut here---start->8---
[pid 1] stat("/etc/localtime", {st_mode=S_IFREG|0444, st_size=2298, ...}) = 0
[pid 1] write(9, "shepherd[1]: clearing HTTP/HTTPS"..., 59) = 59
[pid 1] getpgid(266)= 0
--8<---cut here---end--->8---

Thanks,

Mathieu


strace.log
Description: Binary data

bug#41038: gcc creates binaries that don't find their shared libraries

[Bruno Haible]

Ludovic Courtès wrote:
> I tried hard to avoid
> having a wrapper at all but came to the conclusion that this was the
> best we could do

Can something be done to avoid that installing the packages 'glibc' and
'binutils' shadows this wrapper?

Maybe moving the wrapper to a different package than it is now?

Or adding specific metainformation to some packages?

Bruno

bug#41093: --with-commit only works with git repos

[Hartmut Goebel]

guix build --with-commit only works with git repos

I would expect it to work with mercurial repos, too, as basically this
is just setting a value in the source definition. (At least this is what
I would assume it does.)

bug#40929: go-sctp build failure: "protocol not supported"

[Josh Holland]

Hi,

zimoun  writes:
>
> However, it seems fixed on core-updates.
>
> https://ci.guix.gnu.org/search?query=spec%3Acore-updates-core-updates+system%3Ax86_64-linux+docker-19.03.7

Ah, that's good.  I'll just wait for the (hopefully soon) core-updates
merge since this isn't essential to me.  If it is fixed, then presumably
this bug can be closed?

Thanks,

--
Josh Holland

bug#41090: [core-updates] fakeroot fails its test suite (breaks spacefm)

[Marius Bakke]

Maxim Cournoyer  writes:

> Hello,
>
> Testing the core-updates branch, I got this failure from fakeroot:
>
> --8<---cut here---start->8---
> make  check-TESTS
> make[2]: Entering directory 
> '/tmp/guix-build-fakeroot-1.24.drv-0/fakeroot-1.24/test'
> make[3]: Entering directory 
> '/tmp/guix-build-fakeroot-1.24.drv-0/fakeroot-1.24/test'
> PASS: t.falsereturn
> PASS: t.truereturn
> PASS: t.option
> PASS: t.echoarg
> FAIL: t.mknod
> PASS: t.touchinstall
> FAIL: t.chmod_dev
> PASS: t.no_ld_preload
> PASS: t.no_ld_preload_link
> FAIL: t.xattr
> PASS: t.cp-a
> PASS: t.tar
> 
>fakeroot 1.24: test/test-suite.log
> 
>
> # TOTAL: 12
> # PASS:  9
> # SKIP:  0
> # XFAIL: 0
> # FAIL:  3
> # XPASS: 0
> # ERROR: 0
>
> .. contents:: :depth: 2
>
> FAIL: t.chmod_dev
> =
>
> -rw-r--r-- 1 nixbld nixbld 0 May  5 00:04 t.chmod_dev.dir/hda3
> FAIL t.chmod_dev (exit status: 1)
>
> FAIL: t.mknod
> =
>
> -rw-r--r-- 1 nixbld nixbld 0 May  5 00:04 t.mknod.dir/hda3
> FAIL t.mknod (exit status: 1)

These two tests create a block device with 'mknod' inside the fakeroot,
and afterwards verifies with 'ls' that they are in fact block devices.

It turns out that the 'ls' invokation does not work because the newer
'ls' uses statx() which is not supported/caught by fakeroot, and thus it
does not see the fake block device.  So I changed these tests to use
'test -b' as a stopgap measure.

> FAIL: t.xattr
> =
>
> unable to set CAP_SETFCAP effective capability: Operation not permitted
> FAIL t.xattr (exit status: 1)

This turned out to be a regression in 'libcap', fixed by providing a
newer version.

Fixed in ba151b7e1a9cc0baf932b5c5e0c916e54d2e27f4, thanks!


signature.asc
Description: PGP signature

bug#41082: nomodeset

[Ryan Osborne]

nomodest allows the system to boot, but when it boots the framebuffer
and X don't seem to work.


[0.00] Linux version 5.4.38-gnu (nixbld@) (gcc version 7.4.0 (GCC)) #1 
SMP 1
[0.00] Command line: 
BOOT_IMAGE=/gnu/store/kygqk99rl8g66j9z125gnx4cyp7m9a5v-linux-libre-5.4.38/bzImage
 --root=/dev/mapper/cryptroot 
--system=/gnu/store/6hsgwcwzlyybim96i1jdp9hymsfj2sgf-system 
--load=/gnu/store/6hsgwcwzlyybim96i1jdp9hymsfj2sgf-system/boot 
modprobe.blacklist=usbmouse,usbkbd quiet nomodeset
[0.00] KERNEL supported cpus:
[0.00]   Intel GenuineIntel
[0.00]   AMD AuthenticAMD
[0.00]   Hygon HygonGenuine
[0.00]   Centaur CentaurHauls
[0.00]   zhaoxin   Shanghai  
[0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
[0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
[0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
[0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, 
using 'standard' format.
[0.00] BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
[0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0xcca94fff] usable
[0.00] BIOS-e820: [mem 0xcca95000-0xcca9bfff] ACPI NVS
[0.00] BIOS-e820: [mem 0xcca9c000-0xcd44bfff] usable
[0.00] BIOS-e820: [mem 0xcd44c000-0xcd710fff] reserved
[0.00] BIOS-e820: [mem 0xcd711000-0xdde9bfff] usable
[0.00] BIOS-e820: [mem 0xdde9c000-0xddf27fff] reserved
[0.00] BIOS-e820: [mem 0xddf28000-0xddf42fff] ACPI data
[0.00] BIOS-e820: [mem 0xddf43000-0xde970fff] ACPI NVS
[0.00] BIOS-e820: [mem 0xde971000-0xdeffefff] reserved
[0.00] BIOS-e820: [mem 0xdefff000-0xdeff] usable
[0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
[0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
[0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
[0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
[0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
[0.00] BIOS-e820: [mem 0xff00-0x] reserved
[0.00] BIOS-e820: [mem 0x0001-0x00021eff] usable
[0.00] NX (Execute Disable) protection: active
[0.00] SMBIOS 2.8 present.
[0.00] DMI: LENOVO 10B5US/, BIOS FCKT50AUS 04/03/2014
[0.00] tsc: Fast TSC calibration using PIT
[0.00] tsc: Detected 3192.712 MHz processor
[0.001552] e820: update [mem 0x-0x0fff] usable ==> reserved
[0.001553] e820: remove [mem 0x000a-0x000f] usable
[0.001558] last_pfn = 0x21f000 max_arch_pfn = 0x4
[0.001561] MTRR default type: uncachable
[0.001562] MTRR fixed ranges enabled:
[0.001563]   0-9 write-back
[0.001563]   A-B uncachable
[0.001564]   C-C write-protect
[0.001565]   D-E7FFF uncachable
[0.001565]   E8000-F write-protect
[0.001565] MTRR variable ranges enabled:
[0.001567]   0 base 00 mask 7E write-back
[0.001567]   1 base 02 mask 7FF000 write-back
[0.001568]   2 base 021000 mask 7FF800 write-back
[0.001569]   3 base 021800 mask 7FFC00 write-back
[0.001569]   4 base 021C00 mask 7FFE00 write-back
[0.001570]   5 base 021E00 mask 7FFF00 write-back
[0.001570]   6 base 00E000 mask 7FE000 uncachable
[0.001571]   7 disabled
[0.001571]   8 disabled
[0.001571]   9 disabled
[0.001854] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
[0.001984] total RAM covered: 8176M
[0.002302] Found optimal setting for mtrr clean up
[0.002302]  gran_size: 64K  chunk_size: 32M num_reg: 6  lose 
cover RAM: 0G
[0.002584] e820: update [mem 0xe000-0x] usable ==> reserved
[0.002587] last_pfn = 0xdf000 max_arch_pfn = 0x4
[0.008697] found SMP MP-table at [mem 0x000fcd40-0x000fcd4f]
[0.018390] check: Scanning 1 areas for low memory corruption
[0.018394] Using GB pages for direct mapping
[0.018396] BRK [0xd7c01000, 0xd7c01fff] PGTABLE
[0.018397] BRK [0xd7c02000, 0xd7c02fff] PGTABLE
[0.018398] BRK [0xd7c03000, 0xd7c03fff] PGTABLE
[0.018420] BRK [0xd7c04000, 0xd7c04fff] PGTABLE
[0.018421] BRK [0xd7c05000, 0xd7c05fff] PGTABLE
[0.018531] BRK [0xd7c06000, 0xd7c06fff] PGTABLE
[0.018558] BRK [0xd7c07000, 0xd7c07fff]

bug#41098: Messages sent via mumi have no subject

[Leo Famulari]

I noticed that messages sent via the web form from mumi have no subject.
For example the subject's look like "bug#40587: (no subject)".

bug#41019: util-linux runstatedir is not actually a state directory

[Leo Famulari]

On Mon, May 04, 2020 at 12:14:44AM +0200, Danny Milosavljevic wrote:
> Also added horrible workaround for this bug in commit
> da09c63e78ebebeabb347f483d7284b87ff51c2f.

Do you want to leave the bug ticket open? Or is it "done"?

bug#41019: util-linux runstatedir is not actually a state directory

[Danny Milosavljevic]

I'd prefer if we left the bug report still open and eventually fixed this
bug--although util-linux has a huge number of dependents.

The workaround is just removing the store reference from the executable file,
after the fact.
I mean it works because then libuuid.a can't find the socket for uuidd using
the name "", but that's not the right way :P


pgpKTpIPlyfwK.pgp
Description: OpenPGP digital signature

bug#41019: util-linux runstatedir is not actually a state directory

[Marius Bakke]

Danny Milosavljevic  writes:

> I'd prefer if we left the bug report still open and eventually fixed this
> bug--although util-linux has a huge number of dependents.

You could create a 'util-linux/fixed' variable for this package if you
know how to fix it, and merge it with util-linux in the next
core-updates round.


signature.asc
Description: PGP signature

bug#41093: --with-commit only works with git repos

[Ludovic Courtès]

Hi,

Hartmut Goebel  skribis:

> guix build --with-commit only works with git repos

Yup, as documented (info "(guix) Package Transformation Options").  :-)

> I would expect it to work with mercurial repos, too, as basically this
> is just setting a value in the source definition. (At least this is what
> I would assume it does.)

And Subversion, and Monotone, and CVS…  but no, this is not
implemented.  ;-)

The implementation is different from what you suggest: it uses a
 record instead of an .  That performs a checkout
beforehand and uses that as the source.

Closing, but you can open a wishlist item if you want.

Thanks,
Ludo’.

bug#41044: [guix 1.1.0] guix pull failed

[Ludovic Courtès]

Hi,

wensheng xie  skribis:

> ./guix/store.scm:1034:9: Throw to key `srfi-34' with args `(# &store-protocol-error [message: "error parsing derivation 
> `/gnu/store/7vs0arx5s6whljvbbb5rky4mbrs61f85-icu4c-datetime-regression.patch.drv':
>  expected string `)'" status: 1] 7fa6368f3f30>)'.

Could you check the contents of the file above?  It seems to be corrupt,
which could be the result of a hard disk corruption, possibly due to
hardware issues.

Thanks in advance,
Ludo’.

bug#41028: Channel/inferior error with core-updates: Unbound variable: call-with-new-thread

[Ludovic Courtès]

Hey!

Christopher Baines  skribis:

> → guix build -f test.scm 
> Updating channel 'guix' from Git repository at 
> 'https://git.savannah.gnu.org/git/guix.git'...
> Backtrace:
>4 (primitive-load "/gnu/store/8mv5bpjgxg9c369xnbb5rf1kv9r?")
> In ice-9/eval.scm:
> 619:8  3 (_ #(#(#(#(#(#(#(#(#(#(#(?) ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
>182:19  2 (proc #(#(#(#(#(#(#(#(#(#(# ?) ?) ?) ?) ?) ?) ?) ?) ?) ?))
>142:16  1 (compile-top-call # ?)
> In unknown file:
>0 (%resolve-variable (7 . call-with-new-thread) #)
>
> ERROR: In procedure %resolve-variable:
> Unbound variable: call-with-new-thread
> guix build: error: You found a bug: the program 
> '/gnu/store/8mv5bpjgxg9c369xnbb5rf1kv9r6z5hw-compute-guix-derivation'
> failed to compute the derivation for Guix (version: 
> "e02c2f85b36ce1c733bd908a210ce1182bdd2560"; system: "x86_64-linux";
> host version: "a8cb1e72ef351330d1521833c1b270dcc0da593f"; pull-version: 1).

A summary of the IRC discussion and experiments:

  1. The underlying problem is a missing (ice-9 threads) import in the
 ‘compute-guix-derivation’ script, fixed in
 05e783871c2c69b402e088863d46f5be7915ac74.

  2. The ‘%quirks’ mechanism in (guix channels) doesn’t work as is here
 because what we would need to change is the #:guile parameter
 passed to ‘gexp->script’ (the one defined in build-self.scm).
 Attached a patch to add a quirk but that doesn’t solve the problem.

Possible solutions include:

  a. Changing the value returned by ‘default-guile’ as used by
 ‘gexp->script’.

  b. Supporting the definition of quirks that patch the code.

Thanks,
Ludo’.

diff --git a/guix/channels.scm b/guix/channels.scm
index 041fae2a9c..cbb0a97546 100644
--- a/guix/channels.scm
+++ b/guix/channels.scm
@@ -328,16 +328,34 @@ to '%package-module-path'."
   #f
   (apply throw args)
 
+(define (missing-ice-9-threads-import? source)
+  "Return true of %SELF-BUILD-FILE is missing an (ice-9 threads) import as
+described at ."
+  (define content
+(call-with-input-file (string-append source "/" %self-build-file)
+  read-string))
+
+  ;; The faulty code uses 'call-with-new-thread' without importing (ice-9
+  ;; threads).  However, the 'call-with-new-thread' binding is no longer
+  ;; available in the default name space on Guile 3.0.
+  (and (string-contains content "(call-with-new-thread")
+   (not (string-contains content "(ice-9 threads)"
+
 (define (guile-2.2.4)
   (module-ref (resolve-interface '(gnu packages guile))
   'guile-2.2.4))
 
+(define (guile-2.2)
+  (module-ref (resolve-interface '(gnu packages guile))
+  'guile-2.2))
+
 (define %quirks
   ;; List of predicate/package pairs.  This allows us provide information
   ;; about specific Guile versions that old Guix revisions might need to use
   ;; just to be able to build and run the trampoline in %SELF-BUILD-FILE.  See
   ;; 
-  `((,syscalls-reexports-local-variables? . ,guile-2.2.4)))
+  `((,syscalls-reexports-local-variables? . ,guile-2.2.4)
+(,missing-ice-9-threads-import? . ,guile-2.2)))
 
 (define* (guile-for-source source #:optional (quirks %quirks))
   "Return the Guile package to use when building SOURCE or #f if the default
@@ -372,32 +390,32 @@ package modules under SOURCE using CORE, an instance of Guix."
 (string-append source "/" %self-build-file))
 
   (if (file-exists? script)
-  (let ((build (save-module-excursion
-(lambda ()
-  ;; Disable deprecation warnings; it's OK for SCRIPT to
-  ;; use deprecated APIs and the user doesn't have to know
-  ;; about it.
-  (parameterize ((guix-warning-port
-  (%make-void-port "w")))
-(primitive-load script)
-(guile (guile-for-source source)))
+  (mlet* %store-monad ((guile -> (guile-for-source source))
+   (_(mwhen guile
+   (set-guile-for-build (pk 'G guile
+   (build -> (save-module-excursion
+  (lambda ()
+;; Disable deprecation warnings; it's
+;; OK for SCRIPT to use deprecated
+;; APIs and the user doesn't have to
+;; know about it.
+(parameterize ((guix-warning-port
+(%make-void-port "w")))
+  (primitive-load script))
 ;; BUILD must be a monadic procedure of at least one argument: the
 ;; source tree.
 ;;
 ;; Note: BUILD can return #f if it does not support %PULL-VERSION.  In
 ;; the futu

bug#41082: nomodeset

[Mathieu Othacehe]

Hello,

Thanks for reporting! It has been discussed on IRC, and booting the same
machine with integrated graphics works.

While uvesafb allows us to get framebuffer support in the
installer, the installed system will blackscreen or fail to boot with
those AMD GPUs.

Should we propose the installation of uvesafb service in the
installation? Or detect that it is currently used and force its install?

Florian, WDYT?

Thanks,

Mathieu

Ryan Osborne  writes:

> nomodest allows the system to boot, but when it boots the framebuffer
> and X don't seem to work.
>
>
> [0.00] Linux version 5.4.38-gnu (nixbld@) (gcc version 7.4.0 (GCC)) 
> #1 SMP 1
> [0.00] Command line: 
> BOOT_IMAGE=/gnu/store/kygqk99rl8g66j9z125gnx4cyp7m9a5v-linux-libre-5.4.38/bzImage
>  --root=/dev/mapper/cryptroot 
> --system=/gnu/store/6hsgwcwzlyybim96i1jdp9hymsfj2sgf-system 
> --load=/gnu/store/6hsgwcwzlyybim96i1jdp9hymsfj2sgf-system/boot 
> modprobe.blacklist=usbmouse,usbkbd quiet nomodeset
> [0.00] KERNEL supported cpus:
> [0.00]   Intel GenuineIntel
> [0.00]   AMD AuthenticAMD
> [0.00]   Hygon HygonGenuine
> [0.00]   Centaur CentaurHauls
> [0.00]   zhaoxin   Shanghai  
> [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point 
> registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
> [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
> [0.00] x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
> [0.00] x86/fpu: Enabled xstate features 0x7, context size is 832 
> bytes, using 'standard' format.
> [0.00] BIOS-provided physical RAM map:
> [0.00] BIOS-e820: [mem 0x-0x0009d7ff] usable
> [0.00] BIOS-e820: [mem 0x0009d800-0x0009] reserved
> [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved
> [0.00] BIOS-e820: [mem 0x0010-0xcca94fff] usable
> [0.00] BIOS-e820: [mem 0xcca95000-0xcca9bfff] ACPI NVS
> [0.00] BIOS-e820: [mem 0xcca9c000-0xcd44bfff] usable
> [0.00] BIOS-e820: [mem 0xcd44c000-0xcd710fff] reserved
> [0.00] BIOS-e820: [mem 0xcd711000-0xdde9bfff] usable
> [0.00] BIOS-e820: [mem 0xdde9c000-0xddf27fff] reserved
> [0.00] BIOS-e820: [mem 0xddf28000-0xddf42fff] ACPI 
> data
> [0.00] BIOS-e820: [mem 0xddf43000-0xde970fff] ACPI NVS
> [0.00] BIOS-e820: [mem 0xde971000-0xdeffefff] reserved
> [0.00] BIOS-e820: [mem 0xdefff000-0xdeff] usable
> [0.00] BIOS-e820: [mem 0xf800-0xfbff] reserved
> [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved
> [0.00] BIOS-e820: [mem 0xfed0-0xfed03fff] reserved
> [0.00] BIOS-e820: [mem 0xfed1c000-0xfed1] reserved
> [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved
> [0.00] BIOS-e820: [mem 0xff00-0x] reserved
> [0.00] BIOS-e820: [mem 0x0001-0x00021eff] usable
> [0.00] NX (Execute Disable) protection: active
> [0.00] SMBIOS 2.8 present.
> [0.00] DMI: LENOVO 10B5US/, BIOS FCKT50AUS 04/03/2014
> [0.00] tsc: Fast TSC calibration using PIT
> [0.00] tsc: Detected 3192.712 MHz processor
> [0.001552] e820: update [mem 0x-0x0fff] usable ==> reserved
> [0.001553] e820: remove [mem 0x000a-0x000f] usable
> [0.001558] last_pfn = 0x21f000 max_arch_pfn = 0x4
> [0.001561] MTRR default type: uncachable
> [0.001562] MTRR fixed ranges enabled:
> [0.001563]   0-9 write-back
> [0.001563]   A-B uncachable
> [0.001564]   C-C write-protect
> [0.001565]   D-E7FFF uncachable
> [0.001565]   E8000-F write-protect
> [0.001565] MTRR variable ranges enabled:
> [0.001567]   0 base 00 mask 7E write-back
> [0.001567]   1 base 02 mask 7FF000 write-back
> [0.001568]   2 base 021000 mask 7FF800 write-back
> [0.001569]   3 base 021800 mask 7FFC00 write-back
> [0.001569]   4 base 021C00 mask 7FFE00 write-back
> [0.001570]   5 base 021E00 mask 7FFF00 write-back
> [0.001570]   6 base 00E000 mask 7FE000 uncachable
> [0.001571]   7 disabled
> [0.001571]   8 disabled
> [0.001571]   9 disabled
> [0.001854] x86/PAT: Configuration [0-7]: WB  WC  UC- UC  WB  WP  UC- WT  
> [0.001984] total RAM covered: 8176M
> [0.002302] Found optimal setting for mtrr clean up
> [0.002302]  gran_size: 64Kchunk_size: 32M num_reg: 6  
> lose cover RAM: 0G
> [0.002584] e820: update [mem 0xe000-0xf