I am trying to enable systemd's libcryptsetup module in order to decrypt a drive at bootup through crypttab. It seems crypttab is not present because the systemd-cryptsetup-generator is missing from the systemd (216) build.
I have tried specifying the "cryptsetup" option in the PACKAGECONFIG?? statement and also specifying --enable-libcryptsetup as argument in the build but the option is disabled by the config script bitbake uses (it appends automatically --disable-cryptsetup after my enable statement)
I suspect this is because configure detected some missing dependency, therefore I tried specifying that the systemd recipe depends on the cryptsetup recipe but I ended in a recipe loop (cryptsetup depends on lvm2 which depends on systemd, so cryptsetup will not be buildable before systemd is built).
Does anyone have any suggestion or encountered a similar issue? Thanks!
Adding "cryptsetup" to PACKAGECONFIG either via a direct change in the recipe, or a bbappend or local.conf, should do the trick. What release of OE are you using, can you paste your changes, and ideally the beginning of the log.do_configure where it shows what the configure options are.
And you'll see --enable --disable if you attempted to enable it directly in EXTRA_OECONF but didn't delete the PACKAGECONFIG[cryptsetup] line which it thinks is disabled (so adds the disabled flag for you).
Related
1. What I am trying to achieve:
Build a custom kernel so I can install and run Anbox-git from AUR on my Arch laptop. Custom kernel is needed for the package to work.
2. What I did to achieve it:
Download Arch Linux kernel v5.8.5-arch1 from here
I followed the guidelines on tradional compilation Arch wiki to create the custom kernel
Via make nconfig I applied the changes mentioned in the Anbox Arch wiki page.
Via make nconfig I changed EFIVAR_FS option from "M" to "*" to resolve an error from earlier attemps.
Via make nconfig under Location: -> Device Drivers-> Multiple devices driver support (RAID and LVM) (MD [=y])-> Device mapper support (BLK_DEV_DM [=y]) I added a few more options (*) because on earlier builds mkinitpcio gave errors for missing modules for DM_CRYPT, and some more DM_ modules which I cannot easily reproduce (will do if necessary for the answer, but I hope it'll be irrelevant).
After creating the config this way I did:
sudo make modules_install
sudo cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-linux58ac
sudo cp /etc/mkinitcpio.d/linux.preset /etc/mkinitcpio.d/linux58ac.preset
Adapted the preset file per Arch wiki instructions
sudo mkinitcpio -p linux58ac
Important: The mkinitpcio runs fine, but keeps giving me a warning:
WARNING: No modules were added to the image. This is probably not what
you want.
sudo grub-mkconfig -o /boot/grub/grub.cfg
3. Expected result:
I am able to reboot, select the new kernel from grub menu, get the usual LVM password prompt, and launch into it without problems.
4. Result I get:
I can reboot and select new kernel from grub but when I select it I get a
Warning: /lib/modules/5.8.5-arch1/modules.devname not found, ignoring.
Starting version 246.4-1-arch
ERROR device 'dev/mapper/vg0-root' not found. Skipping fsck.
mount /new_root: special device /dev/mapper/vg0-root does not exist.
You are being dropped into an emergy shell.
I checked and the /lib/modules/5.8.5-arch1/modules.devnamedoes indeed exist. But I think the actual problem is that mkinitcpio doesn't load the correct modules into the custom kernel, causing it to become unbootable.
Any help appreciated!
I'm building a Poky-based embedded Linux distribution for a target which doesn't have a real-time clock. System time is only set by ntpd. Therefore I don't really need an init script which calls hwclock --hctosys during boot, and in fact I'm afraid that this might cause the system time which is set by ntpd to be
overwritten with an incorrect value.
So how do I get rid of the hwclock init script? It turns out that it comes from the busybox recipe. The default recipe for busybox in Poky contains the following lines:
PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev ${PN}-hwclock"
...
FILES_${PN}-hwclock = "${sysconfdir}/init.d/hwclock.sh"
...
INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev ${PN}-hwclock"
...
INITSCRIPT_NAME_${PN}-hwclock = "hwclock.sh"
I have no idea how to remove all the references to hwclock from within a *.bbappend file. Is there any straightforward solution, or is it not possible from a bbappend and I have to re-write the entire recipe?
You can disable it from its defconfig file by configuring CONFIG_HWCLOCK=n located at openembedded-core/meta/recipes-core/busybox/busybox/defconfig.
If you want to exclude packages from a build and don't want to resort to manipulating working recipes, just so a PACKAGE_EXCLUDE = "<package_name>" in your local.conf
This is an example of mine:
PACKAGE_EXCLUDE = "busybox-syslog busybox-hwclock"
But note that some packages may depend on hwclock. You'll get a bitbake dependency error at worst.
i am trying to build os-image using bitbake in yocto project. i got the following error.
../util-linux-2.28.1/schedutils/chrt.c:88:17: error: ‘__NR_sched_setattr’ undeclared (first use in this function)
i followed the instructions given in Mega Manual of yocto. how to resolve this build error?
This type of error messages appear when some user space program or library is being built for kernel that doesn't support some system call, sched_setattr in this case. Either you build on very old linux (appeared in 3.14) or which is most probable the arch you are building on doesn't support this system call (you haven't specified which arch you are building on, so I cannot check).
Either way, it's possible to disable this particular part of util-linux with configuration option --disable-schedutils. You won't get chrt, ionice, taskset (process manipulation) tools on your device in this case but they are probably not very useful for you.
In yocto build environment, you can first modify recipe for util-linux, well actually include file for recipe (meta/recipes-core/util-linux/util-linux.inc), by adding one line:
SHARED_EXTRA_OECONF = "--disable-use-tty-group \
--disable-makeinstall-chown \
...
--disable-schedutils \
"
and check if it works for you. Later you can add
EXTRA_OECONF_append_util-linux = " --disable-schedutils"
to your conf/local.conf or to util-linux bbappend file in your working meta layer (if you have it).
It's probably finding ncurses headers from your host machine when it should only be looking in the Yocto sysroot. There's a patch that fixes this, it will probably end up in master soon. Either use the patch locally for now or as a workaround remove libncurses6 and libncursesw6 development packages from your build host.
I have a check for a header file in configure.ac in the source root
AC_CHECK_HEADER(log4c.h,
[],
[AC_MSG_ERROR([Couldn't find or include log4c.h])])
and I'd like to give different feedback on different platform to reflect different most straight forward ways of providing the header:
on Debian it should error with the message Couldn't find or include log4c.h. Install log4c using 'sudo apt-get install liblog4c-dev'
on OpenSUSE it should error with ... Install log4c using 'sudo yum install log4c-devel' (didn't research the package name, but you catch my drift)
on other systems (where I'm too lazy to research the package name) it should error with ... Install log4c by fetching ftp://.../log4c.tar.gz and installing with './configure && make && make install' in the source root
I
checked the AM_CONDITIONAL macro, but I don't get how to use it in configure.ac rather than in Makefile.am (as described in autoconf/automake: conditional compilation based on presence of library?)
found the tip to run esyscmd in stackoverflow.com/questions/4627900/m4-executing-a-shell-command, but adding esyscmd (/bin/echo abc) to configure.ac doesn't print anything when I run autoreconf --install --verbose --force.
Both answers describing the usage of conditional macros without the shell commands for the mentioned OS and links to predefined macros (like AC_CHECK_HEADER_DEBIAN, AC_CHECK_HEADER_SUSE, etc.) are appreciated.
The following configure.ac doesn't work:
AC_INIT([cndrvcups-common], [2.90], [krichter722#aol.de])
AC_CONFIG_MACRO_DIR([m4])
AM_INIT_AUTOMAKE([foreign -Wall subdir-objects])
AC_PROG_CC
AM_PROG_AR
AM_PROG_CC_C_O
AC_MSG_NOTICE([Hello, world.])
AC_INCLUDES_DEFAULT
AC_CHECK_HEADER(check.h,
[],
[
AS_IF (test "$(lsb_release -cs)" = "vivid", [echo aaaaaa], [echo bbbbbb])
])
LT_INIT # needs to be after AM_PROGS_AR
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
because ./configure fails with
checking check.h usability... no
checking check.h presence... no
checking for check.h... no
./configure: line 4433: syntax error near unexpected token `;'
./configure: line 4433: ` if ; then :'
There's also ./configure: line 4427: #include: command not found which happens no matter whether AC_CHECK_HEADER is specified.
Your configure.ac is almost ok. The only problem is space between AS_IF and the parenthesis. No whitespace is allowed between a macro name and the opening parenthesis in m4 scripts. This is correct syntax:
AC_CHECK_HEADER(check.h,
[],
[
AS_IF(test "$(lsb_release -cs)" = "vivid", [echo aaaaaa], [echo bbbbbb])
])
If you are looking for a way to detect different distros look for example at configure.ac of cgmanager.
Update
I noticed one more problem in your configure.ac.
AC_INCLUDES_DEFAULT macro expands to a set of default includes and can't be used here. It is not needed also. It will be used by default in your AC_CHECK_HEADER macro, as you omit last parameter.
This is the cause of line 4427: #include: command not found error you mention.
Update to your comment
First of all, running a system command itself, like lsb_release is not portable. You should first check, for example with AC_CHECK_PROG, for its presence.
Regarding the syntax I would first get the output of the command using backticks: result=`lsb_release -cs` and later test resulting output: test "x$result" = "xvivid". x is needed to avoid problems with empty value in some shells.
At last, I have doubts whether configure script is a proper place for all this distro specific messages. You may consider placing it in the README file.
Avoid those system specific messages.
Print one message which allows people to figure out what package to install on their respective system, but avoid naming the system specific package names and system specific installation tools.
You will never be able to add messages for all systems, so it is better to go the part of the way which you know and let your users go the rest of the way because they know their systems better than you can.
The proper way would be to write a software package outside but called from your configure which, given a header filename, foo.pc filename, library name, etc. figures out how to install that on the respective system. Then let system specific maintainers fix that package, and call it from configure if it is installed, and issue a generic error message otherwise.
A portable shell script local to your software package might do the same job to some extent. You still have to maintain all the system specific parts for all possible systems, though.
Hmm... now that I am thinking about that, the idea appears not that bad. I might add such a script to some of the projects I maintain and see how it turns out in practical use.
I would still try to keep most of that logic outside configure, though.
I know the purpose of "biosdevname" feature in Linux, but I'm not sure how
exactly it works.
I tested it with Ubuntu 14.04 and Ubuntu 14.10 (both 64-bit server editions)
and it looks like they enable it by default - right after system startup my
network interface has a name such as p4p1 instead of eth0, no customization
is needed. As I understood it, in order for biosdevname to be enabled, BOTH
of these two conditions must be met:
a boot option biosdevname=1 must be passed to a kernel
biosdevname package must be installed
As I already mentioned, both Ubuntu 14.04 and 14.10 seem to offer biosdevname
as a default feature: they come with biosdevname package already installed, I
didn't need to modify grub.cfg either - GRUB_CMDLINE_LINUX_DEFAULT has no
parameters and my network interface still has a BIOS name (p*p*) instead of a
kernel name (eth*.)
Later I wanted to restore the old style device naming and that's where the
interesting part begins. I decided to experiment a bit while trying to disable
the biosdevname feature. Since it requires biosdevname package to work (or
so I read here and there), I assumed removing it would be enough to disable the
feature, so I typed:
sudo apt-get purge biosdevname
To my surprise, after reboot my network interface was still p4p1, so
biosdevname clearly still worked even though biosdevname package had been
wiped out.
As a next step, I applied appropriate changes to /etc/network/interfaces in
order to restore the old name of my network interface (removed entry for p4p1
and added entry for eth0). As a result, after another reboot, ifconfig
reported neither eth0 nor p4p1 which was another proof that OS still
understood BIOS names instead of kernel names.
It turned out that I also had to explicitly change GRUB entry to
GRUB_CMDLINE_LINUX_DEFAULT=biosdevname=0 and update GRUB to get the expected
result (biosdevname disabled and old name of network interface restored).
My question is: how could biosdevname work without biosdevname package? Is
it not required after all? If so, what exactly provides the biosdevname
functionality and how does it work?
The reason biosdevname keeps annoying you even after you uninstall the package, is that it installed itself in the initrd 'initial ramdisk' file as well.
When uninstalling, the /usr/share/initramfs-tools/hooks/biosdevname is removed, but there is no postrm script in the package so update-initramfs is not executed and biosdevname is still present in the /boot/initrd... file used in the first stage of system startup.
You can fully get rid of it like this:
$ sudo update-initramfs -u