Re: Gatesgarth-24.0.4 image-live fails

Ferry Toth

Op 25-05-2021 om 22:13 schreef Guillaume Champagne:
Le mar. 25 mai 2021 à 12:25, Ferry Toth <fntoth@...> a écrit :

Op 25-05-2021 om 15:09 schreef Guillaume Champagne:
Le mar. 25 mai 2021 à 08:19, Ferry Toth <fntoth@...> a écrit :
Adding Richard and Guillaume.

it seems seems sets ROOTFS as empty:

so do_bootimg won't depend on ${PN}:do_image:${LIVE_ROOTFS_TYPE}. That
dependency would, I think, create the folder you mentioned.

Maybe the patch wrongly assumes that if ROOTFS is empty, we shouldn't
add a dependency on "do_image.${LIVE_ROOTFS_TYPE}" at all since It
looks like still depends on
${PN}:do_image.${LIVE_ROOTFS_TYPE} even though ROOTFS is empty. I
haven't looked too much into why edison-image works this way.
It may well be a bug in meta-intel-edison. Although you are looking at
the very, very old code.

So what we have now is:

this generates a dir edison-image-1.0/hddimg/ containing: bzImage
initrd ldlinux.sys libcom32.c32 libutil.c32 syslinux.cfg vesamenu.c32

and this should generate in dir deploy-edison-image-image-complete/ a
file called edison-image-edison.hddimg

which it does without the patch. So would would I set rootfs to to make
it work?
That's my bad. The initial patch is not right. I could reproduce your
issue on my side. I think ROOTFS should be able to remain empty if
your image does all its work in its initd/initramfs.

I think IMGDEPLOYDIR isn't created in time because the patch removes
the "depends" on "do_image -> do_rootfs" , which would create
IMGDEPLOYDIR via do_rootfs[cleandirs] before do_bootimg runs:

One way I could think of to fix:

diff --git a/meta/classes/image-live.bbclass b/meta/classes/image-live.bbclass
index e9eba1fc4b..eb92573488 100644
--- a/meta/classes/image-live.bbclass
+++ b/meta/classes/image-live.bbclass
@@ -260,5 +260,6 @@ python do_bootimg() {
do_bootimg[subimages] = "hddimg iso"
do_bootimg[imgsuffix] = "."
+do_bootimg[dirs] = "${IMGDEPLOYDIR} ${TOPDIR}"

_AND_ to add to my image recipe:
BUILD_REPRODUCIBLE_BINARIES = "0" # otherwise image.bbclass looks for
a the image's rootfs
deltask rootfs

I am not sure this is the right solution. There might be a way to
avoid adding a "deltask" in my recipe. And image.bbclass could
probably avoid its BUILD_REPRODUCIBLE_BINARIES check on the rootfs if
ROOTFS is empty.
Maybe someone else has a better solution?
Thanks. For some reason I don't see your message appearing on ML.
BTW It also generates a directory iso and associated iso image. Never
understood why, we also set NOISO = "1"
NOISO is valid in Yocto releases before 2.6 (thud):
Setting IMAGE_FSTYPES = "hddimg" should be the new equivalent of what does with NOISO="1" and NOHDD="0"

I think setting INITRD_IMAGE_LIVE to core-image-minimal-initramfs
could also replace the custom post process command "install_initrd".
I'll look into that.
Op 24-05-2021 om 14:39 schreef Ferry Toth:
Wow, that got messed up, let me retry.

Op 24-05-2021 om 14:19 schreef Ferry Toth:
Accidentally I refreshed poky and rebuilt. The image-live
(do_bootimg) fails when building hddimg with the following:
ERROR: edison-image-1.0-r0 do_bootimg: Error executing a python
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this
exception/failure was:
File: 'exec_python_func() autogenerated', lineno: 2, function: <module>
*** 0002:do_bootimg(d)
lineno: 258, function: do_bootimg
0254: if d.getVar("PCBIOS") == "1":
0255:'build_syslinux_cfg', d)
0256: if d.getVar("EFI") == "1":
0257:'build_efi_cfg', d)
*** 0258:'build_hddimg', d)
0259:'build_iso', d)
0260:'create_symlinks', d)
0262:do_bootimg[subimages] = "hddimg iso"
lineno: 256, function: exec_func
0252: with bb.utils.fileslocked(lockfiles):
0253: if ispython:
0254: exec_func_python(func, d, runfile, cwd=adir)
0255: else:
*** 0256: exec_func_shell(func, d, runfile, cwd=adir)
0258: try:
0259: curcwd = os.getcwd()
0260: except:
lineno: 503, function: exec_func_shell
0499: with open(fifopath, 'r+b', buffering=0) as fifo:
0500: try:
0501: bb.debug(2, "Executing shell function %s" % func)
0502: with open(os.devnull, 'r+') as stdin, logfile:
*** 0503:, shell=False,
stdin=stdin, log=logfile, extrafiles=[(fifo,readfifo)])
0504: except bb.process.ExecutionError as exe:
0505: # Find the backtrace that the shell trap generated
0506: backtrace_marker_regex = re.compile(r"WARNING:
Backtrace \(BB generated script\)")
0507: stdout_lines = (exe.stdout or "").split("\n")
lineno: 184, function: run
0180: if not stderr is None:
0181: stderr = stderr.decode("utf-8")
0183: if pipe.returncode != 0:
*** 0184: raise ExecutionError(cmd, pipe.returncode, stdout,
0185: return stdout, stderr
Exception: bb.process.ExecutionError: Execution of
failed with exit code 1:
mkdosfs: unable to create
mkfs.fat 4.1 (2017-01-24)
WARNING: exit code 1 from a shell command.

The reason is that the directory deploy-edison-image-image-complete
doesn't exist at the time mkdosfs want to write. However after
completing the remainder of image live the directory does exists.
Consequently, running bitbake a second time image-live succeeds.

I've tried various thing including expressly creating the directory
before mkdosfs, but nothing worked. It seems I don't understand how
it is supposed to work in the first place.

However, I managed to trace back the issue to this commit 91e4a1c1
"image-live.bbclass: optional depends when ROOTFS empty".

Reverting this resolves the issue.

Any idea what could be wrong?

Join { to automatically receive all group messages.