内核将Azure上的虚拟磁盘识别为hda和sda

时间:2015-12-08 16:53:35

标签: linux azure hyper-v

我们有一个基于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!
...

1 个答案:

答案 0 :(得分:1)

我找到了解决方案:必须禁用Linux内核选项CONFIG_IDE。

太糟糕了,它默认启用..