From somenxavier at posteo.net Wed Apr 3 18:01:28 2019 From: somenxavier at posteo.net (Xavier) Date: Wed, 03 Apr 2019 18:01:28 +0000 Subject: [Assist] =?utf-8?q?Migration_from_Parabola_with_OpenRC=3A_proble?= =?utf-8?q?ms_=09detecting_ethernet?= Message-ID: <416bc67d6cc8c2990af9d97f94de7a8b@posteo.net> Sorry for the delay but I confirm that liveCD v0.2.8 detects my network interface (ifconfig shows interface) and automatically assign a IP with dhcpd. In my computer I cannot see any device apart of `lo`. So, how can I triage this situation? How can I achive that my computer get IP via DHCP? Thanks in advance, Message: 2 Date: Tue, 5 Mar 2019 21:54:59 -0500 From: Luke To: assist at lists.hyperbola.info Subject: Re: [Assist] Migration from Parabola with OpenRC: problems detecting ethernet Message-ID: <298824c0-dca5-3730-42b0-464c97607e1f at hyperbola.info> Content-Type: text/plain; charset="utf-8" Hello Xavier, Can you confirm if the LiveCD is able to detect your ethernet (_ifconfig_ and/or _ip addr_ while connected to the network)? From there we can determine the name of the interface and if it is a kernel issue or not. Thanks! On 03/05/2019 11:35 AM, Xavier wrote: Hi, Previously, I run Parabola GNU/Linux with OpenRC and I migrated to Hyperbola [1]. After migration, system does not detect my ethernet. I have just lo interface. I installed Parabola Linux PAE [2] to discard kernel issues, but booting with this kernel does not solve the problem. dmesg | grep eth0 gives me nothing in both kernels (Hyperbola Linux-LIbre-LTS and Parabola-Linux-PAE). How can I do to detect the problem and use eth0? Thanks in advance, Xavier [1] https://lists.hyperbola.info/pipermail/assist/2019-January/000013.html [2] https://www.parabola.nu/packages/libre/i686/linux-libre-pae/ _______________________________________________ Assist mailing list Assist at lists.hyperbola.info https://lists.hyperbola.info/mailman/listinfo/assist -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 228 bytes Desc: OpenPGP digital signature URL: ------------------------------ Subject: Digest Footer _______________________________________________ Assist mailing list Assist at lists.hyperbola.info https://lists.hyperbola.info/mailman/listinfo/assist ------------------------------ End of Assist Digest, Vol 8, Issue 1 ************************************ From bill-auger at peers.community Wed Apr 3 18:47:34 2019 From: bill-auger at peers.community (bill-auger) Date: Wed, 3 Apr 2019 14:47:34 -0400 Subject: [Assist] Migration from Parabola with OpenRC: problems detecting ethernet In-Reply-To: <416bc67d6cc8c2990af9d97f94de7a8b@posteo.net> References: <416bc67d6cc8c2990af9d97f94de7a8b@posteo.net> Message-ID: <20190403144734.3287c142@parabola> Xavier - you CC'd this to assist at lists.parabola.nu presumably you intended it for assist at lists.hyperbola.info but, sorry to see you go, old friend :( may the green pastures of hyperbola treat you well From edgar at openmail.cc Sun Apr 14 01:43:40 2019 From: edgar at openmail.cc (edgar at openmail.cc) Date: Sun, 14 Apr 2019 01:43:40 +0000 Subject: [Assist] HDMI: AMD Ryzen 5 2500U Radeon Vega Mobile Gfx Message-ID: <7b39e2d7ac4d8696c5c78d13dc7c740d@openmail.cc> Can someone confirm or rebuke that there are no (free) drivers for my HDMI: AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx (that I cannot use my HDMI) with linux-libre. Thanks! From GNUtoo at cyberdimension.org Sun Apr 14 13:15:11 2019 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Sun, 14 Apr 2019 15:15:11 +0200 Subject: [Assist] HDMI: AMD Ryzen 5 2500U Radeon Vega Mobile Gfx In-Reply-To: <7b39e2d7ac4d8696c5c78d13dc7c740d@openmail.cc> References: <7b39e2d7ac4d8696c5c78d13dc7c740d@openmail.cc> Message-ID: <20190414150423.26789006@primarylaptop> On Sun, 14 Apr 2019 01:43:40 +0000 edgar at openmail.cc wrote: > Can someone confirm or rebuke that there are no (free) drivers for my > HDMI: AMD Ryzen 5 2500U with Radeon Vega Mobile Gfx (that I cannot > use my HDMI) with linux-libre. As the upstream Linux driver refuses to load when the nonfree firmware is not used, linux-libre's deblob script patches the radeon driver to still be able to use it. While 3D acceleration still doesn't work, it still brings many benefits over fallbacks like VESA, such as being able to use the HDMI connector, having multi display support, being faster, handling native resolutions, etc. Here's an example of how the patching is done in deblob-5.0 for the r600 class of ATI/AMD GPUs: > clean_sed ' > /r = r600_init_microcode(rdev);/,/}/ s,return r;,/*(DEBLOBBED)*/, > ' drivers/gpu/drm/radeon/r600.c 'enable blobless activation' I don't remember the exact details, but the code above makes sure that the driver doesn't return an error code when the firmware (which is called microcode here) cannot be loaded. When I worked on it, linux-libre maintainers required me to have the change tested on real hardware before enabling it for a given GPU family or file (like r600, evergreen, rv770, etc). So it's probably a matter of: - Finding the GPU class you have and understand which file to patch. - Downloading linux-libre scripts, which are also available in git[1] - Patching them and testing the change - Sending the patch to the linux-libre mailing list == Future directions == Years after working on this, only the following files are handled: - drivers/gpu/drm/radeon/r600.c - drivers/gpu/drm/radeon/evergreen.c - drivers/gpu/drm/radeon/rv770.c This means that the driver most probably don't load on newer GPU. It would be very useful to work toward enabling newer GPUs to work. - One way of doing that would be make it trivial for any user with very basic command line knowledge to test the change, assuming we are able to publicize that work, and get people with such GPU to run the test. If this works the benefit is that the driver would at least be tested on one GPU, making sure that this GPU works with that change. It would then enable us to catch some cases (if there are any) where the GPU worked with the fallback drivers and stops working with the radeon driver (for instance it would give a black screen or something like that). - Another way would be to patch it for every radeon GPUs, without requiring tests on real hardware, assuming that we have a good enough confidence that: - The driver refuses to load because the firmware is not loaded. - The patch enables the driver to load. Here what would need to be publicized would be how to blacklist the radeon driver at boot, in the case something goes wrong and the user is left with a black screen during the boot of linux-libre. On Parabola adding "modprobe.blacklist=radeon" to the kernel command line does that at boot. This enables users to easily use the installation medias. This is probably specific to systemd, so it probably doesn't work if you use Parabola without systemd, or if you use GUIX, or Hyperbola, but it may work on Trisquel 8, and PureOS. Once the distribution is installed, users would also need to be able to do again the change in grub to boot and then, once booted to edit /etc/default/grub to add the change permanently. It could also be automatized in some boot script, but that would require more thinking/work. References: ----------- [1]https://jxself.org/git/linux-libre.git Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From edgar at openmail.cc Mon Apr 15 04:41:55 2019 From: edgar at openmail.cc (edgar at openmail.cc) Date: Mon, 15 Apr 2019 04:41:55 +0000 Subject: [Assist] HDMI: AMD Ryzen 5 2500U Radeon Vega Mobile Gfx In-Reply-To: <20190414150423.26789006@primarylaptop> References: <7b39e2d7ac4d8696c5c78d13dc7c740d@openmail.cc> <20190414150423.26789006@primarylaptop> Message-ID: I am trying to understand what is important here (as compared to informative). > As the upstream Linux driver refuses to load when the nonfree firmware > is not used, linux-libre's deblob script patches the radeon driver to > still be able to use it. I gather that this is informative. It tells me that I am actually using the radeon drivers, right? > > While 3D acceleration still doesn't work, it still brings many > benefits over fallbacks like VESA, such as being able to use the HDMI > connector, having multi display support, being faster, handling native > resolutions, etc. I consider this important. My HDMI connector does not send a signal. Is there a way to test if the HDMI port is active? My tests have been trying to boot with an HDMI cable which is connected from the computer to screens and flat TV (none of which detect any signal). xrandr does not show anything either, even if I boot with the device connected to that port. > Here's an example of how the patching is done in deblob-5.0 for the > r600 > class of ATI/AMD GPUs: >> clean_sed ' >> /r = r600_init_microcode(rdev);/,/}/ s,return r;,/*(DEBLOBBED)*/, >> ' drivers/gpu/drm/radeon/r600.c 'enable blobless activation' > > I don't remember the exact details, but the code above makes sure that > the driver doesn't return an error code when the firmware (which is > called microcode here) cannot be loaded. This also seems informative, but I would not know how to use it right now. Yes, I have seen some messages related to deblobbing in my logs. That made me think that the kernel does not work with my HDMI. > > When I worked on it, linux-libre maintainers required me to have > the change tested on real hardware before enabling it for a given GPU > family or file (like r600, evergreen, rv770, etc). That's why I respect developers and appreciate the efforts of having free software :) . Thanks! > > So it's probably a matter of: > - Finding the GPU class you have and understand which file to patch. > - Downloading linux-libre scripts, which are also available in git[1] > - Patching them and testing the change > - Sending the patch to the linux-libre mailing list Are you suggesting that I do this? (it may be dumb, but it's an actual question). > > == Future directions == ---8<--- Snip > - The patch enables the driver to load. All of this looks like a message to someone else or general information that may be useful at some point. Is it meant for me? > > Here what would need to be publicized would be how to blacklist the > radeon driver at boot, in the case something goes wrong and the user > is left with a black screen during the boot of linux-libre. > > On Parabola adding "modprobe.blacklist=radeon" to the kernel command > line does that at boot. This enables users to easily use the > installation medias. > > This is probably specific to systemd, so it probably doesn't work if > you use Parabola without systemd, or if you use GUIX, or Hyperbola, > but it may work on Trisquel 8, and PureOS. I run OpenRC with Parabola. I think that the HDMI hasn't worked with Trisquel in the past (I did not try modprobe.blacklist=radeon). Is there anything that I need to install in Parabola, Trisquel or PureOS to test? Again, how do I test if the HDMI port is active? > > Once the distribution is installed, users would also need to be able > to do again the change in grub to boot and then, once booted to > edit /etc/default/grub to add the change permanently. > > It could also be automatized in some boot script, but that would > require more thinking/work. I agree, and it seems that you are suggesting that I do this when I test. I would repeat my question. How do I test the HDMI output from my computer? Thank you for your explanation. From GNUtoo at cyberdimension.org Mon Apr 15 14:52:02 2019 From: GNUtoo at cyberdimension.org (Denis 'GNUtoo' Carikli) Date: Mon, 15 Apr 2019 16:52:02 +0200 Subject: [Assist] HDMI: AMD Ryzen 5 2500U Radeon Vega Mobile Gfx In-Reply-To: References: <7b39e2d7ac4d8696c5c78d13dc7c740d@openmail.cc> <20190414150423.26789006@primarylaptop> Message-ID: <20190415165202.56c423f8@primarylaptop> On Mon, 15 Apr 2019 04:41:55 +0000 edgar at openmail.cc wrote: > > As the upstream Linux driver refuses to load when the nonfree > > firmware is not used, linux-libre's deblob script patches the > > radeon driver to still be able to use it. It's informative. It tells you that the upstream driver don't work at all with the nonfree firmware. Linux-libre has to patch it to make it work with the limitations mentioned below, but it only does that for some GPUs. It's most probably not patched for one you are using, as the symptoms are similar than the ones you have in that case. This is also why my previous mail has a lot of background. This was done in the hope that it would help you or any other person reading this, to fix the problem. > I gather that this is informative. It tells me that I am actually > using the radeon drivers, right? You are most probably not using the radeon driver. The fact that the radeon module is loaded doesn't mean that the driver is used. A quick way to verify that is to run the 'dmesg | grep radeon' command and check if you have something like that appearing: > radeon: probe of 0000:00:01.0 failed with error -22 This is an error that appears when the driver refuses to work because the firmware was not loaded. It could also do this error for other reasons as well. > > Here's an example of how the patching is done in deblob-5.0 for the > > r600 > > class of ATI/AMD GPUs: > >> clean_sed ' > >> /r = r600_init_microcode(rdev);/,/}/ s,return r;,/*(DEBLOBBED)*/, > >> ' drivers/gpu/drm/radeon/r600.c 'enable blobless activation' > > > > I don't remember the exact details, but the code above makes sure > > that the driver doesn't return an error code when the firmware > > (which is called microcode here) cannot be loaded. This explains how to fix the problem. It's an example on how linux-libre makes the radeon driver work for the r600 GPU family. > > So it's probably a matter of: > > - Finding the GPU class you have and understand which file to patch. > > - Downloading linux-libre scripts, which are also available in > > git[1] > > - Patching them and testing the change > > - Sending the patch to the linux-libre mailing list > > Are you suggesting that I do this? (it may be dumb, but it's an > actual question). Yes, someone needs to do that for fixing the issue for your GPU and by extension all the other GPUs in the same family. > > == Future directions == > ---8<--- Snip > > - The patch enables the driver to load. > > All of this looks like a message to someone else or general > information that may be useful at some point. Is it meant for me? It's some thoughts on how to fix it for all radeon GPUs that are more recent than the one I added support for, and it's meant for anybody that is potentially involved in linux-libre. The issue is that: - I don't have all radeon GPUs, so I cannot add support for the hardware that I don't have. - I also have limited time. - Having the driver not work can be really problematic: it makes many computers potentially unusable[1] with the distributions that respects the free software distribution guidelines (FSDG), and people are probably not able to get new computers that often. - So far nobody added support for more GPUs. Because of that most radeon GPU still don't work with linux-libre. References: ----------- [1]Some of the limitations of the VESA or GOP(same thing than VESA but for UEFI) drivers can be really problematic. For instance if you have a netbook that has a 1024x600 native resolution, you could end up only having 800x600 with VESA, which as of today, probably still makes many websites unusable. Denis. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From edgar at openmail.cc Sun Apr 21 17:08:28 2019 From: edgar at openmail.cc (edgar at openmail.cc) Date: Sun, 21 Apr 2019 17:08:28 +0000 Subject: [Assist] setting up dictd for localhost Message-ID: Hello, I have noticed that dictd only works when I connect to the Internet. I am running openrc. When I type $ dict -d gcide free with the network cable unplugged, I get Cannot connect to any servers (use -v to see why) using the -v string tells me $ dict -v -d gcide free Configuration file: server localhost server dict.org Cannot connect to any servers When I connect the network cable, I get a successful query If I run # dictd then, the query works without Internet connection. What am I missing? Thanks. From bill-auger at peers.community Sun Apr 21 19:13:11 2019 From: bill-auger at peers.community (bill-auger) Date: Sun, 21 Apr 2019 15:13:11 -0400 Subject: [Assist] setting up dictd for localhost In-Reply-To: References: Message-ID: <20190421151311.19e2b536@parabola> do you have polkit-elogind installed? From edgar at openmail.cc Fri Apr 26 17:45:34 2019 From: edgar at openmail.cc (edgar at openmail.cc) Date: Fri, 26 Apr 2019 17:45:34 +0000 Subject: [Assist] setting up dictd for localhost In-Reply-To: References: Message-ID: <6994f7ece71cecf96f6eb2fcda4232df@openmail.cc> On 2019-04-21 17:08, edgar at openmail.cc wrote: > Hello, > > I have noticed that dictd only works when I connect to the Internet. I > am running openrc. > > When I type > $ dict -d gcide free > with the network cable unplugged, I get > Cannot connect to any servers (use -v to see why) > using the -v string tells me > $ dict -v -d gcide free > Configuration file: > server localhost > server dict.org > Cannot connect to any servers > When I connect the network cable, I get a successful query > > If I run > # dictd > then, the query works without Internet connection. > What am I missing? Thanks. I am sorry for the noise, I just realised that the package that I have for dictd (dictd-openrc) comes from AUR, and that its files are in the wrong place.