I want the tar.bz image to be included in the wic image, which is an installer wic image
I have:
IMAGE_FSTYPES += "tar.bz2"
do_image_wic[depends] += "${IMAGE_BASENAME}:do_image_tar"
IMAGE_BOOT_FILES += "${IMAGE_BASENAME}-${MACHINE}.tar.bz2;upgrade.bz2"
so the tar.bz is made first, but... it is not deployed at the point the wic images is made, it is in:
build_output/work/device-type-linux/yocto-image-release/1.0-r0/deploy-yocto-image-release-image-complete/yocto-image-release-device-type-20190611214913.rootfs.tar.bz2
It won't appear in the deploy dir until after image yocto-image-release:do_deploy which naturally occurs after the wic is built (which now fails).
Is there a safe way to access that for the wic imager?
I'm guessing work-shared won't be any good https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#structure-build-work-shared
Is the better way to have a new installer.bb which depends on the yocto-image-release.bb:do_deploy so it can find the pieces and then make its own wic?
One solution seems to involve BBCLASSEXTEND so that I can build bitbake yocto-image-release and bitbake yocto-image-installer by amending the recipe (or a parent class) to include:
BBCLASSEXTEND += "installer"
DEPENDS_installer += "${BPN}"
and in installer.bbclass:
CLASSOVERRIDE = "installer"
and then I can override values with _installer suffix, although there will likely be a lot of work neutralising most of the configuration and methods of the native recipe, because (for now) all I want to build is a wic with the systems own kernel.
No doubt later it will have its own kernel configuration and initramfs anyway as the installer specialises.
This seems nice as there are a variety of images (-dev, -debug, etc) all of which may want an installer. But I still wonder if -installer couples the two too tightly
Related
I have a distro layer "meta-clayer" from a 3rd party which i do not want to edit.
Is there any method in yocto to append/overwrite some settings in distro.conf in "meta-clayer" by appending it from my custom created layer similar to bbappend method.
Any inputs will be helpful.
Create your own layer "meta-my-layer", inside
meta-my-layer/conf/layer.conf
set
LAYERDEPENDS_meta-my-layer = "clayer"
BBFILE_PRIORITY_meta-my-layer = "100"
#Could be any number higher than the one in meta-clayer/conf/layer.conf
create your own distro in conf/distro/include/mydistro.conf
copy paste the distro of meta-clayer inside it and do your own modification.
Do not forget to update your DISTRO variable in conf/local.conf.
An other way would be to override "settings" in your local.conf file which is the file with the higher priority but this is really not advised and not the best practice.
I am developing a multiplatform project, so it is a mix of different boards with appropriate meta layers. My meta image layer contains some bbappend recipes that are board specific although I would like to stick to single image layer repository rather than having image layer repository for each board.
So is there any way to completely hide/ignore/disable specific bbappend files?
Example:
I have bblayers for var-som-* boards. For such boards I have recipes-kernel/linux-variscite_%.bbapend, so building for var-som-* boards is fine, but problem happens when I build for example for raspberry. Having variscite layer (as well as all freescale set) adds a lot of things to the image I don't want, so I am removing variscite and freescale layers and it creates No recipes available for: recipes-kernel/linux-variscite_%.bbappend error.
Luckily this question has already been answered:
Yocto Dunfell error 'No recipes available for' with multiple machines in single custom meta layer
So for those, who faced the same problem here is quick summary:
Within your image meta repository create a folder structure that DOES NOT match BBFILES directive.
Move your .bbappend recipes there.
Include recipes on per-meta-layer basis using BBFILES_DYNAMIC directive.
Example:
# thats default and commonly used way to import recipes from your image
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb \
${LAYERDIR}/recipes-*/*/*.bbappend"
# "hide" recipes "deeper" within folder structure
# so they won't be included by ${LAYERDIR}/recipes-*/*/*.bbappend
#
BBFILES_DYNAMIC += "\
meta-atmel:${LAYERDIR}/dynamic-layers/meta-atmel/recipes-*/*/*.bbappend \
meta-atmel:${LAYERDIR}/dynamic-layers/meta-atmel/recipes-*/*/*/*.bbappend \
"
I am using the raspberry pi layer and the IMAGE_CLASSES variable is set this way, I checked doing bitbake core-image-minimal -e | grep "^IMAGE_CLASSES".
I want to modify what is set in ../meta-raspberrypi/conf/machine/include/rpi-default-settings.inc, which defines how the image is partitioned. I want to avoid to edit this file from the raspberrypi layer.
# RaspberryPi BSP default settings
IMAGE_CLASSES += "sdcard_image-rpi"
I would like to use my own .class file. I tried creating a layer with a higher priority, the same filename, same location and different content, but still, bitbake -e returns the same content. And of course, this layer has been added in the bblayer.conf.
I also tried to add in my local.conf:
IMAGES_CLASSES_remove += "sdcard_image-rpi"
Again, no change.
Any idea?
I'm not sure I understand your intention. If you want to override a .class file completely, you can place modified version of it in your custom meta layer, and place your custom layer on top of bblayers.conf (your custom meta should be placed before the one you are overriding class from).
BTW: IMAGES_CLASSES_remove += "sdcard_image-rpi" does not look correct: you should either use _append / _remove override or '+=' operator, not both.
I am in the process of writing a PowerShell script for backing up a Windows computer using rsync. To this end, I am attempting to use WMI from said script to create a non-persistent Shadow copy with writer participation (as is apparently recommended for backups).
I found out from another question (Accessing Volume Shadow Copy (VSS) Snapshots from powershell) a way to create a shadow copy in general, but the example given there uses "ClientAccessible" as the context parameter, which results in the creation of a persistent Shadow Copy, without writer participation.
While searching for a solution, I have found that I could use the following command to obtain a list of contexts, which I assume are understood by WMI:
Get-WmiObject win32_shadowcontext | Out-GridView
It does the list have a context named "Backup", which is conveniently what I want. I proceeded to attempt creating a non-persistent shadow copy using that context:
$shadow = (Get-WmiObject -list win32_shadowcopy).Create("C:\", "Backup")
However, this seems to fail and the content of the $shadow variable is set to
ReturnValue : 5
ShadowID : {00000000-0000-0000-0000-000000000000}
According to the relevant documentation (Create method of the Win32_ShadowCopy class), the return value means "Unsupported shadow copy context."
I couldn't find any relevant documentation as to why this context is unsupported or whether it is possible to use it at all. I have also tried the "FileShareBackup" and "AppRollback" contexts without success.
I assume I am either missing something obvious, or that for some reason, WMI really doesn't support anything else than "clientAccessible" when creating shadow copies, or that this is OS-dependent (I am testing this on Windows 7, 64-bit)
How can I get this to work?
Okay, Technoob1984 here with the scoop. See my attached screen shot.
This one is tricky, because you have to use x64 version of Powershell (located under system32 not wow64)
The Shadow Copy Context are the .properties of the object.
Also I used the static method in my screenshots below.
https://learn.microsoft.com/en-us/previous-versions/windows/desktop/vsswmi/create-method-in-class-win32-shadowcopy
# get existing shadow copies
$shadow = get-wmiobject win32_shadowcopy
"There are {0} shadow copies on this sytem" -f $shadow.count
""
# get static method
$class=[WMICLASS]"root\cimv2:win32_shadowcopy"
# create a new shadow copy
"Creating a new shadow copy"
$class.create("C:\", "ClientAccessible")
# Count again
$shadow = get-wmiobject win32_shadowcopy
so in the example there, you would want to use $class.Properties to see what you can use as a Shadow Context.
See my screen shot:
So Shadow Context is 'Caption, Count, Description' and anything else under the 'Name:' value of .Properties. I do not see 'Backup' as one of the options.
Enjoy
Your $shadow has a 5 on return value looking at the error message, your shadow id has all zeros , you would need to add a 1 or a 2 to the end of the volume shadow copy in the registry using binary or dword.
find the folder in the registry named volsnap in your regedit search .volsnap.sys is found in the C:\Windows\System32\drivers directory. The file size is 52,352 bytes.The volsnap file contains Microsoft's digital signature make sure its the correct bytes.
This confirms its authenticity. volsnap.sys appears to be a file that was compressed by an EXE-Packer. This technique is often used by trojans to keep the file size small and also hamper debugging efforts.
However, this in itself is not sufficient reason to presume malicious intent, since even well-intentioned, professional software producers take advantage of compressed files. For this reason, 2% of all experts consider this file to be a possible threat. The probability that it can cause harm is high. Please consider the additional Comments from other users.
shadow id default
00000000-0000-0000-0000-000000000000
00000000-0000-0000-0000-000000000005
if it already has a 5 which it probably doesn't change it to 1
or create new code
Shadow id $shadow 00000000-0000-0000-0000-0000000000001
not exactly as shown.you may have to try different wording I'm not sure if $will work, if not, try the js standalone version.
I am working the particle effects in ogre3d for iphone
Ogre::ParticleSystem* sunParticle = OgreFramework::getSingletonPtr()->m_pSceneMgr- >createParticleSystem("Smoke", "Examples/Smoke");
sunParticle = OgreFramework::getSingletonPtr()->m_pSceneMgr->createParticleSystem("Smoke", "Examples/Smoke");
Ogre::SceneNode* particleNode = OgreFramework::getSingletonPtr()->m_pSceneMgr->getRootSceneNode()->createChildSceneNode("Particle");
particleNode->attachObject(sunParticle);
This is my plugin code
# Defines plugins to load
# Define plugin folder
PluginFolder=./
# Define plugins
Plugin=RenderSystem_GL
Plugin=Plugin_ParticleFX
In staticloader also contains this installing manually
#ifdef OGRE_STATIC_ParticleFX
mParticleFXPlugin = OGRE_NEW ParticleFXPlugin();
root.installPlugin(Plugin_ParticleFX);
root.loadPlugin(mParticleFXPlugin);
endif
I have also add the .particle file
I think i followed all the steps
An exception has occurred: OGRE EXCEPTION(2:InvalidParametersException): Cannot find required template 'Examples/Smoke' in ParticleSystemManager::createSystem at /Users/davidrogers/Documents/Ogre/ogre-v1-7/OgreMain/src/OgreParticleSystemManager.cpp (line 327)
2012-03-22 14:06:46.757 iphonesampleOgreapp[23041:207] Applications are expected to have a root view controller at the end of application launch
You need to specify the resource folder(s), too, to be able to use the actual particle scripts. Are you absolutely sure you do this correctly?
Have a look at this tutorial.
I really think that this error message sounds like the ressources are not correctly initialized or -if they are- the particle script is simply erroneous.