Untitled – Li Shangyin

As it happens, a Parted command needs to be updated on the compile server for the purpose of executing the script. But because the compile server is really quite old (Ubuntu12.0), and I am not very familiar with the use of APT series commands. In addition to the fact that the software source is too old to be found, the autoremove subparameter is misused, so that some key dependent libraries and packages of the system are removed, and then the system is constantly rebooting, and then it never gets up again. When the system is started, it freezes, and even tty cannot be accessed

It can be seen from the Log printed by the terminal (it was quite a long time ago, it is a pity that the Log was not saved at that time) that it is really related to package system. In this case, we are thinking of starting in recovery mode on grub, because GRUB provides some system repair modules in revovery mode, including package System repair. Since there is no screenshot saved on site, here is a similar picture of the network, as follows:

In general, just click the DPKG TAB and wait for the system to fix. But it backfired. After I clicked it, the results still stuck, stuck for more than two hours. I don’t know if the system (GRUB) is too old or something, but this approach doesn’t work. After relentless testing and numerous reboots (dog heads), even grub suddenly disappeared,The grub boot menu is missing.

Looks like we can only reinstall the system. On second thought, there is a way to fix it (Linux is all file). After all, the system is still on hard disk, isn’t it?

Solution idea

  • Find a way to access the terminal of the build server system
  • Repair package system
  • Reinstall the GRUB boot menu

Tortuous steps

  • Get a usb drive with a pre-burned Ubuntu system on it (maybe a bit older, I’m using Ubuntu18.04)

  • When the computer starts, choose U disk inside BIOS to start

  • After booting the usb flash drive and entering the Ubuntu temporary installation screen, you can open the terminal and use sudo fdisk -l to see the block device (let’s say Sda1) that originally stored the build server system (root /).

  • From the system on the USB disk, chroot to the system on the hard disk (then the running environment of the terminal is switched to the compiler server system on the hard disk), and the command is as follows:

    // Find the server system partition sudo fdisk -l // mount the server system partition to the/MNT folder on the USB disk sudo mount /dev/sda1 / MNT // Mount some necessary system folders and run the chroot command, Sudo mount --bind /dev/mnt /dev sudo mount --bind /proc/mn/proc sudo mount --bind /sys/mn/sys cd /mnt sudo chroot . ./bin/bashCopy the code

  • Repair package system, specific reference askubuntu.com/questions/1… The following is an example:

    sudo apt-get clean
sudo apt-get install -f
sudo dpkg --configure -a
Copy the code

  • Reinstall the GRUB boot menu. Ubuntu has a list of commands to refer to and use. I’ve tried both of the following and it works:

    • Pure command line mode
    sudo grub-install /dev/sda 
sudo grub-mkconfig -o /boot/grub/grub.cfg
Copy the code
    • Combined with GUI interface operation
    sudo apt install boot-repair
boot-repair
Copy the code

And then — and then I thought it was okay, save it, turn it on.

As a result, the GRUB boot menu was still not visible on the BIOS, and while I was scratching my head, I accidentally clicked on one of the BIOS Settings (the compiler server is branded as ASUS) :

After tests, it was found thatOperating System TypeIf you chooseWindow UEFI modeYou will not be able to see the Grub screen of UbuntuOther OSCan. After selecting reboot, you can see the normal GRUB boot menu, and the system that compilers the server can also run normally, hahahahahaha ！！！！！！

conclusion

Q: Does that mean reinstalling GRUB was unnecessary?

A: About half, because the GRUB boot menu currently displayed is the one I updated with the previous command, and the RECOVERY mode of the GRUB menu in this version is also available, including DPKG fixes. This indicates that the GRUB reloading command works properly, but it may not be needed for the package System issue. As for why the BIOS is automatically set back to Window UEFI Mode, I don’t know. The server is still too old (I’m too lame).

In fact, the switch from Linux system on usb disk to Linux system on hard disk is used when you cannot access the system through the hard disk but need to operate the system on the hard disk. The repair package System here is just a simple case.