Ubuntu16.04使用所遇问题记录

Posted 2020-10-12 yhjoker

　　记录笔者在使用Ubuntu系统过程中所遇到过的错误/问题。本机系统为Ubuntu 16.04 LTS，64-bit。

　　1.输入法设置--安装了搜狗拼音的linux版本

　　由于尝试了多种解决方案，可能使得各个步骤混淆在一起，这里只列出自己尝试过的操作，而不是具体的某一种方法。

　　(1)将System Setting->Language Support中的Keyboard input method system选项改为fcitx；

　　(2)在Install/Remove Language弹出的对话框中将Chinese语言包选择，点击apply。完成中文语言包的安装；

　　(3)在搜狗官网下载sogou for linux的deb安装包，这里笔者直接通过点击进行安装，没有报错；

　　(4)在System Setting->Text Entry->Input sources to use中点击“+”按钮，找到Sogou Pinyin(Fcitx)，进行添加,右侧还可以选择切换的快捷键方式；

　　(5)同样的界面下，点击类似于维修的按钮，进入到Input Method Configuration，点击左下角的“+”按钮，寻找Sogou的输入方式，若未找到，可以点击取消下方的Only Show Current Language，选择Sogou的输入方式，点击OK即可，此时应该已经可以根据已设置的切换快捷键进行输入方式的切换。

 

　　2.对于Windows和Ubuntu的双系统，Bios时间会在启动时发生改变(参见UbuntuTime)

　　问题产生的原因在于Windows与linux默认的设置硬件时钟(hardware clock)的方式不同。Windows将硬件时间设置为本地时间(localtime)而Ubuntu默认设置为UTC时间。也就是说，当在7:00PM关机时，Windows会将硬件时钟设置为7：00PM，硬件以这个时间为基准继续计时，开机时读取到的也是正确的本地时间。而对于Ubuntu，系统默认会将7:00PM转化为UTC时间进行存储，而启动时再将读取的硬件时钟的时间转化为本地时间。这样就会造成Ubuntu关机之后，Windows开机时时间会出现问题的情况。

　　解决方法：

　　1.禁用UTC而使用本地时间。对于老版本的ubuntu，将Ubuntu的配置文件/etc/default/rcS中关于UTC的选项由yes转换为no。对于较新的版本，可以使用命令sudo timedatectl set-local-rtc 1即可以进行设置。相应的关闭使用本地时间功能可以使用sudo timedatectl set-local-rtc 0；

　　2.将Windows设置为使用UTC时间(在Windows8.1和Windows10中验证通过)。桌面右下角windows图标-->右键，运行-->regedit，选择HKEY_LOCAL_MACHINE->SYSTEM->CurrentControlSet->Control->TimeZoneInformation，出现关于时间信息的注册表项，右键新建-->DWORD(32位)/QWORD(64位)(位数根据系统位数确定)-->将项目名称改为RealTimeIsUniversal-->将值改为1，格式为16进制。或则参考链接中的方法，即新建一个注册表文件来实现相同的功能。

 

　　3.关于删除了/etc目录之后的补救O.O（有备份）

　　在练习使用打包命令tar的过程中产生事故。笔者练习使用tar指令将/etc进行打包。并在/tmp新建了一个/etc目录以供解压，解压时发现tar产生的文件的解压结果是生成完整的/etc目录，从而产生了/tmp/etc/etc的目录结构。于是进入/tmp/etc目录，想将里面重复的/etc目录使用rm -rf命令删除掉。结果想当然的使用了rm -rf /etc命令...发现/tmp/etc文件下的/etc目录仍然存在...然后突然意识到自己用绝对路径删除掉了/etc文件夹。

　　补救过程：

　　(1)由于是tar命令的练习，所以有/etc文件生成的压缩文件存在。尝试将压缩文件再解压到根目录下，提示permission denied。尝试使用sudo命令，提示无法识别uid，推测是因为关于用户信息的/etc/passwd和/etc/shadow等文件已经被删除了；

　　(2)尝试上网查找资料，结果发现网络链接不可用。原因和配置文件缺失也有关系；

　　(3)想到以前看到过的重启进入单用户调试模式尝试进行修复，但是由于/etc目录缺失，担心可能进入不了单用户模式，而且一旦关机将再无法进入系统(/etc目录没有了)，所以没有进行这一种方法的尝试；

　　(4)由于文件系统中是存在/etc的备份的，所需要的是找到root权限将备份文件写回原来的/etc目录，但是当前系统由于没有了/etc目录又无法提升权限。最终想到了使用live CD的方法。即借助装有linux安装程序的U盘，设置BIOS从U盘启动，再使用安装程序所自带的试用选项。此时将可以使用sudo进行权限的提升。在进入试用模式后，使用sudo fdisk /dev/sda(不同设备的设备名可能不同)得到系统的磁盘分区情况，分别将需要的文件系统挂载(在笔者情况下，是分别挂载了/和/home)，然后使用sudo命令将备份的信息写回挂载的根目录即可。最后再重新启动，发现可以正常进入系统了，问题解决！

　　联想：既然可以通过Ubuntu的Live CD使用备份文件恢复/etc文件夹，是否可以在Live CD上进行新建用户等操作，再直接将Live CD的/etc用于被删除的/etc的恢复？这样虽然会有部分配置文件会丢失，但是在没有备份的情况下比重装系统的性价比还是大不少？当然对于配置环境较多的系统，首先还是经常备份。

　　经验与教训：

　　(1)linux命令中敲击命令时千万不要想当然，特别是对于root权限，带来极大的便利的同时也可能孕育魔鬼，对于命令的作用和潜在效果一定要做重审；

　　(2)对与linux中的路径问题，只存在绝对路径和相对路径两种情况，对应产生问题的命令，使用相对路径就应该为./etc，而使用绝对路径时就应该使用/tmp/etc/etc的完整路径名，使用/etc会被认作绝对路径，从而造成问题；

　　(3)备份是十分重要的。这次问题能够解决一定程度上要感谢是在练习使用打包指令tar，从而存在备份，否则会有更大的麻烦。相对的，若是存在备份，再借助live CD的强大功能，便可以解决很多问题。所以有备份的习惯，做好的备份，会在关键时刻帮上很大的忙。

 

　　4.在64位Ubuntu环境下运行32位程序的问题

　　在做CSAPP配套的buffer实验时发现实验提供的hex2raw为64位程序，无法在32位环境中使用(可通过命令 file execname 来查看文件的相关信息 )，切换至64位环境后，发现另一个程序bufbomb为32位，理论上可以在64位环境下运行，但实际使用 ./bufbomb 命令运行时，bash总是报错 bash: ./bufbomb: No such file or directory。可以看到设备还无法处理32位程序。

 　　通过搜索后发现，在Ubuntu64位环境下想要执行32位程序需要安装额外的32位兼容的库。找到的答案有：

　　收集到的一些信息有：

　　(1)在Ubuntu13.10版本之前，可以通过一个安装包 ia32-libs 来安装32位程序所需的环境；

　　(2)对Ubuntu13.10以后的版本，如果只是运行单个程序的需求，则可以查看试图运行程序时系统的提示信息，如缺失某个函数库，则可以通过 sudo apt-get install libname：i386安装对应的i386体系库解决；

　　(3)也可以直接将i386体系结构下的常用库安装，从而使得64位系统提供32位程序的兼容；使用 sudo dpkg --add-architecture i386 将i386架构列入无需使用 --force-architecture 选项指定就能安装的安装包的体系列表中。再安装32位程序运行常用的库文件，sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386，即可运行。（主要参考askubuntu）

　　

　　5.关于/boot分区经常空间饱和的问题

　　最初安装系统时为/boot分配了大致120M左右的空间，觉得应该够用，结果发现在进行OS更新时，会将新的内核文件也放置在/boot文件夹下，直接导致/boot剩余空间不足系统报错的情况，所以需要进行一定的调整。主要收集到的解决方案有一下几种：

　　(1)可以进入/boot目录，若该目录下存在有多个内核版本的内核文件，则可以进行若干删除操作，操作一定要慎重，不要删除正在使用的内核文件，不要在正在进行OS更新时使用此操作；

　　(2)使用命令sudo apt-get autoremove，apt-get的autoremove选项会将之前为满足其他包的依赖关系而自动下载但现在不再需要的包删除。使用该命令会删除部分在/boot中的旧内核文件(但不限于此)。还可以在此命令上加上--purge参数，在删除上述文件时会将对应的配置文件也删除，该种方法可能也需要一部分剩余的/boot空间，所以更适合正常情况下的空间清理，而无法用在/boot接近饱和时进行清理。

　　(3)使用live CD的方法，通过其中的GParted工具重新调整分区的大小，减少某些分区的大小，从而将空间分配给/boot。Gparted软件目前好像只包含在Ubuntu的Live CD版本中。可以通过从U盘启动进入Live CD，选择试用Ubuntu，在软件搜索中键入GParted，即可找到对应的软件。在GParted界面中，选中正确的硬盘(界面右上角)和分区，右键选择resize，可以通过拖动图标或键入数字的方式设置想要修改的分区大小。在所有的修改设置完成后，点击界面上方的 √ 按钮，则开始执行之前的设置操作。

　　注意：修改/boot分区可能会影响系统的再次启动(笔者本次的操作中并未遇到)，对于数据分区的操作应该提前做好备份操作。

　　可以参考教程：How to Resize Your Ubuntu Partitions

　　(4)在Ubuntu论坛中看到的一个方案，在合适的目录新建一个足够空间的文件夹，并将原/boot目录下的文件复制至该文件夹，再修改/etc/fstab中的挂载关系，使得系统在启动时挂载新建的文件夹。个人认为只是新建一个文件夹是无法进行挂载的，若设备上尚有较大的未分配的空间，可以使用fdisk先建立一个大小合适的分区，再将/boot内容复制(部分数据应该需要使用dd而不是简单的cp)至新分区，此时修改/etc/fstab中的挂载关系应该是可行的。感觉这种方法较之使用GParted由于没有移动和修改其他分区的数据似乎更稳妥一点，但首先需要有未分配的额外空间，其次可能需要修改一些开机有关的信息(如grub的信息)，笔者并未进行尝试，仅在此陈述思路。

　　

　　6.关于出现如下错误信息的解决方案　

E: Could not get lock /var/lib/dpkg/lock - open (11: Resource temporarily unavailable)
E: Unable to lock the administration directory (/var/lib/dpkg/), is another process using it?

　　从报错的字面信息来看，主要是由于无法对于需要运行的进程上锁，且系统询问是否有另外一个进程在使用锁。这是由于使用apt命令时，相应的进程会被上锁，进程结束时则会释放锁。但若是某个进程在运行过程中受阻，则锁无法释放，使得后续的需要加锁的进程也无法运行。

　　解决方法：

　　(1)根据系统的提示，检查是否真的有另外一个apt进程在使用锁。使用命令 ps aux | apt 显示所有名字包含apt的进程，查看该进程运行状态是否正常，若是运行停滞状态，则可以使用kill pid的方式将其强制结束.,注意，上述进程也有可能是正常运行的apt进程(如正在正常进行之前指定的安装操作)，该情况下应该等待进程的进程结束，而不是将其强制停止。上述方法对于apt-get进程较为有效。

　　(2)上述情况很容易发生在用户刚进入Ubuntu即进行apt操作的过程中，这好像是由于Ubuntu的一些新的版本中引入了自动更新的功能，系统在每次开机后会检查是否有新的版本更新，并自动进行更新操作而不需要用户的参与。可以权衡一下是否需要关闭该操作，若用户可以坚持手动更新，可以选择将此服务关闭。

sudo systemctl disable apt-daily.service # 使得自动更新服务不再开机启动
sudo systemctl disable apt-daily.timer   # 使得timer不再能用

　　相应的启动该服务只需将上述命令中的disable修改位enable即可。主要参考这里。

　　(3)删除与apt的锁操作有关的文件夹。建议只有所有的方法都不管用的情况下使用该操作，可以参考这里的第一个回答。