自动分区问题

原因 ： Kylin在partman中的一个脚本recipes.sh中添加了自己的逻辑，但是并不严谨，导致dell传入的recipe不生效，并会导致一些无法预料的问题。
解决 ： 将recipe.sh替换为原生的。

initramfs阶段安装dell-recovery包失败

原因 ： 缺包 —— 可以在/var/log/boot.log中找到问题
解决 ： 在作ISO时，在squansh中通过chroot将缺失的包安装进去。
解决2 ： 将缺失包放在/cdrom/debs下（dell-recovery也是放在该目录下的），在initramfs阶段制作本地源时将这些包包含进去。该方法未验证，理论可行。

dell-recovery进入第二阶段无法正确引导

原因 ： EFI引导EFI分区 efi/ubuntu/grubx64.efi起来后，grub的root、prefix不对，导致无法找到grub.cfg导致，此时会进入grub的命令行模式。
解决 ： 此时grub的root指向当前分区，prefix指向**(prefix)处建立一个grub.cfg文件

search --file --set=new_root /factory/grubenv
set root=$new_root
set prefix=($root)/boot/grub
configfile /boot/grub/grub.cfg

在新建立的grub.cfg中搜索RP分区，然后进入RP分区中的grub.cfg。

解决2 ： 从新生成grubx64.efi文件。理论可行，但是担心引入新问题，没有采用该方式。

grub阶段红屏问题

原因 ： grub.cfg中检测/factory/grubenv及其中的数据。正常安装完毕后，在ubiquity最后阶段，会调用 ubiquity/install/success_command中存储的命令 —— dell-recovery中的chroot.sh 传入的参数为success。该脚本最终会删除/factory/grubenv文件。目前的情况是在执行chroot.sh过程中失败了，导致没有删除/factory/grubenv，所以出现红屏。
解决 ： 排除chroot.sh中的脚本问题，使之走完全流程。
PS ： 目前是初步解决，还有完善空间。

EFI Entry —— 多一个ubuntu问题

这个entry只有在第二阶段有用，添加逻辑在进入第二阶段后，通过efibootmgr删除所有名为ubuntu的entry。

Kylin修改ubiquity引入问题

见代码

gtk_ui.py

        # kylin add, is_oem is last
        if os.path.isfile("/tmp/.kylin_reboot_go_oem"):
            last_page = self.pages[-3].module.__name__
            ..........



        if finished_step == last_page and not self.backup:
            self.finished_pages = True
            syslog.syslog("fucking life enter into last_page")

            if self.finished_installing or self.oem_user_config:
                self.debconf_progress_info('')
                # thaw container size
                self.progress_section.set_size_request(-1, -1)
                self.install_details_expander.show()
                self.install_progress.show()
                self.progress_section.show()
                dbfilter = plugininstall.Install(self)
                dbfilter.start(auto_process=True)

        elif finished_step == 'ubi-partman':
            # Flush changes to the database so that when the parallel db
            # starts, it does so with the most recent changes.
            self.stop_debconf()
            self.start_debconf()
            options = misc.grub_options()
            self.grub_options.clear()
            for opt in options:
                self.grub_options.append(opt)
            self.switch_to_install_interface()
            from ubiquity.debconfcommunicator import DebconfCommunicator
            if self.parallel_db is not None:
                # Partitioning failed and we're coming back through again.
                self.parallel_db.shutdown()
            env = os.environ.copy()
            # debconf-apt-progress, start_debconf()
            env['DEBCONF_DB_REPLACE'] = 'configdb'
            env['DEBCONF_DB_OVERRIDE'] = 'Pipe{infd:none outfd:none}'
            self.parallel_db = DebconfCommunicator('ubiquity', cloexec=True,
                                                   env=env)
            dbfilter = partman_commit.PartmanCommit(self, db=self.parallel_db)
            dbfilter.start(auto_process=True)

ubi-usersetup.py:

        #elif os.path.isfile("/tmp/.kylin_reboot_go_oem"):
        #    return True

问题1： kylin使用一个文件kylin_reboot_go_oem，开控制是否是OEM安装。该文件在ubi-isoem.py中被创建。但是在dell_recovery干预下，ubi-isoem无法出现，导致不能生成该文件。
解决办法：在dell-recovery的第二阶段添加逻辑，创建kylin_reboot_go_oem文件；该方法为临时方法，后期考虑使用环境变量的形式控制OEM流程。

问题2： kylin修改了lastpage，如果有文件kylin_reboot_go_oem则lastpage为倒数第二个步骤。按照dell-recovery中的情况，ubiquity共有4个步骤 dell-bootstrap、 ubi-lanuage、partman、usersetup。若按照kylin的逻辑，lastpage变成了partman，那么就破坏了ubiquity的工作流程。
ubiquity目前的步骤为 dell-bootstrap --> ubi-lanuage ----> partman -----> partman-commit -------> install ---->install plugin。按此时逻辑，到partman就断了，导致安装流程无法走完。
解决办法 ：

1. 不让user-setup skip，以automatic模式运行，这样lastpage为user-setup；这就是ubiquity的正常流程。
2. lasetpage指向除user-setup、partman之外的步骤。这种改法和kylin的做法一致，不推荐。

kylin postaction重复执行问题

原因 ：在install-plugin阶段，一般都会判断UBIQUITY_OEM_USER_CONFIG是否存在于环境变量中；如果ENV中有这个，表示当前处于OEM模式下，需要额外的处理（一般都return了）。但是在kylinpostaction步骤中，没有对这个进行判断，所有ubiquity执行几次（oem同样是ubiquity），这个步骤执行几次。
解决方法： 判断该环境变量，如果发现，则不再执行即可。

配置较低机型安装过程中出现内核panic

原因：ubiquity最后阶段，执行chroot.sh，再往下会调用 SUCCESS_SCRIPT，其中有个步骤：

105     IFHALT "Regenerate md5sum.txt at the end..."
106     $(python3 << EOF                                                                                                                                                                       
107 from Dell.recovery_common import regenerate_md5sum
108 regenerate_md5sum("$RP")
109 EOF
110 )

这个步骤导致硬盘及其繁忙，有几率（几率较大）导致问题。
解决方法：注释调这段代码即可。
影响：估计不会有影响，关于该功能的说明：
head_info = """This file contains the list of md5 checksums of all files on this medium.\n\nYou can verify them automatically with the 'integrity-check' boot parameter,\nor, manually with: 'md5sum -c md5sum.txt'.\n\n"""

user-setup出错

原因：如果没有文件kylin_reboot_go_oem文件的话，usersetup不会跳过，则会走到usersetup-apply中，在这里会设置用户名和密码；来源是dell-recovery中的 ubuntu.seed文件，用户名:密码为 【oem:password】；在V10中，要求密码必须是数字、字母甚至更多种类。
解决方法： 修改ubuntu.seed，将密码改为qwe123即可。

Dell recovery模式总结

四种模式

x模式（该模式在UI文件中有体现，但是代码中没有相关处理，无视之）

image.png

dhc模式

image.png

automatic模式（选中磁盘后，不用管）

image.png

interactive模式（手动模式，自己分区等）

image.png

目前常用的是 automatic模式和interactive模式
PS：这几种模式是界面上体现出来的，还有通过debconf设置的模式

factory（该模式下，直接进入第二阶段——stage=2）

hdd模式

dev模式