Error informing the kernel about modifications to partition

本文记录了在CentOS 7.2中使用partprobe命令更新内核分区表时遇到的问题及解决办法。当使用parted创建分区后执行partprobe时,会因设备繁忙而失败。文中提到这可能是partprobe与CentOS 7.2内核的兼容性问题,并给出了使用partx命令作为替代方案。

centos7.2  partprobe 执行失败的问题

给ceph的osd配置分区的过程中,想通过partprobe命令及时通知kernel去更新分区表,
所以用parted命令创建完分区后就执行partprobe命令,在centos7.1上代码跑得666的,
但是centos7.2上就发生如下蛋痛的问题:

[root@ai126251006028 udev]# partprobe
Error: Error informing the kernel about modifications to partition /dev/sdb1 -- Device or resource busy.  This means Linux won't know about any changes you made to /dev/sdb1 until you reboot -- so you shouldn't mount it or use it in any way before rebooting.
Error: Failed to add partition 1 (Device or resource busy)
[root@ai126251006028 udev]# partprobe
Error: Error informing the kernel about modifications to partition /dev/sdb1 -- Device or resource busy.  This means Linux won't know about any changes you made to /dev/sdb1 until you reboot -- so you shouldn't mount it or use it in any way before rebooting.
Error: Failed to add partition 1 (Device or resource busy)


到google上搜索发现针对ceph-deploy工具(http://ceph-users.ceph.narkive.com/nDZS0mBE/ceph-disk-from-jewel-has-issues-on-redhat-7 ),  有人提了相同的问题,用partx可以搞定。


[root@ai126251006028 udev]# partx -u /dev/sdd
[root@ai126251006028 udev]# partx -u /dev/sdd
[root@ai126251006028 udev]# partx -u /dev/sdd
[root@ai126251006028 udev]# partprobe
Error: Error informing the kernel about modifications to partition /dev/sdb1 -- Device or resource busy.  This means Linux won't know about any changes you made to /dev/sdb1 until you reboot -- so you shouldn't mount it or use it in any way before rebooting.
Error: Failed to add partition 1 (Device or resource busy)
[root@ai126251006028 udev]# partx -u /dev/sdd
[root@ai126251006028 udev]# partx -u /dev/sdd


感觉应该是partprobe跟centos7.2内核有地方不兼容导致的,暂时mark下。
翻译成中文,只做翻译: 9. Conflict Resolution A conflict occurs when a Multicast DNS responder has a unique record for which it is currently authoritative, and it receives a Multicast DNS response message containing a record with the same name, rrtype and rrclass, but inconsistent rdata. What may be considered inconsistent is context sensitive, except that resource records with identical rdata are never considered inconsistent, even if they originate from different hosts. This is to permit use of proxies and other fault-tolerance mechanisms that may cause more than one responder to be capable of issuing identical answers on the network. A common example of a resource record type that is intended to be unique, not shared between hosts, is the address record that maps a host's name to its IP address. Should a host witness another host announce an address record with the same name but a different IP address, then that is considered inconsistent, and that address record is considered to be in conflict. Whenever a Multicast DNS responder receives any Multicast DNS response (solicited or otherwise) containing a conflicting resource record in any of the Resource Record Sections, the Multicast DNS responder MUST immediately reset its conflicted unique record to probing state, and go through the startup steps described above in Section 8, "Probing and Announcing on Startup". The protocol used in the Probing phase will determine a winner and a loser, and the loser MUST cease using the name, and reconfigure. It is very important that any host receiving a resource record that conflicts with one of its own MUST take action as described above. In the case of two hosts using the same host name, where one has been configured to require a unique host name and the other has not, the one that has not been configured to require a unique host name will not perceive any conflict, and will not take any action. By reverting to Probing state, the host that desires a unique host name will go through the necessary steps to ensure that a unique host name is obtained. The recommended course of action after probing and failing is as follows: 1. Programmatically change the resource record name in an attempt to find a new name that is unique. This could be done by adding some further identifying information (e.g., the model name of the hardware) if it is not already present in the name, or appending the digit "2" to the name, or incrementing a number at the end of the name if one is already present. 2. Probe again, and repeat as necessary until a unique name is found. 3. Once an available unique name has been determined, by probing without receiving any conflicting response, record this newly chosen name in persistent storage so that the device will use the same name the next time it is power-cycled. 4. Display a message to the user or operator informing them of the name change. For example: The name "Bob's Music" is in use by another music server on the network. Your music collection has been renamed to "Bob's Music (2)". If you want to change this name, use [describe appropriate menu item or preference dialog here]. The details of how the user or operator is informed of the new name depends on context. A desktop computer with a screen might put up a dialog box. A headless server in the closet may write a message to a log file, or use whatever mechanism (email, SNMP trap, etc.) it uses to inform the administrator of error conditions. On the other hand, a headless server in the closet may not inform the user at all -- if the user cares, they will notice the name has changed, and connect to the server in the usual way (e.g., via web browser) to configure a new name. 5. After one minute of probing, if the Multicast DNS responder has been unable to find any unused name, it should log an error message to inform the user or operator of this fact. This situation should never occur in normal operation. The only situations that would cause this to happen would be either a deliberate denial-of-service attack, or some kind of very obscure hardware or software bug that acts like a deliberate denial-of-service attack. These considerations apply to address records (i.e., host names) and to all resource records where uniqueness (or maintenance of some other defined constraint) is desired.
最新发布
10-18
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值