# 在LVM分区上安装Manjaro Linux

lvm的好处，就不多讲了。Manjaro以前（今天是2017年04月09日）在cli安装器中是支持直接安装到lvm的，然而后来出于某些原因废掉了cli安装器，但新生的图形安装器尚未支持直接安装到lvm，于是就尴尬了。

今天尝试了一把，最终还是完美把它安装到了lvm上。其实所需的步骤不多，但是不清楚底细的话容易掉坑里。这里把过程步骤简述一下，留给后人参考。

我是用`UEFI`引导的，相信这年头还要坚持用`MBR`的人应该也不多了。本文只讲关键的、网上难以搜到的步骤，读者应该起码有能力自己**用`UEFI`模式**启动到`live-cd/usb`，建立想要的`lvm`逻辑分区和`efi`分区。

# 曲线安装

不支持直接安装到lvm，可以曲线来呀！

1. 磁盘上随便找一个空闲空间（可以用安装光盘自带的分区工具临时搞一个出来），新建分区，不用太大，10G足够了，强烈怀疑5G也够。只需要装得下一个新安装的系统即可。
2. 使用图形安装器，正常安装到该分区。**不要设置启动分区**，因为反正过会儿要重新搞。会有警告，忽略即可。
3. 安装完毕后**不要急着重启**，把自己准备好的用来装系统的`lvm`分区挂载到随便什么地方：
`cp -R -p /path/to/temp_10G_part/* /target/lvm/`
4. 刚才临时用的那个分区可以删掉了。

# 修复启动

做到这里，仍然不要重启。因为此时没有任何引导指向新安装的系统，肯定是启动不了的。准备好你的`efi`分区，继续搞：

## `chroot`到新装的系统

这一步很重要，网上流传着很多`chroot`的准备步骤，但大部分都是修个`apt`包或者`update-grub`一下用的，能用然而不完整，用来配置`UEFI`是不行滴。前几天我的另外一个系统出毛病，用这些不甚严格的挂载指令来修复`UEFI`就总是无效，现在想来应该也是这个毛病。

闲话少数，上代码：

1. `su`切换到管理员权限，或者下面的命令全自己加`sudo`
1. `mkdir haha`（或者随便什么你喜欢的文件夹啦，蛤蛤蛤）
2. `mount /dev/mapper/Your-LVM haha`挂载刚刚被拷入所有系统文件的那个lvm分区
2. 绑定各种运行时信息：`
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/
`
3. 还没完，要搞`efi`，需要加载一个内核模块：`modprobe efivarfs`
4. `chroot haha`
5. `mount -t efivarfs efivarfs /sys/firmware/efi/efivars` 
+ 在`chroot`环境中绑定`efi`相关信息，这一步相当重要，不做的话，下面的命令可能不会返回错误，但就是没法启动。
+ 这一步成功的前提条件是`live-cd`必须使用`efi`模式启动。如果是`mbr`模式启动的，`/sys/firmware/`目录下不会有`efi`目录。
6. **记得从`live-cd`重启之前，把刚才准备`chroot`时挂载的东西都`umount`掉。**当然重启是要在做完下面说的一系列步骤之后。


> [原文在此](https://wiki.manjaro.org/index.php/Restore_the_GRUB_Bootloader)，鸟语好的或者非要用`MBR`启动的可以参考原文。原文推荐的那个`mhwd-chroot`是不认识`lvm`的


## 在`UEFI`分区安装`grub`

此时可以动手往`UEFI`分区写东西了：

1. `mkdir /boot/efi`
2. `mount /dev/sdXY /boot/efi`，其中`/sdXY`是你准备的`UEFI`分区
3. `grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck`
4. `update-grub`

会报一些关于`lvm`的`warning`，没关系的，这是`chroot`环境下特有的，不影响效果。

## 更新`fatab`

更改分区之后，要告诉系统到哪里去找文件系统。

`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`的内存镜像：

1. `nano /etc/mkinitcpio.conf`
2. 找到那一行**没被注释掉的**`
HOOKS="base udev autodetect modconf block keyboard keymap filesystems fsck"`
这个文件前面是大量`#`开头的说明注释，不要修改到那里去了，没用的
3. 在`block keyboard keymap filesystems`这里，`block`后面， 添加一个`lvm2`：`
HOOKS="base udev autodetect modconf block lvm2 keyboard keymap filesystems fsck"
` `arch`的文档说要在`block`和`filesystems`中间加，没看见还有`keyboard keymap`……不管了，总之这样有用
4. `mkinitcpio -p linux49`，这一步相当于`ubuntu`的`update-initramfs -u`，注意`linux49`那里，`49`这俩数字取决于你的`/etc/mkinitcpio.d`目录下写的是几

好了，你可以重启了。

# grub的小坑

此时系统仍不是完全正常，`grub`界面过去之后会有一个错误说：

`Diskfilter writes are not supported`

此时按任意键或者等待几秒，系统会自动正常启动，直至进入桌面，一切正常。然而让这个错误挂在这里终究是很难受的。

如果搜这个错误信息，可以搜到[AskUbuntu上一个长篇大论的帖子](http://askubuntu.com/questions/468466/diskfilter-writes-are-not-supported-what-triggers-this-error)，但是时间是2014年的。这是`lvm`与`grub`的兼容问题，在当时是`grub`的一个bug（早已被修复）。帖子里提供了两种解决方案：

+ 关掉`quick_boot`，但是我在新版没找到这个选项……
+ 用一个`patch`覆盖`/etc/grub.d/00_header`，我想了想没敢这么干，都多少年了……

之所以老bug会在这里重现，是由于原生安装不是到`lvm`的，这里默认开启了一个与`lvm`不兼容的选项，[只需要改一行](https://classicforum.manjaro.org/index.php?topic=7425.msg112623#msg112623)：

```
nano /etc/default/grub
# 修改 GRUB_SAVEDEFAULT 选项为：
GRUB_SAVEDEFAULT=false
```

然后`update-grub`，重启，万事如意！

# PS

编辑`fstab`时，挂载选项`default,noatime,discard`中后两项`noatime,discard`为针对`SSD`的选项，意为不记录最后访问时间（减小磁盘写入以），以及启用`TRIM`命令。

# PPS

上面修复`EFI`启动的部分，理论上可以用于任意情况下`EFI`启动的修复，不限于`LVM`。
今天（20171007），`EFI`无故挂掉，然后那段文字又救了我一次——我已经完全忘掉写这篇文章的时的思路了，连`chroot`都不熟练了，幸亏当时事无巨细都写下来了。