• Content Count

  • Joined

  • Last visited

About marcz

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I was just pointing out that even if "Nightly" are unavailable, "Other" can still work. Since the previous post answered that "Other" is working. So is just to avoid confusion between these two actions, if some other people happen to read this thread, and to tell them, don't do like I did, first look at available packages.
  2. First in armbian-config the entry is not the same that nightly build, the first one look for an other kernel in the same repository so you can switch to an other version without changing your source list in armbian.list, going back to the old kernel work flawessly, but nightly change the repository, this is why if your distribution is missing after deleting packages, you cannot go forward installing inexistent nightly build, nor backward since the stable packages are not there either. EspressoBin is not the same than helios4 since the first is arm64 and the second armhf, but looking to it seems it is also currently missing in nightly builds; and I guess that if you try on your board to switch to nightly builds, may be you non longer can tell that
  3. I looked in armbian-config and the debian-config-functions and I may have found why the test of downloading did not work. At the beginning of reload_bsp we update the cache to use which does not include the architecture and the board. So all lookup by apt-cache fail, In this case the PACKAGE_LIST is set to the old packages, so the download work and no error is returned. The the purge is not done on the the PACKAGE_LIST but on a fixed list of package, which may be or not in PACKAGE_LIST. When trying to reinstall the purged packages are missing. This as a script which is quite complicated if we have to consider all combination of parameters, and I don't think I am able to give a pull request that will not break a lot more than what it will repair. But I would suggest that if the apt-cache lookup always fail, the script exit without deleting anything. And only purging the PACKAGE_LIST that has been downloaded.
  4. Yes it is what is done in #1597 now in the kernel tree.
  5. Sorry Igor if my post looks like ranting, it was not my purpose, I don't want to protest against any defect, if it looks so I apologize. This title that I thought to be a joke mimicking tabloids title , may have caused a misunderstanding. I was knowing that switching to nightly build could break the system, but I was supposing it is because a defect in or incompatibility in the development package, I was surprised the script uninstall packages without verifying there is a replacement. I wanted also to tell other users of Helios4 to care not to switch to nightly build without first checking it exists. When I asked "and why?" it was not a complain, but I would like to know why this architecture is missing. For the armbian-config script, I did not know if it could be useful to open an issue on github, so I asked here, with your answer I suppose, that such issue is not welcome until I can submit a push request. I'm new, no to armbian, but to armbian build system. It is why I was asking the question about how to build a module, looking at the forum, I have found people having tried different methods, but I don't know what is the right way. May be I have to reinstall my broken banana pi, and wait for linux-mvebu64-next for DRBD. I apologize again if something could look offensive in my post, I am thankful to developers who provide this great distribution, and hope not to hurt anybody.
  6. I bought an helios4 (and run helios4 4.19.63-mvebu) to replace a bananapi server under armbian, the bananapi was running a DRBD node, so I need this service. I first tried to install it, and have seen that DRBD was not configured in the kernel linux-image-next-mvebu 5.91. and the module was missing I checked in the git repository that linux-mvebu64-next.config has now this configuration option, and thought that I will get a new kernel by switching to nightly build. As this option is offered by armbian-config I toggled it. After some time my Helios4 failed to reboot and was bricked. I mounted my SD on an other system to try to analyze the situation, nothing appeared in the log neither syslog, message, or apt/history.log. So I checked the script armbian-config. only switch the source.list from to then call reload_bsp which remove linux-image-next-mvebu, linux-dtb-next-mvebu, linux-buster-root-next-helios4, armbian-config. Then it try to reinstall them, but for helios4 linux-image-next-mvebu, linux-dtb-next-mvebu, and linux-buster-root-next-helios4 are not in, so nothing get reinstalled and the system was broken. So I checked that the previous packages were missing, except the kernel which was not removed. I downloaded them from stable, re-installed them on the sdcard with `dpkg -x`, I edited the armbian.list to switch back to, and my system came back to life after few hours of work. I would consider that it is not reasonable to propose to switch to nightly build when they don't exist. The script should first verify that the packages to be uninstalled are present on And now my question is how to install the development kernel on Helios4, do I need to recompile the kernel, or only the DRBD module, and why daily build are missing for helios4.
  7. You can also use the UUID both in your /boot/armbianEnv.txt and the fstab. So a lvrename or vgrename will not make your system unbootable. I use it for using as rootfs a btrfs filesystem in an lvm logical volume.
  8. I find quite strange that CONFIG_DM_MIRROR is not set in the kernel. It makes impossible under lvm to have logical volume mirror, and I just experienced an impossibility to make a pvmove to change one drive for another one. All my filesystems are built upon lvm, the only possibility would be to rebuild a kernel. But I find it quite heavy, since I have to platforms bananapi and espressobin; and it needs to be done for each release. But why no have built dm-mirror as module with the usual CONFIG_DM_MIRROR=m ?