已更新linux 5.0.9.arch1-1，但是系统依然运行4.12.12-1-arch

leixianb · 2019-05-01 15:57:04

xtricman 说：

就暂时忽略掉楼上的奇怪说法，认为你就是把ESP 挂到了/boot 吧，然后重新运行了pacman -S linux-lts. 你从我12楼说的再想想你干了啥。
迄今为止楼主要干嘛还是只有靠我猜，也没告诉我猜对没猜对。
我们就不停的从你说白了就是使用只有你自己能听懂的terminology 来猜你要干嘛，然后你也不说猜没猜对，最后做的事情又跟我们猜测的不一样。
你还一直以为菜就是原罪。

我的arch是安装在virtualbox上的，那我按照你们的指导，启动virtualbox上的arch之后，为了查看一下ESP里面的文件，尝试将ESP挂载到/boot，但是结果报错，说是未知文件系统vfat。
我上网搜索之后，有人遇到过这样的问题，就是因为pacman下载的包，也就是pacman -Q linux显示的结果，和ESP里面的内核版本不匹配导致的这个问题。
那我想到我当时下载的ISO版本就是4.12那个版本的，于是我就通过virtualbox启动LiveCD。从始至终我的virtualbox只配了一台虚拟机。所以可以通过LiveCD来对安装的arch做一些操作。
进入LiveCD之后，我直接将sda2，也就是ESP挂载到了LiveCD的/mnt下面，查看文件发现确实有内核文件以及grub文件夹，且grub文件夹下面有grub.cfg文件。
那么根据现象判断，ESP下面的内核应该就是4.12版本的。而每次启动的时候都是用的这里的内核，不是用我sda1里面/boot下面新版本的内核。
那我想到我之前每次把/sda1挂载到/mnt之后，arch-chroot进入/mnt，再使用pacman -S linux命令都会更新/mnt/boot下面的内核。所以我挂载sda1到LiveCD的/mnt之后，再把sda2挂载到/mnt/boot。然后再更新内核。
这样的话，更新的内核就会进入到我的ESP当中。
然后操作完了之后，我退出chroot，并umount两个分区，关闭LiveCD，然后启动arch，就是用的更新的内核了。

我挂载ESP到LiveCD下面的/mnt之后看到了有内核，有gurb.cfg文件，说明你们猜对了啊。

我是懂得没你们多，没法用通用的专业术语来描述问题，也请你们多多包涵。总之感谢你们的帮助我才解决了这个问题。

leixianb · 2019-05-01 16:05:13

xtricman 说：

楼主一直也没说目的是啥。到底内核想装哪？我猜要装在sda1，好，不告诉我猜错猜对。那就当我猜对吧。楼主26楼做了啥呢？不知道，那就猜我27楼是猜对了。
根据我在12楼所述，pacman不关心安装目录是否为挂载点，于是内核再次被安装入ESP，于是推出矛盾。那问题来了，两个假设到底哪个是错的？
楼主还意识不到解决问题缺失的条件吗？

从一开始我提问的时候，我并不知道内核要装在哪里。我只是描述了我看到的现象。就是我每次更新了内核之后，我看到/boot下面的文件确实有相应更新。但是我启动系统却依然显示是老版本的内核。
那我就猜测系统有两套内核，并且每次启动的时候用的是另一套内核。但是我并不知道另一套装在哪里，如何查询。以及查询到之后如何指定系统使用哪个内核来启动。这些问题我google过，但是没有找到答案，所以来这里寻求帮助。
而我之前自己所做的尝试我并没有在帖子里说出来，因为我也不知道我做的尝试是否对这个问题有什么帮助。所以我就把现象描述了一下。

最近编辑记录 leixianb (2019-05-01 16:06:11)

驿窗 · 2019-05-01 16:15:46

你们这字数，劳动节就是敲键盘啊...

yw662 · 2019-05-02 04:42:12

leixianb 说：

说是未知文件系统vfat

你需要安装dosfstools以挂载fat分区。

另外，如果你希望保持现状，或者说保持grub使用ESP中的内核，那么你需要做如下操作：

删除根分区下/boot中的内容
修改/etc/fstab，将/dev/sda2挂载到/boot

不然下次更新内核时依然会有这个现象。

依云 · 2019-05-02 13:45:09

yw662 说：

leixianb 说：
说是未知文件系统vfat
你需要安装dosfstools以挂载fat分区。
另外，如果你希望保持现状，或者说保持grub使用ESP中的内核，那么你需要做如下操作：
删除根分区下/boot中的内容
修改/etc/fstab，将/dev/sda2挂载到/boot
不然下次更新内核时依然会有这个现象。

你别瞎说，挂载文件系统根本不需要文件系统的用户态工具。那个是格式化、改标签、检查错误之类用的。
这里不能识别 vfat 是因为运行的内核与安装的内核模块（/lib/modules）版本不匹配，内核找不到对应的 vfat 模块。

leixianb · 2019-05-02 15:01:18

yw662 说：

leixianb 说：
说是未知文件系统vfat
你需要安装dosfstools以挂载fat分区。
另外，如果你希望保持现状，或者说保持grub使用ESP中的内核，那么你需要做如下操作：
删除根分区下/boot中的内容
修改/etc/fstab，将/dev/sda2挂载到/boot
不然下次更新内核时依然会有这个现象。

好的，谢谢。或者下次我再升级之前先把ESP挂载到/boot，这样应该也可以吧

yw662 · 2019-05-02 19:13:49

依云说：

yw662 说：
leixianb 说：
说是未知文件系统vfat
你需要安装dosfstools以挂载fat分区。
另外，如果你希望保持现状，或者说保持grub使用ESP中的内核，那么你需要做如下操作：
删除根分区下/boot中的内容
修改/etc/fstab，将/dev/sda2挂载到/boot
不然下次更新内核时依然会有这个现象。
你别瞎说，挂载文件系统根本不需要文件系统的用户态工具。那个是格式化、改标签、检查错误之类用的。
这里不能识别 vfat 是因为运行的内核与安装的内核模块（/lib/modules）版本不匹配，内核找不到对应的 vfat 模块。

呀我想错了。。。
但是他的版本为什么不匹配啊。。。。

依云 · 2019-05-02 20:40:43

yw662 说：

呀我想错了。。。
但是他的版本为什么不匹配啊。。。。

由于挂载问题，内核没更新内核模块更新了。

xtricman · 2019-05-03 10:08:35

/boot有单独的分区，其实二楼就已经说明了一切，只是楼主强行说不是罢了。pacman装内核是不管三七二十一直接装进/boot完事的。这意味着pacman管理了不位于同一个文件系统的文件。这个时候你没有将各个文件系统挂载到正确的位置的话，pacman是没意识的，你再更新，内核文件就会被安装到跟之前安装不一样的位置（虽然看起来都是/boot，但实际位置完全不一样)。但是模块不在/boot呀，会被更新，下次启动还是之前的内核，老内核，新模块，加载模块就会失败了，然后vfat就不能用了。

如果pacman能记录当前本地安装的文件系统UUID及物理路径，更新时做更多检查，检查到旧版文件异常（在那个文件系统上不存在或者内容摘要，元数据不正确）的话，用户就能更好的意识到这个问题，带来更好的体验。

其实讲道理就是Linux这种单根树状表现的VFS设计，过度复杂，用户体验比较差。

全局设计一张[UUID: per-filesystem-mount-option]表，
而一个mount namespace可以设计成一张[mount_id: UUID: mounted_inode: per-mount-option]。

用户态靠mount_id: path_from_mounted_inode访问文件系统，这样平板状结构，和文件系统本身对应更直接，概念清晰得多。

依云 · 2019-05-03 13:03:24

xtricman 说：

如果pacman能记录当前本地安装的文件系统UUID及物理路径，更新时做更多检查，检查到旧版文件异常（在那个文件系统上不存在或者内容摘要，元数据不正确）的话，用户就能更好的意识到这个问题，带来更好的体验。
其实讲道理就是Linux这种单根树状表现的VFS设计，过度复杂，用户体验比较差。

实际上更新的时候是有警告的。然而有用么？

xtricman · 2019-05-03 22:42:54

依云说：

实际上更新的时候是有警告的。然而有用么？

没有吧，它不会感知到文件即将被安装到另一个文件系统上吧。它不会记录旧版文件是在sda2的/boot，然后报告说现在发现sda2没挂载。只会认VFS路径，如果你拷贝一份文件到另一个文件系统上然后把文件系统挂到相同位置pacman不会感知到吧，它还会觉得一切正常，只要内容和元数据没问题。

依云 · 2019-05-03 22:59:23

xtricman 说：

依云说：
实际上更新的时候是有警告的。然而有用么？
没有吧，它不会感知到文件即将被安装到另一个文件系统上吧。它不会记录旧版文件是在sda2的/boot，然后报告说现在发现sda2没挂载。只会认VFS路径，如果你拷贝一份文件到另一个文件系统上然后把文件系统挂到相同位置pacman不会感知到吧，它还会觉得一切正常，只要内容和元数据没问题。

更新的时候它会发现要删除的旧文件不存在。

xtricman · 2019-05-04 11:03:13

依云说：

更新的时候它会发现要删除的旧文件不存在。

我觉得你大约没听懂我意思。它只按VFS 路径找文件的。它又感知不到旧文件实际上已经不在当初安装的文件系统上了，只要按VFS 路径找到了，并且摘要和元数据正确它就无所谓啊。它不关心找到的文件实际上在哪个文件系统上。你把整个系统从ext4拷贝到xfs上它都感知不到。

Mr.I · 2019-05-04 11:18:26

xtricman 说：

只要按VFS 路径找到了，并且摘要和元数据正确它就无所谓啊。

但现在的情况不就是没找到吗

yw662 · 2019-05-04 11:36:05

xtricman 说：

依云说：
更新的时候它会发现要删除的旧文件不存在。
我觉得你大约没听懂我意思。它只按VFS 路径找文件的。它又感知不到旧文件实际上已经不在当初安装的文件系统上了，只要按VFS 路径找到了，并且摘要和元数据正确它就无所谓啊。它不关心找到的文件实际上在哪个文件系统上。你把整个系统从ext4拷贝到xfs上它都感知不到。

然而。。。不应该是这样么？

Arch Linux

#31 2019-05-01 15:57:04

Re: 已更新linux 5.0.9.arch1-1，但是系统依然运行4.12.12-1-arch

#32 2019-05-01 16:05:13

Re: 已更新linux 5.0.9.arch1-1，但是系统依然运行4.12.12-1-arch

#33 2019-05-01 16:15:46

Re: 已更新linux 5.0.9.arch1-1，但是系统依然运行4.12.12-1-arch

#34 2019-05-02 04:42:12

Re: 已更新linux 5.0.9.arch1-1，但是系统依然运行4.12.12-1-arch

#35 2019-05-02 13:45:09

Re: 已更新linux 5.0.9.arch1-1，但是系统依然运行4.12.12-1-arch

#36 2019-05-02 15:01:18

Re: 已更新linux 5.0.9.arch1-1，但是系统依然运行4.12.12-1-arch

#37 2019-05-02 19:13:49

Re: 已更新linux 5.0.9.arch1-1，但是系统依然运行4.12.12-1-arch

#38 2019-05-02 20:40:43

Re: 已更新linux 5.0.9.arch1-1，但是系统依然运行4.12.12-1-arch

#39 2019-05-03 10:08:35

Re: 已更新linux 5.0.9.arch1-1，但是系统依然运行4.12.12-1-arch

#40 2019-05-03 13:03:24

Re: 已更新linux 5.0.9.arch1-1，但是系统依然运行4.12.12-1-arch

#41 2019-05-03 22:42:54

Re: 已更新linux 5.0.9.arch1-1，但是系统依然运行4.12.12-1-arch

#42 2019-05-03 22:59:23

Re: 已更新linux 5.0.9.arch1-1，但是系统依然运行4.12.12-1-arch

#43 2019-05-04 11:03:13

Re: 已更新linux 5.0.9.arch1-1，但是系统依然运行4.12.12-1-arch

#44 2019-05-04 11:18:26

Re: 已更新linux 5.0.9.arch1-1，但是系统依然运行4.12.12-1-arch

#45 2019-05-04 11:36:05

Re: 已更新linux 5.0.9.arch1-1，但是系统依然运行4.12.12-1-arch

页脚