Crostini backup creates a xxx.tini file. What is the format of this file? Is there a way to view the file list of this file, ideally from within the Chromebook?
The format does not appear to be documented at the Crostini developer site so the following is based on checking an actual backup experimentally! (If someone finds a link, please add it or comment.)
This is a tar archive which is compressed with gzip with structure as follows:
The file system (usually /dev/vdb in btrfs format) mounted as / in the container is stored under the top-level directory rootfs in this archive. Note that this includes the rootfs/home sub-directory and its contents so be careful what you do with copies of the .tini file.
In addition, there is a top-level metadata.yaml file of which a version is reproduced below.
In addition, there is a top-level directory templates which contains the files hosts.tpl and hostname.tpl which are referred to in the metadata.yaml file. Presumably, this allows for additional templates to be added at a later stage via the metadata file.
metadata.yaml contents:
architecture: amd64
creation_date: 1573104613
expiry_date: 1575696613
properties:
architecture: amd64
description: Debian buster amd64 (20191107_05:24)
name: debian-buster-amd64-default-20191107_05:24
os: debian
release: buster
serial: "20191107_05:24"
tremplinSetupFinished: "true"
variant: default
templates:
/etc/hostname:
when:
- create
- copy
create_only: false
template: hostname.tpl
properties: {}
/etc/hosts:
when:
- create
- copy
create_only: false
template: hosts.tpl
properties: {}
Related
At the moment I am using the Clang Format utility in my project. In order to share its settings in my team, I put the .clang-format configuration file in the root of the project folder, and now IDE automatically loads it when working with the project.
In the same way, I want to use the Clang Tidy utility. However, unlike Clang Format, I cannot find a description of the configuration file format or a utility to create it. I need IDE to also automatically load these settings and take them into account in autoformatting, so it's not possible for me to run the utility using a script that will pass it the necessary parameters. Is there a way to achieve what I need?
.clang-tidy file format is actually specified in the command-line help, see the documentation.
--config=<string> -
Specifies a configuration in YAML/JSON format:
-config="{Checks: '*',
CheckOptions: [{key: x,
value: y}]}"
When the value is empty, clang-tidy will
attempt to find a file named .clang-tidy for
each source file in its parent directories.
--config-file=<string> -
Specify the path of .clang-tidy or custom config file:
e.g. --config-file=/some/path/myTidyConfigFile
This option internally works exactly the same way as
--config option after reading specified config file.
Use either --config-file or --config, not both.
All you need to do is to put the config string in a file and you're good to go. If you don't specify the --config-file option it will automatically search for a .clang-tidy file in the directory where the checked code is.
An example .clang-tidy file:
Checks: '-*,bugprone-*'
CheckOptions:
- key: bugprone-argument-comment.StrictMode
value: 1
- key: bugprone-exception-escape.FunctionsThatShouldNotThrow
value: WinMain,SDL_main
FormatStyle: 'file'
This would run all bugprone checks and set options for two of them.
I thought I have to use busybox to populate init filesystem and use cpio to make initramfs image and add it to the linux kernel source tree (like in arch/arm64/boot ?) before I build the kernel. But if I skip the process and just build the kernel, does it contain a kind of default initramfs? or does it have empty initramfs? (many examples on the web doesn't show busybox procedures.. )
If I build linux kernel from source, does it contain initramfs inside by default?
Yes, but it will be empty (by default).
As stated in Documentation/filesystems/ramfs-rootfs-initramfs.txt:
The 2.6 kernel build process always creates a gzipped cpio format initramfs
archive and links it into the resulting kernel binary. By default, this
archive is empty (consuming 134 bytes on x86).
You can populate the initramfs with either an internal or external cpio archive.
Use CONFIG_INITRAMFS_SOURCE to point to a cpio archive file, which will be embedded into the kernel image.
Otherwise an (external) cpio archive file can be specified during boot by using the old initrd mechanism.
If an initrd/initramfs is passed to the arm64 kernel at boot, it must reside entirely within a 1 GB aligned physical memory window of up to 32 GB in size that fully covers the kernel Image as well.
The cpio archive needs to contain an init file in order to inhibit the further processing for mounting a root filesystem. As documented:
After extracting, the kernel checks to see if rootfs contains a file "init",
and if so it executes it as PID 1.
If found, this init process is responsible for bringing the system the
rest of the way up, including locating and mounting the real root device (if
any).
If rootfs does not contain an init program after the embedded cpio
archive is extracted into it, the kernel will fall through to the older code
to locate and mount a root partition, then exec some variant of /sbin/init
out of that.
Busybox can be built to provide that init file.
ADDENDUM
I had found CONFIG_INITRAMFS_SOURCE value in my old .config file (year 2013~2014) was set to just empty (set to " ").
A string of a single space does not make sense.
Did you mean an empty string, as in "" which is the default value?
The default value means that no archive for the initramfs is to be built with the kernel image.
Now I just now found CONFIG_RD_GZIP=y too in the file.
That simply enables support for loading of a gzip-encoded initial ramdisk or cpio buffer. It is just one of several compression methods available that can be configured. There could also be support for bzip2, LZMA, XZ, LZO, and LZ4.
The salient configuration symbol would be CONFIG_BLK_DEV_RAM, which would enable RAM disk support.
At that time we put busybox120.gz file under arch/sparc/boot before doing linux 'make sImage'. so I guess when there is a .gz file under arch/sparc/boot, the kernel build system uses that .gz file as the initramfs.
No, simply storing a file in a directory is not going to cause inclusion in the kernel build.
Since no initramfs file is specified, the likeliest use of that busybox120.gz file would be for a ramdisk.
Archives are typically named with .cpio or .tar filename extensions. Your file has neither, so that could mean that it is not an archive. The absence of an archive extension could mean that it is an image file, which would never be used for a ramfs but could be used for a ramdisk (or initrd).
AFAIK an image (or archive) for the initrd is loaded by the boot program (ref: Using the initial RAM disk (initrd)) rather than linked in.
Check the kernel command line used with that kernel image.
Are there parameters that specify a ramdisk, e.g. initrd=... and/or root=/dev/ram0?
Be sure that you do not conflate initramfs and initrd. See Documentation/filesystems/ramfs-rootfs-initramfs.txt and
The difference between initrd and initramfs?
I'm looking at this example which uses deployment manager to deploy a cloud function: https://github.com/GoogleCloudPlatform/deploymentmanager-samples/tree/master/examples/v2/cloud_functions
One of the things that makes this unwieldy and not very usable is this, it requires you explicitly import EVERY file in the function:
imports:
- path: cloud_function.py
# The function code will be defined for the files in function/
- path: function/index.js
- path: function/package.json
It's not acceptable to have to add to that every time there is a new file. Deployment Manager also does not support wildcards.
How can you import files programmatically?
This is the part of cloud_function.py that references the imported files, I tried to just use a string but it seems that import actually copies files somewhere? How do I do that programmatically so I don't need to explicitly define every individual file?
files = ["function/index.js","function/package.json"] # this does not work if these files have not been declared via "import"
#for imp in ctx.imports:
for imp in files:
if imp.startswith(ctx.properties['codeLocation']):
zip_file.writestr(imp[len(ctx.properties['codeLocation']):],
ctx.imports[imp])
You have to turn on globbing, in this way config files can now use glob patterns in import paths:
gcloud config set deployment_manager/glob_imports True
Here are examples where entire folders can be added:
imports:
- path: templates/simple_frontend.py
name: simple_frontend.py
# Helper classes
- path: helper/*.py
# Configuration files
- path: configs/*.yaml
- path: configs/*/*.yaml
The full documentation can be found here.
I am trying to follow the example here and create my own dataset for training using MXnet. My data is organized as specified in the example:
/data
yes/
file1.png
file2.png
...
no/
file1.png
file2.png
...
The tutorial says the first step is to run im2rec.py to create a .lst file, then run im2rec.py again (different options) to create the .rec file. To create the .lst file I type:
> python tools/im2rec.py my_data /data --list True --recursive True --train-ratio .75 --exts .png
After doing this, two files are created (as expected), my_data_train.lst and my_data_val.lst. The total number of lines in the two files is the same as the number of files in my yes/ and no/ directory combined. Then, I attempt to run im2rec a second time to create the .rec file using:
> python tools/im2rec.py my_data /data --resize 227 --num-thread 16
This runs for a few seconds and then (silently) crashes. In the process it creates 4 empty files: my_data_train.idx, my_data_train.rec, my_data_val.idx, and my_data_val.rec.
Question: What do I need to do differently to be able to create a proper .rec file containing my own .png images?
Extra Details:
I am working inside a docker container (mxnet/python:gpu) provided by dmlc on docker hub; they also provided the example on their github page. The data is available through a shared directory in the container. So it is presumably possible that this is a docker issue. What makes me slightly worried that it is a docker issue is that I had to pip install opencv-python in order for im2rec to be able to import cv2... I would have hoped that the people providing the container would have taken care of this.
You are right that the image is missing opencv for python. Instead of installing via pip, please do apt-get install python-opencv.
PR posted here: Using im2rec in MXnet to create dataset with png images
I have created a gstreamer plugin with an element inside that would generate some data when put in a pipeline (by following the GStreamer Plugin Writer's Guide).
My problem is that I cannot load my plugin in a test application. When I call gst_element_factory_make("myextractor", NULL) the result is always NULL.
More data (I'm not sure this is related):
When I run gst-inspect on my dll I get incomplete output (output generated using cygwin):
beq11049#beqleuleu1nb028 /cygdrive/c/work
$ /cygdrive/c/OSSBuild/GStreamer/v0.10.6/bin/gst-inspect.exe MyProject/Release/gstxyzlibrary.dll
Plugin Details:
Name: myextractor
Description: XYZ Library
Filename: MyProject/Release/gstxyzlibrary.dll
Version: 1.0
License: LGPL
Source module: myextractor
Binary package: MyProject
Origin URL: http://www.example.com/
myextractor: XYZExtractor
1 features:
+-- 1 elements
If I compare this with the avisubtitle addon (from the GStreamer Good Plug-ins package) I get a lot less information for mine.
For example, my plugin says:
1 features:
+-- 1 elements
The avisubtitle plugin says (generated using $ /cygdrive/c/OSSBuild/GStreamer/v0.10.6/bin/gst-inspect.exe avisubtitle):
GObject
+----GstObject
+----GstElement
+----GstAviSubtitle
My question: I need advice on how to debug this / determine what I am missing (enabling debugging output, settings and paths to check and so on). My test code (the call to gst_element_factory_make) is written in a Songbird adon, but I get the same results if I put my code in a separate executable.
It might be because the loader can't find your plugin, you should check that your plugin is in the shared library path:
Make sure you've set the LD_LIBRARY_PATH environment variable to the directory containing your compiled plugin.
In cygwin, add this to your .profile, or run it before you run your program:
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/cygdrive/c/path/to/your/plugin/"
You could also use the -L linker option to specify a search path at compile time.
I am not sure how to answer your question, because there might be several things missing. I think about unresolved symbol depedencies (although unlikely, since you can actually inspect your plugin) or wrong registration, somehow (it's also difficult to get it wrong), perhaps issue with songbird or windows that I ignore.
However, I just want to clear out one thing: GStreamer has "plug-ins" (aka dynamically loadable library) that can contain one or more elements. When you gst-introspect the plug-in or the element, you get different outputs! In the case of "avisubtitle", it's an element, and you can read the class hierarchy. If you introspect the plugin (or the library) "avi" or "/usr/lib/gstreamer-0.10/libgstavi.so" (on Unixes), you get the list of elements it contains and some common properties (version, project etc..).
For example, gst-introspect XYZ (XYZ a library or a path to a library) is different than gst-introspect XYZ (XYZ the name of the element in the XYZ library)
Perhaps that will helps you. good luck! Oh, and errors/warning can be displayed with the environment variable GST_DEBUG=*:2