Chrooting and updating initramfs

This morning, my SSD looked this way.

Model: KINGSTON SA2000M8250G (nvme)
Disk /dev/nvme0n1: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End    Size    File system     Name                          Flags
 1      1049kB  275MB  274MB   fat32           EFI system partition          boot, esp
 2      275MB   409MB  134MB   linux-swap(v1)  Microsoft reserved partition  msftres
 3      409MB   125GB  125GB   ntfs            Basic data partition          msftdata
 4      125GB   130GB  4194MB  linux-swap(v1)  Linux swap                    swap
 5      130GB   160GB  30.4GB  ext4            racine arch
 6      160GB   190GB  30.4GB  ext4            home arch
 7      190GB   220GB  29.4GB  ext4            root manjaro                  boot, esp
 8      220GB   250GB  30.3GB  ext4            home manjaro

As you can see the EFI boot partition is the number 1.

After saving elsewhere the manjaro partitions (number 7 and 8), I installed two former Antergos partitions (used till the 3rd of January 2021 ) from my former SSD using Clonezilla at their place (number 7 and 8).

The reinstall was successful and I updated the /etc/fstab file. Clonezilla had told me that I had to update initramfs and initrd. I intend to do it using the Arch iso disk and chroot.

To be honest I am scared to screw my system and I would be happy if some experimented user could have a look at it. I googled a lot, and this is what I intend to do, which is pretty short:

Boot from the Arch iso disk to chroot these partitions.

# fdisk -l
# mount /dev/nvme0n1p1 /mnt/boot
# mount /dev/nvme0n1p7 /mnt
# cd /mnt
# chroot /mnt
# mkinitcpio -p linux
# grub-mkconfig -0 /boot/grub/grub.cfg
# umount -a
# exit

Shall I do it? I had a dry test. It seems it can be done but I am afraid to miss something…

why not using arch-chroot?

Thanks for the link. It should be safer.

I replaced /mnt/boot with /mnt/boot/efi
and wrote arch-chroot instead of chroot

also the commands for launching initcpio and updating grub will be different

Now

# fdisk -l
sudo su
# mount /dev/nvme0n1p1 /mnt/boot/efi
# mount /dev/nvme0n1p7 /mnt
# cd /mnt
# arch-chroot /mnt
# arch-chroot /mnt mkinitcpio -p linux
# arch-chroot /mnt grub-mkconfig -o /boot/grub/grub.cfg
# arch-chroot /mnt grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Antergos
# umount -a
# exit

If no other remark, I’ll try it to morrow morning crossing my fingers :wink:

After arch-chroot you are in your installed system, so

# mkinitcpio -p linux
# grub-mkconfig -0 /boot/grub/grub.cfg
# exit

should be correct.

Thanks for your confirmation.

I’ll also add

# arch-chroot /mnt grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Antergos

Well, at least I survived. :wink: The three arch-chroot commands went through and this is really a powerful tool. The stern arch Grub splash took over first place as expected. Happily, the efiboomgr helps restore the previous boot order, so no external damage.

The OS failed to boot (though it was declared clean) because of an arcane reason about hibernation and UUID.(I had created new UUIDs in the /etc/fstab). So, this deserves a second try - this time without tweaking the uuids - whose results will be published tomorrow.

The commands had to be slightly modified to run properly with the Archlinux iso (01/01/2021). I am still not sure about the right order of the last two. Maybe umount /mnt /mnt/boot/efi would also be better.

# fdisk -l
# mount /dev/nvme0n1p7 /mnt
# mount /dev/nvme0n1p1 /mnt/boot/efi
# arch-chroot /mnt
# cd /mnt
# mkinitcpio -p linux
# grub-mkconfig -o /boot/grub/grub.cfg
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=Antergos
# exit
# umount -a

1 Like

Well, it was quicker than expected. This is to report success. :smiley:

BTW: to answer the question above, a clean way to get out is
#exit
#umount /mnt/boot/efi
#umount /mnt
#reboot

I’ll join later some photos.

I reinstalled the Clonezilla images using Clonezilla on partitions 7 and 8.
I resumed directly arch-chroot to do the things named above.
I booted to the new OS (the former antergos)
disk: clean
error resume (but quickly passed). Then some seconds of black screen and a report about /etc/fstab errors (three old directories, wrong uuid for /swap and /boot/efi.

I decided to solve this immediately from my Arcolinux.

I rebooted. Black screen again but not dead, I still could see appear the small notifications for updates and for network connection. Only the display was black…

I used arch-chroot again. I decided to update the system (pacman -Syu) and if this update failed to install a linux-lts. Other things were beyond my knowledge. A long update (over 1 gig) was reported successful.

I booted to my OS and that’s it. It seems to work fine like before. But on reboot, I had again a black screen. This time, the cure lasted only five minutes (really thanks arch-chroot!!). I installed linux-lts and linux-lts-headers which, I know work well with my Nvidia GTX 1050 and the OS is up and running again, this time I hope for good (till kernel 5.11).

Edit: I am confused, this kernel is running well. At least i am prepared for the worse

uname -a
Linux lenovo 5.10.12-arch1-1 #1 SMP PREEMPT Sun, 31 Jan 2021 00:41:06 +0000 x86_64 GNU/Linux

I just have to deal with this “error resume” which appears briefly at boot .

If you’re not using swap for hibernation you can get rid of that error message by

  1. removing the resume hook frome the line Hooks=... in the file /etc/mkinitcpio.conf
  2. removing resume=... reference from the line GRUB_CMDLINE_LINUX… in the file /etc/default/grub
  3. rebuild grub with sudo grub-mkconfig -o /boot/grub/grub.cfg
  4. update kernel image with sudo mkinitcpio -p linux

Thank you for this complete info. This message will disappear for sure :smiley:

First one to show why you need to avoid writing #arch-chroot /mnt mkinitcpio…
Second one just what I received from Clonezilla before using arch-chroot



My images are too heavy. The forum will crumble…

Looking for expert help

This system installed on a Lenovo laptop and running on Arch (former Antergos) is no more useful for me. It had been running for over three years without problem. I extracted all the personal information I needed before installing a new system. I keep it for the time being for learning purposes. After I rescued it (see the thread above), the GUI has been working six times, every time after a big update. On reboot, I have only black screen (with tty available) till next update. Yesterday I updated it for the last time both with current and LTS kernels.

It’s an Optimus laptop, set with Bumblebee. While trying to make it work better, I may have - probably - screwed something.

I can boot it only from the efibootmgr entry. The grub entries do not work

If somebody feels confident enought to help me track the current problem, I’ll be happy to provide any information and testing. If nobody steps in, well, no problem, I’ll erase it.