我们有一个基于LFS的自定义Linux,我们将其导入Azure。我们将它作为一个经典的虚拟机运行。
系统启动并且似乎运行良好,但虚拟磁盘发生了奇怪的事情。它们在hdX上作为ide磁盘出现一次,在sdx上作为sata磁盘出现一次。
[dl-azure-jp-east-pub-1:~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
hda 3:0 0 21G 0 disk
|-hda1 3:1 0 1024M 0 part
|-hda2 3:2 0 50M 0 part
|-hda3 3:3 0 100M 0 part
|-hda4 3:4 0 1K 0 part
|-hda5 3:5 0 5.9G 0 part
|-hda6 3:6 0 5.9G 0 part
`-hda7 3:7 0 8.1G 0 part
hdb 3:64 0 70G 0 disk
`-hdb1 3:65 0 70G 0 part
hdc 22:0 1 4G 0 disk
sda 8:0 0 21G 0 disk
|-sda1 8:1 0 1024M 0 part [SWAP]
|-sda2 8:2 0 50M 0 part /boot
|-sda3 8:3 0 100M 0 part
|-sda4 8:4 0 1K 0 part
|-sda5 8:5 0 5.9G 0 part /usr/backup
|-sda6 8:6 0 5.9G 0 part /
`-sda7 8:7 0 8.1G 0 part /shared
sdb 8:16 0 70G 0 disk
`-sdb1 8:17 0 70G 0 part
另外,如果你检查fdisk -l的输出,你会看到每个分区的开始/结束块hdXY等于sdXY。
使用内核3.18.16以及使用内核4.1.10时,会发生这种情况。
我还检查了Azure VM的XML配置文件,但它不包含有关磁盘控制器的任何信息。
有没有办法完全禁用ide / ata控制器? 还有其他想法如何解决这个问题?
顺便说一句,我发现这个的原因是dmesg中的大量日志条目:....
[ 4451.750444] hdb: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
[ 4451.750461] hdb: task_no_data_intr: error=0x04 { DriveStatusError }
[ 4451.750463] hdb: possibly failed opcode: 0xea
[ 4451.750563] hdb: wcache flush failed!
[ 4451.750840] hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
[ 4451.750856] hda: task_no_data_intr: error=0x04 { DriveStatusError }
[ 4451.750858] hda: possibly failed opcode: 0xea
[ 4451.750957] hda: wcache flush failed!
[ 4451.757472] hdb: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error }
[ 4451.757490] hdb: task_no_data_intr: error=0x04 { DriveStatusError }
[ 4451.757492] hdb: possibly failed opcode: 0xea
[ 4451.757606] hdb: wcache flush failed!
...
答案 0 :(得分:1)
我找到了解决方案:必须禁用Linux内核选项CONFIG_IDE。
太糟糕了,它默认启用..