<lfam>efraim: Does the new busybox pass the 'du-l-works' test for you? It fails on my Debian machine <lfam>Interesting! I tried the update about a week ago but hadn't gotten around to investigating the failure <lfam>I'm using Linux 4.8.15 on ext4 <efraim>i just built it again with no problems <lfam>Okay, hopefully Hydra has luck :) <Acou_Bass>soo has anyone used guixSD 0.12.0 with an encrypted root? i just updated my (existing) guixSD install with crypted root and ive still got to manually do the grub stuff :( <davexunit>taylan: guile-json needs to be built with guile 2.2 as well <red__>FYI - the instructions for building guix in a VM using qemu specify a 5G drive <red__>guix system init failed with that amount of space <Pastaf>Being terse for various reasons. EFI fails to find internal HDD, no further message. Formatted GPT. Partition one ESP. Partition two encrypted LVM. GuixSD install onto partition two appears to work except bootloader. I have made many attempts to manually install grub using the grub-efi package with target x86_64-efi, setting --efi-directory(?) and --boot-directory to /esp where I mounted partition one. I <Pastaf>don't think it is an EFI error because worked with debian before just fine, and I'm pretty sure it was using EFI. I'll attempt to get more information, but the installee is distant from this terminal, and is on boot screen, not install stick screen, so I'm working from limited memory and forgot much since this is attempt three to write. I will search for more information and keep checking here. <Pastaf>If I should try another channel, feel free to redirect me. <Pastaf>Well, now I've done it again but with BIOS instead of EFI, normal install worked, including grub, I know everything is marked correctly, etc, and it's not working anyway. To be honest, I've been at this for two days, and this is my fifth time trying to install GuixSD, attempted on three machines, and I've failed each time. Honestly, I'm just going to give up on GuixSD until there's a real installer, and just <Pastaf>do debian (main only, of course). Sorry to bother. <Pastaf>(I say that, of course, but I know I'll try again within six months. Oh well.) ***jje is now known as Guest75939
<Akko_Teru>#dragora, sans systemd, uses store concept and graft. Dragora is a GNU/Linux distro based on concepts of simplicity. <buenouanq>but can it see why kids love the taste of cinnamon toast crunch? <rekado>red__: I recommend doing the init with a minimal configuration. Once initialised it’s easy and safe to reconfigure with a different configuration. <ng0>better than securedrop (almost no system iirc) and almost similar to GNU Health (bash magix) ***jje is now known as Guest7667
<kqb>hi, trying to install on a qubes hvm. (1) booting USB installer works (2) ip link set eth0 up works (3) ip address add (...) dev eth0 works (4) ip route add default dev eth0 fails <kqb>what is a good way to track down the cause of the resulting Network unreachable error? <kqb3>somehow losing connection <jmd>kqb3: Your network doesn't offer dhcp ? <kqb3>the qubes people say in their doc, <kqb3>that their dhcp may need a specific client (they only have layer 3) <kqb3>they currently assign IP adresses statically <jmd>Anyway, "eth0" sounds like a wierd name. What version are you installing? <kqb3>they try and set eth0 from outside the VM. The VMs with wifi call the wifi adaptor wlps0 (or whatever the current standard is) <kqb3>version 11.0 or so. 2 days after getting the USB stick to work with Xen, guiz reeleased <jmd>Anyway, to track down network issues, ping and traceroute will come in usefull. <kqb3>I started googling for "linux network unreachable" and more spexific queries (like replacing linux with guix) <kqb3>I first want to find error messages which only depends on the guix version if they changed the logging code <kqb3>ping (and ip route) fail with network unreachable. dmesg sys network stack came up <jmd>what does "route -n" say? <jmd>and what does "ifconfig" say? <kqb>hi, connection should be a lot better now <kqb>ip addr show yields: lo (...) and eth0 (...) <kqb>ip route show yields nothing <kqb>let me rephrase my question: I want to know how I can debug a defunct network device in guix (so I can go the qubes guys and fix this) <kqb>defunct means the following: device can be assigned an IP4 and IP6 address. <kqb>and routing cannot be established (ping does not work either) ***kelsoo1 is now known as kelsoo
<jmd>kqb: You need to take a step back and get all the facts. <jmd>Is the network device active? <jmd>Does it have an IP address assigned? <kqb>ifconfig eth0 up changes the state from DOWN to UP and automatically assigns an IP6 address <jmd>Is the routing table correctly set up? <kqb>the routing table is empty <jmd>well that is the one problem. <jmd>But before we go there, ... <jmd>try pinging the first connected machine with ping -r <kqb>"ip route add default dev eth0" should add the default route. <kqb>but it creates the error: "Network unreachable". <jmd>kqb: You need to be wary of random blogs on the net. <kqb>ping: sending packet: Network is unreachable <jmd>You used 'ping -r <address-of-host>' <kqb>the article seemed plausible and the commands I looked at, fit the manual and withstood simple tests on debian 8. <cast>pastebinning `ip a` would be enlightening <jmd>kqb: So what happens if you type "ping -r 10.137.2.50" ? <kqb>... 56 data bytes \\n # and just waits <cast>bit peculiar that lo is down <kqb>ifconfig lo up && ip a # yields (...) state UNKNOWN <kqb>ping -r (...) now works <jmd>kqb: Try "ip link set lo up" <jmd>kqb: Ok. Now ping the host to which you are directly connected. <kqb>ping: sending packet: Network is unreachable <jmd>So either the ip address you gave is wrong, or that host's network is broken. <kqb>My guess is the network is broken. But I overlooked that lo is down. <kqb> It seems like the problem is not with guix but with qubes. <kqb> Now I feel like I did enough to go to the qubes mailing list. <kqb> Thanks for everyones help :) <jmd>We wish you a merry Guixmas! ***red__ is now known as __red__
<__red__>Well, I got guix for Christmas and so far I'm 1/2 part confused, 1 part inspired and 3 parts happy. <__red__>(installed it at a few minutes past midnight on xmas day) ;-) <__red__>now trying to work out if there's a way to get guix running in a cloud service provider so I can test and compare against my production NixOS hosts... ***Guest7667 is now known as jje
<Acou_Bass>__red__: i love nixos, will take a lot for me to stitch from it to guix on all my machines but guix is awesome :D ***jje is now known as Guest83618
***jje_ is now known as jje
<marusich>I'm trying to transfer files from my GuixSD computer to an Android device using MTP. I've tried installing gmtp, and running that as root, but it doesn't seem to be working. Am I missing something? <rekado>marusich: gmtp is *very* slow to connect (on the order of several minutes), but it does work for me. <marusich>Hmmm. That's one thing I was a little confused about. <marusich>I don't know much about MTP; I'm not even sure if it exposes a device in /dev/ as is the case for most USB storage devices... <rekado>it’s on another laptop, let me check. <rekado>I have a udev rule for a different reason <rekado>it changes ownership of all USB device nodes to the “usb” group <marusich>Hm. Do you know if libmtp uses device files? <marusich>I didn't see a device file show up when I plugged my phone into my computer, so I'm not sure. <rekado>SUBSYSTEM=="usb", GROUP="usb", OPTIONS+="last_rule" <rekado>the user is added to the usb group (probably not a good idea in general) <marusich>Ah, sweet, after a few mins, gmtp is working. <rekado>(I have that rule for KVM USB device forwarding) <marusich>I do need to run it as root, though; I wish I knew what the right solution to give it permission would be... <rekado>I do not run it as root and all I do is change usb device node ownership <rekado>you could try this without a udev rule first <rekado>plugging in the device, chown’ing the usb dev nodes, and then running gmtp as a user. <rekado>nautilus should support mtp as well, but for some reason it doesn’t show mtp devices when they are attached. <marusich>Is there a trick to get it working with gvfs? <rekado>even when gvfs is installed in the system profile <marusich>Yeah I noticed that even when I installed gvfs it didn't seem to respond <marusich>I guess maybe there's some glue we're missing to make it use libmtp or something? <rekado>(that’s what’s needed to detect and automount regular USB devices) <marusich>gmtp worked when i ran it as root - it just took a few minutes to function. <marusich>rekado, where are the udev rules used by the current system stored? and how would I modify them? <marusich>Looks like maybe I should modify the udev-service to pass in packages whose rules I want to use...does that sound right? <ng0>I've contacted the GNU Health maintainer this morning and announced that I'll slowly work on improving their build system. Very slowly, as it's not a priority task for me :) <jmd>I always get confused between GNU Health and GNU Med. <taylan>it looks like GNUmed is EMR only whereas GNU Health is a lot more... <marusich>rekado, I think I figured out the mtp stuff for gvfs. Simple solution... libmtp comes with a config flag to set the group of the device via udev rules. <marusich>I set it to "audio" and things Just Worked. <marusich>Not sure if that's the right group long-term, but I think I'll submit a patch. <marusich>I also had to modify the udev service to use the udev rules from libmtp <marusich>Is there any way to say "when I install a package (such as libmtp), please also make sure to add its udev rules to the rules used by the eudev service"? I modified the service in my config.scm file, but it would be a bummer if anyone who wants to transfer files to/from their mtp-compatible device needed to remember to do that...