April 2015 - Luv - Ml01.01.Org

Re: [Luv] Issues with unpacking LUV binary.

by Matt Fleming

(Corrected email address to LUV mailing list) Is it possible that the file system that you're extracting the LUV image onto doesn't understand UNIX uids? Examples of how to use the luv live images are available here, https://videoportal.intel.com/media/Linux+UEFI+Validation+for+Windows+Use... https://videoportal.intel.com/media/Linux+UEFI+Validation+for+Linux+Users... On Thu, 2015-04-09 at 23:00 +0000, Geer, Kenneth (EXL) wrote: > Hi, > > Is this a list were I can get help on this issus? > > > > We are trying to unpack the file luv-live-v1.2.tar.bz2 file. The > error I am getting is that it cannot change the ownership of either of > the files. > > > > > > 5439 [1m[31mfix_host:~ # [0;10mmount /dev/sdc1 /flash > > 5440 [1m[31mfix_host:~ # [0;10mcd /flash > > 5441 [1m[31mfix_host:/flash # [0;10mls > > 5442 [0m[00;32mluv-live-v1.2.tar.bz2[0m > > 5443 [1m[31mfix_host:/flash # [0;10mtar xvjf luv-live-v1.2.tar.bz2 > > 5444 luv-live-v1.2/ > > 5445 luv-live-v1.2/luv-live-v1.2.img > > 5446 tar: luv-live-v1.2/luv-live-v1.2.img: Cannot change ownership to > uid 1002, gid 1005: Operation not permitted > > 5447 luv-live-v1.2/README > > 5448 tar: luv-live-v1.2/README: Cannot change ownership to uid 1002, > gid 1005: Operation not permitted > > 5449 tar: luv-live-v1.2: Cannot change ownership to uid 1002, gid > 1005: Operation not permitted > > 5450 tar: Exiting with failure status due to previous errors > > 5451 [1m[31mfix_host:/flash # [0;10mll > > > > Beyond that, I am unsure how to run the luv-live-v1.2.img file that is > produced. I’m not sure if I am getting an error because of an > improper unpackaging of the file, or if I am doing something wrong > with my attempts to run the *.img file. > > > > Log File: > > http://fctest.fc.usa.hp.com/utils/viewfile.cgi?file=/mfwt/logs/mfwt/seale... > > > > 5614 [25;01HDirectory of: [1m[37m[40mFS0:\luv-live-v1.2[0m[37m[40m > > 5615 03/27/2015 16:13 <DIR> 512 [1m[34m[40m.[0m[37m[40m > > 5616 04/07/2015 21:18 <DIR> 0 [1m[34m[40m..[0m[37m[40m > > 5617 03/27/2015 16:13 85,492,224 luv-live-v1.2.img > > 5618 03/27/2015 15:17 786 README > > 5619 2 File(s) 85,493,010 bytes > > 5620 2 Dir(s) > > 5621 [25;01H[1m[33m[40mFS0:\luv-live-v1.2\> > [0m[37m[40m./luv-live-v1.2.img[25;41H > > 5622 '[1m[33m[40m./luv-live-v1.2.img[0m[37m[40m' is not recognized as > an internal or external command, operable program, or script file. > > 5623 [25;01H[1m[33m[40mFS0:\luv-live-v1.2\> > [0m[37m[40mluv-live-v1.2.img[25;39H > > 5624 Error reported: Unsupported > > 5625 [25;01H[1m[33m[40mFS0:\luv-live-v1.2\> > > > > > > > > Ken Geer SFW Quality Lead|Enterprise X86 Lab - Superdome and Integrity > Platforms | 916.748.0361 | ken.geer(a)hp.com > > “It's easier to take than to give. It's nobler to give than to take. > The thrill of taking lasts a day. The thrill of giving lasts a > lifetime.” ~ Joan Marques > > > >

6 years, 3 months

4
8
0 / 0

LUV-live usage on Apple hardware?

by Blibbet

Hi, First post to list. Unfortunately with a dumb end user question... Has anyone gotten latest LUV-live release (or a build from source) to work on recent models of Apple hardware, like a Macbook with Yosemite-ere OSX? I'm having problems getting anything to happen. rEFInd was broke by recent EFI changes in Apple platform, perhaps related?? And Apple EFI systems are lower version than most modern Win8 boxes, does LUV prsume the latter UEFI versions? The checksums on the downloaded image are good. I currently use a Fedora liveboot solution for CHIPSEC, and I am really wanting to start using LUV's liveboot solution and it's version of CHIPSEC. Any suggestions appreciated. Thanks, Lee PS: I notice ARM patches, exciting. Is there any effort to port CHIPSEC to ARM, along with LUV?? That would be very exciting. Thanks again.

6 years, 5 months

7
21
0 / 0

Re: [Luv] Issues with unpacking LUV binary.

by Seale, David (EXL/SETI)

Greetings, Kenneth Geer recently asked about using/running the LUV image. I was the person with the original question he was seeking an answer for. I tried following the links provided, but was unable to connect. I got the following errors: This webpage is not available ERR_TUNNEL_CONNECTION_FAILED Hide details The webpage athttps://videoportal.intel.com/media/Linux+UEFI+Validation+for+Windows+U... might be temporarily down or it may have moved permanently to a new web address. This webpage is not available ERR_TUNNEL_CONNECTION_FAILED Hide details The webpage athttps://videoportal.intel.com/media/Linux+UEFI+Validation+for+Linux+Use... might be temporarily down or it may have moved permanently to a new web address. Are there any other possible links that I might try to get additional information? Regards, David Seale (CFE-SETI) (916) 785-8766 (wk) (916) 765-5774 (cell) david.seale(a)hp.com -----Original Message----- From: Matt Fleming [mailto:matt.fleming@intel.com] Sent: Friday, April 10, 2015 4:34 PM To: Geer, Kenneth (EXL) Cc: luv(a)lists.01.org<mailto:luv@lists.01.org> Subject: Re: Issues with unpacking LUV binary. (Corrected email address to LUV mailing list) Is it possible that the file system that you're extracting the LUV image onto doesn't understand UNIX uids? Examples of how to use the luv live images are available here, https://videoportal.intel.com/media/Linux+UEFI+Validation+for+Windows+Use... https://videoportal.intel.com/media/Linux+UEFI+Validation+for+Linux+Users... On Thu, 2015-04-09 at 23:00 +0000, Geer, Kenneth (EXL) wrote: > Hi, > > Is this a list were I can get help on this issus? > > > > We are trying to unpack the file luv-live-v1.2.tar.bz2 file. The > error I am getting is that it cannot change the ownership of either of > the files. > > > > > > 5439 [1m[31mfix_host:~ # [0;10mmount /dev/sdc1 /flash > > 5440 [1m[31mfix_host:~ # [0;10mcd /flash > > 5441 [1m[31mfix_host:/flash # [0;10mls > > 5442 [0m[00;32mluv-live-v1.2.tar.bz2[0m > > 5443 [1m[31mfix_host:/flash # [0;10mtar xvjf luv-live-v1.2.tar.bz2 > > 5444 luv-live-v1.2/ > > 5445 luv-live-v1.2/luv-live-v1.2.img > > 5446 tar: luv-live-v1.2/luv-live-v1.2.img: Cannot change ownership to > uid 1002, gid 1005: Operation not permitted > > 5447 luv-live-v1.2/README > > 5448 tar: luv-live-v1.2/README: Cannot change ownership to uid 1002, > gid 1005: Operation not permitted > > 5449 tar: luv-live-v1.2: Cannot change ownership to uid 1002, gid > 1005: Operation not permitted > > 5450 tar: Exiting with failure status due to previous errors > > 5451 [1m[31mfix_host:/flash # [0;10mll > > > > Beyond that, I am unsure how to run the luv-live-v1.2.img file that is > produced. I’m not sure if I am getting an error because of an > improper unpackaging of the file, or if I am doing something wrong > with my attempts to run the *.img file. > > > > Log File: > > http://fctest.fc.usa.hp.com/utils/viewfile.cgi?file=/mfwt/logs/mfwt/se > ale_185/20150407_123448_Interact-GUI.pl/2_Console-OA-CLI-mifflin-oa.lo > g#5614 > > > > 5614 [25;01HDirectory of: [1m[37m[40mFS0:\luv-live-v1.2[0m[37m[40m > > 5615 03/27/2015 16:13 <DIR> 512 [1m[34m[40m.[0m[37m[40m > > 5616 04/07/2015 21:18 <DIR> 0 [1m[34m[40m..[0m[37m[40m > > 5617 03/27/2015 16:13 85,492,224 luv-live-v1.2.img > > 5618 03/27/2015 15:17 786 README > > 5619 2 File(s) 85,493,010 bytes > > 5620 2 Dir(s) > > 5621 [25;01H[1m[33m[40mFS0:\luv-live-v1.2\> > [0m[37m[40m./luv-live-v1.2.img[25;41H > > 5622 '[1m[33m[40m./luv-live-v1.2.img[0m[37m[40m' is not recognized as > an internal or external command, operable program, or script file. > > 5623 [25;01H[1m[33m[40mFS0:\luv-live-v1.2\> > [0m[37m[40mluv-live-v1.2.img[25;39H > > 5624 Error reported: Unsupported > > 5625 [25;01H[1m[33m[40mFS0:\luv-live-v1.2\> > > > > > > > > Ken Geer SFW Quality Lead|Enterprise X86 Lab - Superdome and Integrity > Platforms | 916.748.0361 | ken.geer(a)hp.com<mailto:ken.geer@hp.com> > > “It's easier to take than to give. It's nobler to give than to take. > The thrill of taking lasts a day. The thrill of giving lasts a > lifetime.” ~ Joan Marques > > > >

6 years, 6 months

6
5
0 / 0

[PATCH 0/3] Build luvOS natively on ARM64 server machines

by Naresh Bhat

Install Debian/Fedora/Ubuntu..etc any standard distribution on ARM64 machine. Along with pre-installed Yocto build dependency packages you can kick a build of luvOS natively on ARM64. These patches support to build the luvOS distribution natively on ARM64 machines. Kai Kang (1): libatomics-ops: add aarch64 target iniitial support Naresh Bhat (2): syslinux: Fix no buildable providers on AArch64 qemu: Add ovmf-native only on x86 meta-luv/recipes-devtools/qemu/qemu_2.1.0.bbappend | 3 +- meta/classes/syslinux.bbclass | 6 +- .../0001-libatomic_ops-Aarch64-basic-port.patch | 239 ++++++++++++++++++++ .../pulseaudio/libatomics-ops_7.2.bb | 1 + 4 files changed, 247 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-multimedia/pulseaudio/files/0001-libatomic_ops-Aarch64-basic-port.patch -- 1.7.9.5

6 years, 6 months

3
11
0 / 0

[PATCH] qemu: Add ovmf-native only on x86

by Naresh Bhat

The ovmf-native is required to run the qemu on x86 machine. We don't need this package on AArch64 architecture. Signed-off-by: Naresh Bhat <naresh.bhat(a)linaro.org> --- meta-luv/recipes-devtools/qemu/qemu_2.2.0.bbappend | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/meta-luv/recipes-devtools/qemu/qemu_2.2.0.bbappend b/meta-luv/recipes-devtools/qemu/qemu_2.2.0.bbappend index e4eec8c..03cfa9e 100644 --- a/meta-luv/recipes-devtools/qemu/qemu_2.2.0.bbappend +++ b/meta-luv/recipes-devtools/qemu/qemu_2.2.0.bbappend @@ -1 +1,2 @@ -DEPENDS_append_class-native = " ovmf-native" +DEPENDS_append_class-native_x86 = " ovmf-native" +DEPENDS_append_class-native_x86-64 = " ovmf-native" -- 1.7.9.5

6 years, 7 months

1
0
0 / 0

[PATCH v2] efivarfs: Preserve --sysroot in CC

by Matt Fleming

From: Matt Fleming <matt.fleming(a)intel.com> The efivarfs executables are currently being linked against the build machine's ld.so not the sysroot version, which means some of the efivarfs tests are failing at runtime. Follow the same route as the perf recipe and ensure we preserve --sysroot in ${CC}. We also don't need our own copy of the kernel tree in SRC_URI now that there's a shared kernel workdir. We do however need to depend on it before applying our patch. Finally, perform a 'make clean' in the efivarfs/ directory to ensure that we always rebuild the executables where necessary (if we're running do_configure() the build system obviously thinks a rebuild is necessary). Signed-off-by: Matt Fleming <matt.fleming(a)intel.com> --- Update from v1 is that we need to "clean" any existing executables in the kernel source when rebuilding. meta-luv/recipes-core/efivarfs/efivarfs-test.bb | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/meta-luv/recipes-core/efivarfs/efivarfs-test.bb b/meta-luv/recipes-core/efivarfs/efivarfs-test.bb index a0ba80b..4a78048 100644 --- a/meta-luv/recipes-core/efivarfs/efivarfs-test.bb +++ b/meta-luv/recipes-core/efivarfs/efivarfs-test.bb @@ -6,8 +6,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" KBRANCH="stable" # Picking up matts branch -SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git;protocol=g... \ - file://bash-to-sh.patch \ +SRC_URI = "file://bash-to-sh.patch \ file://luv-parser-efivarfs \ file://efivarfs" @@ -18,7 +17,7 @@ inherit autotools luv-test S = "${STAGING_KERNEL_DIR}" do_fetch[noexec] = "1" -do_configure[depends] += "virtual/kernel:do_shared_workdir" +do_patch[depends] += "virtual/kernel:do_shared_workdir" do_package[depends] += "virtual/kernel:do_populate_sysroot" EXTRA_OEMAKE = " \ @@ -28,6 +27,16 @@ EXTRA_OEMAKE = " \ #I am not sure why I am getting this FILES_${PN}-dbg += "/usr/share/efivarfs-test/.debug" +do_configure_prepend() { + # We need to ensure the --sysroot option in CC is preserved + if [ -e "${S}/tools/testing/selftests/efivarfs/Makefile" ]; then + sed -i 's,CC = $(CROSS_COMPILE)gcc,#CC,' ${S}/tools/testing/selftests/efivarfs/Makefile + fi + + # Fix for rebuilding + oe_runmake clean +} + #This is the compilation area #we need to compile the self tests do_compile() { -- 2.1.0

6 years, 7 months

2
1
0 / 0

[PATCH] efivarfs: Update SRC_URI for aarch64

by Naresh Bhat

efivarfs won't build because it can't find the kernel source for aarch64 ... .... WARNING: kernel-efi-warnings: the directory ${WORKDIR}/${BP} (../build/tmp/work/aarch64-oe-linux/kernel-efi-warnings/0.1-r0/kernel-efi-warnings-0.1) pointed to by the S variable doesn't exist - please set S within the recipe to point to where the source has been unpacked to ERROR: Function failed: Fetcher failure: Fetch command failed with exit code 128, output: fatal: repository '..build/downloads/git2/git.kernel.org.pub.scm.linux.kernel.git.mfleming.efi.git/' does not exist Signed-off-by: Naresh Bhat <naresh.bhat(a)linaro.org> --- meta-luv/recipes-core/efivarfs/efivarfs-test.bb | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/meta-luv/recipes-core/efivarfs/efivarfs-test.bb b/meta-luv/recipes-core/efivarfs/efivarfs-test.bb index a0ba80b..da75f19 100644 --- a/meta-luv/recipes-core/efivarfs/efivarfs-test.bb +++ b/meta-luv/recipes-core/efivarfs/efivarfs-test.bb @@ -6,8 +6,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" KBRANCH="stable" # Picking up matts branch -SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git;protocol=g... \ - file://bash-to-sh.patch \ +SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git;protocol=g..." +SRC_URI_aarch64 = "git://git.linaro.org/leg/acpi/leg-kernel.git;protocol=git;branch=leg-kernel" +SRC_URI += "file://bash-to-sh.patch \ file://luv-parser-efivarfs \ file://efivarfs" -- 1.7.9.5

6 years, 7 months

2
2
0 / 0

[PATCH] efivarfs: Preserve --sysroot in CC

by Matt Fleming

From: Matt Fleming <matt.fleming(a)intel.com> The efivarfs executables are currently being linked against the build machine's ld.so not the sysroot version, which means some of the efivarfs tests are failing at runtime. Follow the same route as the perf recipe and ensure we preserve --sysroot in ${CC}. We also don't need our own copy of the kernel tree in SRC_URI now that there's a shared kernel workdir. We do however need to depend on it before applying our patch. Signed-off-by: Matt Fleming <matt.fleming(a)intel.com> --- meta-luv/recipes-core/efivarfs/efivarfs-test.bb | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/meta-luv/recipes-core/efivarfs/efivarfs-test.bb b/meta-luv/recipes-core/efivarfs/efivarfs-test.bb index a0ba80b..41622e8 100644 --- a/meta-luv/recipes-core/efivarfs/efivarfs-test.bb +++ b/meta-luv/recipes-core/efivarfs/efivarfs-test.bb @@ -6,8 +6,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" KBRANCH="stable" # Picking up matts branch -SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git;protocol=g... \ - file://bash-to-sh.patch \ +SRC_URI = "file://bash-to-sh.patch \ file://luv-parser-efivarfs \ file://efivarfs" @@ -18,7 +17,7 @@ inherit autotools luv-test S = "${STAGING_KERNEL_DIR}" do_fetch[noexec] = "1" -do_configure[depends] += "virtual/kernel:do_shared_workdir" +do_patch[depends] += "virtual/kernel:do_shared_workdir" do_package[depends] += "virtual/kernel:do_populate_sysroot" EXTRA_OEMAKE = " \ @@ -28,6 +27,13 @@ EXTRA_OEMAKE = " \ #I am not sure why I am getting this FILES_${PN}-dbg += "/usr/share/efivarfs-test/.debug" +do_configure_prepend() { + # We need to ensure the --sysroot option in CC is preserved + if [ -e "${S}/tools/testing/selftests/efivarfs/Makefile" ]; then + sed -i 's,CC = $(CROSS_COMPILE)gcc,#CC,' ${S}/tools/testing/selftests/efivarfs/Makefile + fi +} + #This is the compilation area #we need to compile the self tests do_compile() { -- 2.1.0

6 years, 7 months

1
0
0 / 0

[PATCH] efivarfs: Update SRC_URI for aarch64

by Naresh Bhat

efivarfs won't build because it can't find the kernel source for aarch64 ... .... WARNING: kernel-efi-warnings: the directory ${WORKDIR}/${BP} (../build/tmp/work/aarch64-oe-linux/kernel-efi-warnings/0.1-r0/kernel-efi-warnings-0.1) pointed to by the S variable doesn't exist - please set S within the recipe to point to where the source has been unpacked to ERROR: Function failed: Fetcher failure: Fetch command failed with exit code 128, output: fatal: repository '..build/downloads/git2/git.kernel.org.pub.scm.linux.kernel.git.mfleming.efi.git/' does not exist Signed-off-by: Naresh Bhat <naresh.bhat(a)linaro.org> --- meta-luv/recipes-core/efivarfs/efivarfs-test.bb | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/meta-luv/recipes-core/efivarfs/efivarfs-test.bb b/meta-luv/recipes-core/efivarfs/efivarfs-test.bb index a0ba80b..8b87f23 100644 --- a/meta-luv/recipes-core/efivarfs/efivarfs-test.bb +++ b/meta-luv/recipes-core/efivarfs/efivarfs-test.bb @@ -6,8 +6,9 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7" KBRANCH="stable" # Picking up matts branch -SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git;protocol=g... \ - file://bash-to-sh.patch \ +SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/mfleming/efi.git;protocol=g..." +SRC_URI_aarch64 = "git://git.linaro.org/leg/acpi/leg-kernel.git;protocol=git;branch=leg-kernel" +SRC_URI = "file://bash-to-sh.patch \ file://luv-parser-efivarfs \ file://efivarfs" -- 1.7.9.5

6 years, 7 months

1
1
0 / 0

Resetting the luv-yocto master branch

by Matt Fleming

Folks, Based on the recent discussions we've had on this mailing list, https://lists.01.org/pipermail/luv/2015-January/000265.html and the pain points experienced in moving from Dora to Dizzy, I think it's best if we move to a release process that more closely matches upstream Yocto Project and OE-core, where we fork a branch every time a new release is created in upstream Yocto Project. So, once v1.2 drops (week of 23rd March) I plan on moving the 'master' branch of the luv-yocto repository to point at the 'master' branch of Poky. The benefits are discussed in the thread referenced above but mainly it allows us to pull new changes from upstream much sooner. What this will mean is that after the v1.2 tag is created you'll see something like the following when fetching updates, $ git fetch remote: Counting objects: 12698, done. remote: Compressing objects: 100% (2537/2537), done. remote: Total 10416 (delta 7720), reused 10409 (delta 7713) Receiving objects: 100% (10416/10416), 2.60 MiB | 0 bytes/s, done. Resolving deltas: 100% (7720/7720), completed with 879 local objects. From /home/foobar/luv-yocto + fd8d0b4...dda70ca master -> origin/master (forced update) and a git pull will fail with a whole bunch of conflicts, because git can't do a simple merge. If you don't have any changes on your master branch the easiest way to get upto date is to do, $ git reset --hard origin/master However, if you do have updates, before you do the reset you must save them either by creating patches or stashing your changes. Do not merge your old branches into the new master branch, the resulting history will be an abomination, and explicitly contradicts what I'm trying to do here - make it possible to merge upstream without causing huge amounts of conflicts. The old tip of the master branch will always be accessible with the 'v1.2' tag, so it's not like the history is going to be lost in any way. Let me know if you have any questions. -- Matt Fleming, Intel Open Source Technology Center

6 years, 7 months

1
1
0 / 0

2021

2020

2019

2018

2017

2016

2015

2014

Luv April 2015