Re: Video narration

[Laura Lazzati]

Hi everybody!

These days I will be migrating my VM since I am running out of space,
so sorry for the delay :/

I am testing right now.

> Commit 4bd2e78b893fef5ce1f12bec895ee8234cabaf1f fixes the colors.
> ffmpeg needed a different pixel format to set the chroma subsampling
> correctly [1].
>
> I have been able to play the newly built cli and nocli videos in
> Firefox.  Also, the combined video now starts in Firefox but stops just
> before the first transition.  I think the concatenation step in the
> Makefile could be the cause.
The same happens to me with Firefox.
Now, as regards the colours, it works with totem too :)
But the cli sessions are at kind of super speed now, it happens
watching the full video, or the separate cli session videos. I've
tried it with totem, mvp and vlc. Any clue about it?


Regards :)
Laura

Guile Days in Strasbourg, France, June 19–22

[Ludovic Courtès]

Hello Guilers!  Hello Guix!

We’re organizing Guile Days at the University of Strasbourg, France,
co-located with the Perl Workshop, from June 19th to 22nd:

  https://journeesperl.fr/jp2019/

We were kindly invited by the Perl Workshop organizers to join them and
have Guile + Guix sessions, while they take care of all the logistics
and web site—how could we refuse?  :-)

You are encouraged to submit by June 1st, on the web site, talks on
topics such as:

  • The neat Guile- or Guix-related project you’ve been working on.

  • Cool Guile hacking topics—Web development, databases, system
development, graphical user interfaces, shells, you name it!

  • Fancy Guile technology—concurrent programming with Fibers, crazy
macrology, compiler front-ends, JIT compilation and Guile 3,
development environments, etc.

  • Guixy things: on Guix subsystems, services, the Shepherd, Guile
development with Guix, all things OS-level in Guile, Cuirass,
reproducible builds, bootstrapping, Mes and Gash, all this!

You can also submit hands-on workshops, which could last anything from
an hour to a day.  We expect newcomers at this event, people who don’t
know Guile and Guix and want to learn about it.  Consider submitting
introductory workshops on Guile and Guix!

We encourage submissions from people in communities usually
underrepresented in free software, including women, people in sexual
minorities, or people with disabilities.

Participation to the event is subject to a code of conduct:
.

Many thanks to the organizers of the Perl Workshop and in particular to
Marc Chantreux, and thanks to the sponsors of the event: RENATER, and
Université de Strasbourg.

See you there!

Ludo’.


signature.asc
Description: PGP signature

Re: Trouble getting 'fprintd-service-type' to work

[Mark H Weaver]

Hi Danny,

Danny Milosavljevic  writes:

> On Tue, 16 Apr 2019 16:07:19 -0400
> Mark H Weaver  wrote:
>
>> Did you test this service before pushing it to master?
>
> I can't remember - but probably not.  Sorry.
>
>> Does it work for you?
>
> It didn't work but I fixed it now with commit 
> 0682f084635cdc289aabafc4b2583639e00a28b3.

Thanks, but did you test that it actually works in practice?

I strongly suspect that it still won't work.  According to
, the 'pam_fprintd.so'
module needs to be added to the PAM configuration.

So, I guess we also need something along the lines of the following,
which is used in 'elogind-service-type' in (gnu services desktop):

   ;; Extend PAM with pam_fprintd.so.
   (service-extension pam-root-service-type
  pam-extension-procedure)

Would you be willing to take a look?  I think it would be embarrassing
to release Guix 1.0 with a documented service that has never been
tested.  What do you think?

  Regards,
Mark

Re: Problem with `direnv` package definition

[Christopher Baines]

Tanguy Le Carrour  writes:

> Dear Guix
>
> As I'm still in the process of setting up my environment,
> I am not (yet) able to write and submit a patch for package `direnv`,
> so I'm sending this report instead…
>
> As mentioned on the `direnv` homepage, "direnv is compiled into
> a single static executable" [1]. As I understand it, this means that
> Go is required to build it, but not to run it.
>
> [1]: https://github.com/direnv/direnv
>
> However, in the package definition [2], 3 Go packages are listed as
> "inputs" whereas they should be listed as "native-inputs". Is this
> correct?
>
> [2]: gnu/packages/shellutils.scm

Hi Tanguy,

That sounds right to me, although there have been issues with binaries
generated with Go still referencing the Go compiler, and that's
seemingly the case with the direnv package in Guix at the moment.

There's also an important aspect of cross-compilation to these fields,
which you can read about here:

  https://www.gnu.org/software/guix/manual/en/html_node/package-Reference.html

> As I said, I'm still learning. But I've tried, and here is what I've
> done so far…
>
> I've `git clone`d the repo, ran the `guix env… guix` then `bootstrap`
> `configure` and `make` and everything seems to be fine.
> Just to make sure, I did `./pre-… guix env… direnv` then
> ran `./pre-… guix build direnv` and everything went well.
> Then I moved the direnv dependencies from inputs to native-inputs and
> build it again… and it unsurprisingly failed! The error message [3]
> does not say much… at least to me! ^_^'
>
> [3]: output of `./pre-inst-env guix build --keep-failed direnv`
>   direnv-2.15.2/version.txt
>   direnv-2.15.2/xdg.go
>   phase `unpack' succeeded after 0.0 seconds
>   starting phase `bootstrap'
>   no 'configure.ac' or anything like that, doing nothing
>   phase `bootstrap' succeeded after 0.0 seconds
>   starting phase `patch-usr-bin-file'
>   phase `patch-usr-bin-file' succeeded after 0.0 seconds
>   starting phase `patch-source-shebangs'
>   phase `patch-source-shebangs' succeeded after 0.0 seconds
>   starting phase `patch-generated-file-shebangs'
>   phase `patch-generated-file-shebangs' succeeded after 0.0 seconds
>   starting phase `build'
>   make: *** No targets specified and no makefile found.  Stop.
>   Backtrace:
>   4 (primitive-load
>   "/gnu/store/7rrxdai48si293dihzf55zn3svn…")
>   In ice-9/eval.scm:
>  191:35  3 (_ #f)
>   In srfi/srfi-1.scm:
>  863:16  2 (every1 #
>   …)
>   In
>/gnu/store/i5ip2vy29fqppjb4pq5isq36gqd42d89-module-import/guix/build/gn
>u-build-system.scm:
>799:28  1 (_ _)
>   In
>
> /gnu/store/i5ip2vy29fqppjb4pq5isq36gqd42d89-module-import/guix/build/utils.scm:
>616:6  0 (invoke _ . _)
>
> /gnu/store/i5ip2vy29fqppjb4pq5isq36gqd42d89-module-import/guix/build/utils.scm:616:6:
>  In procedure invoke:
>   Throw to key `srfi-34' with args `(# "make" arguments: ("-j" "8"
>   "DESTDIR=/gnu/store/dcvs8cq0ll4hcxc4x3mlcf24y1cw4ckm-direnv-2.15.2")
>   exit-status: 2 term-signal: #f stop-signal: #f] 869e80>)'.
>
>
> I've tried to read the rest of the package definition, but as I'm still
> attending Guile 1-0-1, that didn't help much!
>
> I would very much appreciate it if someone could point out my mistake!

I tried changing the inputs to native-inputs, and the package built for
me. Could you share the exact changes you made?

Chris


signature.asc
Description: PGP signature

Re: ISO installer image: GPT versus MBR partitions

[Thomas Schmitt]

Hi,

Florian Pelz wrote:
> mkfs.fat fatfs.img
> sudo mount fatfs.img /mnt/img
> sudo cp -r /mnt/efiimg/efi /mnt/img/
> Hooray!  It boots!

So it is indeed the filesystem hull, which is to blame.

We still need to find out whether the partition entry is the culprit.
So please do the experiment with the Guix EFI partition image in
partition 2 of the USB stick and

   dd if=/dev/zero bs=1 count=16 seek=446 of=/dev/sdc2

The partition entry in the Guix EFI partition image has all the
properties of the thing we are looking for:
- Not in the FAT filesystem, but also not outside of it.
- Plausible to be differently approached from USB stick and DVD.
- Self referring enough for an endless inspection loop in EFI.


> It uses mkfs.fat for creating FAT partitions, but maybe this
> particular EFI partition is created by grub-mkrescue?

Yes.
  http://git.savannah.gnu.org/cgit/grub.git/tree/util/grub-mkrescue.c#n812
has:
  rv = grub_util_exec ((const char * []) { "mformat", "-C", "-f", "2880", 
"-L", "16", "-i",
efiimgfat, "::", NULL });

This run produces an image file with partition 1, starting at LBA 0.
A remark below
  https://sources.debian.org/src/mtools/4.0.23-1/mformat.c/#L1373
says:
  /* install fake partition table pointing to itself */

(But why does grub-mkrescue.c create a 2.8 MB floppy where Guix has a
 1.4 MB floppy image ? Does Guix use a patched version of grub-mkrescue ?)

---
Under the assumption that it is really the partition entry, i snooped ahead:

mformat options -2 and -k can suppress the production of the partition
entry. Option -2 is for some exotic floppy format from the 1990s.

Option -k seems better, but if i use it, program "file" becomes sparing
with words:

  $ file /u/test/mformat.fat
  /u/test/mformat.fat: DOS floppy 1440k
  $

It can be mounted by Linux and offers free space, though.

More similar to the current FAT image hull is the result of

   dd if=/dev/zero bs=1 count=16 seek=446 of=/dev/sdc2

I actually did with a copy of partition 2:
   dd if=/dev/zero bs=1 count=16 seek=446 conv=notrunc of=test.img
and the report of "file" did not change. fdisk reports no partitions
in test.img any more.


Assuming that we cannot easily convince GRUB to use mformat -k or to
switch to some other FAT creator, i currently ponder the opportunity
to let my man-in-the-middle script do this dd patching of the EFI image
before it gets copied into the ISO.

-
Second correction of my statement about zapping the partition entry:

i wrote:
> The 16 bytes written to /dev/sdc1 would deface the GPT's "protective" MBR
> and thus make the GPT invalid.

Wrong again. Because it is a grub-mkrescue ISO, it hit byte 446 ff of
the ISO Primary Volume Descriptor. Funnily this is the place where
xorriso placed its hallmark:
   XORRISO-1.5.0 2018...
So the misplaced dd was effectively without effect.

-

Have a nice day :)

Thomas

Re: ISO installer image: GPT versus MBR partitions

[pelzflorian (Florian Pelz)]

On Sat, Apr 20, 2019 at 04:54:24PM +0200, pelzflorian (Florian Pelz) wrote:
> But…  Guix’ gnu/build/vm.scm already uses mkfs.fat.  Strange…
> 

It uses mkfs.fat for creating FAT partitions, but maybe this
particular EFI partition is created by grub-mkrescue?

Regards,
Florian

Re: ISO installer image: GPT versus MBR partitions

[pelzflorian (Florian Pelz)]

On Sat, Apr 20, 2019 at 04:54:24PM +0200, pelzflorian (Florian Pelz) wrote:
> sudo dd if=fatfs.img of=/dev/sdc2
> sync
> 

I can copy the same fatfs.img from Guix System 0.16.0 onto a current
Guix git master installer iso and it works too.

Re: ISO installer image: GPT versus MBR partitions

[pelzflorian (Florian Pelz)]

It works, see end of this e-mail.

On Sat, Apr 20, 2019 at 12:50:49PM +0200, Thomas Schmitt wrote:
> So after these steps :
> 
> > I wrote guixsd-install-0.16.0.x86_64-linux.iso to my USB drive again.
> > Boot gets stuck again.
> >
> > I did `sudo dd if=/dev/zero of=/dev/sdc2` to zero out the EFI
> > partition.
> 
> mount the Debian Live 9 ISO (e.g. at /mnt/iso) and do
> 
>   dd if=/mnt/iso/boot/grub/efi.img of=/dev/sdc2
> 
> 

It still does not get stuck. :)



On Sat, Apr 20, 2019 at 01:16:14PM +0200, Thomas Schmitt wrote:
> My favorite suspect would be the partition table in Guix /efi.img.
> 
> To kill table entry 1 after having put the Guix EFI image back into
> partition 2 of the USB stick:
> 
>dd if=/dev/zero bs=1 count=16 seek=446 of=/dev/sdc1
>

I did

sudo dd if=Downloads/guixsd-install-0.16.0.x86_64-linux.iso of=/dev/sdc
sudo dd if=/dev/zero bs=1 count=16 seek=446 of=/dev/sdc1

Boot gets stuck.

On Sat, Apr 20, 2019 at 04:23:49PM +0200, Thomas Schmitt wrote:
> Of course i meant  of=/dev/sdc2
> 

Oops, too late.


> If this does not help, then create a new empty FAT filesystem image,
> mount it, and copy the tree from the mounted Guix /efi.img into it.
> The new filesystem should have between 200 KiB and 1.4 MiB.
> (The Guix image of 1.4 MiB still has 90 % of its capacity free.)
> 

I do not recreate the USB drive.  I do:

qemu-img create -f raw fatfs.img 1M
mkfs.fat fatfs.img # from package dosfstools like the EFI system
   # partition on Arch wiki
sudo mount Downloads/guixsd-install-0.16.0.x86_64-linux.iso /mnt/iso
sudo mount fatfs.img /mnt/img
sudo mount /mnt/iso/efi.img /mnt/efiimg
sudo cp -r /mnt/efiimg/efi /mnt/img/
sudo umount /mnt/img

> Then put the new filesystem into /dev/sdc2 and see what happens.
>

sudo dd if=fatfs.img of=/dev/sdc2
sync

Hooray!  It boots!  Thank you so much for your patience.

I remember back when I used Parabola GNU/Linux-libre, I had to make
sure I used mkfs.fat instead of mkfs.msdos or else the EFI partition
did not work, I think.

But…  Guix’ gnu/build/vm.scm already uses mkfs.fat.  Strange…

Regards,
Florian

Re: ISO installer image: GPT versus MBR partitions

[Thomas Schmitt]

Hi,

i wrote:
> To kill table entry 1 after having put the Guix EFI image back into
> partition 2 of the USB stick:
>
>   dd if=/dev/zero bs=1 count=16 seek=446 of=/dev/sdc1

Of course i meant  of=/dev/sdc2

The 16 bytes written to /dev/sdc1 would deface the GPT's "protective" MBR
and thus make the GPT invalid.


Have a nice day :)

Thomas

Problem with `direnv` package definition

[Tanguy Le Carrour]

Dear Guix

As I'm still in the process of setting up my environment,
I am not (yet) able to write and submit a patch for package `direnv`,
so I'm sending this report instead…

As mentioned on the `direnv` homepage, "direnv is compiled into
a single static executable" [1]. As I understand it, this means that
Go is required to build it, but not to run it.

[1]: https://github.com/direnv/direnv

However, in the package definition [2], 3 Go packages are listed as
"inputs" whereas they should be listed as "native-inputs". Is this
correct?

[2]: gnu/packages/shellutils.scm

As I said, I'm still learning. But I've tried, and here is what I've
done so far…

I've `git clone`d the repo, ran the `guix env… guix` then `bootstrap`
`configure` and `make` and everything seems to be fine.
Just to make sure, I did `./pre-… guix env… direnv` then
ran `./pre-… guix build direnv` and everything went well.
Then I moved the direnv dependencies from inputs to native-inputs and
build it again… and it unsurprisingly failed! The error message [3]
does not say much… at least to me! ^_^'

[3]: output of `./pre-inst-env guix build --keep-failed direnv`
  direnv-2.15.2/version.txt
  direnv-2.15.2/xdg.go
  phase `unpack' succeeded after 0.0 seconds
  starting phase `bootstrap'
  no 'configure.ac' or anything like that, doing nothing
  phase `bootstrap' succeeded after 0.0 seconds
  starting phase `patch-usr-bin-file'
  phase `patch-usr-bin-file' succeeded after 0.0 seconds
  starting phase `patch-source-shebangs'
  phase `patch-source-shebangs' succeeded after 0.0 seconds
  starting phase `patch-generated-file-shebangs'
  phase `patch-generated-file-shebangs' succeeded after 0.0 seconds
  starting phase `build'
  make: *** No targets specified and no makefile found.  Stop.
  Backtrace:
  4 (primitive-load
  "/gnu/store/7rrxdai48si293dihzf55zn3svn…")
  In ice-9/eval.scm:
 191:35  3 (_ #f)
  In srfi/srfi-1.scm:
 863:16  2 (every1 #
  …)
  In
   /gnu/store/i5ip2vy29fqppjb4pq5isq36gqd42d89-module-import/guix/build/gn
   u-build-system.scm:
   799:28  1 (_ _)
  In
   
/gnu/store/i5ip2vy29fqppjb4pq5isq36gqd42d89-module-import/guix/build/utils.scm:
   616:6  0 (invoke _ . _)
   
/gnu/store/i5ip2vy29fqppjb4pq5isq36gqd42d89-module-import/guix/build/utils.scm:616:6:
 In procedure invoke:
  Throw to key `srfi-34' with args `(#)'.


I've tried to read the rest of the package definition, but as I'm still
attending Guile 1-0-1, that didn't help much!

I would very much appreciate it if someone could point out my mistake!

Regards,

-- 
Tanguy

Re: ISO installer image: GPT versus MBR partitions

[Thomas Schmitt]

Hi,

... and if the erasure of the partition table entry helps, would it then
also help if that entry's partition does not start at LBA 0 ?

Change bytes 446 (dec) to 461 (dec) from (in hex):

  80  00  01  00  01  01  12  4f  00  00  00  00  40  0b  00  00

to

  80  00  02  00  01  01  12  4f  01  00  00  00  3f  0b  00  00

"02" = Sector 2 = LBA 1.
"01 00 00 00" = LBA 1.
"3f 0b 00 00" = bloc count 2879, rather than 2880.


Reasoning:

It would make a nice endless loop if EFI dives into any partition
and looks for sub partition tables. The one in GRUB's efi.img refers
to itself.
DVD might be immune because EFI does not do this diving when it finds
the partition by the El Torito boot catalog.


Have a nice day :)

Thomas

Re: KMScon vs. AMD Radeon

[Félicien Pillot]

Le Sat, 20 Apr 2019 12:39:57 +0200,
"pelzflorian (Florian Pelz)"  a écrit :

> lspci reports my card as Radeon R7 240/340.  According to Wikipedia
> this GPU was released in 2013.  Xorg attempted to load the radeon
> driver and not amdgpu.
> 
> Regards,
> Florian

I also have a Radeon R7 240/340. lspci -k outputs these lines:

> 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] 
> Oland PRO [Radeon R7 240/340] (rev 87)
> Subsystem: ASUSTeK Computer Inc. Oland PRO [Radeon R7 240/340]
> Kernel driver in use: radeon
> Kernel modules: radeon, amdgpu

I tried a lot, but couldn't manage to start Xorg with amdgpu. Actually I can't 
either use linux-libre if I want a good resolution (1920x1080), I have to 
inject binary firmwares, as explained at 
https://wiki.gentoo.org/wiki/Amdgpu#Incorporating_firmware

-- 
Félicien Pillot
2C7C ACC0 FBDB ADBA E7BC  50D9 043C D143 6C87 9372
felic...@gnu.org - felicien.pil...@riseup.net


pgpindjdXbHvh.pgp
Description: Signature digitale OpenPGP

Re: ISO installer image: GPT versus MBR partitions

[Thomas Schmitt]

Hi,

i now look at the FAT filesystem images of Debian Live 9 and Guix 0.16.0:

Guix:

- There is an MBR partition table in the image file:
DeviceBoot Start   End Sectors  Size Id Type
/mnt/iso/efi.img1 *0  28792880  1.4M  1 FAT12

- Program "file" says:

  DOS/MBR boot sector, code offset 0x3c+2,
  OEM-ID "MTOO4021",
  root entries 224, sectors 2880 (volumes <=32 MB) ,
  sectors/FAT 9, sectors/track 18,
  serial number 0x336648a7, unlabeled,
  FAT (12 bit), followed by FAT

Debian:

- No partition table in image.

- Program "file" says:
  DOS/MBR boot sector, code offset 0x3c+2,
  OEM-ID "mkfs.fat",
  sectors/cluster 4, root entries 512, sectors 832 (volumes <=32 MB) ,
  Media descriptor 0xf8,
  sectors/FAT 1, sectors/track 32, heads 64,
  serial number 0x64c6c435, unlabeled, FAT (12 bit)

-

My favorite suspect would be the partition table in Guix /efi.img.

To kill table entry 1 after having put the Guix EFI image back into
partition 2 of the USB stick:

   dd if=/dev/zero bs=1 count=16 seek=446 of=/dev/sdc1

-

If this does not help, then create a new empty FAT filesystem image,
mount it, and copy the tree from the mounted Guix /efi.img into it.
The new filesystem should have between 200 KiB and 1.4 MiB.
(The Guix image of 1.4 MiB still has 90 % of its capacity free.)

Then put the new filesystem into /dev/sdc2 and see what happens.

-

If this does not help, then copy again the Debian efi.img into partition 2,
mount it, and replace the file bootx64.efi by the one of the mounted
Guix efi.img.

-

Have a nice day :)

Thomas

Re: ISO installer image: GPT versus MBR partitions

[Thomas Schmitt]

Hi,

Florian Pelz wrote:
> I wonder, what kind of FAT is the EFI partition using?  Could it be
> the wrong kind of FAT?

I got a mail from a bystander, Ady Ady whom i know from SYSLINUX/ISOLINUX
mailing list. He proposes the experiment to exchange the whole EFI partition
of the Guix ISO by the one of Debian Live 9.

This will not be able to really boot Guix, of course. But if the Mac's
boot manager shows it and is willing to start the bootx64.efi program,
then the FAT filesystem's meta data become prime suspect.


The EFI partition of Debian Live 9 is smaller than the one of Guix 0.16.0.
So after these steps :

> I wrote guixsd-install-0.16.0.x86_64-linux.iso to my USB drive again.
> Boot gets stuck again.
>
> I did `sudo dd if=/dev/zero of=/dev/sdc2` to zero out the EFI
> partition.

mount the Debian Live 9 ISO (e.g. at /mnt/iso) and do

  dd if=/mnt/iso/boot/grub/efi.img of=/dev/sdc2


Have a nice day :)

Thomas

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

This is interesting.  I presume if you add modprobe.blacklist=radeon
to the kernel commandline, your system is degraded, e.g. the
resolution is lower?  The installer probably would have a lower
resolution, too, when booting it with modprobe.blacklist=radeon?  Or
maybe the radeon kernel module is not used at all?

Are you using current linux-libre or are you using an old kernel?

On Sat, Apr 20, 2019 at 12:16:43PM +0200, Pierre Neidhardt wrote:
> Maybe Florian's issue is with an older card that does not support
> "ati" or "amdgpu".
> 

lspci reports my card as Radeon R7 240/340.  According to Wikipedia
this GPU was released in 2013.  Xorg attempted to load the radeon
driver and not amdgpu.

Regards,
Florian

Re: ISO installer image: GPT versus MBR partitions

[pelzflorian (Florian Pelz)]

I wrote guixsd-install-0.16.0.x86_64-linux.iso to my USB drive and
mounted it.  I am trying to make the boot not get stuck.

I replaced efi/boot/bootx64.efi by Debian’s bootx64.efi.  Still stuck.

I deleted efi/boot/bootx64.efi.  Still stuck.

I changed the EFI partition’s GPT type code with gdisk from EF00 to
0700.  Still stuck.

I deleted the EFI partition.  Now I can boot (but not from the USB
drive, of course).

I wrote guixsd-install-0.16.0.x86_64-linux.iso to my USB drive again.
Boot gets stuck again.

I did `sudo dd if=/dev/zero of=/dev/sdc2` to zero out the EFI
partition.  Now I can boot again (not from the Guix USB drive, of
course).

I wonder, what kind of FAT is the EFI partition using?  Could it be
the wrong kind of FAT?

Regards,
Florian

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Sat, Apr 20, 2019 at 11:47:56AM +0200, Ludovic Courtès wrote:
> So basically GNU/Linux distros in general fail to work on machines with
> these GPUs?
> 

The radeon driver requires nonfree firmware.  This is the core issue
which is not going to get fixed anytime soon.  There appear to be
partial fixes for some cards, for example I see mailing list threads
like https://www.fsfla.org/pipermail/linux-libre/2015-July/003080.html

Xorg on fbdev fails on Guix but works on other distros with 800×600
resolution at 75 Hz for my AMD GPU.

Regards,
Florian

Re: KMScon vs. AMD Radeon

[Ludovic Courtès]

Hi,

"pelzflorian (Florian Pelz)"  skribis:

> On Fri, Apr 19, 2019 at 05:17:31PM +0200, Ludovic Courtès wrote:
>> OK, so that’s suboptimal, but do you still consider it usable
>> nonetheless?
>> 
>
> Yes, the installer is usable.  Its just when using Manual partitioning
> that the message
>
> You can change a disk's partition table by \
> selecting it and pressing ENTER. You can also edit a partition by selecting 
> it \
> and pressing ENTER, or remove it by pressing DELETE. To create a new \
> partition, select a free space area and press ENTER.
>
>
> is clipped to
>
> ENTER. You can also edit a partition by selecting it \
> and pressing ENTER, or remove it by pressing DELETE. To create a new \
> partition, select a free space area and press ENTER.
>
> It is not very important.

OK, so I’ll push the “modprobe.blacklist=radeon” trick.

> The important remaining issue is that Xorg does not start on this
> computer.  Neither the radeon nor fbdev and not even vesa works, for
> whatever reason.  fbdev apparently is not supported.  VESA might be a
> fixable bug (it displays “(EE) VESA(0): Cannot read int vect” like
> ).
> On other AMD GPUs the results may be more successful.  I have not
> tried other free distributions on this PC yet.

So basically GNU/Linux distros in general fail to work on machines with
these GPUs?

> I believe issues with (some?) AMD GPUs should be mentioned in the
> manual.  Also, on the downloads page perhaps it should be mentioned
> that there may be issues with some hardware, referring users to the
> Hardware Considerations in the Guix manual.

We could do that, but these kind of kernel-side issues tend to appear
and vanish quickly, no?  But I don’t know much about these AMD GPU
issues, so I’m happy to do what people consider appropriate.

Thanks,
Ludo’.

Re: KMScon vs. AMD Radeon

[pelzflorian (Florian Pelz)]

On Fri, Apr 19, 2019 at 07:11:17PM +0200, pelzflorian (Florian Pelz) wrote:
> The important remaining issue is that Xorg does not start on this
> computer.  Neither the radeon nor fbdev and not even vesa works, for
> whatever reason.  fbdev apparently is not supported.  VESA might be a
> fixable bug (it displays “(EE) VESA(0): Cannot read int vect” like
> ).
> On other AMD GPUs the results may be more successful.  I have not
> tried other free distributions on this PC yet.
> 

fbdev works for Xorg on the AMD GPU on Trisquel and Debian with
800x600 resolution at 75 Hz refresh rate.  It displays: “(==) Depth 24
pixmap format is 32 bpp”.

Perhaps the Guix config for fbdev is wrong.  I do not find a fbdev
configuration in xorg.conf.d, but I find none on Debian either.  This
is strange.

Regards,
Florian