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
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
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
> 0682f084
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
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
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
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.
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
>
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
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 m
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
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. l
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 b
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
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 no
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
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
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
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 bu
19 matches
Mail list logo
