I m using buildroot to create a filesystem for a Raspberry Pi. I have uncompressed the filesystem image in the Root partition of my SD card but I can't boot the operative system. I get the following errors:
Can't open /dev/null no such file or directory
Can't open /dev/ttyS0 no such file or directory
Which line of the configuration tool should I enable or modify in order to boot the system?
EDIT
I've followed the steps provided by Thomas Petazzoni and used a preconfigured version of buildroot. Now the system works but I still don't know which option in the kernel configuration tool was causing the problem.
You don't have devtmpfs enabled in your kernel.
Also, you should start by using the raspberrypi_defconfig in Buildroot instead of rolling your own. Do:
make distclean
make raspberrypi_defconfig
make
And then follow the instructions in board/raspberrypi/readme.txt to know how to use the resulting images.
Related
Hi I am working on building a disk image which can run PARSEC benchmarks on QEMU, I got everything working, but when I run a benchmark I get it tells me that it can't generate files because it is a read-only file system. Is there an option to disable this in Buildroot menuconfig?
Thanks all !
There is an option remount root filesystem read-write during boot in the System configuration menu in make menuconfig. It defaults to on. If you disable it, the root filesystem will be readonly.
I'm using Yocto on Ubuntu 18.04 with the Warrior Branch of Meta-Tegra in order to try to integrate the RAUC Open Source project for Linux Firmware Updates.
I've learned that U-Boot has issues writing to EXT4 partitions ( to update the U-Boot Env ) if the EXT4 filesystem it is writing to has the metadata_csum attribute. Linux cannot mount the Root Filesystem if that attribute is enabled and U-Boot writes at all to it.
Here are some posts on that:
https://patchwork.ozlabs.org/patch/818337/
http://u-boot.10912.n7.nabble.com/PATCH-1-1-fs-ext4-do-not-write-on-filesystem-with-metadata-csum-feature-td362715.html
I proved that this is the case by mounting the resulting SDCARD image from Yocto on Ubuntu and running the following command to disable metadata_csum:
sudo tune2fs -O ^metadata_csum /dev/sdb1
tune2fs 1.44.1 (24-Mar-2018)
Disabling checksums could take some time.
Proceed anyway (or wait 5 seconds to proceed) ? (y,N) y
After running that command - U-Boot can read/write at will from U-Boot space and Linux can mount the Root File System.
I am trying to figure out how to disable the checksums with Tune2fs on Ubuntu at image creation time with Yocto. Where/How can I add this so that the image has checksums disabled at image creation time from Yocto?
I briefly looked over meta-tegra and I think it uses the ext4 root filesystem image created through image_class.bcclass. You can add parameters to the mkfs.ext4 thorugh EXTRA_IMAGECMD. It should be possible to just create the filesystem with metadata_csum disabled, instead of turning it off later.
Try
EXTRA_IMAGECMD_append = " -O ^metadata_csum"
in your local.conf
I'm building an LFS (Linux From Scratch) system in a VM and so far I've managed to get a workable, desktop system, booting from a known device, /dev/sda1 in my case. I'm now trying to make a live system that boots from an ISO image. Instead of using /dev/sr0 as the root, which I've already established is possible (and, since it's more likely to be used from a USB stick than an actual CD-ROM, is too inflexible) I've set my mind on booting it into an initrd root. The idea is to use that as the system's root instead of using it as a temporal root to load the "real" root, and since it's already in memory, it saves me the trouble of setting up a tmpfs root, copy all the files, and switch to it.
I had been previously been experimenting with a squashfs image as I had seen that Ubuntu seemed to use that and has what I needed: a small sized root, being faster to load, using less memory, and is fast (xz is SSLLOOWW to extract and gzip is slow to load). At first I was having trouble booting it, so i switched to the cpio based initrd. After some initial trouble due to missing files on the archive I did manage to boot it.
I left that aside for the time being (around a month ago) to do other tasks on the system. I lost the original GRUB2 settings and kernel config so went about doing it again but Ive been running into a brick wall. I'm hoping someone here might know what I'm missing.
When I boot up I never see any message about the loading of the initrd file, it goes straight into the loading, uncompressing and booting up of the kernel. And this ends up in a kernel panic with the message
VFS: cannot open root device "(null)" or unknown-block (1,0): error -6
Please append the correct "root=" boot option; here are the available partitions:
No partitions are shown and following that is the "kernel panic" message, just repeating the first line. If I use the "rootfstype=ramfs" I get:
VFS: mounted root (ramfs filesystem) readonly on device 0:15.
devtmpfs: error mounting -2
Essentially, it's mounting an EMPTY ramfs file system as root, so mounting the devtmpfs fails because the /dev entry doesn't exist. But certain I used that boot option before.
Here's my GRUB 2 config:
menuentry = "LFS (inird test)" {
linux /boot/kernel/initrd/linux ro rdinit=/etc/init
initrd /boot/kernel/initrd/root.cpio.gz
}
Yes, /boot/kernel/initrd/ directory entry exists, linux is the kernel (the bzimage file produced by compiling the kernel), and root.cpio.gz is my compressed initrd root cpio archive.
Here's my kernel's .config file (sorry can't paste it here).
If any more info is needed, don't hesitate to ask. That you.
OK, I managed to solve the problem! Apparently, it wasn't the kernel's configuration, GRUB2, or even the bootup sequence. It was the initrd archive itself. Deep in the bowels of the Linux kernel's configuration lied the answer: the archive must be built using cpio's --newc option. The one I built manually lacked this option, so the kernel was ignoring the archive and just proceeding with the normal boot procedure.
This came about because I managed to stumble across an older script I used to build them and saw all the options in it for cpio. I checked the much more recent script I hastily put together and double-checked the kernel documentation (as well as the init/do_mounts.c and init/initramfs.c files) and realized what was going on. I tried it with the corrections and the system now happily boots into the initrd with no problem! :D
I am developing applications on Beaglebone board with Angstrom Linux distro.
I tend to mount root file system as read only because, it is not robust on readable/writeable configuration across power offs.
Can you make suggestions about how to mount root file system as read only?
What are the steps for mounting root file system read only and then turn it back to readable/writable?
With these step i tend to get a more robust file system.
Regards
You would need to edit the boot arguments that you pass to the kernel to use ro instead of rw for mounting the root file system. For example root=/dev/mmcblk0p1 ro. They are modifiable via the uboot environment variables
On a similar Angstrom-based system, I got the same "must specify the filesystem type" message.
After trying a few different things, I was able to remount root as ro using:
busybox mount -o remount,ro /
I have to admit I'm not certain why calling busybox directly worked when the "mount" command (which is a link to busybox) did not work, but I didn't have time to dig further.
I tried using make defconfig to compile the kernel, but as expected, it failed to boot. I was wondering what .config file do kernel vendors like Canonical for Ubuntu use, that the kernel is able to boot right out-of-the-box. Of course, I am still a beginner and configuring the various parameters, is a little out of my league currently.
Specifically,I am looking to load a basic "hello, world!" module to my running kernel 2.6.32.41. For that, I would need to compile kernels source against the same .config file that was used for the running kernel.
If your running kernel was compiled with the CONFIG_IKCONFIG_PROC option, you can get the config in /proc/config.gz:
$ zcat /proc/config.gz >my_config
Copy my_config into your kernel build directory as .config and run make config to be prompted for configuration options that are absent from your config file (this will only happen if you are using a kernel source that is newer than your running kernel). You should then be able to compile a new kernel with the same features as your current one.
Distros typically use their own kernel configuration, where most of the drivers are compiled as modules to be dynamically loaded when the corresponding hardware is requested. Also the kernel needs to be booted with relevant boot options (like the one specifying the root filesystem). Your defconfig kernel probably failed to boot because of that.
I don't know about getting the one that's "correct for your hardware", but you can use the config that Ubuntu gives you by looking in /boot/ for a file starting with the name config. There may be more than one, in which case use the command uname -r to tell which kernel you're currently running, and then you can use the appropriate config.
option1:
source code of your booted system
cd /usr/src/linux-headers-3.2.0-29;
this will generate .config
sudo make oldconfig;
vi .config
option2:
zcat /proc/config.gz > my_config
option3:
echo /boot/config* > my_config
"defconfig" is usually pegged at the commonly used hardware - x86, or x86_64, and perhaps not so recent chipset or motherboard. Sometimes, like my Lenovo laptop, only the latest kernel source, and with enabling some config option, after googling through the bugzilla database, will it work.
Like what Jeff Welling said, to get the config in use, u can look under /boot directory. Same for my Fedora Core too. But if u want to compile a basic program as a "kernel module", and by that it simply means "loadable kernel module", u don't need to compile the kernel source. U just need the kernel headers for that current version. For example, "apt-cache search" in Ubuntu 10.04 returns several possible option:
linux-headers-2.6.38 - Header files related to Linux kernel, specifically,
linux-libc-dev - Linux Kernel Headers for development
Ubuntu normally patched the stock kernel (from kernel.org) to have their own kernel. If u have downloaded the stock kernel, and attempt to use the /boot's config file (or sometimes u can find the currently loaded config as /proc/config.gz, like the Backtrack's Ubuntu, which is based on 10.04 LTS), then u may need to do a "make oldconfig" with the current config file named as ".config". "make oldconfig" will then use the .config to generate a new .config that is compatible with the kernel source.