Jump to content

stamasd

Members
  • Content Count

    39
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by stamasd

  1. Solved. It seems that there was something wrong with my Arduino board, as changing to a different one solved the problem.
  2. This question is not Funtoo-specific, except for the fact that I am working to get this project done on a Funtoo box. I have a headless box on which I installed Funtoo, which I plan on using as a home server. I don't want to have any monitor or keyboard attached to it, and yet I want it to display some status messages on a small attached display. For that I made a small gadget consisting of an Arduino Nano with a I2C OLED attached, which simply takes characters from the serial port and displays them onto the OLED. It shows up as /dev/ttyUSB0 and the serial port speed is 115200. It works as expected when I use a terminal emulator such as picocom to connect to it: picocom -b 115200 /dev/ttyUSB0 then it takes my keyboard input and displays it to the OLED. However I want to use it non-interactively, and have messages sent to the display from a script run periodically from a cron job. But attempting to do that from the CLI with either echo or printf fails: printf 1234 > /dev/ttyUSB0 or echo "1234" > /dev/ttyUSB0 Neither of the above displays anything on the OLED. There is no error message; the serial port has been set to the correct speed with stty -F /dev/ttyUSB0 115200 and checking with "stty -F /dev/ttyUSB0" shows that it's set to the correct speed. It's not a permission problem, my user has access to the port, and the same thing happens when I try the above as root. At this point I'm not exactly sure why this fails. (edit) FWIW it's not a function of the serial port speed. If I set the speed to 9600 both on the Arduino and in the terminal I get the exact same behavior: it works with picocom, but not with echo/printf.
  3. The needed libraries are installed by flatpak. I choose this method because it's easy, and it works. I'm lazy at baseline. 🙂 Forgot to say that you need to reboot after the last line so the kernel gets the appropriate parameter. After that Steam will work.
  4. You can run Steam using flatpak. Use the Gentoo flatpak overlay: https://github.com/fosero/flatpak-overlay (I use the local repository method, which I put it in /opt/flatpak), emerge flatpak, add the flathub repository: flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo then install Steam from flathub: flatpak install flathub com.valvesoftware.Steam Then as root issue: echo 'kernel.unprivileged_userns_clone=1' > /etc/sysctl.d/unprivileged_userns_clone.conf Works for me.
  5. @lazlo.vii Off-topic: how do you like the Odroid-XU4? I have a C2 but haven't really done much with it. It has a tendency to overheat even with the extra cooling I added to it.
  6. I have mixed feelings about this. On the one hand, patent trolls=bad. On the other hand, Gnome=systemd. I'll watch but I won't intervene.
  7. New hardware is not always better. I have a notebook from circa 2012 which has an amazing sound codec, on the level with the best sound cards that you can buy for desktops today. But it was probably too expensive and the brand decided to drop it and replace with a cheap run-of-the-mill codec in their next generation of notebooks. I keep that laptop around just because of the amazing sound it has. It's not a slouch either, quad-core Ivy Bridge, 16GB and a SSD make it fly even with today's software. The last time I was amazed by new hardware was a few years ago when I built my latest desktop: AMD Vishera FX-8370 8-core, 32GB, SSD, Radeon HD7970. A definite upgrade from my previous Sandy Bridge desktop. To this day I haven't felt the need to upgrade it, though I've been eyeing the new Ryzens. But I just can't justify it to myself.
  8. Hm. I had the same issue when installing flatpak using the Gentoo overlay (with local repo) and I solved it simply by creating a file /etc/portage/categories with the contents: acct-group acct-user It just worked, I could install flatpak without any issues as well as updating it normally.
  9. Yeah, was going to say I just found out there is an ebuild for fbreader; I couldn't check at the time of my original post because I was waiting for calibre to emerge (which failed BTW, I posted a bug report). Trying to install fbreader now. Thanks! (edit) fbreader installed correctly, seems to be the one I was looking for. Thank you again.
  10. One ongoing issue that I've been having is the availability of a good epub reader. I have thousands of ebooks in epub format (and a minority in other formats like mobi). Yes there is the excellent Calibre, but I have some issues with its integrated epub reader - it's not compatible with some of my ebooks, especially those purchased from Barnes&Noble. Specifically it doesn't interpret correctly page order and I get sudden page jumps, for instance from page 54 to 170 and them back to 112 etc. I have tried to edit the epub files themselves but I can't figure out what's wrong, and this is compounded by the fact that other epub readers don't exhibit this behavior and show pages in the correct order. I prefer a lightweight reader too; on Windows there is the excellent SumatraPDF, and on Android I use the Moon+ reader. Both work well and don't have the page order issue with my respective epub files. On Linux however, the top readers that I have seen recommended (apart from Calibre): FBReader and Cool Reader, only come as .deb packages. So, what do other Funtoo users have been using for reading ebooks (again, except for Calibre which has the above problem for me)?
  11. Yeah I've read about this a week or two ago. I feel very safe at /home, thankyouverymuch.
  12. Since 1.3 was released I've been using this Gentoo overlay (using the local repository method) to install flatpak and Steam in it: https://github.com/fosero/flatpak-overlay It works well even after upgrading to 1.4
  13. Made a HOWTO on the wiki. https://www.funtoo.org/32_bit_chroot_environment_for_Wine
  14. Running 32-bit Win apps requires 32-bit wine. The wine available in 1.4 is 64-bit and will not run 32-bit Win binaries. The following is a quick writeup on how I did it. There are other ways, possibly better, but this one is mine and I stand by it. 🙂 I opted to use a chrooted 32-bit environment in which I installed Gentoo and wine. I started by making a ~/gentoo folder and downloading a current 32-bit Gentoo stage3 in it: mkdir gentoo cd gentoo wget <stage3_URL> You need to be root for the following steps sudo su tar xpf <stage3> cp /etc/resolv.conf /home/<username>/gentoo/etc And then follow the installation steps in the Gentoo manual mount -t proc none proc mount --rbind /sys sys mount --rbind /dev dev env -i HOME=/root TERM=$TERM /bin/chroot . bash -l # export PS1="(chroot) $PS1" (chroot)# emerge-webrsync (chroot)# emerge --sync (chroot)# eselect profile list and select a desktop profile. For me it was #5, default/linux/x86/17.0/desktop (stable). The desktop profile brings in Xorg which will be needed later for wine anyway. (chroot)# eselect profile set 5 Edit make.conf to add the correct MAKEOPTS ("-j7" worked for me) then do a world update, and go do something else for a couple of hours. (chroot)# emerge -avuDN @world Once done, set up Xserver redirection in chroot so it displays the image on the host. On the host: xauth list will show you the "magic" cookie of your host display. Put it into .Xauthority on the chroot: sudo xauth extract <path_to_chroot>/root/.Xauthority <hostname>/unix:0 where <hostname> is the name of your host machine (mine is eb1) (edit) NB when you log out of your host then log back in, the cookie changes so you will have to redo the line above, or X redirection will stop working. In the chroot, verify that the cookie is set correctly: (chroot)# xauth list should show the same as on the host Also set the DISPLAY variable in chroot: (host) echo $DISPLAY should show ":0.0" (chroot)# export DISPLAY=":0.0" You can add the above line to /etc/profile in Gentoo so it gets automatically set every time you enter the chroot. Verify that it works. In chroot run xcalc (you may have to install xcalc first), and it should display on the host. (chroot)# xcalc If no errors, emerge wine in the chroot and configure it. You should have a 32-bit wine now, ready to run 32-bit Windows binaries (minus configuring, figuring out missing libs etc - but this is beyond the scope of this writeup) (chroot)# emerge wine Final size of the chroot Gentoo on my disk was close to 4.5GB.
  15. Looks good. It wasn't a big deal TBH but this order of things makes things smoother.
  16. Upgrading a machine 1.3 -> 1.4, emerge -auDN @world fails at numpy. Specifically one of the patches fails to apply (numpy-1.9.2-no-hardcode-blas.patch) Logs attached. (Edit) made a bug report https://bugs.funtoo.org/browse/FL-6732 build.log info.txt numpy-1.9.2-no-hardcode-blas.patch.out
  17. One issue that I've run into while upgrading (several machines) from 1.3 to 1.4 is that during the world update, packages that depend on python-3.7 get pulled before the python upgrade itself, and fail repeatedly (e.g. libpsl-0.20.2). Perhaps the instructions should mention that python 3.7 should be installed separately before doing the world update, and the default python interpreter should be switched to 3.7 also before the world update.
  18. I don't think that's the case. The USB stick is almost new, and it has only had a few MB of files written to it once. Also even 8GB is not a significant part of the drive's capacity of 128GB. For testing I only wrote one file at a time, and I did a total of 5-6 tests. Wear leveling should not come into play unless Lexar is totally off their game. Regardless like you said there isn't much I can do. I'll go back to using external enclosures. A small stick that fits in a pocket would have been a nice upgrade. Or maybe try a stick that's below 64GB.
  19. Small update, it seems that this USB stick is not very adequate for my purpose. It does not handle large files well. I tested it with a few files, between 5 and 8GB. They appear to copy well, but the stick's activity LED continues to flash as if stuff still happens (and it doesn't stop for a long time: I waited at one point for 1h and it still continued to do it). This activity continues even if I unmount the drive. No error message is generated, and if I try to mount the stick again it gives me a device busy error. If I physically remove the stick after unmounting and then plug it back in and mount it, the files copied over are damaged. Looks like I'll have to look elsewhere for a large file transfer medium.
  20. Hm, interesting. Gdisk says it's a MBR volume, not GPT. It also complains of overlapping partitions... like cfdisk does. Doesn't find any other partition schemes either, which is normal. Dirty tricks, I tell ya. However, sgdisk -Z /dev/sdb worked at destroying all partitioning tables on the disk and I was able to partition it and format the usual way. I now have a /dev/sdb1 of 128GB formatted ext4, exactly what I wanted. Thank you!
  21. I have a Lexar 128GB USB stick, formatted exFAT out of the box. I have been trying to repartition it and format it ext4 so I can use it to transfer large files between Linux machines. I don't know what dirty tricks Lexar used to partition and format it, but the partition table is really screwed up. Moreover, I can't change it. If I delete the fictitious partitions on the stick in cfdisk, write a new partition to the stick, exit and try to read the stick again it fails. I have to physically disconnect and reconnect it, and then the original partition table is back. It looks like I'm getting some cache errors when trying to write the partition table: [ 417.015912] sd 6:0:0:0: [sdb] Synchronizing SCSI cache [ 417.015960] sd 6:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK I've looked for a solution but haven't really found anything. The stick itself works when attached to a Windows machine. I'm attaching a screenshot of the partition table, and the output of dmesg. Did anyone have success partitioning and formatting one of these in Linux?
  22. Hmm, with the new fix in place mesa emerges successfully, however I still can't start a X server. The Xorg log says it can't find module "nouveau". Nouveau is in fact compiled and installed in the usual kernel module tree, and loaded (it's listed with lsmod).
  23. Thanks. I did that. FL-6604 https://bugs.funtoo.org/projects/FL/issues/FL-6604
  24. I'm testing the new 1.4. My test system is an older laptop, MSI GX720, core2duo P8400 with a nvidia GT9600M video card. I started with a blank disk, installed the minimal 1.3 system from the latest stage3 (core2 subarch) and from there proceeded to upgrade to 1.4 as per instructions. I tried the nvidia driver first (gfxcard_nvidia) but it seems that there's no driver compatible with my video card. So then I switched to gfxcard_nouveau and I get an error emerging mesa-19.1.3. Everything else emerges fine but the last step, mesa, fails. I'm attaching an archive of logs. I think the issue is related to the following in build.log: . >>> Configuring source in /var/tmp/portage/media-libs/mesa-19.1.3-r1/work/mesa-19.1.3 ... meson /var/tmp/portage/media-libs/mesa-19.1.3-r1/work/mesa-19.1.3 /var/tmp/portage/media-libs/mesa-19.1.3-r1/work/mesa-19.1.3-build --buildtype release -Db_ndebug=if-release --libdir lib64 --localstatedir /var/lib --sharedstatedir /usr/share/mesa-19.1.3 --prefix /usr --wrap-mode nodownload --prefix=/usr --libdir=lib64 -Dplatforms=x11,drm,surfaceless -Ddri3=false -Ddri-drivers=swrast,nouveau -Dgallium-drivers=gallium-nouveau -Dgallium-extra-hud=false -Dgallium-vdpau=auto -Dgallium-xvmc=auto -Dgallium-omx=disabled -Dgallium-va=auto -Dgallium-xa=auto -Dgallium-nine=false -Dgallium-opencl=disabled -Dvulkan-drivers= -Dshader-cache=auto -Dshared-glapi=true -Dgles1=auto -Dgles2=auto -Dopengl=true -Dgbm=auto -Dglx=auto -Degl=auto -Dglvnd=true -Dasm=true -Dglx-read-only-text=false -Dllvm=true -Dvalgrind=false -Dlibunwind=false -Dlmsensors=false -Dbuild-tests=false -Dselinux=false -Dosmesa=classic -Dosmesa-bits=8 -Dswr-arches= -Dtools=glsl,nir,nouveau -Dxlib-lease=auto . . meson.build:21:0: [1;31mERROR:[0m Options "gallium-nouveau" are not in allowed choices: ", auto, kmsro, radeonsi, r300, r600, nouveau, freedreno, swrast, v3d, vc4, etnaviv, tegra, i915, svga, virgl, swr, panfrost, iris, lima" mesaerror.tar.bz2
  25. The linked article "why hard drives fail" from the above fails to mention one of the most frequent failure modes that I have observed with my usage: the SATA connectors breaking after only 2-3 uses due to poor plastics used. Sometimes they can be repaired (on one drive I cut the end of a SATA cable and soldered the wires directly to the drive's PCB) but sometimes they're not.
×
×
  • Create New...