bug#55907: VFIO kernel module fails to capture PCI device
Hello all,
I am trying to capture my graphics card at initrd, using vfio, to later pass it
through to a virtual machine. Judging by dmesg, the VFIO module does load
early, however, the card is not captured at that point and the amdgpu driver is
later loaded instead.
This is what I have in my `operating-system` config:
> (kernel-arguments '("iommu=pt" "vfio-pci.ids=1002:73bf"))
> (initrd-modules (cons* "vfio_pci" "vfio" "vfio_iommu_type1" "vfio_virqfd"
> %base-initrd-modules))
There are two video cards in the system, both AMD, but different models. The
video card of interest is in a separate IOMMU group and the : combination is correct for my machine.
Best I can tell, vfio-pci.ids argument is not propagated to the module by
initramfs. See the following:
Searching online I came up against a GitHub issue for a different initramfs
generator that exhibited the same symptoms: VFIO module was loaded, kernel
arguments were correct, yet the card was not captured by the vfio driver. The
maintainer there did a great job tracking down and fixing the issue and came up
with this insight
https://github.com/anatol/booster/issues/20#issuecomment-808956316
> After reading kmod code I found that kernel does not use cmdline params for
> loadable modules. It was surprising for me. Instead it is expected that
> userspace handles cmdline parsing and provides required module params
> explicitly.
Another way to attach the correct driver to the gpu is to run a script at
initrd, which I don't know how to accomplish with Guix. This approach has the
advantage of working with two identical video cards (or disks, etc) See
https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF#Using_identical_guest_and_host_GPUs
I tried following the kernel docs to rebind a different driver after boot, but
I believe this doesn't work for video cards, and hasn't worked for me.
Any help is greatly appreciated!
Links:
Kernel docs for vfio
https://www.kernel.org/doc/html/latest/driver-api/vfio.html
Arch guide for GPU passthrough
https://wiki.archlinux.org/title/PCI_passthrough_via_OVMF
Thank you!
-Nick
bug#52807: Guix home executables are not executable
I'd like to use `guix home` to symlink an executable into my home directory.
Following simple configuration stored at `~/.dotfiles/home-configuration.scm`
> (use-modules
> (gnu home)
> (gnu packages)
> (gnu home services)
> (gnu services)
> (guix gexp)
> (gnu home services shells))
>
> (home-environment
> (services
> (list (service
> home-bash-service-type
> (home-bash-configuration
> (guix-defaults? #t)))
> (simple-service 'my-files
> home-files-service-type
> `(("run" ,(local-file "run")))
`~/.dotfiles/run` is an executable file, after home reconfigure a `~/.run`
symlink is created, however the file it is pointing to does _not_ have the
execute bit set.
As a result, when I try to execute `~/.run` file I get a "Permission denied"
error.
Thank you,
-Nick
bug#52808: Guix home should not assume that all targets are dot files
The following configuration results in a `~/.run` symlink being created. My
expectation is that a `~/run` symlink is created instead. (ie. not a dotfile)
> (home-environment
> (services
> (list (service
> home-bash-service-type
> (home-bash-configuration
> (guix-defaults? #t)))
> (simple-service 'my-files
> home-files-service-type
> `(("run" ,(local-file "run")))
This applies to all other targets. My expectation is that the configuration
should expect the exact target and not make an assumption that all targets are
hidden files, since that allows for more utility:
> (home-environment
> (services
> (list (service
> home-bash-service-type
> (home-bash-configuration
> (guix-defaults? #t)))
> (simple-service 'config-files
> home-files-service-type
> `(("run" ,(local-file "run"))
> ("README.txt" ,(local-file "README.txt"))
> (".config/guix/channels.scm" ,(local-file "config/guix
> (".emacs.d/init.el" ,(local-file "emacs.d/init.el"))
> (".vimrc" ,(local-file "vimrc"))
> (".gitconfig" ,(local-file "gitconfig")))
Thank you,
-Nick
bug#52807: Guix home executables are not executable
Indeed I missed this in the manual. Thank you!
I was trying to figure out how to close this... no luck.
-Nick
On Sun, Dec 26, 2021, at 4:44 PM, Aleksandr Vityazev wrote:
> Hi,
>
> On 2021-12-26, 12:03 -0500, "Nick Zalutskiy" wrote:
>
>> I'd like to use `guix home` to symlink an executable into my home
>> directory.
>>
>> Following simple configuration stored at
>> `~/.dotfiles/home-configuration.scm`
>>
>> (use-modules
>>(gnu home)
>>(gnu packages)
>>(gnu home services)
>>(gnu services)
>>(guix gexp)
>>(gnu home services shells))
>>
>> (home-environment
>>(services
>> (list (service
>> home-bash-service-type
>> (home-bash-configuration
>>(guix-defaults? #t)))
>>(simple-service 'my-files
>>home-files-service-type
>>`(("run" ,(local-file "run")))
>>
>> `~/.dotfiles/run` is an executable file, after home reconfigure a
>> `~/.run` symlink is created,
>> however the file it is pointing to does _not_ have the execute bit set.
>>
>> As a result, when I try to execute `~/.run` file I get a "Permission
>> denied" error.
>>
>> Thank you,
>>
>> -Nick
>>
> In the Guix manual you can find the following information about
> local-file:
>
> --8<---cut here---start->8---
> -- Scheme Procedure: local-file FILE [NAME] [#:recursive? #f]
> [#:select? (const #t)]
>
> When RECURSIVE? is true, the contents of FILE are added
> recursively; if FILE designates a flat file and RECURSIVE? is true,
> its contents are added, and its permission bits are kept.
> --8<---cut here---end--->8---
>
> So you can just do this:
>
> #+begin_src scheme
> (simple-service 'my-files
> home-files-service-type
> `(("run" ,(local-file "run" #:recursive? #t
> #+end_src
>
> --
> Best regards,
> Aleksandr Vityazev
bug#52808: Guix home should not assume that all targets are dot files
Hi Andrew,
I have files that I consider my "home configuration" that do not go into
.config or any other dot dir. For example, I place an executable shell script
to automate some tasks in the home dir of every machine. The script is called
`run` all I want to do is place it as ~/run Placing this file in PATH is not
appropriate in my case.
The current design makes this impossible to achieve it seems. I just live with
`~/.run` now, but it is ergonomically cumbersome for reasons that are too
obscure to go into.
Why not, just as an example:
`("$XDG_CONFIG_DIR/guix/channels.scm" ,(local-file "./chans.scm"))`
Which is explicit and sets the right expectation without any other context. The
implicit heuristics around how the input is interpreted are an unfortunate
design decision in my opinion, they make a simple tool more difficult to use.
Having said all that, the documentation helps a lot. Thank you for the patch!
Best,
-Nick
On Fri, Jan 28, 2022, at 5:51 AM, Andrew Tropin wrote:
> On 2021-12-26 12:17, Nick Zalutskiy wrote:
>
>> The following configuration results in a `~/.run` symlink being
>> created. My expectation is that a `~/run` symlink is created
>> instead. (ie. not a dotfile)
>
> Some how I missed it and not documented home-files-service-type in the
> manual, I'll add it soon. Thank you for mentioning it. It should break
> this expectation :)
>
>>> (home-environment
>>> (services
>>> (list (service
>>> home-bash-service-type
>>> (home-bash-configuration
>>> (guix-defaults? #t)))
>>> (simple-service 'my-files
>>> home-files-service-type
>>> `(("run" ,(local-file "run")))
>>
>> This applies to all other targets. My expectation is that the
>> configuration should expect the exact target and not make an
>> assumption that all targets are hidden files, since that allows for
>> more utility:
>>
>>> (home-environment
>>> (services
>>> (list (service
>>> home-bash-service-type
>>> (home-bash-configuration
>>> (guix-defaults? #t)))
>>> (simple-service 'config-files
>>> home-files-service-type
>>> `(("run" ,(local-file "run"))
>>> ("README.txt" ,(local-file "README.txt"))
>>> (".config/guix/channels.scm" ,(local-file "config/guix
>>> (".emacs.d/init.el" ,(local-file "emacs.d/init.el"))
>>> (".vimrc" ,(local-file "vimrc"))
>>> (".gitconfig" ,(local-file "gitconfig")))
>>
>> Thank you,
>>
>> -Nick
>
> It's intentional and is a part of a design decision:
>
> For example for ("config/guix/channels.scm" ,(local-file "./chans.scm"))
> chans.scm goes not to ~/.config/guix/channels.scm, but to
> $XDG_CONFIG_DIR/guix/channels.scm, which can be a different location
> from ~/.config, absent dot should partially break this expectation.
>
> It's a bad practice to use something without "config/..." prefix and
> generally it should be avoided, it still possible to use something
> different in rare use-cases, for example for zsh: ("zshenv"
> ,zshenv-file-like-here), because it's hard to implement the lookup for
> initial configuration file other way for shells.
>
> You can elaborate more on what you try to achieve and I can try to give
> you a recommendation how to implement it.
>
> --
> Best regards,
> Andrew Tropin
>
> Attachments:
> * signature.asc
bug#64659: bug in guix-compute-derivation
I've been facing the same issue, not a fresh install in my case. I'm not sure what the problem is, but forcing `bordeaux.guix.gnu.org as the substitute server to use got me past the issue.` `> guix pull --substitute-url="https://bordeaux.guix.gnu.org"` `This link was also helpful and mentions the same error with same backtrace: `https://simon.tournier.info/posts/2023-06-23-hackathon-repro.html `Best,` -Nick
