Jump to content

going

Members
ย View Profile ย See their activity

  • Posts

    610

  • Joined

  • Last visited

 Content Type 

Everything posted by going

  1. going
    Ricardo, all we need in the future is a lot of additional versioning of the commands that we use in the build system. And a message to the user if the version is lower than the required one. Linux OS can be anything if the versions of the commands meet the requirements. This will save us from a lot of discussions on the forum.
  2. going
    Probably this message printed once is enough. You have a good tracer. Error occurred in main shell code 1 at /mnt/data/build-armbian/armbian-next/build/lib/functions/logging/runners.sh:186 run_host_command_logged_raw() --> ./lib/functions/logging/runners.sh:186 run_host_command_logged() --> ./lib/functions/logging/runners.sh:169 aggregate_all_packages() --> ./lib/functions/configuration/aggregation.sh:59 do_main_configuration() --> ./lib/functions/configuration/main-config.sh:428 prepare_and_config_main_build_single() --> ./lib/functions/main/config-prepare.sh:93 cli_standard_build_run() --> ./lib/functions/cli/cli-build.sh:12 armbian_cli_run_command() --> ./lib/functions/cli/utils-cli.sh:126 cli_entrypoint() --> ./lib/functions/cli/entrypoint.sh:155 main() --> ./compile.sh:52
  3. going
    Thanks for the clarification. If you think all this information is necessary for debugging, then you can try to enter the key "VERBOSE" and set it to "0" by default. In this case, the log will contain only brief messages about the execution stage. If "1" then the values of the variables for this stage are added (not all). If "2", then the name of the execution stage function and the place from which it was called are additionally printed. And then up to the number "7". But I think this is somewhat superfluous for such a simple script as the armbian build system. This particular message is not necessary at all. # ARGs: 'BOARD=orangepi-r1' 'BRANCH=current' 'RELEASE=bullseye' 'BUILD_MINIMAL=yes' 'BUILD_DESKTOP=no' 'KERNEL_ONLY=no' 'KERNEL_CONFIGURE=no' 'CREATE_PATCHES=no' This is printed at the very beginning. That's enough. If the build was successful, 90% of this log is not needed. If I got an error, I need this error in the log. I need the name of the function and the file where the error occurred. And that's probably it.
  4. going
    I cleaned part of the log from the husk that prevented reading. But I didn't understand what the mistake was. I guess I'll have to do this every time I get an error and try to read the log. Is that true? What is the sacred meaning of typing the same message 2 and 3 times?
  5. going
    @schwar3kat A good place to discuss. Please add echo "$(git diff)" here. I am interested in whether or not new files appeared in the build system after you started it to run? @rpardini Please explain why this is in the log: .... --> ๐Ÿฆ‹ 1: 2382876 - 2382876 - 2382876: ehBE: .... --> ๐Ÿงฝ 1: 2382876 - 2382876 - 2382876: ehBE: .... --> ๐Ÿงฝ 1: 2382876 - 2382876 - 2382876: ehBE: .... .... And what does it mean, how can I understand the meaning?
  6. going
    This question is for a philosophical conversation. Let's leave it hanging in the air.
  7. going
    For me, it's still vague. The topic requires study for me. I assume that there should be no development packages in the standard image. The fakeroot package alone is a security issue.
  8. going
    This image is assembled incorrectly. This error has been fixed in the build system to date. You need to uninstall the kernel header package. Then install the dependencies necessary for the build. apt-get install build-essential kmod debhelper devscripts After that, install the kernel header package again. @Igor I still have a question about why the kernel headers are installed in the standard image?
  9. going
    @atone The only option for changes can only be if we add an additional global variable that can be defined at the very beginning of the path, instead of having to program the value 500. For your case, 400-450 will be the optimal value. For my case, it will have a different meaning. If you make this fix, then I approve this pull request.
  10. going
    This is not a mistake. This is not a very good way to get around some of the providers' restrictions on the download speed for the end user. If the download speed is less than specified in the limit, then the connection breaks and an attempt is made to download from the following address. We can pre-check the speed of distribution from a specific address, but we will not be able to do a download speed check for your specific provider. For example, a provider can provide a high download speed for the first 50-100 megabytes from the download address, and then reduces the download speed to 20 kilobytes/sec. The existing algorithm in this situation allows for faster loading. The downside of this is getting error messages.
  11. going
    The chip operates at a voltage of 1.1V, and you have applied a voltage of 1.8V or vice versa, you have not applied enough voltage of 0.9V. You are trying to change the mode of operation of the chip and write a value to the register, but the register is mixed up and something else will change. You need to learn how to properly read the user documentation, the schematic diagram of the device. And learn how to compare the documentation and the device tree file. Sorry, the question is general - the answer is general.
  12. going

    RAM problem

    going replied to sp595's topic in Allwinner sunxi

    If this is your device, then there is only one RAM chip on it. I find it difficult to guess anything.
  13. going

    RAM problem

    going replied to sp595's topic in Allwinner sunxi

    If the radiator is not glued, but screwed with a screw and thermal paste. If you glued it, then don't touch it.
  14. going

    RAM problem

    going replied to sp595's topic in Allwinner sunxi

    @sp595 UART output shows? If this is not possible for you, then publish the inscriptions on the memory chips.
  15. going

    RAM problem

    going replied to sp595's topic in Allwinner sunxi

    It can't be called a marriage. The device board was tested before sale. The test image did not register an error and the device was sold. I have 4 RAM bars of different manufacturers on an x86 machine. All of them say that they work at 1800 Mhz, but one bar works stably only at 1600. I just set this frequency and enjoy stable operation. You can set the value of the variable "verbosity=7" in the file "/boot/armbianEnv.txt " and see what the UART output shows. When you can catch a stable value and the value of the frequency at which one memory chip fails, then write here and call me like this: @going
  16. going

    RAM problem

    going replied to sp595's topic in Allwinner sunxi

    Very strange behavior. But unfortunately this happens. This is similar to the fact that one memory chip soldered to the device cannot work at a frequency \ mode at which the other chip works normally. A possible solution to the problem is to experimentally select the operating modes on which both chips will function normally. Try to register this in the device tree overlay file. This will only be your personal file. But unfortunately I am not an assistant in this matter.
  17. going

    [๐ŸŒฑ] Downloading Kernel bundle [ stable; this might take a long time ] Initializing download: https://mirrors.edge.kernel.org/pub/scm/.bundles/pub/scm/linux/kernel/git/stable/linux/clone.bundle File size: 4.2958 Gigabyte(s) (4612578906 bytes) @rpardini We've already discussed this. And I see it again. Who should I bill for such a large traffic?
  18. going

    I promised that I would try to run a test build in the "armbian-next" branch. The first run with my test config failed. [๐Ÿ’ฅ] Error occurred in main shell [ code 2 at /home/leo/armbian/lib/functions/configuration/main-config.sh:59 do_main_configuration() --> ./lib/functions/configuration/main-config.sh:59 prepare_and_config_main_build_single() --> ./lib/functions/main/config-prepare.sh:109 cli_standard_build_run() --> ./lib/functions/cli/cli-build.sh:12 armbian_cli_run_command() --> ./lib/functions/cli/utils-cli.sh:121 cli_entrypoint() --> ./lib/functions/cli/entrypoint.sh:154 main() --> ./compile.sh:52 ] [๐ŸŒฟ] Built ANSI log file [ /home/leo/armbian/output/logs/armbian-build-28afec36-cd02-43ba-be63-5334f3516cba.ansitxt.log ] [๐Ÿ’ฅ] Error occurred in main shell [ code 2 at /home/leo/armbian/lib/functions/cli/utils-cli.sh:215 cli_standard_relaunch_docker_or_sudo() --> ./lib/functions/cli/utils-cli.sh:215 cli_standard_build_pre_run() --> ./lib/functions/cli/cli-build.sh:5 armbian_cli_pre_run_command() --> ./lib/functions/cli/utils-cli.sh:107 cli_entrypoint() --> ./lib/functions/cli/entrypoint.sh:67 main() --> ./compile.sh:52 ] I very briefly looked at the code that the tracer output. For lib/functions/configuration/main-config.sh:59 file This is a very gross mistake. The name of the remote repository can be anything. "origin" is a common option, but far from the only one. leo@vm-jammy:~/armbian$ echo "$(git remote)" armbian host
  19. going
    Please roll back to kernel 5.19. Wait a few days. There will be a working 6.1 kernel. Work in progress.
  20. going
    Hello Alistair. leo@localhost:/1.8T/gituser/armbian-build> url="cache/sources/linux-mainline/6.1" leo@localhost:/1.8T/gituser/armbian-build> mkdir -p ~/tmp/test/patches.test leo@localhost:/1.8T/gituser/armbian-build> tdir="/home/leo/tmp/test/patches.test" leo@localhost:/1.8T/gituser/armbian-build> tools/mk_format_patch $url mego-6.1..HEAD "$tdir" LOCAL GIT URL =: [/1.8T/gituser/armbian-build/cache/sources/linux-mainline/6.1] revision range =: [mego-6.1..HEAD] target folder for patches =: [/home/leo/tmp/test/patches.test] prefix =: [] numbered =: [false] It's generate format-patch: In tmp folder: /tmp/format_patch_lD9TFyE All generated patches: [7] Good patches: [7] leo@localhost:/1.8T/gituser/armbian-build> tree /home/leo/tmp/test/ /home/leo/tmp/test/ โ”œโ”€โ”€ patches.test โ”‚ โ”œโ”€โ”€ Doc-dt-bindings-usb-add-binding-for-DWC3-controller-on-Allwinne.patch โ”‚ โ”œโ”€โ”€ drv-bluetooth-btrtl-Add-rtl8822cs-hci-ver-0008.patch โ”‚ โ”œโ”€โ”€ drv-mfd-Add-support-for-AC200.patch โ”‚ โ”œโ”€โ”€ drv-net-phy-Add-support-for-AC200-EPHY.patch โ”‚ โ”œโ”€โ”€ drv-pinctrl-pinctrl-sun50i-a64-disable_strict_mode.patch โ”‚ โ”œโ”€โ”€ drv-rtc-sun6i-support-RTCs-without-external-LOSCs.patch โ”‚ โ””โ”€โ”€ Revert-net-Remove-net-ipx.h-and-uapi-linux-ipx.h-header-files.patch โ””โ”€โ”€ series.test 1 directory, 8 files revision range =: [mego-6.1..HEAD] After I applied all the "megous" patches, at the top of the story I made the tag "mego-6.1". Now you can see at what stage my work is today. Specify the full, absolute paths and everything will work.
  21. going
    sudo apt install apt-file sudo apt-file update apt-file search /usr/bin/cvt gnustep-base-runtime: /usr/bin/cvtenc sudo: /usr/bin/cvtsudoers sudo-ldap: /usr/bin/cvtsudoers xcvt: /usr/bin/cvt apt search xcvt Sorting... Done Full Text Search... Done libxcvt-dev/jammy 0.1.1-3 amd64 VESA CVT standard timing modelines generator -- development files libxcvt0/jammy 0.1.1-3 amd64 VESA CVT standard timing modelines generator -- shared library wcslib-tools/jammy 7.7+ds-1 amd64 Command line tools utilizing wcslib xcvt/jammy 0.1.1-3 amd64 VESA CVT standard timing modelines generator
  22. going
    This opportunity is necessary for professionals. I have almost implemented such an opportunity to build and develop packages in a chroot environment. And this remains only in my local branch for now. First, we need to make a small adjustment in the logic of choosing goals.
  23. going
    What do you want to say? Stop the execution of the build system and output the command line in the chroot environment? And provide the user with the ability to enter commands, install or remove packages, fix system scripts?
  24. going
    https://github.com/armbian/build/pull/4515 armbian-build/cache/sources/linux-mainline/6.0> ls arch/arm/boot/dts/*nanopi* arch/arm/boot/dts/sun8i-h2-plus-nanopi-duo.dts arch/arm/boot/dts/sun8i-h3-nanopi-m1.dts arch/arm/boot/dts/sun8i-h3-nanopi-neo.dts arch/arm/boot/dts/sun8i-h3-nanopi.dtsi arch/arm/boot/dts/sun8i-h3-nanopi-m1-plus.dts arch/arm/boot/dts/sun8i-h3-nanopi-r1.dts arch/arm/boot/dts/sun8i-h3-nanopi-duo2.dts arch/arm/boot/dts/sun8i-h3-nanopi-neo-air.dts
  25. going
    If you want to check the operation of the device, boot it from the memory card and check the file system on the soldered chip with the standard fsck utility. That's enough. But I think the reboot problem for bananapiM3 is related to the firmware of the controller and its interaction with the kernel. It's not related to the operating system at all. I have this device and I confirm the problem.
ร—
ร—
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept