从dd的操作失败说起

这些天,项目中需要不少统一配置的服务器,一台台的装实在是一个费时费力的工程,可数量又实在没有到达值得配个网络安装+kickstart的数量级。于是就自作聪明的利用服务器热插拔硬盘的优势,直接通过一个udev脚本触发dd操作。就是只要系统一发现有新的硬盘插入,就直接把系统OS所在的/dev/sda直接dd过去。操作人员只要看到哪块硬盘灯不再闪烁了就直接拔盘换新的上去就好。

尽管看上去非常的简单粗暴,可这样相安无事地装出了数十套系统之后,居然没出什么大问题。似乎觉得这就是一个完美的方案了。

后来,曾经一块通过这个系统dd出来的硬盘由于操作失误,需要重新安装。照旧扔到了这个磁盘克隆系统上。结果,非但没有复制成功,反而连母盘也损坏了。按理说dd中if入参中的原盘只是一个只读方式,系统中又全是SSD,正常的情况读取不会有电气上的重大损耗,怎么也不会沦落到损坏母盘的地步。

反思了很久,发现问题所在。

由于通过dd方式的克隆硬盘,新的硬盘的分区和旧的硬盘的分区有着同样的uuid,正常情况下uuid都应该是独立且唯一的,这也就无怪乎当下所有的Linux都把uuid作为分区的识别号。

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda1 during installation
UUID=ca3c4e13-c158-44cb-bcd8-2e917418017b / ext4 errors=remount-ro 0 1
# swap was on /dev/sda5 during installation
UUID=47e4fc5c-0ff4-4c58-bc68-082c24e62b7c none swap sw 0 0
~
~

当一个空硬盘加入到系统之后,没有任何分区,也就自然没有uuid的问题。当一块硬盘被第二次加入系统,系统中就会出现uuid重复,自然无法判断哪一个是原盘哪一个是目的盘,dd出现了方向相反甚至方向混乱的情况也就在情理之中了。

好吧,其实我之前已经知道了原理,但还是掉到这个坑里了。最后还是通过硬盘的id来做dd,彻底避免了这个uuid的坑。

关于如何修改分区uuid的问题:

tune2fs /dev/sda1 -U `uuid`

在这里,/dev/sda1是你要修改uuid的分区,且必须处于umount的状态。uuid命令需要安装包支持。

修改好了uuid之后,请确保你的/etc/fstab文件和grub配置的正确,要不然还是无法启动系统。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

请补全下列算式: *

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据