

callegar
Members-
Posts
20 -
Joined
-
Last visited
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
`/etc/armbian-image-release` is not updated...
callegar replied to umlaeute's topic in Software, Applications, Userspace
Same issue here. I originally installed a bullseye image and then updated to buster. However /etc/armbian-image-release does not get updated and unfortunately, it is the sole place where motd 10-armbian-header can find information about the distribution codename. In fact: - first /etc/armbian-image-release is read that contains DISTRIBUTION_CODENAME from the original image (which I think is OK because I understand that file should always keep info from the image employed for the initial installation); - then /etc/armbian-release is read, but does not contain anything about the DISTRIBUTION_CODENAME (this does not seem OK to me). - finally no other info is gathered because DISTRIBUTION_CODENAME is already set -
A quick msg to kindly ask what should be the current kernels with an RK3318/28 TV Box. My system is currently on -edge and having 6.8.11 installed, but reading here that doing an upgrade on edge, people are receiving 6.10. At the same time `armbian-config` -> System -> Other does not even show me my own kernel among the options, edge being at proposed at 6.7 (associated at armian 24.2.1) and current at 6.6. Is there anything wrong with my config? Is it normal not to see edge kernels associated to the most recent armbian releases (e.g. 24.8.2)?
-
This is actually my problem. My kernel is an edge package (`linux-image-edge-rockchip64`). And if I start `armbian-config` and then go to System → Other (switch to other kernels), still I cannot find any kernel newer than 6.1.11. What should I look at? My impression is that the newer kernel get to the pre-built images but do not get at all to the apt repos. At least I am unable to find them in apt.armbian.com (stable). I can find newer stuff in beta, but now that 23.05 has stabilized, I was expecting to see 23.05 kernels in apt.armbian.com.
-
Just to make sure I have not messed up anything. For a long time I have not received any kernel update. Is the most recent kernel available via apt still linux-image-edge-rockchip64 23.02.2 corresponding to 6.1.11? Looks like the pre-built images get a much more recent kernel. Yet even if I switch the apt source lists for armbian to bookworm I still remain on 6.1.11...
-
Hi, would like to know whether there is experience in upgrading to bookworm from bullseye with these RK3318/28 boards. Notably I would like to know about upgrading without a reinstall from scratch. From the general armbian upgrade instructions (https://docs.armbian.com/User-Guide_Getting-Started/#how-to-upgrade-distribution-like-focal-to-jammy-or-bullseye-to-bookworm) I see that I should: Fire up armbian-config to freeze the firmware packages (if not frozen already, by selecting System and Freeze) Follow the generic upgrade instructions specific to debian Is this enough? Should I unfreeze the firmware packages afterwords? Others when it was time to upgrade from buster to bullseye suggested a slightly different procedure: apt update & full-upgrade Disable /etc/apt/sources.list.d/armbian.list all entries to stop armbian from upgrading Use normal debian upgrade steps -> Change release in /etc/apt/sources.list apt update & full-upgrade Restart, validate working system Update /etc/apt/sources.list.d/armbian.list with new release apt update & full-upgrade Is this any safer? They recommend making sure at least some working version of armbian-image-* armbian-dtb-* is installed before rebooting which seems reasonable, but is there any reason this might fail? Thanks!
-
Just installed them and they seem totally fine. A big thank you!!! When you ssh onto the machine you find it at 60°. With the 22.05 build I think it was at 61°, so maybe there is also a little advantage here. Also got rid of the previous `-current` dtb, kernel and headers packages. One final question: the correct u-boot to use is the one from the previous 5.15 branch, namely `linux-u-boot-current-rk3318-box_22.08.0-trunk_arm64.deb`, right?
-
Tried with that and the edge kernel packages. Now I have 5.18.6 and everything seems fine. Just one question: I now have both the -current and -edge kernel packages installed and the system boots the -edge kernel. I think I should remove the -current packages, right? Some armbian threads seems to state that switching kernel from legacy to current, from current to edge or the other ways round should be done with the assistance of `armbian-config` for the removal of the unused packages. I do not have such option in `armbian-config` though. Is it OK to just remove the -current packages?
-
Indeed, I found because a few people were reporting issues with 5.18, but at the very same time I was encountering quite similar issues on 5.15, which seemed to me a weird coincidence. I saw there is no similar patch for 5.18, so I thought that maybe that 5.15 patch was meant at porting into 5.15 some change that was already in built in 5.18 and maybe help at confining the search for the actual problem. I do not have enough knowledge about the inner matters, though. Is there some way to find out if a tvbox has aproper power regulation or not (apart from breaking that open)? In addition to that, should I also test the 333MHz idbloader? Is there an easy way to switch back and forth from the 333 and 666MHz idbloader? I've seen that changing the idboader is a matter of dd-ing a file onto the machine, but it is unclear to me which file is for 333 and which one for 666 MHz. Looking forward to the new build to test.
-
The relevant difference seems to be in the `board-tvbox-rk3318.patch` file that is updated also for the 5.15 kernel sources in the *22.08* packages. The latest git commit is "rk3318: use 666mhz ddrbin, reduce cpu and gpu voltages". It is unclear to me which part of it is playing badly with my board, whether the "use 666MHz" or the "reduce cpu voltage". I understand that both of them can lead to erratic behavior and code segfaulting (either because the CPU is operating incorrectly as its voltage is too low for the given frequency or because incorrect data is exchanged with the memory if the latter cannot work at 666MHz). My suspect is that the issue is with the reduced cpu voltage, since other users in this thread report instability and it looks like they "fixed" it by reducing the cpu frequency (that is finding a sweet spot wrt the voltage-frequency trade off at a lower voltage). Because reducing the CPU frequency is not all that desirable performance wise, I would like to ask about the reason for the cpu voltage reduction. Was the cpu incorrectly run out of specs wrt its voltage until 22.08 so that had to be fixed?