补充,更新是用的命令行 sudo apt dist-upgrade
补充,更新是用的命令行 sudo apt dist-upgrade
这个问题已被复现,deepin正在修了
这个问题已被复现,deepin正在修了
好的,目前暂时手搓了grub.cfg启动项解决
这个内核的问题已经定位到是磐石相关的导致的,目前内部已经修复,会尽快推送更新解决。大家出现这类内核问题的,可以先用这个脚本修复一下:sync_boot_immutable.zip

这个内核的问题已经定位到是磐石相关的导致的,目前内部已经修复,会尽快推送更新解决。大家出现这类内核问题的,可以先用这个脚本修复一下:sync_boot_immutable.zip
亲测,管用
这个内核的问题已经定位到是磐石相关的导致的,目前内部已经修复,会尽快推送更新解决。大家出现这类内核问题的,可以先用这个脚本修复一下:sync_boot_immutable.zip
已测,管用。比手搓好使😁
这个内核的问题已经定位到是磐石相关的导致的,目前内部已经修复,会尽快推送更新解决。大家出现这类内核问题的,可以先用这个脚本修复一下:sync_boot_immutable.zip
结合自己踩过的坑,猜测一下:deepin镜像安装时默认生成镜像当前版本的磐石,然后,grub更新配置时,只针对磐石镜像这个版本进行更新。
引发的问题: 1. 【自己经历】由于从alpha版本就镜像安装,本人的磐石内核版本是6.12.9,所以我的grub什么更新都是只有6.12.9。上面是6.12.33的坛友应该是release版本安装的。如果此时删除了/lib/modules下对应的版本模块,你就会得到无法挂载 /boot/efi 而导致的问题【https://bbs.deepin.org.cn/post/289722】
- 即使你有对应的/lib/modules模块,如果手工改grub.cfg成其它内核版本启动,启动时大概率得到初始化失败的问题。
- 问题1个人解决方法:1). 应急模式下【提示时输入root密码进入应急模式】,vi /etc/fstab,注释的 /boot/efi 的挂载,重启。 2). 进入桌面后,重装6.12.9镜像,使/lib/modules生成6.12.9版本的模块包:sudo apt install --reinstall linux-image-6.12.9-amd64-desktop-rolling。3). vi /etc/fstab,去掉 /boot/efi 挂载点的注释。mount -a【此时/boot/efi可以挂载】。原因:因为缺失模块,挂载efi时因为缺失io字符集而失败,导致无法引导系统。
结合自己踩过的坑,猜测一下:deepin镜像安装时默认生成镜像当前版本的磐石,然后,grub更新配置时,只针对磐石镜像这个版本进行更新。
引发的问题: 1. 【自己经历】由于从alpha版本就镜像安装,本人的磐石内核版本是6.12.9,所以我的grub什么更新都是只有6.12.9。上面是6.12.33的坛友应该是release版本安装的。如果此时删除了/lib/modules下对应的版本模块,你就会得到无法挂载 /boot/efi 而导致的问题【https://bbs.deepin.org.cn/post/289722】
- 即使你有对应的/lib/modules模块,如果手工改grub.cfg成其它内核版本启动,启动时大概率得到初始化失败的问题。
- 问题1个人解决方法:1). 应急模式下【提示时输入root密码进入应急模式】,vi /etc/fstab,注释的 /boot/efi 的挂载,重启。 2). 进入桌面后,重装6.12.9镜像,使/lib/modules生成6.12.9版本的模块包:sudo apt install --reinstall linux-image-6.12.9-amd64-desktop-rolling。3). vi /etc/fstab,去掉 /boot/efi 挂载点的注释。mount -a【此时/boot/efi可以挂载】。原因:因为缺失模块,挂载efi时因为缺失io字符集而失败,导致无法引导系统。
昨天手动改了grub.cfg,可以正常引导的,引导的内核不是/boot/这里的,是从/boot/复制内核到/boot/immutable/52c26855ebf15b2c072f1090a33caca38a1f5ea9b3e011bfd4de97b709a619c4.0/里的,自动生成的引导项也是这个长路径
你说的无法引导可能是直接引导了/boot/下的内核,这个没试不敢确定
昨天手动改了grub.cfg,可以正常引导的,引导的内核不是/boot/这里的,是从/boot/复制内核到/boot/immutable/52c26855ebf15b2c072f1090a33caca38a1f5ea9b3e011bfd4de97b709a619c4.0/里的,自动生成的引导项也是这个长路径
你说的无法引导可能是直接引导了/boot/下的内核,这个没试不敢确定
在immutable中存在,说明你同步过磐石的系统版本,对于没有同步过的人,修改grub.cfg是没办法启动的。也就是说,grub.cfg中能正常引导启动的内核版本,必须用ostree同步过,且在ostree仓库里还存在。不知道我的猜测对不对,因为在我抢救我的系统的过程中,我通过各种途径尝试了,发现这个规律——即就算镜像在/boot下是没有办法引导的,最终是指向immutable的镜像才能正常引导。
在immutable中存在,说明你同步过磐石的系统版本,对于没有同步过的人,修改grub.cfg是没办法启动的。也就是说,grub.cfg中能正常引导启动的内核版本,必须用ostree同步过,且在ostree仓库里还存在。不知道我的猜测对不对,因为在我抢救我的系统的过程中,我通过各种途径尝试了,发现这个规律——即就算镜像在/boot下是没有办法引导的,最终是指向immutable的镜像才能正常引导。
我用update-grub更新过grub配置,但是只能有一个6.12.33内核,磐石那个目录里也只有这一个内核,所以我把另外两个内核从/boot里复制到磐石那个目录
改grub.cfg的时候只改内核版本名称就可以了,不用改目录路径,这样是可以用的
新内核好用么
新内核好用么
个人感觉还不错
z怎么更新
z怎么更新
呃……,我的6.15.6是自己编译的,具体步骤可以看看我的帖子,熟练的话20分钟就编译好了
呃……,我的6.15.6是自己编译的,具体步骤可以看看我的帖子,熟练的话20分钟就编译好了
折腾好久没弄成,慢慢折腾吧
Popular Ranking
ChangePopular Events
More
1、更新时使用内核为自己编译安装的6.15.6内核,同时系统有6.12.33内核
更新后,系统又安装6.12.36内核,此时系统内一共有3个内核,如下所示
2、重启系统自动使用6.12.33内核,且无另外2个内核的启动项,使用update-grub无法更新启动项
3、查看grub.cfg,确无其它2个内核启动项,论坛里发现有其他用户也遇到类似问题,请官方早点解决,新硬件还是需要新内核来驱动的