I created a core-image-full-cmdline Image for the intel-corei7-64 machine and have some big troubles booting it via grub (and everything else). The Image boots without any trouble from a usb drive but when I dd it to the SSD it always gets an kernel panic saying:
VFS: Cannot open root device “sda2” or unknown-block(0,0): error -6
Please append a correct “root=” boot option; here are the available partitions:
For me this looks like my ssd is not detected. Even with other grub configurations like root=/dev/mmcblk0p2 I get the same error.
I tried a lot to solve this but everytime I found a thread about this topic, this error is never answered.
I hope anybody of you can help me with that problem.
You should not need to add this manually, and I suspect that something is going wrong during the build. That is why it is cascading in to further errors.
Can you please share the content of the generated grub.cfg from your device?
# Start of ---------- 00_mender_grubenv_defines_grub.cfg ----------
mender_rootfsa_part=2
mender_rootfsb_part=3
mender_kernel_root_base=/dev/sda
mender_grub_storage_device=hd0
kernel_imagetype=bzImage
# End of ---------- 00_mender_grubenv_defines_grub.cfg ----------
# Start of ---------- 01_console_bootargs_grub.cfg ----------
set console_bootargs="console=tty0,115200n8 console=ttyS0,115200n8 console=ttyO0,115200n8 console=ttyAMA0,115200n8"
# End of ---------- 01_console_bootargs_grub.cfg ----------
set rootargs="rootwait"
# Start of ---------- 05_mender_setup_grub.cfg ----------
# See the fw_printenv script for how this works.
function maybe_pause {
# By default we do nothing. debug-pause PACKAGECONFIG replaces this so we
# can pause at strategic places.
echo
}
# Load environment.
MENDER_ENV1=${prefix}/mender_grubenv1/env
MENDER_ENVPREFIX1=${prefix}/mender_grubenv1/
MENDER_LOCK1=${prefix}/mender_grubenv1/lock
MENDER_LOCKSUM1=${prefix}/mender_grubenv1/lock.sha256sum
MENDER_ENV2=${prefix}/mender_grubenv2/env
MENDER_ENVPREFIX2=${prefix}/mender_grubenv2/
MENDER_LOCK2=${prefix}/mender_grubenv2/lock
MENDER_LOCKSUM2=${prefix}/mender_grubenv2/lock.sha256sum
function mender_check_and_restore_env {
if ! hashsum --hash sha256 --prefix ${MENDER_ENVPREFIX2} --check ${MENDER_LOCKSUM2}; then
load_env --skip-sig --file ${MENDER_ENV1} bootcount mender_boot_part upgrade_available
save_env --file ${MENDER_ENV2} bootcount mender_boot_part upgrade_available
editing=0
save_env --file ${MENDER_LOCK2} editing
if ! hashsum --hash sha256 --prefix ${MENDER_ENVPREFIX2} --check ${MENDER_LOCKSUM2}; then
echo "Environment 2 still corrupt after attempted restore. Halting."
halt
fi
elif ! hashsum --hash sha256 --prefix ${MENDER_ENVPREFIX1} --check ${MENDER_LOCKSUM1}; then
load_env --skip-sig --file ${MENDER_ENV2} bootcount mender_boot_part upgrade_available
save_env --file ${MENDER_ENV1} bootcount mender_boot_part upgrade_available
editing=0
save_env --file ${MENDER_LOCK1} editing
if ! hashsum --hash sha256 --prefix ${MENDER_ENVPREFIX1} --check ${MENDER_LOCKSUM1}; then
echo "Environment 1 still corrupt after attempted restore. Halting."
halt
fi
fi
}
function mender_save_env {
# Save redundant environment.
editing=1
save_env --file ${MENDER_LOCK2} editing
save_env --file ${MENDER_ENV2} bootcount mender_boot_part upgrade_available
editing=0
save_env --file ${MENDER_LOCK2} editing
editing=1
save_env --file ${MENDER_LOCK1} editing
save_env --file ${MENDER_ENV1} bootcount mender_boot_part upgrade_available
editing=0
save_env --file ${MENDER_LOCK1} editing
}
function mender_check_grubenv_valid {
if [ "${mender_boot_part}" != "${mender_rootfsa_part}" -a "${mender_boot_part}" != "${mender_rootfsb_part}" ]; then
return 1
fi
if [ "${bootcount}" != "0" -a "${bootcount}" != "1" ]; then
return 1
fi
if [ "${upgrade_available}" != "0" -a "${upgrade_available}" != "1" ]; then
return 1
fi
return 0
}
mender_check_and_restore_env
# Now load environment.
# Skipping signatures?? Yes, because these values will change over time, so they
# cannot be signed. There is also no checksum facility that will work for
# changing values. Instead we check their content for validity.
load_env --skip-sig --file ${MENDER_ENV1} bootcount mender_boot_part upgrade_available
if ! mender_check_grubenv_valid; then
if [ "${check_signatures}" == "enforce" ]; then
echo "Unverified environment and signatures enabled. Halting."
halt
fi
fi
if [ "${upgrade_available}" = "1" ]; then
if [ "${bootcount}" != "0" ]; then
echo "Rolling back..."
if [ "${mender_boot_part}" = "${mender_rootfsa_part}" ]; then
mender_boot_part="${mender_rootfsb_part}"
else
mender_boot_part="${mender_rootfsa_part}"
fi
upgrade_available=0
bootcount=0
else
echo "Booting new update..."
bootcount=1
fi
mender_save_env
fi
# End of ---------- 05_mender_setup_grub.cfg ----------
# Start of ---------- 10_bootargs_grub.cfg ----------
set bootargs="${bootargs} ${console_bootargs} ${rootargs}"
# End of ---------- 10_bootargs_grub.cfg ----------
# Start of ---------- 90_mender_boot_grub.cfg ----------
if test -e (${mender_grub_storage_device},gpt${mender_boot_part})/; then
ptable_type=gpt
else
ptable_type=msdos
fi
if test -n "${kernel_devicetree}"; then
if test -e (${mender_grub_storage_device},${ptable_type}${mender_boot_part})/boot/${kernel_devicetree}; then
devicetree (${mender_grub_storage_device},${ptable_type}${mender_boot_part})/boot/${kernel_devicetree}
fi
fi
if [ test -n "${mender_rootfsa_uuid}" -a test -n "${mender_rootfsb_uuid}" ]; then
if [ "${mender_boot_part}" = "${mender_rootfsa_part}" ]; then
mender_root="PARTUUID=${mender_rootfsa_uuid}"
elif [ "${mender_boot_part}" = "${mender_rootfsb_part}" ]; then
mender_root="PARTUUID=${mender_rootfsb_uuid}"
fi
else
mender_root="${mender_kernel_root_base}${mender_boot_part}"
fi
if linux (${mender_grub_storage_device},${ptable_type}${mender_boot_part})/boot/${kernel_imagetype} root=${mender_root} ${bootargs}; then
maybe_pause "Pausing before booting."
boot
fi
maybe_pause "Pausing after failed boot."
# End of ---------- 90_mender_boot_grub.cfg ----------
# Start of ---------- 95_mender_try_to_recover_grub.cfg ----------
if [ "${upgrade_available}" == "1" ]; then
reboot
fi
# End of ---------- 95_mender_try_to_recover_grub.cfg ----------
Yeah, that log does not give away why it is failing.
I would try to attach the SSD to a PC and make sure that I can mount all the partitions and do a sanity check of content, especially the rootfs partition since this is probably failing for some reason.
I do that for days now… What I find suspicious is that the /boot/ folder in the rootfs does not contain any initrd like microcode.cpio or initramfs.cpio.gz. Is this normal for a default mender built?
I do that for days now… What I find suspicious is that the /boot/ folder in the rootfs does not contain any initrd like microcode.cpio or initramfs.cpio.gz. Is this normal for a default mender built?
Yes this is normal in a Mender build.
I am curious, are you trying to integrate Mender in a existing Yocto setup or is it a “bare” setup with poky/oe-core + mender?
This whole Yocto - Mender thing is an experiment to see if it works with the hardware that I currently have available. So it’s just a base yocto setup with mender. Since I am not using super standard hardware like a beaglebone or raspberry pi I start to believe that the problems are on hardware site. I am using a x86 ipc with an intel atom chip.
One thing I’ve seen, esp on X86 PC-like systems, is that if there is a USB drive inserted, the device numbering can change. Can you make sure that the SSD is the only block device in the system when you try to boot?
If that turns out to be the case, then you likely will need to enable the mender-partuuid feature to use PARTUUIDs rather than device node names.
You are right, it was only booting further because it detected the usb drive as /dev/sda… I now tried it with mender-partuuid enabled but I still got the kernel panic from my first post. Where do I have to enable mender-partuuid exactly? I put it in MENDER_FEATURES_ENABLE_append in local.conf and added
set it leads me to a build failure /dev/mmcblk0p2 Does not contain a valid PARTUUID path and for MENDER_STORAGE_DEVICE = "/dev/sda" its the same. Is partuuid the right way to work with SSD’s in Yocto builds?
