Chris Marusich <[email protected]> writes: > Hi Divan! > > Thank you for taking the time to write to us about the problem. These > kinds of but reports are very helpful!
Your welcome. Thanks for the great reply. > On Tue, Apr 17, 2018, 06:43 Divan Santana <[email protected]> wrote: > >> OK, I think this is a bug. > > > It could be. Please report it to [email protected]. If you have an > operating system configuration file that reproduces the problem > consistently, please share it in your report. In particular, if you can > reproduce the problem using "guix system vm", it will make things much > easier for us to debug. The manual describes how to use that command: > > https://www.gnu.org/software/guix/manual/html_node/Invoking-guix-system.html I need to spend time on this and try reproduce it and report it properly. For the moment I've worked around it. > > The way I worked around it was to: > > >> 1) remount /gnu/store rw >> >> 2) >> >> cd >> >> /gnu/store/n9ym4yl7s55pm57rnc5whjlzjgvxas32-linux-libre-4.16.2/lib/modules/4.16.2-gnu/kernel/drivers/usb/storage/ >> cp usb_storage.ko usb-storage.ko >> > > That's good to know, but you should not modify files in the store or mount > it rw. Absolutely. I just did it to try test the theory. I've undone the hack and will see if things break later. But this is a test system. > It can lead to unpredictable behavior because doing so may violate > certain invariants. When hacking around on a throw-away system to > investigate an issue like this, don't this might be useful, but on systems > you care about, essentially the only way you should interact with the store > is via the public Guix scheme APIs and the Guix command line tools, since > they will ensure that the store's invariants are never violated. > Again, thank you for the report! I hope everything is smooth sailing from > this point on. Thanks again. Doubt it will be smooth sailing lol. But I'm learning and guix is awesome and hope to continue learning and cotribute more in time. -- Divan
