lvm的好处,就不多讲了。Manjaro以前(今天是2017年04月09日)在cli安装器中是支持直接安装到lvm的,然而后来出于某些原因废掉了cli安装器,但新生的图形安装器尚未支持直接安装到lvm,于是就尴尬了。
今天尝试了一把,最终还是完美把它安装到了lvm上。其实所需的步骤不多,但是不清楚底细的话容易掉坑里。这里把过程步骤简述一下,留给后人参考。
我是用UEFI
引导的,相信这年头还要坚持用MBR
的人应该也不多了。本文只讲关键的、网上难以搜到的步骤,读者应该起码有能力自己用UEFI
模式启动到live-cd/usb
,建立想要的lvm
逻辑分区和efi
分区。
不支持直接安装到lvm,可以曲线来呀!
lvm
分区挂载到随便什么地方:
cp -R -p /path/to/temp_10G_part/* /target/lvm/
做到这里,仍然不要重启。因为此时没有任何引导指向新安装的系统,肯定是启动不了的。准备好你的efi
分区,继续搞:
这一步很重要,网上流传着很多chroot
的准备步骤,但大部分都是修个apt
包或者update-grub
一下用的,能用然而不完整,用来配置UEFI
是不行滴。前几天我的另外一个系统出毛病,用这些不甚严格的挂载指令来修复UEFI
就总是无效,现在想来应该也是这个毛病。
闲话少数,上代码:
su
切换到管理员权限,或者下面的命令全自己加sudo
mkdir haha
(或者随便什么你喜欢的文件夹啦,蛤蛤蛤)mount /dev/mapper/Your-LVM haha
挂载刚刚被拷入所有系统文件的那个lvm分区
mount -t proc proc haha/proc
mount -t sysfs sys haha/sys
mount -o bind /dev haha/dev
mount -t devpts pts haha/dev/pts/
efi
,需要加载一个内核模块:modprobe efivarfs
chroot haha
mount -t efivarfs efivarfs /sys/firmware/efi/efivars
+ 在chroot
环境中绑定efi
相关信息,这一步相当重要,不做的话,下面的命令可能不会返回错误,但就是没法启动。
+ 这一步成功的前提条件是live-cd
必须使用efi
模式启动。如果是mbr
模式启动的,/sys/firmware/
目录下不会有efi
目录。live-cd
重启之前,把刚才准备chroot
时挂载的东西都umount
掉。当然重启是要在做完下面说的一系列步骤之后。[原文在此](https://wiki.manjaro.org/index.php/Restore_the_GRUB_Bootloader),鸟语好的或者非要用`MBR`启动的可以参考原文。原文推荐的那个`mhwd-chroot`是不认识`lvm`的
此时可以动手往UEFI
分区写东西了:
mkdir /boot/efi
mount /dev/sdXY /boot/efi
,其中/sdXY
是你准备的UEFI
分区grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
update-grub
会报一些关于lvm
的warning
,没关系的,这是chroot
环境下特有的,不影响效果。
更改分区之后,要告诉系统到哪里去找文件系统。
nano /etc/fstab
,按你的lvm
更改挂载选项。贴上我的做例子:
/dev/mapper/Linux-Root / ext4 defaults,noatime,discard 0 1 /dev/mapper/Linux-Home /home ext4 defaults 0 1 /dev/sda1 /boot/efi vfat defaults 0 1 tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0
保存退出。
此时重启的话,可以走到grub界面,但还是不能启动到系统里面,累了的话可以先去歇会儿……
默认安装的Manjaro
初始内存镜像是没有lvm模块的,也就是此时grub
引导出来的初始内存盘不知道怎样读lvm
分区,这怎么可能启动嘛。如果你非要此时启动一下试试,应该会挂在一个emergency shell
里面,你可以自己翻看一些系统的/dev
目录:只有各种lvm pv
,lvm
逻辑分区是看不到的。
此时需要调整mkinitcpio
的选项,重新生成一份支持lvm
的内存镜像:
nano /etc/mkinitcpio.conf
HOOKS="base udev autodetect modconf block keyboard keymap filesystems fsck"
这个文件前面是大量#
开头的说明注释,不要修改到那里去了,没用的block keyboard keymap filesystems
这里,block
后面, 添加一个lvm2
:
HOOKS="base udev autodetect modconf block lvm2 keyboard keymap filesystems fsck"
arch
的文档说要在block
和filesystems
中间加,没看见还有keyboard keymap
……不管了,总之这样有用mkinitcpio -p linux49
,这一步相当于ubuntu
的update-initramfs -u
,注意linux49
那里,49
这俩数字取决于你的/etc/mkinitcpio.d
目录下写的是几好了,你可以重启了。
此时系统仍不是完全正常,grub
界面过去之后会有一个错误说:
Diskfilter writes are not supported
此时按任意键或者等待几秒,系统会自动正常启动,直至进入桌面,一切正常。然而让这个错误挂在这里终究是很难受的。
如果搜这个错误信息,可以搜到AskUbuntu上一个长篇大论的帖子,但是时间是2014年的。这是lvm
与grub
的兼容问题,在当时是grub
的一个bug(早已被修复)。帖子里提供了两种解决方案:
quick_boot
,但是我在新版没找到这个选项……patch
覆盖/etc/grub.d/00_header
,我想了想没敢这么干,都多少年了……
之所以老bug会在这里重现,是由于原生安装不是到lvm
的,这里默认开启了一个与lvm
不兼容的选项,只需要改一行:
nano /etc/default/grub # 修改 GRUB_SAVEDEFAULT 选项为: GRUB_SAVEDEFAULT=false
然后update-grub
,重启,万事如意!
编辑fstab
时,挂载选项default,noatime,discard
中后两项noatime,discard
为针对SSD
的选项,意为不记录最后访问时间(减小磁盘写入以),以及启用TRIM
命令。
上面修复EFI
启动的部分,理论上可以用于任意情况下EFI
启动的修复,不限于LVM
。
今天(20171007),EFI
无故挂掉,然后那段文字又救了我一次——我已经完全忘掉写这篇文章的时的思路了,连chroot
都不熟练了,幸亏当时事无巨细都写下来了。