Jump to content

Issue with installation of firmware


borsti67

Recommended Posts

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...

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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 handling

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 B)
  • 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?

Link to comment
Share on other sites

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 B)
  • 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

Link to comment
Share on other sites

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 console

You'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.
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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...

Link to comment
Share on other sites

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"?)

Link to comment
Share on other sites

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

Link to comment
Share on other sites

My project is also a git "around" Armbian. :D - 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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines