Re: [yocto] [bitbake-devel] Add custom user to custom group in bitbake recipe

[Khem Raj]

On 3/2/18 3:36 AM, Parthiban Nallathambi wrote:
> Hello All,
> 
> I have created a custom group e.g "grp1" in my application recipe say
> "app.bb".
> 
> GROUPADD_PARAM_${PN} = "grp1"
> 
> I am trying to add my custom user e.g: "user1" to this group "grp1" in
> "space.bb".
> 
> USERADD_PARAM_${PN} = "-d ${localstatedir}/lib/space/ -s /bin/false -G
> grp1 -U user1"
> 
> The useradd command failed: "useradd: group 'grp1' does not exist". I
> have also tried adding DEPENDS_${PN} = "app" in space.bb, but it doesn't
> help.

ensure that the package adding group is also part of final image. For
that you might use something like

RDEPENDS_${PN} += "app"

in the recipe which is adding the user

> 
> How can I add my custom user to my custom group in bitbake recipe?
> 
> Question in Stackoverflow:
> https://stackoverflow.com/questions/49068076/yocto-add-custom-user-to-custom-group
> 
> 

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Adding Gnome to X11

[Khem Raj]

On 3/2/18 2:29 AM, Q. Gouès wrote:
> Actually the problem didn't come from doing IMAGE_INSTALL +=.
> 
> The problem came from the fact that in my recipe, I was adding the
> "IMAGE_INSTALL +=" line before the "inherit core-image" in which
> IMAGE_INSTALL is defined as a ?=. By doing that, the packages defined in
> the core-image class are not added because the variable IMAGE_INSTALL
> already exists.
> 
> Adding the "IMAGE_INSTALL +=" line after "inherit core-image" solved the
> problem.
> 
> I decided to use xfce as GUI because a recipe for the whole package
> exists (packagegroup-xfce-base).
> 

If you are inheriting core-image, its probably better for you to use
CORE_IMAGE_EXTRA_INSTALL to add packages to such image instead of
changing IMAGE_INSTALL directly.

see
http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#var-CORE_IMAGE_EXTRA_INSTALL


> Thanks for your help
> 
> *Quentin Gouès*
> Ingénieur Développement Logiciel
> 
> *ACTIA* PCs
> 14, rue Charles Martigny
> 94700 MAISONS ALFORT (FRANCE)
> Tel. +33 (0)1 42 07 18 00 - Fax +33 (0)1 42 07 85 55
> http://www.actia-pcs.fr 
> 
> Le 28/02/2018 à 17:17, Burton, Ross a écrit :
>> Because by doing IMAGE_INSTALL += you wiped out the default value
>> which is a ?=.
>>
>> gnome-desktop3 isn't the GNOME interface though, it's just a small
>> library.
>>
>> If you want the full GNOME 3 desktop then you'll need to start with
>> meta-gnome and write more recipes, as it's not entirely packaged.
>>
>> Ross
>>
>> On 28 February 2018 at 14:10, Q. Gouès > > wrote:
>>
>> Hi,
>>
>> I am trying to add gnome to my x11 image based on the recipe
>> core-image-x11. I am using Poky 2.0 (Jethro).
>>
>> For that, I added the following line to my recipe:
>>
>> /IMAGE_INSTALL += "gnome-desktop3"/
>>
>> Unfortunately I get the following error:
>>
>> /switch_root: can't execute '/sbin/init': No such file or directory//
>> //Kernel panic - not syncing: Attempted to kill init!
>> exitcode=0x0100/
>>
>> I tried the same thing with XFCE (I am trying to add a window
>> manager to my image) and I got the same results.
>>
>> After taking a look at the rootfs in the iso file, I can notice
>> that the file '/sbin/init' is indeed missing. And it's not the
>> only file missing ! The rootfs went from ~420Mo to ~220Mo and the
>> list of files present in the rootfs went from:
>>
>> /badblocks//
>> //blkid -> /bin/busybox.nosuid//
>> //bootlogd//
>> //debugfs//
>> //depmod -> /sbin/depmod.kmod//
>> //depmod.kmod -> ../bin/kmod//
>> //dumpe2fs//
>> //e2freefrag//
>> //e2fsck//
>> //e2image//
>> //e2undo//
>> //e4defrag//
>> //fdisk -> /bin/busybox.nosuid//
>> //filefrag//
>> //fsck -> /bin/busybox.nosuid//
>> //fsck.ext2//
>> //fsck.ext3//
>> //fsck.ext4//
>> //fsck.ext4dev//
>> //fstab-decode//
>> //fstrim -> /bin/busybox.nosuid//
>> //getty -> /bin/busybox.nosuid//
>> //halt -> /sbin/halt.sysvinit//
>> //halt.sysvinit//
>> //hdparm -> /sbin/hdparm.hdparm//
>> //hdparm.hdparm//
>> //hwclock -> /bin/busybox.nosuid//
>> //ifconfig -> /bin/busybox.nosuid//
>> //ifdown -> /bin/busybox.nosuid//
>> //ifup -> /bin/busybox.nosuid//
>> //init -> /sbin/init.sysvinit//
>> //init.sysvinit//
>> //insmod -> /sbin/insmod.kmod//
>> //insmod.kmod -> ../bin/kmod//
>> //ip -> /bin/busybox.nosuid//
>> //iwconfig//
>> //iwgetid -> iwconfig//
>> //iwlist -> iwconfig//
>> //iwpriv -> iwconfig//
>> //iwspy -> iwconfig//
>> //killall5//
>> //klogd -> /bin/busybox.nosuid//
>> //ldconfig//
>> //loadkmap -> /bin/busybox.nosuid//
>> //logread -> /bin/busybox.nosuid//
>> //logsave//
>> //losetup -> /bin/busybox.nosuid//
>> //lsmod -> /bin/lsmod.kmod//
>> //mke2fs//
>> //mkfs.ext2//
>> //mkfs.ext3//
>> //mkfs.ext4//
>> //mkfs.ext4dev//
>> //mklost+found//
>> //mkswap -> /bin/busybox.nosuid//
>> //modinfo -> /sbin/modinfo.kmod//
>> //modinfo.kmod -> ../bin/kmod//
>> //modprobe -> /sbin/modprobe.kmod//
>> //modprobe.kmod -> ../bin/kmod//
>> //nologin//
>> //pivot_root -> /bin/busybox.nosuid//
>> //populate-extfs.sh//
>> //poweroff -> /sbin/poweroff.sysvinit//
>> //poweroff.sysvinit -> halt.sysvinit//
>> //reboot -> /sbin/reboot.sysvinit//
>> //reboot.sysvinit -> halt.sysvinit//
>> //rmmod -> /sbin/rmmod.kmod//
>> //rmmod.kmod -> ../bin/kmod//
>> //route -> /bin/busybox.nosuid//
>> //runlevel -> /sbin/runlevel.sysvinit//
>> //runlevel.sysvinit//
>> //setconsole -> /bin/busybox.nosuid//
>> //shutdown -> /sbin/shutdown.sysvinit//
>> //shutdown.sysvinit//
>> //start-stop-daemon -> /bin/busybox.nosuid//
>> //sulogin -> /sbin/sulogin.util-linux//
>> //sulogin.util-linux//
>>   

[linux-yocto] [PATCH 052/269] arch/arm: arm changes to support the axxia BSP

[Daniel Dragomir]

From: Charlie Paul 

These files were changed to support the LSI axxia 5500 board.

Signed-off-by: Charlie Paul 
Signed-off-by: John Jacques 
---
 arch/arm/Kconfig  | 84 ++-
 arch/arm/Kconfig.debug|  4 ++
 arch/arm/Makefile |  2 +-
 arch/arm/include/asm/kmap_types.h |  5 +++
 arch/arm/include/asm/spinlock.h   |  6 +++
 arch/arm/kernel/head.S|  8 
 arch/arm/kernel/irq.c |  2 +-
 arch/arm/kernel/perf_event_v7.c   |  3 +-
 arch/arm/tools/mach-types |  1 +
 9 files changed, 111 insertions(+), 4 deletions(-)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index c0fcab6..0f6c9e0 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -359,6 +359,29 @@ config ARM_SINGLE_ARMV7M
select SPARSE_IRQ
select USE_OF
 
+config ARCH_AXXIA
+   bool "LSI Axxia family"
+   select ARCH_PHYS_ADDR_T_64BIT
+   select ARCH_DMA_ADDR_T_64BIT
+   select ARCH_WANT_OPTIONAL_GPIOLIB
+   select ARM_AMBA
+   select COMMON_CLK
+   select CLKDEV_LOOKUP
+   select CLKSRC_MMIO
+   select GENERIC_CLOCKEVENTS
+   select HAVE_CLK
+   select HAVE_PATA_PLATFORM
+   select ARM_TIMER_SP804
+   select ICST
+   select NEED_MACH_IO_H
+   select ZONE_DMA
+   select PCI
+   select PCI_DOMAINS if PCI
+   select ARCH_SUPPORTS_MSI if PCI
+   select HAS_RAPIDIO
+   help
+ This enables support for the LSI Axxia boards.
+
 config ARCH_EBSA110
bool "EBSA-110"
select ARCH_USES_GETTIMEOFFSET
@@ -839,6 +862,8 @@ source "arch/arm/mach-ux500/Kconfig"
 
 source "arch/arm/mach-versatile/Kconfig"
 
+source "arch/arm/mach-axxia/Kconfig"
+
 source "arch/arm/mach-vexpress/Kconfig"
 source "arch/arm/plat-versatile/Kconfig"
 
@@ -1268,6 +1293,19 @@ source "drivers/pci/Kconfig"
 
 source "drivers/pcmcia/Kconfig"
 
+config HAS_RAPIDIO
+   bool
+   default n
+
+config RAPIDIO
+   bool "RapidIO support"
+   depends on HAS_RAPIDIO || PCI
+   help
+  If you say Y here, the kernel will include drivers and
+  infrastructure code to support RapidIO interconnect devices.
+
+source "drivers/rapidio/Kconfig"
+
 endmenu
 
 menu "Kernel Features"
@@ -1438,12 +1476,46 @@ config NR_CPUS
depends on SMP
default "4"
 
+menu "Support for hot-pluggable CPUs"
+
 config HOTPLUG_CPU
bool "Support for hot-pluggable CPUs"
-   depends on SMP
+   depends on SMP && HOTPLUG
help
  Say Y here to experiment with turning CPUs off and on.  CPUs
  can be controlled through /sys/devices/system/cpu.
+choice
+   prompt "CPU Power Down Mode"
+   default HOTPLUG_CPU_COMPLETE_POWER_DOWN
+   help
+   This is used to select how the CPU is going to be powered down. 
If LOW POWER
+   is selected then the CPU enters a WFI state and waits for an 
interrupt to
+   wake up. If COMPLETE POWER down is selected the CPU power is 
turned off. The only
+   way to power on the CPU is to execute a command.
+
+config HOTPLUG_CPU_COMPLETE_POWER_DOWN
+   bool "Power off the CPU"
+   help
+   This will power off the CPU completely. The irqs are migrated
+   to another CPU.
+
+config HOTPLUG_CPU_LOW_POWER
+   bool "Low Power CPU (wfi)"
+   help
+   This will put the CPU into a low power mode wfi mode. When an 
interrupt
+   is received the CPU will power on again.
+
+endchoice
+
+config HOTPLUG_CPU_L2_POWER_DOWN
+   bool "Power Off L2 Cache"
+   depends on HOTPLUG_CPU_COMPLETE_POWER_DOWN
+   default n if HOTPLUG_CPU_LOW_POWER
+   help
+   Select this if you want to power down the L2 cache when
+   all CPUS of a cluster have been powered off.
+
+endmenu
 
 config ARM_PSCI
bool "Support for the ARM Power State Coordination Interface (PSCI)"
@@ -1456,6 +1528,16 @@ config ARM_PSCI
  0022A ("Power State Coordination Interface System Software on
  ARM processors").
 
+config LOCAL_TIMERS
+   bool "Use local timer interrupts"
+   depends on SMP
+   default y
+   help
+ Enable support for local timers on SMP platforms, rather then the
+ legacy IPI broadcast method.  Local timers allows the system
+ accounting to be spread across the timer interval, preventing a
+ "thundering herd" at every timer tick.
+
 # The GPIO number here must be sorted by descending number. In case of
 # a multiplatform kernel, we just want the highest value required by the
 # selected platforms.
diff --git a/arch/arm/Kconfig.debug b/arch/arm/Kconfig.debug
index 426d271..4f58e22 100644
--- a/arch/arm/Kconfig.debug
+++ b/arch/arm/Kconfig.debug
@@ -145,6 +145,10 @@ choice
  Say Y here if you want kernel low-level 

[linux-yocto] [PATCH 077/269] kernel/irq/manage.c: Fix irq_set_affinity to allow use with buslocks

[Daniel Dragomir]

From: David Mercado 

Modify irq_set_affinity() to allow usage of bus locks with "slow bus" IRQ
controllers.  This only affects those BSPs that use bus locks in their IRQ
controllers, such as the LSI Axxia GIC.  The recommendation for this
change originated from Thomax Gleixner at Linutronix.

Signed-off-by: David Mercado 
---
 kernel/irq/manage.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 425170d..ff0 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -244,16 +244,16 @@ int irq_set_affinity_locked(struct irq_data *data, const 
struct cpumask *mask,
 
 int __irq_set_affinity(unsigned int irq, const struct cpumask *mask, bool 
force)
 {
-   struct irq_desc *desc = irq_to_desc(irq);
unsigned long flags;
+   struct irq_desc *desc = irq_get_desc_buslock(irq, ,
+   IRQ_GET_DESC_CHECK_GLOBAL);
int ret;
 
if (!desc)
return -EINVAL;
 
-   raw_spin_lock_irqsave(>lock, flags);
ret = irq_set_affinity_locked(irq_desc_get_irq_data(desc), mask, force);
-   raw_spin_unlock_irqrestore(>lock, flags);
+   irq_put_desc_busunlock(desc, flags);
return ret;
 }
 
-- 
2.7.4

-- 
___
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto

[linux-yocto] [PULL REQUEST v2] Intel Axxia updates to linux-yocto-4.12

[Daniel Dragomir]

Hello Bruce and Paul!

I made a cleanup on the first series of patches as you sugested, but need
your opinion on this v2 series.

For some patches, I spoke with the authors about the need of the changes
since some are beyond my knowledge. I didn't send all 269 patches to the
mailing list, but only some for review:

- without the change in kernel/irq/manage.c the 5500 board (axxiaarm bsp)
  will not boot (details in commit log)

- some changes in arch/arm/kernel required to support axxia 5500 board

- fs/vmfs: Adding arm vmfs file system
  Virtual file system originally available from ARM, deprecated and not 
supported,
  but still needed for Axxia5500 simulator.

I checked all the patches with checkpatch.pl script and fixed all errors.
Also, I compiled Axxia BSP using both branches and successfully booted the
Victoria (axxiaarm64) and Amarillo (axxiaarm) boards.

Please pull the patches from
https://github.com/axxia/axxia_yocto_linux_4.12_pull.git
into
git://git.yoctoproject.org/linux-yocto-4.12

Pull
standard/axxia/base-1.1v2 -> standard/axxia/base
standard/preempt-rt/axxia/base-1.1v2 -> standard/preempt-rt/axxia/base

If you add more patches to standard/(preempt-rt)/axxia/base beforehand
please notify me. I will rebase our changes so you can do a clean,
fast-forward pull.

Thank you,
Daniel Dragomir

Anders Berg (14):
  arm64: dts: Add initial AXM56xx device tree
  arm64: Add Axxia NEMAC Gigabit Ethernet controller
  arm64: dts: Corrected SPI definitions for AXM56xx
  arm64: dts: Added SPI and flash for AXM56xx sim
  arm64: dts: Add VMFS node for simulation DT
  net: ethernet: Enable Axxia FEMAC driver
  arm64: dts: Add device tree for AXC67xx (Lionfish)
  arm64: dts: Fixed bad VMFS reg property
  net: ethernet: Add MDIO driver for LSI AXM55xx
  net: ethernet: Add driver for FEMAC on AXM55xx
  drivers: net: Add Axxia NEMAC driver
  arm64: dts: Add NEMAC device nodes
  net: nemac: Fix crash when using NEMAC from bootloader
  misc: lsi-ncr: Only use AMP lock on PPC platforms.

Charlie Paul (43):
  fs/vmfs: Adding arm vmfs file system
  i2c: Support for i2c to the LSI axxia 5500 board
  drivers/dma: Updated to support Axxia dma
  arch/arm/boot/dts: Files added to support axxia 5500 board
  arch/arm/boot: Changes to support the axxia BSP
  arch/arm/mach-axxia: kernel files to support the mach-axxia
  arch/arm: arm changes to support the axxia BSP
  misc: Changes made to support axxia BSP
  drivers/mtd: Changes to support the axxia BSP
  drivers/net/ethernet: Changes to support the axxia BSP
  drivers/rapidio/devices: Changes to support axxia BSP
  drivers/spi: Changes to support the axxia BSP
  drivers/tty: Changes to support the axxia BSP
  drivers/usb/host: Changes to support the axxia BSP
  arch/arm/mach-axxia: Removed axxia_circular_queue
  arch/arm/mach-axxia: fixed compiler warning
  arch/arm/mach-axxia: fixed NO SMP
  arch/arm/mach-axxia: changed affinity parameter to cpu
  arch/arm/mach-axxia: Reverse checkpatch compatibility
  arch/arm/mach-axxia: Fixed L2 power up failure
  arch/arm/axxia: Remove the axxia zImage.fm build
  drivers/ethernet/lsi: Fixed code to support 4.1
  arm/mach-axxia: Updated to support linux 4.1
  drivers/misc: Updated to support linux 4.1
  drivers/rapidio: Update to support linux 4.9
  drivers/pci: updated to support axxia for 4.9
  drivers/net: Updated to support axxia on 4.9
  driver/net/ethernet: Updated to support axxia on 4.9
  drivers/misc: Updated to support axxia on 4.9
  drivers/i2c/busses: Updated to support axxia on 4.9
  arch/arm/mach-axxia: Updated to support 4.9 on the 5500
  i2c/busses: Updated to support 4.9 on the 5500
  drivers/net: Updated to support 4.9 on the 5500
  boot/dts/axxia: Updated to support 4.9 on the 5500
  arm/mach-axxia: allow interupts (16-32) set to LOW
  drivers/usb/core: fix over-current race condition
  drivers/usb/dwc3: Initialize dma for axxia dwc3
  drivers/misc: Add Fault Handling for Axxia
  drivers/edac: Added axxia edac
  drivers/gpio: updated to support axxia gpio
  drivers/net/ethernet: updated nemac for compile
  drivers/usb/dwc3: updated to compile usb dwc3
  linux/amba: added support for pl061.h

Daniel Dragomir (1):
  tools/perf: Correct the hexa value 0x1ULL from opencsd

David Mercado (1):
  kernel/irq/manage.c: Fix irq_set_affinity to allow use with buslocks

Fredrik Markstrom (1):
  usb ehci-ci13612: Enable HCD_BH mode in ci13612

Gary McGee (9):
  mach-axxia: Make AXXIA_NCR_RESET_CHECK a Kconfig Option
  power: reset: preliminary support for Axxia DDR Retention reset
  arch/arm/mach-axxia: Flush TLB
  axxia-reset.c: Use syscon address from device tree
  axxia: enable trng for axc6732-waco and axm5616-victoria
  axxia: generalize driver support for multi-controller PCI/SRIO/SATA
  axxia: enable PCI1/PCI2 controllers in device tree
  drivers/misc/axxia-pei.c: Update PEI Configuration
  drivers/misc/axxia-pei: Update PCIe/sRIO Lane Configuration

Geoff Levand (1):
  arm64: Enable the identity mapping to allow the MMU 

Re: [yocto] [bitbake-devel] Yocto: Add custom user to custom group in bitbake recipe

[Maxin B. John]

Hi Parthiban,

On Fri, Mar 02, 2018 at 01:58:35PM +0100, Parthiban Nallathambi wrote:
> Hi Maxim,
> 
> space.bb --> chromium recipe in 
> https://github.com/OSSystems/meta-browser/tree/master/recipes-browser/chromium
> 
> app.bb --> http-server.bb attached
> 
> I have created a group "www" in http-server_0.10.0.bb and trying to add
> "chromium" user to this group in chromium-x11_%.bbappend.

As useradd documentation says,
for -G " The group name must exist. A group number must refer to an already 
existing group."

So, the "GROUPADD_PARAM_${PN} = "www", should be in 
chromium-x11_%.bbappend before we use:

USERADD_PARAM_${PN} = "-d ${localstatedir}/lib/chromium -s /bin/false -G 
tty,video,input,www,www-data -U chromium

> But the useradd command is failed: group 'www' does not exit.
> 
> 
> On 03/02/2018 01:29 PM, Maxin B. John wrote:


Best Regards,
Maxin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] error: possibly undefined macro: PKG_CONFIG_SYSROOT_DIR

[Khem Raj]

On Fri, Mar 2, 2018 at 4:38 AM, Abhishekh Awanti
 wrote:
> Hi,
> Before i was trying to build the baseline version only, due to this error i
> moved to latest version.
> As Ross said i deleted tmp/ and now the package can able to build
> successfully.
> Should i move to original version only?
>

if you have no pressing need to upgrade
staying with original version is better since thats the tested set.

> On Fri, Mar 2, 2018 at 11:25 AM, Khem Raj  wrote:
>>
>>
>>
>> On 3/1/18 2:21 AM, Abhishekh Awanti wrote:
>>>
>>> Hi,
>>>
>>> I am trying to build the package "/harfbuzz-1.3.0" , /but i am getting
>>> the following configure error
>>
>>
>> your build seems to be a bit mixed, the baseline seems to be daisy based (
>> 1.6 ) but you are building harfbuzz which is introduced in morty ( 2.2 )
>> release. Doe the original version work ?
>>
>>>
>>> /Build Configuration:/
>>> /BB_VERSION= "1.22.0"/
>>> /BUILD_SYS = "x86_64-linux"/
>>> /NATIVELSBSTRING   = "Ubuntu-14.04"/
>>> /TARGET_SYS= "arm-poky-linux-gnueabi"/
>>> /MACHINE   = "iwg21m"/
>>> /DISTRO= "poky"/
>>> /DISTRO_VERSION= "1.6.1"/
>>> /TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa15"/
>>> /TARGET_FPU= "vfp-neon"/
>>> /meta /
>>> /meta-yocto /
>>> /meta-yocto-bsp= "hmi_tmp:9febda430a88ba23b539394e5d54b59ae87405f6"/
>>> /meta-renesas /
>>> /meta-rzg1 = "master:2ea602f03b9c2378c1d7dc28675a675d18edb0e3"/
>>> /meta-oe /
>>> /meta-multimedia /
>>> /meta-networking   = "hmi_tmp:dca466c074c9a35bc0133e7e0d65cca0731e2acf"/
>>> /meta-linaro-toolchain =
>>> "hmi_build:8a0601723c06fdb75e62aa0f0cf15fc9d7d90167"/
>>> /common /
>>> /hmi-demo  = "master:2cdb73bb902ecd4462cd0a4a66d5d116d0f7c113"/
>>> /meta-ndvr = ":"/
>>> /
>>> /
>>> /NOTE: Preparing runqueue/
>>> /NOTE: Executing SetScene Tasks/
>>> /NOTE: Executing RunQueue Tasks/
>>> /ERROR: Function failed: do_configure (log file is located at
>>> /home/bharath/Abhishek_WorkSpace/Projects/Renesas/RZG1H/iwave/build/Build_As_On_23_feb_2018/build/tmp/work/cortexa15hf-vfp-neon-poky-linux-gnueabi/harfbuzz/1.3.0-r0/temp/log.do_configure.451)/
>>> /ERROR: Logfile of failure stored in:
>>> /home/bharath/Abhishek_WorkSpace/Projects/Renesas/RZG1H/iwave/build/Build_As_On_23_feb_2018/build/tmp/work/cortexa15hf-vfp-neon-poky-linux-gnueabi/harfbuzz/1.3.0-r0/temp/log.do_configure.451/
>>> /Log data follows:/
>>> /| DEBUG: Executing python function sysroot_cleansstate/
>>> /| DEBUG: Python function sysroot_cleansstate finished/
>>> /| DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common',
>>> 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']/
>>> /| DEBUG: Executing shell function autotools_preconfigure/
>>> /| DEBUG: Shell function autotools_preconfigure finished/
>>> /| DEBUG: Executing python function autotools_copy_aclocals/
>>> /| DEBUG: Python function autotools_copy_aclocals finished/
>>> /| DEBUG: Executing shell function do_configure/
>>> /| automake (GNU automake) 1.14/
>>> /| Copyright (C) 2013 Free Software Foundation, Inc./
>>> /| License GPLv2+: GNU GPL version 2 or later
>>> >> >/
>>> /| This is free software: you are free to change and redistribute it./
>>> /| There is NO WARRANTY, to the extent permitted by law./
>>> /| /
>>> /| Written by Tom Tromey >/
>>> /|and Alexandre Duret-Lutz >./
>>> /| AUTOV is 1/
>>> /| NOTE: Executing ACLOCAL="aclocal
>>> --system-acdir=/home/bharath/Abhishek_WorkSpace/Projects/Renesas/RZG1H/iwave/build/Build_As_On_23_feb_2018/build/tmp/work/cortexa15hf-vfp-neon-poky-linux-gnueabi/harfbuzz/1.3.0-r0/build/aclocal-copy/"
>>> autoreconf --verbose --install --force --exclude=autopoint -I
>>> /home/bharath/Abhishek_WorkSpace/Projects/Renesas/RZG1H/iwave/build/Build_As_On_23_feb_2018/build/tmp/work/cortexa15hf-vfp-neon-poky-linux-gnueabi/harfbuzz/1.3.0-r0/harfbuzz-1.3.0/m4//
>>> /| autoreconf: Entering directory `.'/
>>> /| autoreconf:configure.ac : not using Gettext/
>>> /| autoreconf: running: aclocal
>>> --system-acdir=/home/bharath/Abhishek_WorkSpace/Projects/Renesas/RZG1H/iwave/build/Build_As_On_23_feb_2018/build/tmp/work/cortexa15hf-vfp-neon-poky-linux-gnueabi/harfbuzz/1.3.0-r0/build/aclocal-copy/
>>> -I
>>> /home/bharath/Abhishek_WorkSpace/Projects/Renesas/RZG1H/iwave/build/Build_As_On_23_feb_2018/build/tmp/work/cortexa15hf-vfp-neon-poky-linux-gnueabi/harfbuzz/1.3.0-r0/harfbuzz-1.3.0/m4/
>>> -I
>>> /home/bharath/Abhishek_WorkSpace/Projects/Renesas/RZG1H/iwave/build/Build_As_On_23_feb_2018/build/tmp/work/cortexa15hf-vfp-neon-poky-linux-gnueabi/harfbuzz/1.3.0-r0/harfbuzz-1.3.0/m4/
>>> --force -I m4/
>>> /| autoreconf:configure.ac : tracing/
>>> /| autoreconf: running: libtoolize --copy --force/
>>> /| 

Re: [yocto] [OE-core] Questions about udev rule and systemd-udev，relevant to mounting block device

[Vincent Prince]

Hi,

I'm not sure what is your use case, but you can check usbmount[1][2]
or automount-usb[3] for example on how to use udev with systemd:

Regards,
Vincent

[1]https://github.com/rbrito/usbmount
[2]
https://github.com/nefethael/meta-random/blob/master/recipes-support/usbmount/usbmount_git.bb
[3]https://github.com/six-k/automount-usb


2018-03-02 6:44 GMT+01:00 Hongzhi, Song :

> Hi all,
>
> Does anyone have suggestion for me?
>
> Thanks.
>
> Hongzhi.Song
>
> On 2018年03月01日 18:35, Hongzhi, Song wrote:
>
> Defect:
>
> The exiting method of automount of udev in *oe-core/meta/ *is using
>
> *automount.rules* which call *mount.sh* that using */bin/mount* to mount
> device.
>
> But systemd-udevd detaches *mount()* operations done within the service
>
> from the rest of the system with MountFlag=slave， this means host can
>
> not access device. (e.g. Executing *mkfs.ext4 /dev/sda1/* prompts
>
> */dev/sda1 is apparently in use by the system; will not make a filesystem
> here!*)
>
>
> Solution:
>
> Systemd upstream suggest that the best way is to use "systemd-mount"
>
> in udev rules, which will request the mount operation to be executed by
> PID 1.
>
> And I have tested it was effective.
>
>
> Uncertain：
>
> The exiting method is designed for *SysV-init *which is not
> compatible to
>
> systemd-udev, at least that's what I think. So I think that we should
> design
>
> a new rule or organizational structure to be suitable for systemd-udev and
>
> to mount deferent device. Dose anyone help do this? Or I can make some
>
> improvements on the basis of the existing with "systemd-mount".
>
>
>
>
> --
> ___
> Openembedded-core mailing list
> openembedded-c...@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] [bitbake-devel] Yocto: Add custom user to custom group in bitbake recipe

[Parthiban Nallathambi]

Hi Maxim,

space.bb --> chromium recipe in 
https://github.com/OSSystems/meta-browser/tree/master/recipes-browser/chromium


app.bb --> http-server.bb attached

I have created a group "www" in http-server_0.10.0.bb and trying to add 
"chromium" user to this group in chromium-x11_%.bbappend.


But the useradd command is failed: group 'www' does not exit.


On 03/02/2018 01:29 PM, Maxin B. John wrote:

Hi Parthiban,

On Fri, Mar 02, 2018 at 12:29:25PM +0100, Parthiban Nallathambi wrote:

Hello All,

I have created a custom group e.g "grp1" in my application recipe say
"app.bb".

GROUPADD_PARAM_${PN} = "grp1"

I am trying add my custom user e.g: "user1" to this group "grp1" in
"space.bb".

USERADD_PARAM_${PN} = "-d ${localstatedir}/lib/space/ -s /bin/false -G grp1
-U user1"

The useradd command failed saying the "useradd: group 'grp1' does not
exist". I have also tried adding DEPENDS_${PN} = "app" in space.bb, but it
doesn't help.

How can I add my custom user to my custom group in bitbake recipe?


Please share your sample recipes here. It will be helpful to debug the problem.


Question in Stackoverflow: 
https://stackoverflow.com/questions/49068076/yocto-add-custom-user-to-custom-group

--
Thanks,
Parthiban Nallathambi


Best Regards,
Maxin



--
Thanks,
Parthiban Nallathambi

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
inherit systemd
inherit useradd

# skip runtime dependency on bash
# since we don't use the wrapper script
RDEPENDS_${PN}_remove = "bash"

FILESEXTRAPATHS_append := "${THISDIR}/files:"

SRC_URI += " \
 file://chromium-start \
 file://chromium.service \
 file://chromium-tty.rules \
 "

do_install_append() {

install -d ${D}${systemd_unitdir}/system
install -m 755 ${WORKDIR}/chromium-start  ${D}${bindir}/
install -m 644 ${WORKDIR}/chromium.service ${D}${systemd_unitdir}/system

install -d ${D}${sysconfdir}/udev/rules.d
install -m 644 ${WORKDIR}/chromium-tty.rules ${D}${sysconfdir}/udev/rules.d

rm ${D}${libdir}/chromium/chromium-wrapper
rm ${D}${bindir}/chromium
ln -s ${libdir}/chromium/chromium-bin ${D}${bindir}/chromium
}

SYSTEMD_SERVICE_${PN} = "chromium.service"
FILES_${PN} += " ${bindir}/chromium-start 
${sysconfdir}/udev/rules.d/chromium-tty.rules"

USERADD_PACKAGES = "${PN}"
USERADD_PARAM_${PN} = "-d ${localstatedir}/lib/chromium -s /bin/false -G 
tty,video,input,www,www-data -U chromium"
SUMMARY = "http-server: a command-line http server"
DESCRIPTION = "http-server is a simple, zero-configuration command-line \
http server. It is powerful enough for production usage, but it's simple \
and hackable enough to be used for testing, local development, and learning.\
"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=8805b6f8b8c4f6ceff520f4c3aaa8094"

SRC_URI = "npm://registry.npmjs.org;name=http-server;version=${PV} \
file://http-server.service \
file://ssc_gen.sh \
"
inherit npm
# Must be set after inherit npm since that itself sets S
S = "${WORKDIR}/npmpkg"
DEPENDS_${PN} = "nodejs-npm"
RDEPENDS_${PN}-ecstatic = "bash"

LICENSE_${PN} = "MIT"

inherit systemd
inherit useradd
do_install_append() {

install -d ${D}${systemd_unitdir}/system
install -m 644 ${WORKDIR}/http-server.service ${D}${systemd_unitdir}/system
install -m 755 ${WORKDIR}/ssc_gen.sh ${D}${bindir}
}

SYSTEMD_SERVICE_${PN} = "http-server.service"
USERADD_PACKAGES = "${PN}"
GROUPADD_PARAM_${PN} = "www"
USERADD_PARAM_${PN} = "-d ${localstatedir}/lib/chromium -s /bin/false -G 
www-data -U www"
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] error: possibly undefined macro: PKG_CONFIG_SYSROOT_DIR

[Abhishekh Awanti]

Hi,
Before i was trying to build the baseline version only, due to this error i
moved to latest version.
As Ross said i deleted tmp/ and now the package can able to build
successfully.
Should i move to original version only?

On Fri, Mar 2, 2018 at 11:25 AM, Khem Raj  wrote:

>
>
> On 3/1/18 2:21 AM, Abhishekh Awanti wrote:
>
>> Hi,
>>
>> I am trying to build the package "/harfbuzz-1.3.0" , /but i am getting
>> the following configure error
>>
>
> your build seems to be a bit mixed, the baseline seems to be daisy based (
> 1.6 ) but you are building harfbuzz which is introduced in morty ( 2.2 )
> release. Doe the original version work ?
>
>
>> /Build Configuration:/
>> /BB_VERSION= "1.22.0"/
>> /BUILD_SYS = "x86_64-linux"/
>> /NATIVELSBSTRING   = "Ubuntu-14.04"/
>> /TARGET_SYS= "arm-poky-linux-gnueabi"/
>> /MACHINE   = "iwg21m"/
>> /DISTRO= "poky"/
>> /DISTRO_VERSION= "1.6.1"/
>> /TUNE_FEATURES = "armv7a vfp neon callconvention-hard cortexa15"/
>> /TARGET_FPU= "vfp-neon"/
>> /meta /
>> /meta-yocto /
>> /meta-yocto-bsp= "hmi_tmp:9febda430a88ba23b539394e5d54b59ae87405f6"/
>> /meta-renesas /
>> /meta-rzg1 = "master:2ea602f03b9c2378c1d7dc28675a675d18edb0e3"/
>> /meta-oe /
>> /meta-multimedia /
>> /meta-networking   = "hmi_tmp:dca466c074c9a35bc0133e7e0d65cca0731e2acf"/
>> /meta-linaro-toolchain = "hmi_build:8a0601723c06fdb75e6
>> 2aa0f0cf15fc9d7d90167"/
>> /common /
>> /hmi-demo  = "master:2cdb73bb902ecd4462cd0a4a66d5d116d0f7c113"/
>> /meta-ndvr = ":"/
>> /
>> /
>> /NOTE: Preparing runqueue/
>> /NOTE: Executing SetScene Tasks/
>> /NOTE: Executing RunQueue Tasks/
>> /ERROR: Function failed: do_configure (log file is located at
>> /home/bharath/Abhishek_WorkSpace/Projects/Renesas/RZG1H/
>> iwave/build/Build_As_On_23_feb_2018/build/tmp/work/cortex
>> a15hf-vfp-neon-poky-linux-gnueabi/harfbuzz/1.3.0-r0/
>> temp/log.do_configure.451)/
>> /ERROR: Logfile of failure stored in: /home/bharath/Abhishek_WorkSpa
>> ce/Projects/Renesas/RZG1H/iwave/build/Build_As_On_23_
>> feb_2018/build/tmp/work/cortexa15hf-vfp-neon-poky-linux-
>> gnueabi/harfbuzz/1.3.0-r0/temp/log.do_configure.451/
>> /Log data follows:/
>> /| DEBUG: Executing python function sysroot_cleansstate/
>> /| DEBUG: Python function sysroot_cleansstate finished/
>> /| DEBUG: SITE files ['endian-little', 'bit-32', 'arm-common',
>> 'common-linux', 'common-glibc', 'arm-linux', 'arm-linux-gnueabi', 'common']/
>> /| DEBUG: Executing shell function autotools_preconfigure/
>> /| DEBUG: Shell function autotools_preconfigure finished/
>> /| DEBUG: Executing python function autotools_copy_aclocals/
>> /| DEBUG: Python function autotools_copy_aclocals finished/
>> /| DEBUG: Executing shell function do_configure/
>> /| automake (GNU automake) 1.14/
>> /| Copyright (C) 2013 Free Software Foundation, Inc./
>> /| License GPLv2+: GNU GPL version 2 or later <
>> http://gnu.org/licenses/gpl-2.0.html > .0.html>>/
>> /| This is free software: you are free to change and redistribute it./
>> /| There is NO WARRANTY, to the extent permitted by law./
>> /| /
>> /| Written by Tom Tromey >/
>> /|and Alexandre Duret-Lutz >./
>> /| AUTOV is 1/
>> /| NOTE: Executing ACLOCAL="aclocal --system-acdir=/home/bharath/A
>> bhishek_WorkSpace/Projects/Renesas/RZG1H/iwave/build/Build_
>> As_On_23_feb_2018/build/tmp/work/cortexa15hf-vfp-neon-poky
>> -linux-gnueabi/harfbuzz/1.3.0-r0/build/aclocal-copy/" autoreconf
>> --verbose --install --force --exclude=autopoint -I
>> /home/bharath/Abhishek_WorkSpace/Projects/Renesas/RZG1H/
>> iwave/build/Build_As_On_23_feb_2018/build/tmp/work/cortex
>> a15hf-vfp-neon-poky-linux-gnueabi/harfbuzz/1.3.0-r0/harfbuzz-1.3.0/m4//
>> /| autoreconf: Entering directory `.'/
>> /| autoreconf:configure.ac : not using Gettext/
>> /| autoreconf: running: aclocal --system-acdir=/home/bharath/A
>> bhishek_WorkSpace/Projects/Renesas/RZG1H/iwave/build/Build_
>> As_On_23_feb_2018/build/tmp/work/cortexa15hf-vfp-neon-poky
>> -linux-gnueabi/harfbuzz/1.3.0-r0/build/aclocal-copy/ -I
>> /home/bharath/Abhishek_WorkSpace/Projects/Renesas/RZG1H/
>> iwave/build/Build_As_On_23_feb_2018/build/tmp/work/cortex
>> a15hf-vfp-neon-poky-linux-gnueabi/harfbuzz/1.3.0-r0/harfbuzz-1.3.0/m4/
>> -I /home/bharath/Abhishek_WorkSpace/Projects/Renesas/RZG1H/
>> iwave/build/Build_As_On_23_feb_2018/build/tmp/work/cortex
>> a15hf-vfp-neon-poky-linux-gnueabi/harfbuzz/1.3.0-r0/harfbuzz-1.3.0/m4/
>> --force -I m4/
>> /| autoreconf:configure.ac : tracing/
>> /| autoreconf: running: libtoolize --copy --force/
>> /| libtoolize: putting auxiliary files in `.'./
>> /| libtoolize: copying file `./ltmain.sh'/
>> /| libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'./
>> /| libtoolize: copying file `m4/libtool.m4'/
>> /| libtoolize: copying file 

Re: [yocto] [bitbake-devel] Yocto: Add custom user to custom group in bitbake recipe

[Maxin B. John]

Hi Parthiban,

On Fri, Mar 02, 2018 at 12:29:25PM +0100, Parthiban Nallathambi wrote:
> Hello All,
> 
> I have created a custom group e.g "grp1" in my application recipe say
> "app.bb".
> 
> GROUPADD_PARAM_${PN} = "grp1"
> 
> I am trying add my custom user e.g: "user1" to this group "grp1" in
> "space.bb".
> 
> USERADD_PARAM_${PN} = "-d ${localstatedir}/lib/space/ -s /bin/false -G grp1
> -U user1"
> 
> The useradd command failed saying the "useradd: group 'grp1' does not
> exist". I have also tried adding DEPENDS_${PN} = "app" in space.bb, but it
> doesn't help.
>
> How can I add my custom user to my custom group in bitbake recipe?

Please share your sample recipes here. It will be helpful to debug the problem.

> Question in Stackoverflow: 
> https://stackoverflow.com/questions/49068076/yocto-add-custom-user-to-custom-group
> 
> -- 
> Thanks,
> Parthiban Nallathambi

Best Regards,
Maxin
-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Yocto: Add custom user to custom group in bitbake recipe

[Parthiban Nallathambi]

Hello All,

I have created a custom group e.g "grp1" in my application recipe say 
"app.bb".


GROUPADD_PARAM_${PN} = "grp1"

I am trying add my custom user e.g: "user1" to this group "grp1" in 
"space.bb".


USERADD_PARAM_${PN} = "-d ${localstatedir}/lib/space/ -s /bin/false -G 
grp1 -U user1"


The useradd command failed saying the "useradd: group 'grp1' does not 
exist". I have also tried adding DEPENDS_${PN} = "app" in space.bb, but 
it doesn't help.


How can I add my custom user to my custom group in bitbake recipe?

Question in Stackoverflow: 
https://stackoverflow.com/questions/49068076/yocto-add-custom-user-to-custom-group


--
Thanks,
Parthiban Nallathambi

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

[yocto] Add custom user to custom group in bitbake recipe

[Parthiban Nallathambi]

Hello All,

I have created a custom group e.g "grp1" in my application recipe say 
"app.bb".


GROUPADD_PARAM_${PN} = "grp1"

I am trying to add my custom user e.g: "user1" to this group "grp1" in 
"space.bb".


USERADD_PARAM_${PN} = "-d ${localstatedir}/lib/space/ -s /bin/false -G 
grp1 -U user1"


The useradd command failed: "useradd: group 'grp1' does not exist". I 
have also tried adding DEPENDS_${PN} = "app" in space.bb, but it doesn't 
help.


How can I add my custom user to my custom group in bitbake recipe?

Question in Stackoverflow: 
https://stackoverflow.com/questions/49068076/yocto-add-custom-user-to-custom-group


--
Thanks,
Parthiban Nallathambi

DENX Software Engineering GmbH,  Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto

Re: [yocto] Adding Gnome to X11

[Q . Gouès]

Actually the problem didn't come from doing IMAGE_INSTALL +=.

The problem came from the fact that in my recipe, I was adding the 
"IMAGE_INSTALL +=" line before the "inherit core-image" in which 
IMAGE_INSTALL is defined as a ?=. By doing that, the packages defined in 
the core-image class are not added because the variable IMAGE_INSTALL 
already exists.


Adding the "IMAGE_INSTALL +=" line after "inherit core-image" solved the 
problem.


I decided to use xfce as GUI because a recipe for the whole package 
exists (packagegroup-xfce-base).


Thanks for your help

*Quentin Gouès*
Ingénieur Développement Logiciel

*ACTIA* PCs
14, rue Charles Martigny
94700 MAISONS ALFORT (FRANCE)
Tel. +33 (0)1 42 07 18 00 - Fax +33 (0)1 42 07 85 55
http://www.actia-pcs.fr 

Le 28/02/2018 à 17:17, Burton, Ross a écrit :
Because by doing IMAGE_INSTALL += you wiped out the default value 
which is a ?=.


gnome-desktop3 isn't the GNOME interface though, it's just a small 
library.


If you want the full GNOME 3 desktop then you'll need to start with 
meta-gnome and write more recipes, as it's not entirely packaged.


Ross

On 28 February 2018 at 14:10, Q. Gouès > wrote:


Hi,

I am trying to add gnome to my x11 image based on the recipe
core-image-x11. I am using Poky 2.0 (Jethro).

For that, I added the following line to my recipe:

/IMAGE_INSTALL += "gnome-desktop3"/

Unfortunately I get the following error:

/switch_root: can't execute '/sbin/init': No such file or directory//
//Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0100/

I tried the same thing with XFCE (I am trying to add a window
manager to my image) and I got the same results.

After taking a look at the rootfs in the iso file, I can notice
that the file '/sbin/init' is indeed missing. And it's not the
only file missing ! The rootfs went from ~420Mo to ~220Mo and the
list of files present in the rootfs went from:

/badblocks//
//blkid -> /bin/busybox.nosuid//
//bootlogd//
//debugfs//
//depmod -> /sbin/depmod.kmod//
//depmod.kmod -> ../bin/kmod//
//dumpe2fs//
//e2freefrag//
//e2fsck//
//e2image//
//e2undo//
//e4defrag//
//fdisk -> /bin/busybox.nosuid//
//filefrag//
//fsck -> /bin/busybox.nosuid//
//fsck.ext2//
//fsck.ext3//
//fsck.ext4//
//fsck.ext4dev//
//fstab-decode//
//fstrim -> /bin/busybox.nosuid//
//getty -> /bin/busybox.nosuid//
//halt -> /sbin/halt.sysvinit//
//halt.sysvinit//
//hdparm -> /sbin/hdparm.hdparm//
//hdparm.hdparm//
//hwclock -> /bin/busybox.nosuid//
//ifconfig -> /bin/busybox.nosuid//
//ifdown -> /bin/busybox.nosuid//
//ifup -> /bin/busybox.nosuid//
//init -> /sbin/init.sysvinit//
//init.sysvinit//
//insmod -> /sbin/insmod.kmod//
//insmod.kmod -> ../bin/kmod//
//ip -> /bin/busybox.nosuid//
//iwconfig//
//iwgetid -> iwconfig//
//iwlist -> iwconfig//
//iwpriv -> iwconfig//
//iwspy -> iwconfig//
//killall5//
//klogd -> /bin/busybox.nosuid//
//ldconfig//
//loadkmap -> /bin/busybox.nosuid//
//logread -> /bin/busybox.nosuid//
//logsave//
//losetup -> /bin/busybox.nosuid//
//lsmod -> /bin/lsmod.kmod//
//mke2fs//
//mkfs.ext2//
//mkfs.ext3//
//mkfs.ext4//
//mkfs.ext4dev//
//mklost+found//
//mkswap -> /bin/busybox.nosuid//
//modinfo -> /sbin/modinfo.kmod//
//modinfo.kmod -> ../bin/kmod//
//modprobe -> /sbin/modprobe.kmod//
//modprobe.kmod -> ../bin/kmod//
//nologin//
//pivot_root -> /bin/busybox.nosuid//
//populate-extfs.sh//
//poweroff -> /sbin/poweroff.sysvinit//
//poweroff.sysvinit -> halt.sysvinit//
//reboot -> /sbin/reboot.sysvinit//
//reboot.sysvinit -> halt.sysvinit//
//rmmod -> /sbin/rmmod.kmod//
//rmmod.kmod -> ../bin/kmod//
//route -> /bin/busybox.nosuid//
//runlevel -> /sbin/runlevel.sysvinit//
//runlevel.sysvinit//
//setconsole -> /bin/busybox.nosuid//
//shutdown -> /sbin/shutdown.sysvinit//
//shutdown.sysvinit//
//start-stop-daemon -> /bin/busybox.nosuid//
//sulogin -> /sbin/sulogin.util-linux//
//sulogin.util-linux//
//swapoff -> /bin/busybox.nosuid//
//swapon -> /bin/busybox.nosuid//
//switch_root -> /bin/busybox.nosuid//
//sysctl -> /bin/busybox.nosuid//
//syslogd -> /bin/busybox.nosuid//
//telinit -> init//
//udhcpc -> /bin/busybox.nosuid//
//vigr -> /sbin/vigr.shadow//
//vigr.shadow -> vipw.shadow//
//vipw -> /sbin/vipw.shadow//
//vipw.shadow/

to:

/ldconfig//
//nologin//
//sulogin -> /sbin/sulogin.util-linux//
//sulogin.util-linux//
//vigr -> /sbin/vigr.shadow//
//vigr.shadow -> vipw.shadow//
//vipw -> /sbin/vipw.shadow//
//vipw.shadow/

It looks like busybox was removed as well as other 

Re: [yocto] Yocto procedure to write generated image to hdd

[Iván Castell]

I have modified poky/meta/recipes-core/initrdscripts/initramfs-framework/init
to force a shell script when the "fatal" function is called:

# Prints a message and start a endless loop
fatal() {
echo $1 >/dev/console
echo >/dev/console
sh

#if [ -n "$bootparam_init_fatal_sh" ]; then
#sh
#else
#while [ "true" ]; do
#   sleep 3600
#done
#fi
}

After regenerating the hddimage, adding "noapic" to bootargs and booting
the "install" option, I have a shell console available, but with a very
limited toolbox (cp, cat or even ls command are not available).

Some relevant error messages appear on the boot process. I copy theses
error messages by hand:

sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:0:0: [sda] 234441648 512-byte logical blocks: (120 GB/1112GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
GPT: Primary header thinks Alt. header is not at the end of disk
GPT:1298455 != 234441647
GPT: Alternate GPT header not at the end of the disk
GPT: 1298455 != 234441647
GPT: Use GPU Parted to correct GPT errors.
 sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk

After that, some "command not found messages"

/init: line78: touch: command not found
/init: line81: mkdir: command not found
/init: line82: mount: command not found
/init: line86: cat: command not found
/init: line98: grep: command not found
/init: line112: sed: command not found

And after all, this error message appears:

ERROR: Initramfs failed to initialize the system

Hope all this information can be helpful to fix this issue.

Thank you in advance! :-)



2018-03-02 9:52 GMT+01:00 Iván Castell :

>
> First of all, thank you for your support Mr. Anuj.
>
> I extracted "initrd" image contents:
>
> $ binwalk initrd
>
> DECIMAL   HEXADECIMAL DESCRIPTION
> 
> 
> 0 0x0 ASCII cpio archive (SVR4 with no CRC), file
> name: "kernel", file name length: "0x0007", file size: "0x"
> 120   0x78ASCII cpio archive (SVR4 with no CRC), file
> name: "kernel/x86", file name length: "0x000B", file size: "0x"
> 244   0xF4ASCII cpio archive (SVR4 with no CRC), file
> name: "kernel/x86/microcode", file name length: "0x0015", file size:
> "0x"
> 376   0x178   ASCII cpio archive (SVR4 with no CRC), file
> name: "kernel/x86/microcode/.enuineIntel.align.0123456789abc", file name
> length: "0x0036", file size: "0x"
> 540   0x21C   ASCII cpio archive (SVR4 with no CRC), file
> name: "kernel/x86/microcode/GenuineIntel.bin", file name length:
> "0x0026", file size: "0x00183400"
> 1586864   0x1836B0ASCII cpio archive (SVR4 with no CRC), file
> name: "TRAILER!!!", file name length: "0x000B", file size: "0x"
> 1587200   0x183800gzip compressed data, maximum compression,
> from Unix, last modified: 2018-02-28 14:29:13
>
> $ dd if=initrd bs=1587200 skip=1 | gunzip | cpio -idm
>
> Now I have the initrd filesystem available. I can confirm there is a bug
> in that filesystem because the "init" script uses "sleep" but that tool is
> not installed on it.
>
> # Prints a message and start a endless loop
> fatal() {
> echo $1 >/dev/console
> echo >/dev/console
>
> if [ -n "$bootparam_init_fatal_sh" ]; then
> sh
> else
> while [ "true" ]; do
> sleep 3600
> done
> fi
> }
>
> As you pointed, that "init" script is located into poky/meta/recipes-core/
> initrdscripts/initramfs-framework/init. In that init script there are two
> calls to "fatal" function. Maybe this information can be useful to discover
> what is happening.
>
> I have tested adding suggested "init_fatal_sh" bootarg but I don't get any
> shell to debug the problem.
>
>
>
> 2018-03-02 9:15 GMT+01:00 Anuj Mittal :
>
>> On 03/02/2018 03:41 PM, Iván Castell wrote:
>> >
>> > 2018-03-02 0:41 GMT+01:00 Anuj Mittal > > >:
>> >
>> > Hi,
>> >
>> > On 03/01/2018 07:20 PM, Iván Castell wrote:
>> > >
>> > > Is this the proper way to install the generated image in the hard
>> > disk?
>> > > Maybe I am doing something wrong?
>> >
>> > Does the image boot up if you select 'boot'?
>> >
>> >
>> > I tested selecting 'boot' option and it happens exactly the same: a
>> > black screen appears when booting with default options, and when adding
>> > "noapic", the screen is flooded of "sleep: command not found" messages.
>> >
>> >
>> >
>> > Do you eventually get options to select storage media after all
>> > these 'not found' messages if you select 'install'?
>> >
>> >
>> > After waiting more than 5 minutes, the "sleep: command not found"
>> > message 

Re: [yocto] Yocto procedure to write generated image to hdd

[Iván Castell]

First of all, thank you for your support Mr. Anuj.

I extracted "initrd" image contents:

$ binwalk initrd

DECIMAL   HEXADECIMAL DESCRIPTION


0 0x0 ASCII cpio archive (SVR4 with no CRC), file
name: "kernel", file name length: "0x0007", file size: "0x"
120   0x78ASCII cpio archive (SVR4 with no CRC), file
name: "kernel/x86", file name length: "0x000B", file size: "0x"
244   0xF4ASCII cpio archive (SVR4 with no CRC), file
name: "kernel/x86/microcode", file name length: "0x0015", file size:
"0x"
376   0x178   ASCII cpio archive (SVR4 with no CRC), file
name: "kernel/x86/microcode/.enuineIntel.align.0123456789abc", file name
length: "0x0036", file size: "0x"
540   0x21C   ASCII cpio archive (SVR4 with no CRC), file
name: "kernel/x86/microcode/GenuineIntel.bin", file name length:
"0x0026", file size: "0x00183400"
1586864   0x1836B0ASCII cpio archive (SVR4 with no CRC), file
name: "TRAILER!!!", file name length: "0x000B", file size: "0x"
1587200   0x183800gzip compressed data, maximum compression,
from Unix, last modified: 2018-02-28 14:29:13

$ dd if=initrd bs=1587200 skip=1 | gunzip | cpio -idm

Now I have the initrd filesystem available. I can confirm there is a bug in
that filesystem because the "init" script uses "sleep" but that tool is not
installed on it.

# Prints a message and start a endless loop
fatal() {
echo $1 >/dev/console
echo >/dev/console

if [ -n "$bootparam_init_fatal_sh" ]; then
sh
else
while [ "true" ]; do
sleep 3600
done
fi
}

As you pointed, that "init" script is located into
poky/meta/recipes-core/initrdscripts/initramfs-framework/init. In that init
script there are two calls to "fatal" function. Maybe this information can
be useful to discover what is happening.

I have tested adding suggested "init_fatal_sh" bootarg but I don't get any
shell to debug the problem.



2018-03-02 9:15 GMT+01:00 Anuj Mittal :

> On 03/02/2018 03:41 PM, Iván Castell wrote:
> >
> > 2018-03-02 0:41 GMT+01:00 Anuj Mittal  > >:
> >
> > Hi,
> >
> > On 03/01/2018 07:20 PM, Iván Castell wrote:
> > >
> > > Is this the proper way to install the generated image in the hard
> > disk?
> > > Maybe I am doing something wrong?
> >
> > Does the image boot up if you select 'boot'?
> >
> >
> > I tested selecting 'boot' option and it happens exactly the same: a
> > black screen appears when booting with default options, and when adding
> > "noapic", the screen is flooded of "sleep: command not found" messages.
> >
> >
> >
> > Do you eventually get options to select storage media after all
> > these 'not found' messages if you select 'install'?
> >
> >
> > After waiting more than 5 minutes, the "sleep: command not found"
> > message continues flooding the screen.
> >
> >
> >
> > Can you share the logs?
> >
> >
> > If I could, I would do it, but I have no way to get those logs out of
> > the box without a terminal available.
>
> The error is probably coming from
> meta/recipes-core/initrdscripts/initramfs-framework/init.
>
> You can pass a boot parameter 'init_fatal_sh' and that should help you
> drop to a shell and debug this problem further.
>
>


-- 




*NOTA LEGAL*
Este correo electrónico y, en su caso, cualquier fichero anexo al mismo,
contiene información de carácter confidencial exclusivamente dirigida a su
destinatario y se encuentra protegido por Ley. Cualquier persona distinta
de su destinataria tiene prohibida su reproducción, uso, divulgación, copia
o impresión total o parcial. Si ha recibido este correo electrónico por
error, se ruega lo notifique de inmediato al remitente borrando el mensaje
original juntamente con sus ficheros anexos. Gracias.

De conformidad con lo establecido en la LOPD, NAYAR SYSTEMS SL garantiza la
adopción de las medidas necesarias para asegurar el tratamiento
confidencial de los datos de carácter personal. Así mismo le informamos de
la inclusión de sus datos en un fichero bajo la responsabilidad de NAYAR
SYSTEMS SL, con la finalidad de poder atender los compromisos derivados de
la relación que mantenemos con usted. Si lo desea, puede ejercer sus
derechos de acceso, rectificación, cancelación y oposición mediante un
escrito a la siguiente dirección: i...@nayarsystems.com

*LEGAL NOTE*
This email and any attachments to it contains is confidential information
exclusively intended for the recipients. Any divulgation, copy or
distribution to third parties is prohibited without written permission of
NAYAR SYSTEMS SL. If you have received this e-mail in error, please notify
the sender immediately. In accordance with Law 15/1999 of 13 December on
the Protection of 

Re: [yocto] Yocto procedure to write generated image to hdd

[Anuj Mittal]

On 03/02/2018 03:41 PM, Iván Castell wrote:
> 
> 2018-03-02 0:41 GMT+01:00 Anuj Mittal  >:
> 
> Hi,
> 
> On 03/01/2018 07:20 PM, Iván Castell wrote:
> >      
> > Is this the proper way to install the generated image in the hard
> disk?
> > Maybe I am doing something wrong?
> 
> Does the image boot up if you select 'boot'? 
> 
> 
> I tested selecting 'boot' option and it happens exactly the same: a
> black screen appears when booting with default options, and when adding
> "noapic", the screen is flooded of "sleep: command not found" messages.
> 
>  
> 
> Do you eventually get options to select storage media after all
> these 'not found' messages if you select 'install'? 
> 
> 
> After waiting more than 5 minutes, the "sleep: command not found"
> message continues flooding the screen.
> 
>  
> 
> Can you share the logs?
> 
> 
> If I could, I would do it, but I have no way to get those logs out of
> the box without a terminal available.

The error is probably coming from
meta/recipes-core/initrdscripts/initramfs-framework/init.

You can pass a boot parameter 'init_fatal_sh' and that should help you
drop to a shell and debug this problem further.

-- 
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto