Closed alexrallen closed 2 years ago
No function impact, but want to understand why the error message happened and how to clean it up.
I can confirm this is happening even in a KVM testbed, so it's not platform-specific.
kvm is using vda, so sda is not available on kvm, so it still could be platform specific issue.
kvm is using vda, so sda is not available on kvm, so it still could be platform specific issue.
Guohan as alex pointed out it is seen even in tech supports from Broadcom issues mentioned in the description and so I believe its not platform specific
The Can't open blockdev
message is coming from this line: https://github.com/Azure/sonic-buildimage/blob/9fe128c8e8bb44fa9959c482116541ce64b87486/files/initramfs-tools/union-mount.j2#L135
During initramfs, /dev/sda3
(or in the case of virtual switch, /dev/vda3
) is getting mounted at /root/host
. The mount
binary that runs isn't the mount binary that's available during normal runtime (when the system has fully booted), but the version coming from busybox, since we're in initramfs. As part of the mount sequence, if a filesystem type hasn't been given in the command with the -t
flag, the busybox mount code will go through /etc/filesystems
and /proc/filesystems
to see which filesystems are supported by the kernel, and then tries to mount /dev/vda3
using each filesystem listed there. The first one that succeeds is then used. (See this and this for the code that they use.)
In our initramfs environment, /etc/filesystems
doesn't exist, so only /proc/filesystems
is read. The first filesystem that is tested is squashfs
. For this filesystem, the mount code in the kernel goes through a code path that results in the Can't open blockdev
getting printed. This can be reproduced by running mount -t squashfs /dev/vda3 /root/host
in initramfs (the destination directory doesn't matter, and the mount may fail, but the kernel message will still get printed). The next filesystems that get tested are vfat
, ext3
, and ext2
, all of which fail with a "Device or resource busy" error from the mount command (there's no error message in the kernel for this). The last filesystem that gets printed is ext4
, which does succeed.
This kernel message and the filesystem type testing can be avoided by passing in the filesystem type of the mount command, by changing the command to mount -t ext4 ${ROOT} ${rootmnt}/host
.
Description
On the master branch recently we are seeing the following error during boot
This issue is reproducing on all Mellanox platforms. It also seems to be reproducing on some broadcom platforms as well (see logs from https://github.com/Azure/sonic-buildimage/issues/9028 and https://github.com/Azure/sonic-buildimage/issues/9898)
This issue is a recent degradation (unsure of the exact hash) as we did not detect this issue during prior analysis of master branch syslog errors.
Steps to reproduce the issue:
Version