WrongWorld

Members
  • Content Count

    11
  • Joined

  • Last visited

  1. What is the supported way, if any, to redirect /var/log.hdd to a directory located on a real HDD drive? One of my systems has an eMMC to boot and operate from, and a HDD hooked up on the USB3 port. "Ideally" I'd like to use only the HDD, but the poor/incomplete USB3 boot support on the Rock64 V2 (with Bionic at least) had me to buy an eMMC and live quietly with it. As it is, I'd like to move out of the eMMC all the data that is either written often, or that it could get bigger with time passing. For the logs, however, I don't think to have found a clean way to support the relocation of /var/log.hdd on a different drive/partition, unless I hack the armbian-ramlog script (something I *don't* want to do). Or I could disable completely the log2ram feature. Thanks!
  2. Add me to the list of users who have lost the USB3 port once I've switched to kernel 5.3.11. On one of my boards I have had to hook a monitor to understand why the Rock64 did not boot anymore from the eMMC. The problem is it is failing to mount the USB3 connected HDD and then it goes in recovery mode. The Ethernet port is also not configured. Booting from a SD card with Armbian Bionic 5.90 in it I first upgraded to the latest 5.98, which brought in kernel 4.4.198 (I was on 4.4.192), then using armbian-config I switched to the new kernel 5.3.11. On powering on the board (the switch poweroff the board instead of power cycling it), not depending on a fstab pointing to a missing drive the system booted normally, with the Ethernet port properly configured. The USB3 port is still missing from lsusb -t output
  3. For which OS? I have a Rock64 V2 running 24/7 Ubuntu Bionic with kernel 4.4.192 (Armbian Bionic 5.98), which I have recompiled myself to add back a driver, and it seems pretty stable as of now. With the previous versions I used to have some sporadic zram0 errors, but it's now two days of uptime since my last reboot and I haven't seem them.
  4. Done! ayufan rock64 linux and armbian build pull requests As written in the pull request for armbian, once (and if) ayufan will include the patches into the kernel you will not need them any more.
  5. Followup: I've created a pull request to ayufan's kernel (4.4.190) with the needed patches, hopefully it will be merged soon.
  6. Well it took me a long time (actually it was finding the time to dedicate to something quite new for me), but it seems that I've finally fixed the issue with this popular DVB-USB stick. The problem lies in the linux-rockchip64 driver file provided by ayufan's rockchip kernel fork (dib0700_devices.c), which was not updated after a refactoring of some IR macros occurred in the kernel's headers. Since including the module causes a compilation error, the maintainer probably decided it was easier to remove it from the build. I have forked and cloned the latest armbian build environment, and created a patch file to fix the module's source in the ayufan kernel (4.4.192). I need to do some more test on the reliability of the driver (no antenna connection here in my lab), but a least both the kernel and TVheadend see it again. Since I am new to git-based contribs, I'd like to know which would be the preferable way to prepare the patch for a pull request. move the patch from userpatches/kernel/... to patch/kernel/... and ask for a pull request to armbian, or fork-clone-patch-commit-pull ayufan's kernel, as the issue is really there
  7. Unfortunately it's not my case, I still cannot boot from USB3 even with the latest version of U-Boot.
  8. As much as I like the Rock64 board, I couldn't agree more with you. It is a really nifty board, so much better in many aspects compared to the Pi, yet so badly supported by Pine. This board (REV. 2 in my case) has still the big problem of not being able to boot from the SSD when it's hooked on the USB3 port, not even with the recent U-Boot version provided by ayufan, for which I had some hope. Back on subject, I have no problem with REV. 2 and the latest 4.4.192 kernel. I have even finally solved the problem with the missing DTV-USB driver, more on this on the relevant thread.
  9. Add me to the list. Currently I've reluctantly solved by moving the SSD to the USB2 port, which nulls one of the main reasons for having chosen the Rock64. However, I have this idea that the problem is not the kernel, but u-boot which does not properly initialize the USB3 port. It is a fact that sometime you are able to boot from USB3, as long as you have no other current-dragging devices connected (included the HDMI cable). It is still a shot in the dark, i.e. will mostly fail, but if you have other devices connected, in my own experience, there is 0% possibility that the boot from USB3 succeeds. And no, using an USB3 hub does not make any difference, I agree.
  10. OK, I've checked them and apparently in commit 58725209d970c98489a4ee5cdf085a80347c5d47, in linux-rockchip64-default.config, CONFIG_DVB_USB_DIB0700=m was removed for reasons I haven't investigated yet (although it seems it's coming from a sync with ayufan's branch) , hence the kernel module went out of the package. It will take some time on my side to submit a proper pull request, as I am not particularly fluent in rebuilding the kernel, nor in managing Git contributions. Thank you for your support, Igor.
  11. Hello, I have a Rock64 V2 which I am using as a Tvheadend server, among other stuff. For some months I put the kernel/dtb packages on hold, because I discovered that linux-image-rockchip64 after version 5.75 did not include the kernel module for th USB DVB-T stick I need (an EyeTV DVB-T device, i.e. a clone of Hauppauge), that is dvb-usb-dib0700 or the like (I am trying to remember). I have recently unhold the Linux packages and let apt to update them. Now at version 5.90, I see that the kernel module is still not included, and my USB device cannot be used. Going back to Linux image 5.75 makes the stick to work again, but I'd like to have the latest versions running. Questions: 1) Am I missing an extra package? 2) How can I get back on driver? (Well, a third one would be why it has been removed from the latest versions) Thanks!