balbes150

I run an image build, and an error occurs during the image build process in the log. armbian-config is already the newest version (5.67). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. dpkg-deb: building package 'armbian-bionic' in '/home/user/build/output/debs/bionic/armbian-bionic_5.67_arm64.deb'. Selecting previously unselected package armbian-bionic. dpkg: regarding .../armbian-bionic_5.67_arm64.deb containing armbian-bionic: linux-bionic-root-rockpro64 conflicts with armbian-bsp armbian-bionic provides armbian-bsp and is to be installed. dpkg: error processing archive /root/armbian-bionic_5.67_arm64.deb (--install): conflicting packages - not installing armbian-bionic Errors were encountered while processing: /root/armbian-bionic_5.67_arm64.deb

In the process of building test images, I constantly get an error message about the installation of the package "armbian-bionic". I looked at the log and there is a conflict with the package "linux-bionic-root-rockpro64". This is when building images for s9xx, rk3399-tv etc. Where does this dependence (in the build scripts of the packages I can't find instructions on it) ?

I am using on X96mini (2\16) version 5.67 with DTB from khadas-vim. All the details are in the relevant subject.

For anyone who makes changes to the kernel, I recommend that you make sure to write about it on the mailing list so that these fixes are included in the official version of the kernel. http://linux-meson.com/doku.php

I understood correctly, you can't run USB Burn Tool ? Disconnect all devices from the TV box (including the mains power supply). Run the program on your PC. Select the desired firmware in the program. Put a Daw on" Erase boot "and press"Start". Only after that, plug the USB cable into the PC and TV box ( what you do not need to press Button, the power supply must be turned off).

This solves the problem of automatic updating of existing systems for users. New packages are sent to the network repository and when the user starts the system, new versions will be detected (as far as I remember, you have the formation of an archive with packages and it can be used). Maybe you should create a standard Armbian network repository, add it to the APT list during the build and then everything will be done automatically by users (when the standard "apt update"procedure will be run). By the way, the same network repository can be used to build images (get Armbian packages from It).

Just like in Debian, add the full version number to the package name. When you run a shared build script, it checks the number in the description and if it has changed, it starts the build of a new variant of the package with the replacement (or not) of the current package with a new one.

1. What version of Armbian on SD card. 2. Which dtb is specified in the Armbian launch settings. 3. What version Libreelec ceased to run. 4. What firmware and how did you recorded a TV box.

You didn't write what TV box model.

Update ver 20181220 kernel 4.4.154

Perhaps lightdm is not the best solution and there are others, but it has been repeatedly tested on ARM and works correctly, has the ability to easily configure the auto-login.

On such a meager description of what image you use and what steps did - only psychics will be able to understand what could be the problem.

Now Armbian is increasingly used as a full-fledged working system with DE (by the way, not only at home , but also in organizations). So it may work different users and absolutely necessary system of separation of entrance and lock when the lack in the workplace.

@Igor I mean, a different situation. I will describe in more detail on the example of the image Assembly. For example, I run a clean build (when I don't have a ROOTFS archive yet). The build system , in the process, receives all necessary packages from the network and creates a local archive with ROOTFS. After that, the build system additionally (separately) downloads the packages and dependencies for LIGHTDM installation and installs them in the temporary system generated for the image. After that, the build system forms the finished image. In this use case, receiving packets from the network for ROOTFS and receiving packets for the LIGHTDM Manager occurs at almost the same time, and it is unlikely that there will be a problem. After some time (for example, 3-5 days), I run the Assembly of the same image again. I already have a ready archive with ROOTFS and it is used (packages are not received from the network). But with further image building, the build system accesses the network and receives LIGHTDM packets (and its dependencies) from the network. For the time that has passed since the formation of the ROOTFS, you can change the part of the packet and a collision occurs. Adding to the build system, the process of updating packages on the build system , before installing LIGHTDM packages, can aggravate the situation with unsynchronization. The existing ROOTFS already has its own versions of packages and settings, and an attempt to update them automatically can give an unknown result. I suggest doing getting all the packets from the network reps that are used to form the ROOTFS and the login Manager at one time. That is, LIGHTDM packages and their dependencies must be part of the ROOTFS archive. You don't have to try to retrieve LIGHTDM packages from online repositories every time you run an image build.

I took a quick look, Yes, the idea is good, to make the creation of all the necessary packages in a separate procedure and have a common source with the packages to install. I understand that it is now possible to gradually migrate her assembling the necessary packages for TV boxes ?

Yes, this also happens to users (and quite often). When they run the update and as a result, some of the features they used are broken (you have to remove conflicting packages). They have to either write a bug report and wait for a fix, or roll back to previous, compatible versions of packages. When you manually update the system writes, if there are conflicts and the user decides what functions are important to him and how to do (what to remove and what to leave). In an automatic build, you cannot provide all the behaviors and always use the default. It is possible you that the online repositories used in the build are usually in a stable state (already updated or not yet updated) when you run the build. That is, the time of the build system is well synchronized with the work of updates in network repositories. IMHO I suggest for all versions of images where DE is used to use the standard approach from "adult" systems. The source image must use some kind of login Manager (for example, lightdm). This corresponds to the logic of safe operation and is a common (familiar) option for users moving from PC to ARM. The current state of Armbian and the hardware it runs on has already become quite Mature and capable of working on an equal footing with the PC. If the user wants to make a autologin or use "nodm" - he will do it yourself (good manuals for this is more than enough). In the server options of images, the default should not be any managers of the entrance. In addition. I would put the u-boot Assembly in a separate process, with mandatory testing for the correctness of the assembled version on the intended devices. And only after that place the packages in the repository for Assembly by others or for use by users. U-boot is an important element for the safe use of the device (this is especially true for devices with built-in memory, where it is very difficult to fix not correctly recorded in memory u-boot).

@Igor I looked at the option to neutralize the problem with installing lightdm\nodem packages. I think this may add to the problems. There are ready-made rootfs, which is previously formed and tested. It is used to create a working version of the system, if you try to update the installed packages from it to the current version in the network repositories, you can get to the same problem that we are trying to solve - unsynchronization of packages in an even larger form (since the whole system is updated). The main problem of network repositories is that you can get to a state when some of the packages in it have changed and temporarily lost connections (dependencies). I regularly get on such problems. So I suggest forming all the ROOTFS in one go. All packages that are used from online repositories should be obtained in one transaction (when forming rootfs cast), if lucky and it turned out to be working, then it can be safely used for further builds, until the next (possibly manual) instructions to form a new version of the archive with ROOTFS (if you manually delete the archive with ROOTFS).

To get this to all the images are building, send the patch to the main Linux kernel or to this mailing list. http://www.linux-meson.com/doku.php

To verify that the 4.20 kernel can be installed on the eMMC, you need to run the following set of commands. Run Armbian with the 4xx kernel and run the command "fdisk -l" in the terminal as root to determine which name "/dev/mmcblkX" is assigned to the eMMC.

All startup and RO system problems are the result of bad media (or card reader). Try to run from USB.

The new version of the LE-9.1 aarch64 20181216 for rk3328. I can't get to Freaktab ("glitches" of my provider) yet, so please, to those who have the opportunity to publish the info about the release of new versions of Armbian and Libreelec for RK3328 and for RK3399 (Khadas Edge) on the public FreakTab forum.

Now launched Armbian on MVR9 (rk3328), desktop resolution 1920x1080 (so-called 1080p mode). 720p video is normally played in the window. I tried to fill the entire screen - does not fly, but watchable. Launch the browser with YouTube (in normal mode, the video window on the right, a list is available) - all video works without brakes. If you expand to full screen, artifacts slip through. Switched the resolution of the desktop to 720-all video goes to full screen without brakes and artifacts, almost like in LE. Notice that I reworked the body to improve cooling (drilled pen drill for door handle hole above the CPU and did a side slot for the free passage of air (but without fan). If you bring your hand to the hole, I feel like there is warm air from the body. For information-the system is running with SD card and wired Gigabit network. By the way, he was surprised that YouTube in the browser at the resolution of the desktop 720 and in the YouTube indicated to use 720, when displayed in full screen (all video options, not only 720) is no problem. But if you switch to YouTube to use 1080 artifacts have already appeared ...

can continue in native language http://forum.puppyrus.org/index.php?topic=19828.30

Learn how to use search, this issue has been discussed many times.

On MVR9 wifi and BT and all other elements work.