borsti67 Posted June 17, 2016 Posted June 17, 2016 Hi, after some days with other projects I have updated to newest master and now see this message during installation: [ o.k. ] Installing extra applications and drivers [ o.k. ] Installing linux firmware [ 5.14 ] dpkg: error processing archive /tmp/armbian-firmware_5.14_all.deb (--install): cannot access archive: No such file or directory Errors were encountered while processing: /tmp/armbian-firmware_5.14_all.deb [ o.k. ] Installing [ armbian-hostapd-jessie_5.14_armhf.deb ] invoke-rc.d: policy-rc.d denied execution of stop. dpkg: error processing archive /tmp/armbian-hostapd-jessie_5.14_armhf.deb (--install): cannot access archive: No such file or directory Errors were encountered while processing: /tmp/armbian-hostapd-jessie_5.14_armhf.deb These errors are NOT mentioned in install.log or output.log! It looks like these lines are coming from extras/firmware.sh. May be the last line should be appended with "2>&1" to catch such issues? But I was unable to find out yet why the .deb cannot be found. It is created and has the correct name in output/debs. Have there been changes to the order of processing? It looks like the "mount --bind" to /tmp is no longer (or not yet?) active...
zador.blood.stained Posted June 17, 2016 Posted June 17, 2016 What build settings do you use? EXTENDED_DEBOOTSTRAP=no by any chance? It looks like these lines are coming from extras/firmware.sh.May be the last line should be appended with "2>&1" to catch such issues? These errors are easier to catch on the screen than in build log since there is no error handling
borsti67 Posted June 17, 2016 Author Posted June 17, 2016 Hi Zador, these are my settings: BRANCH="default" RELEASE="jessie" BUILD_DESKTOP="yes" PROGRESS_DISPLAY="plain" PROGRESS_LOG_TO_FILE="yes" FORCE_USE_RAMDISK="no" FIXED_IMAGE_SIZE=12000 KERNEL_ONLY="no" KERNEL_CONFIGURE="no" CLEAN_LEVEL="debs" KERNEL_KEEP_CONFIG="no" EXTERNAL="yes" FORCE_CHECKOUT="yes" BUILD_ALL="no" I haven't changed these for quite a long time, didn't have this issue before.These errors are easier to catch on the screen than in build log since there is no error handlingI don't think so for 2 reasons:there is a lot of stuff rolling by, depending on processor power a build can take several hours where I don't believe anyone is staring at the monitor all of the time at least if I have set the log file option I expect to see EVERYTHING there, especially things which went wrong If an error occurs which does not break the script (like this one) the build will finish nicely but by chance the image will not work. You will not be able to see why, even if you turn on logging!I haven't checked what "output.log" is used for otherwise (or if it is overwritten halfways), it was always very small in my case. So I recommend redirecting error output into the log file as it won't hurt but can be helpful. Not sure what exactly these 2 debs are required for but some error handling (at least logging a warning) sounds reasonable to me?
zador.blood.stained Posted June 17, 2016 Posted June 17, 2016 BUILD_DESKTOP="yes" Desktop code wasn't updated to latest changes yet. Hope this fixes it for now. I don't think so for 2 reasons: there is a lot of stuff rolling by, depending on processor power a build can take several hours where I don't believe anyone is staring at the monitor all of the time at least if I have set the log file option I expect to see EVERYTHING there, especially things which went wrong If an error occurs which does not break the script (like this one) the build will finish nicely but by chance the image will not work. You will not be able to see why, even if you turn on logging!I haven't checked what "output.log" is used for otherwise (or if it is overwritten halfways), it was always very small in my case. So I recommend redirecting error output into the log file as it won't hurt but can be helpful. I agree that everything should go into the logs, but IMO stderr output of package installation should go both to log and console, so you can find regressions with PROGRESS_DISPLAY=none BUILD_ALL=yes without looking through dozens of compressed log files 1
borsti67 Posted June 17, 2016 Author Posted June 17, 2016 Desktop code wasn't updated to latest changes yet. Hope this fixes it for now.Will check it out immediately, thanks! I agree that everything should go into the logs, but IMO stderr output of package installation should go both to log and consoleYou're absolutely right. My proposal would indeed suppress any output to screen, so it should be done with "tee", shouldn't it? At least I saw this in other parts of the script.
borsti67 Posted June 17, 2016 Author Posted June 17, 2016 unfortunately I noticed now that my QT installation script now fails. This error follows the one above, I assume the building order was changed? QT depends on headers which are installed as a part of the sunxi display driver, which now comes after "extra drivers and applications"... Was there a special reason to change that or could it be reverted easily?
zador.blood.stained Posted June 17, 2016 Posted June 17, 2016 Build order was changed to handle /tmp binding in chroot, since desktop installation script needs to bind another directory to /tmp If you put your QT installation script in "extras" directory - then order is definitely changed and it probably won't work (it was never intended to use this stage for user-provided scripts), but if you are calling your script from customize-image.sh and you get an error, then it's possible that another bug was introduced by changing build order.
borsti67 Posted June 17, 2016 Author Posted June 17, 2016 I see. So user scripts should be included to customize-image.sh (only)? The problem there is that it's executed within chroot while I make use of e.g. fetch-from-github to have a local cache. Probably I can solve this issue for the moment by splitting prerequisites (caching etc) from execution (configure/build). Or is it also wrong? What is your recommendation to handle such cases?
zador.blood.stained Posted June 17, 2016 Posted June 17, 2016 Hm. It's easy to "enhance" customize-image.sh so it has part executed at host, but it's hard to do it without breaking backwards compatibility.... If you need working build script now, you can rollback to previous version i.e. by setting LIB_TAG="v2016.06" in compile.sh I'll think later about the best way to solve this...
borsti67 Posted June 18, 2016 Author Posted June 18, 2016 May be I have a solution (I will implement it this way, feel free to adapt if you consider it useful): diff --git a/common.sh b/common.sh index 31a8b68..4f439d6 100644 --- a/common.sh +++ b/common.sh @@ -374,6 +374,8 @@ write_uboot() customize_image() { + display_alert "Calling user defined script" "userscript.sh" "info" + source $SRC/userpatches/userscript.sh cp $SRC/userpatches/customize-image.sh $CACHEDIR/sdcard/tmp/customize-image.sh chmod +x $CACHEDIR/sdcard/tmp/customize-image.sh mkdir -p $CACHEDIR/sdcard/tmp/overlay diff --git a/general.sh b/general.sh index aa88eb5..a30ab01 100644 --- a/general.sh +++ b/general.sh @@ -403,6 +403,8 @@ prepare_host() { [[ ! -f $SRC/userpatches/customize-image.sh ]] && cp $SRC/lib/scripts/customize-image.sh.template $SRC/userpatches/customize-image.sh + [[ ! -f $SRC/userpatches/userscript.sh ]] && cp $SRC/lib/scripts/userscript.sh.template $SRC/userpatches/userscript.sh + if [[ ! -f $SRC/userpatches/README ]]; then rm $SRC/userpatches/readme.txt echo 'Please read documentation about customizing build configuration' > $SRC/userpatches/README plus this new file (scripts/userscript.sh.template): #!/bin/bash # this script will be executed before chrooted customize-image.sh is called (git does not show new files in "git diff"?)
zador.blood.stained Posted June 18, 2016 Posted June 18, 2016 If you just want to store files between compilations to implement caching, you can keep them in /tmp/overlay in chroot (which is bind mounted to userpatches/overlay before calling customize-image.sh). You won't have acces to functions like fetch_from_github, but it shouldn't be hard to implement simple Git update logic
borsti67 Posted June 18, 2016 Author Posted June 18, 2016 My project is also a git "around" Armbian. - I found it a little uncomfortable to store this kind of data there as I would either copy it into my git repo or need some .gitignore(s). I fiddled with it but it was no fun as I'm experimenting a lot and so it got messed up quite often. I wanted to keep it clean so I prefer to only put somewhat "static" scripts and .deb files there. 1
borsti67 Posted June 18, 2016 Author Posted June 18, 2016 yes indeed. I have my script renamed accordingly. Anyway I recommend to add a template for this file as I mentioned in the patch above (and eventually show a message before invocation in case the script has a long runtime)? At the moment I see some "mount" related errors (something about du and busy, later (but before the customization script) about umount .../tmp not mounted. Unfortunately it's not in the logs and screen has passed by, so I need to check it another time. BTW: Do you have a recommendation how to efficiently manage logging while in the chroot?
Recommended Posts