Re: [yocto] beta testing netbooting Yocto on Amazon, Google & Digital Ocean
Hi William - thanks for the feedback - when you make a new thing it’s always really aprpeciated to get any comments. >>I looked at your documentation. You have a section "Is bootrino open source?” >>You don't really answer the question. You’re right - I’ll remove that - it’s a website so the question that the documentation poses doesn’t really make sense. >>>You also say there is an MIT licensed CLI. OK. Yes, an MIT license CLI is planned but not built yet. But you do not mention the server code itself. From that I assume the answer to the question "Is bootrino open source?" is no. Am I correct? Correct - the bootrino website/console is not open source. >>> So for my own POV I would not want to give this access to my cloud account >>> without seeing the code and perhaps running it on my own server so I can be >>> sure of what I am getting. There’s not really any server behind bootrino - apart from user account creation it’s all client side. User accounts are created on Amazon Cognito which is a service purely for creating and authenticating users. Apart from that bootrino has no back end. >>> I could setup a scratch account but I would worry even then and I would still have concerns ever going to "production" mode. I am a bit picky that way. I understand the concern totally. One of my primary considerations designing bootrino is your cloud account keys. I wanted to ensure they are never sent to the bootrino back end because of the trust issue that anyone would reasonably have. So your cloud account keys are stored locally in your browser and never send to the bootrino back end - which consists only of Amazon Cognito anyway as mentioned. Watching network requests from the browsers developer tools or setting up a network analyzer would show that your cloud account keys are not sent to any bootrino back end. So, you might ask, if bootrino effectively has no back end, then how does it work? The answer is that the bootrino JavaScript running in your web browser talks directly to your cloud REST API with no third party in between. That’s as secure as I could make it - the keys stay on your machine and your machine talks directly to your cloud so you need never wonder about the trust level for bootrino’s back end systems. >>>Others may not feel the same way. I wish you luck. Thanks Bill I appreciate your feebdack and candid comments. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] beta testing netbooting Yocto on Amazon, Google & Digital Ocean
Hi folks, I built a website to make it easy to netboot Run-From-RAM operating systems like Yocto Linux on cloud hosts (Google, Amazon & Digital Ocean). I wanted to see if anyone might be interested to give it a try as a beta test. It’s absolutely brand new so likely has bugs and issues. website is https://www.bootrino.com documentation is https://doc.bootrino.com console is https://console.bootrino.com Let me know if you’re interested cause I’d be interested to help directly if any issues come up. thanks! Andrew -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] How to build pure initramfs run from ram Yocto with some packages in initramfs?
Hi folks,
With Tiny Core Linux I am able to have a kernel file plus an initramfs that
boots
My goal is to configure Yocto to these requirements:
1: kernel plus initramfs only - runs entirely from RAM after initial booting
from disk.
2: openssh server installed
3: nginx installed
4: isc dhcp client installed
5: virtualization drivers installed for *both* Xen and KVM - so the same code
can boot on either virtualization type
I’ve spent all day fiddling with every possible variation of
core-image-minimal-initramfs local.conf and bblayers.conf but nothing I do will
install any of the packages above into the initramfs that is created after
running 'bitbake core-image-minimal-initramfs’
I’m out of ideas. Can anyone point me in the right direction please?
thanks!!
Here’s my conf/bblayers.conf and conf.local.conf
ubuntu@ip-10-0-0-63:/opt/mountpoint/poky-rocko-18.0.0/build$ cat
conf/bblayers.conf
# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"
BBPATH = "${TOPDIR}"
BBFILES ?= ""
BBLAYERS ?= " \
/mnt/home/ubuntu/poky-rocko-18.0.0/meta \
/mnt/home/ubuntu/poky-rocko-18.0.0/meta-openembedded/meta-filesystems \
/mnt/home/ubuntu/poky-rocko-18.0.0/meta-openembedded/meta-networking \
/mnt/home/ubuntu/poky-rocko-18.0.0/meta-openembedded/meta-webserver \
/mnt/home/ubuntu/poky-rocko-18.0.0/meta-openembedded/meta-oe \
/mnt/home/ubuntu/poky-rocko-18.0.0/meta-openembedded/meta-python \
/mnt/home/ubuntu/poky-rocko-18.0.0/openembedded-core/meta \
/mnt/home/ubuntu/poky-rocko-18.0.0/meta-poky \
/mnt/home/ubuntu/poky-rocko-18.0.0/meta-virtualization \
/mnt/home/ubuntu/poky-rocko-18.0.0/meta-yocto-bsp \
/mnt/home/ubuntu/poky-rocko-18.0.0/oe-meta-go \
"
ubuntu@ip-10-0-0-63:/opt/mountpoint/poky-rocko-18.0.0/build$
ubuntu@ip-10-0-0-63:/opt/mountpoint/poky-rocko-18.0.0/build$ cat conf/local.conf
#
# This file is your local configuration file and is where all local user
settings
# are placed. The comments in this file give some guide to the options a new
user
# to the system might want to change but pretty much any configuration option
can
# be set in this file. More adventurous users can look at local.conf.extended
# which contains other examples of configuration which can be placed in this
file
# but new users likely won't need any of them initially.
#
# Lines starting with the '#' character are commented out and in some cases the
# default values are provided as comments to show people example syntax.
Enabling
# the option is a question of removing the # character and making any change to
the
# variable as required.
#
# Machine Selection
#
# You need to select a specific machine to target the build with. There are a
selection
# of emulated machines available which can boot and run in the QEMU emulator:
#
#MACHINE ?= "qemuarm"
#MACHINE ?= "qemuarm64"
#MACHINE ?= "qemumips"
#MACHINE ?= "qemumips64"
#MACHINE ?= "qemuppc"
#MACHINE ?= "qemux86"
MACHINE ?= "qemux86-64"
#
# There are also the following hardware board target machines included for
# demonstration purposes:
#
#MACHINE ?= "beaglebone"
#MACHINE ?= "genericx86"
#MACHINE ?= "genericx86-64"
#MACHINE ?= "mpc8315e-rdb"
#MACHINE ?= "edgerouter"
#
# This sets the default machine to be qemux86 if no other machine is selected:
#MACHINE ??= "qemux86"
DISTRO_FEATURES_append = " xen"
EXTRA_IMAGE_FEATURES = "debug-tweaks"
DISTRO_FEATURES_append = " virtualization"
#CORE_IMAGE_EXTRA_INSTALL += "openssh-sshd"
#CORE_IMAGE_EXTRA_INSTALL += "dhcp-client"
#CORE_IMAGE_EXTRA_INSTALL += "dropbear"
#CORE_IMAGE_EXTRA_INSTALL += "dropbear"
#IMAGE_INSTALL_append = " dropbear"
#IMAGE_INSTALL_append = " packagegroup-core-ssh-openssh"
IMAGE_INSTALL_append = " ssh-server-openssh"
IMAGE_INSTALL_append = " dhcp-client"
IMAGE_INSTALL_append = " nginx"
#
# Where to place downloads
#
# During a first build the system will download many different source code
tarballs
# from various upstream projects. This can take a while, particularly if your
network
# connection is slow. These are all stored in DL_DIR. When wiping and
rebuilding you
# can preserve this directory to speed up this part of subsequent builds. This
directory
# is safe to share between multiple builds on the same machine too.
#
# The default is a downloads directory under TOPDIR which is the build
directory.
#
#DL_DIR ?= "${TOPDIR}/downloads"
#
# Where to place shared-state files
#
# BitBake has the capability to accelerate builds based on previously built
output.
# This is done using "shared state" files which can be thought of as cache
objects
# and this option determines where those files are placed.
#
# You can wipe out TMPDIR leaving this directory intact and the build would
regenerate
# from these files if no changes were made to the configuration. If changes
were made
# to the configuration, only shared state files where the state was still valid
would
# be used (done using checksums).
#
# The default
[yocto] ERROR: glibc-locale-2.24-r0 do_package: QA Issue: glibc-locale: Files/directories were installed but not shipped in any package
Hello, Can anyone suggest where I might start to diagnose this problem? I am doing bit "bitbake xen-guest-image-minimal” and getting the errors seen below with locale. thanks! Loading cache: 100% || Time: 0:00:00 Loaded 2597 entries from dependency cache. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION= "1.32.0" BUILD_SYS = "x86_64-linux" NATIVELSBSTRING = "universal" TARGET_SYS= "x86_64-poky-linux" MACHINE = "qemux86-64" DISTRO= "poky" DISTRO_VERSION= "2.2" TUNE_FEATURES = "m64 core2" TARGET_FPU= "" meta meta-poky meta-yocto-bsp meta-webserver= "morty:dc8508f609974cc99606b9042bfa7f870ce80228" meta-virtualization = "master:011c4d611b3ce4e4922207ea0f58fd475eab83fb" meta-networking meta-oe meta-python meta-filesystems = "morty:dc8508f609974cc99606b9042bfa7f870ce80228" Initialising tasks: 100% |###| Time: 0:00:04 NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks ERROR: glibc-locale-2.24-r0 do_package: QA Issue: glibc-locale: Files/directories were installed but not shipped in any package: /usr/share/i18n /usr/share/i18n/locales /usr/share/i18n/charmaps /usr/share/i18n/locales/kw_GB /usr/share/i18n/locales/ug_CN /usr/share/i18n/locales/as_IN /usr/share/i18n/locales/sa_IN /usr/share/i18n/locales/mhr_RU /usr/share/i18n/locales/ml_IN /usr/share/i18n/locales/ak_GH /usr/share/i18n/locales/tg_TJ /usr/share/i18n/locales/translit_compat /usr/share/i18n/locales/fr_FR /usr/share/i18n/locales/sl_SI /usr/share/i18n/locales/xh_ZA /usr/share/i18n/locales/lv_LV /usr/share/i18n/locales/de_DE /usr/share/i18n/locales/bn_BD /usr/share/i18n/locales/so_DJ /usr/share/i18n/locales/ku_TR /usr/share/i18n/locales/es_AR /usr/share/i18n/locales/yi_US /usr/share/i18n/locales/pt_PT /usr/share/i18n/locales/it_IT@euro /usr/share/i18n/locales/st_ZA /usr/share/i18n/locales/translit_cjk_variants /usr/share/i18n/locales/en_HK /usr/share/i18n/locales/ga_IE@euro /usr/share/i18n/locales/ur_PK /usr/share/i18n/locales/tr_TR /usr/share/i18n/locales/aa_ER /usr/share/i18n/locales/nl_AW /usr/share/i18n/locales/tt_RU@iqtelif /usr/share/i18n/locales/es_CL /usr/share/i18n/locales/en_IE@euro /usr/share/i18n/locales/csb_PL /usr/share/i18n/locales/de_BE /usr/share/i18n/locales/br_FR /usr/share/i18n/locales/es_GT /usr/share/i18n/locales/lg_UG /usr/share/i18n/locales/os_RU /usr/share/i18n/locales/uz_UZ /usr/share/i18n/locales/de_BE@euro /usr/share/i18n/locales/mk_MK /usr/share/i18n/locales/nl_NL@euro /usr/share/i18n/locales/i18n /usr/share/i18n/locales/ka_GE /usr/share/i18n/locales/shs_CA /usr/share/i18n/locales/gu_IN /usr/share/i18n/locales/cs_CZ /usr/share/i18n/locales/pap_AW /usr/share/i18n/locales/ar_AE /usr/share/i18n/locales/gez_ET /usr/share/i18n/locales/ha_NG /usr/share/i18n/locales/nso_ZA /usr/share/i18n/locales/en_DK /usr/share/i18n/locales/sq_MK /usr/share/i18n/locales/en_CA /usr/share/i18n/locales/sr_ME /usr/share/i18n/locales/sgs_LT /usr/share/i18n/locales/fr_BE@euro /usr/share/i18n/locales/es_MX /usr/share/i18n/locales/en_NZ /usr/share/i18n/locales/ga_IE /usr/share/i18n/locales/ar_IN /usr/share/i18n/locales/pap_CW /usr/share/i18n/locales/ru_RU /usr/share/i18n/locales/es_US /usr/share/i18n/locales/es_PY /usr/share/i18n/locales/nl_NL /usr/share/i18n/locales/es_ES /usr/share/i18n/locales/en_IN /usr/share/i18n/locales/pl_PL /usr/share/i18n/locales/sq_AL /usr/share/i18n/locales/ca_ES /usr/share/i18n/locales/zh_CN /usr/share/i18n/locales/ks_IN@devanagari /usr/share/i18n/locales/gez_ER@abegede /usr/share/i18n/locales/de_LI /usr/share/i18n/locales/fil_PH /usr/share/i18n/locales/pa_IN /usr/share/i18n/locales/ig_NG /usr/share/i18n/locales/brx_IN /usr/share/i18n/locales/is_IS /usr/share/i18n/locales/en_AU /usr/share/i18n/locales/gez_ER /usr/share/i18n/locales/bem_ZM /usr/share/i18n/locales/sr_RS@latin /usr/share/i18n/locales/mr_IN /usr/share/i18n/locales/ca_AD /usr/share/i18n/locales/ro_RO /usr/share/i18n/locales/kk_KZ /usr/share/i18n/locales/te_IN /usr/share/i18n/locales/en_ZW /usr/share/i18n/locales/dv_MV /usr/share/i18n/locales/az_AZ /usr/share/i18n/locales/aa_ET /usr/share/i18n/locales/es_CU /usr/share/i18n/locales/id_ID /usr/share/i18n/locales/wal_ET /usr/share/i18n/locales/bho_IN /usr/share/i18n/locales/es_BO /usr/share/i18n/locales/hak_TW /usr/share/i18n/locales/ru_UA /usr/share/i18n/locales/zu_ZA /usr/share/i18n/locales/uz_UZ@cyrillic /usr/share/i18n/locales/be_BY@latin /usr/share/i18n/locales/be_BY
Re: [yocto] Errors when doing bitbake xen-guest-image-minimal
Sorry for the noise, please disregard my question, I hit the problem with the large hammer of deleting my temp directory and I now seem to have moved onto some new problem…. On 14 Nov 2016, at 7:15 PM, Andrew Stuart <andrew.stu...@supercoders.com.au> wrote: I’m out of my depth here…. Any suggestions as to what might be causing these errors? thanks! Initialising tasks: 100% |#| Time: 0:00:03 NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks ERROR: gcc-runtime-6.2.0-r0 do_compile: oe_runmake failed ERROR: gcc-runtime-6.2.0-r0 do_compile: Function failed: do_compile (log file is located at /mnt/dude/yocto/poky/build/tmp/work/core2-64-poky-linux/gcc-runtime/6.2.0-r0/temp/log.do_compile.11808) ERROR: Logfile of failure stored in: /mnt/dude/yocto/poky/build/tmp/work/core2-64-poky-linux/gcc-runtime/6.2.0-r0/temp/log.do_compile.11808 Log data follows: | DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc', 'bit-64', 'x86_64-linux', 'common'] | DEBUG: Executing shell function do_compile | NOTE: make -j 4 MULTIBUILDTOP=/mnt/dude/yocto/poky/build/tmp/work/core2-64-poky-linux/gcc-runtime/6.2.0-r0/gcc-6.2.0/build.x86_64-poky-linux.x86_64-poky-linux/x86_64-poky-linux/libgcc/ | # If this is the top-level multilib, build all the other | # multilibs. | # Early copyback; see "all" above for the rationale. The | dest=/mnt/dude/yocto/poky/build/tmp/work/core2-64-poky-linux/gcc-runtime/6.2.0-r0/gcc-6.2.0/build.x86_64-poky-linux.x86_64-poky-linux/x86_64-poky-linux/libgcc/../.././gcc/include/tmp$$-unwind.h; \ | cp unwind.h $dest; \ | chmod a+r $dest; \ | sh ../../../../../../../../work-shared/gcc-6.2.0-r0/gcc-6.2.0/libgcc/../move-if-change $dest /mnt/dude/yocto/poky/build/tmp/work/core2-64-poky-linux/gcc-runtime/6.2.0-r0/gcc-6.2.0/build.x86_64-poky-linux.x86_64-poky-linux/x86_64-poky-linux/libgcc/../.././gcc/include/unwind.h | # early copy is necessary so that the gcc -B options find | # the right startup files when linking shared libgcc. | /bin/bash ../../../../../../../../work-shared/gcc-6.2.0-r0/gcc-6.2.0/libgcc/../mkinstalldirs /mnt/dude/yocto/poky/build/tmp/work/core2-64-poky-linux/gcc-runtime/6.2.0-r0/gcc-6. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Errors when doing bitbake xen-guest-image-minimal
I’m out of my depth here…. Any suggestions as to what might be causing these errors? thanks! Initialising tasks: 100% |#| Time: 0:00:03 NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks ERROR: gcc-runtime-6.2.0-r0 do_compile: oe_runmake failed ERROR: gcc-runtime-6.2.0-r0 do_compile: Function failed: do_compile (log file is located at /mnt/dude/yocto/poky/build/tmp/work/core2-64-poky-linux/gcc-runtime/6.2.0-r0/temp/log.do_compile.11808) ERROR: Logfile of failure stored in: /mnt/dude/yocto/poky/build/tmp/work/core2-64-poky-linux/gcc-runtime/6.2.0-r0/temp/log.do_compile.11808 Log data follows: | DEBUG: SITE files ['endian-little', 'common-linux', 'common-glibc', 'bit-64', 'x86_64-linux', 'common'] | DEBUG: Executing shell function do_compile | NOTE: make -j 4 MULTIBUILDTOP=/mnt/dude/yocto/poky/build/tmp/work/core2-64-poky-linux/gcc-runtime/6.2.0-r0/gcc-6.2.0/build.x86_64-poky-linux.x86_64-poky-linux/x86_64-poky-linux/libgcc/ | # If this is the top-level multilib, build all the other | # multilibs. | # Early copyback; see "all" above for the rationale. The | dest=/mnt/dude/yocto/poky/build/tmp/work/core2-64-poky-linux/gcc-runtime/6.2.0-r0/gcc-6.2.0/build.x86_64-poky-linux.x86_64-poky-linux/x86_64-poky-linux/libgcc/../.././gcc/include/tmp$$-unwind.h; \ | cp unwind.h $dest; \ | chmod a+r $dest; \ | sh ../../../../../../../../work-shared/gcc-6.2.0-r0/gcc-6.2.0/libgcc/../move-if-change $dest /mnt/dude/yocto/poky/build/tmp/work/core2-64-poky-linux/gcc-runtime/6.2.0-r0/gcc-6.2.0/build.x86_64-poky-linux.x86_64-poky-linux/x86_64-poky-linux/libgcc/../.././gcc/include/unwind.h | # early copy is necessary so that the gcc -B options find | # the right startup files when linking shared libgcc. | /bin/bash ../../../../../../../../work-shared/gcc-6.2.0-r0/gcc-6.2.0/libgcc/../mkinstalldirs /mnt/dude/yocto/poky/build/tmp/work/core2-64-poky-linux/gcc-runtime/6.2.0-r0/gcc-6. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Guide to how to build a minimal system
I want to build a minimal Nginx system that does nothing else but serve static files. Preferably with nothing else installed at all apart from network configuration via /etc/network/interfaces. Perhaps also optionally with ssh. Ideally I would be able to provide the HTML files that make up the website via an initramfs file. I’d like this to run on x86-64 on KVM. I’m looking for a guide that shows me the key steps to implement something minimal like this. Does such a guide exist? I’ve watched several hours of Youtube videos on Yocto, I’ve read various getting started guides and spent several hours installing and building. Quite how to configure something down to minimal still is not clear. Can someone guide me please as to where to find such docs? One additional specific question - I can see that there is a web servers layer, but how to only get the one webserver that I want (nginx) as opposed to getting them all? thanks Andrew -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
