0

I'm developing on-premise migration flow based on Ubuntu 14.04. The steps are:

  1. taking snapshot of / using LVM (/sbin/lvcreate -s -n ...)
  2. executing migration scripts
    1. on success
      1. committing the changes using LVM (/sbin/lvremove -f ...)
    2. on failure
      1. reverting snapshot using LVM (/sbin/lvconvert --merge ...)
      2. rebooting

Since the LVM snapshot revert is not executed immediately and scheduled to the next initialization, I follow the command with a reboot command.

On large LVM snapshot diffs - (e.g. between taking snapshot and reverting, I make large changes) - sometimes the OS boot flow stops and drops me to BusyBox shell instead of booting normally.

How do I avoid booting into BusyBox when reverting from LVM snapshot?

content of /proc/cmdline:

BOOT_IMAGE=/vmlinuz-3.19.0-80-generic root=/dev/mapper/root_vg-root_lv ro nomodeset i915.modeset=0 noplymouth acpi_osi=Linux cpi_backlight=vendor rootdelay=90 rootwait=180

content of /etc/default/grub:

# If you change this file, run 'update-grub' afterwards to update

GRUB_DEFAULT=0
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="nomodeset i915.modeset=0 noplymouth acpi_osi=Linux cpi_backlight=vendor rootdelay=90 rootwait=180"
GRUB_CMDLINE_LINUX=""
GRUB_RECORDFAIL_TIMEOUT=5

enter image description here

Gave up waiting for root device. Common problems:
 - Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
   - Check root= (did the system wait for the right device?)
 - Missing modules (cat /proc/modules; ls /dev)
ALERT! /dev/mapper/root_vg-root_lv does not exist. Dropping to a shell!

BusyBox v1.21.1 (Ubuntu 1:1.21.0-1ubuntu1) built-in shell (ash)
Enter 'help' for a lost of built-in commands.

(initramfs)
1
  • To avoid the "safe mode" busybox shell you need to get to the / of the problem. My guess is that the LVM merge is taking so long that the kernel gives up on waiting for the root block device. If that's really the case, a work-around is to lengthen the delay. Please add the contents of /proc/cmdline and /etc/default/grub to your post. The goal is to change the rootdelay kernel parameter, but I'm not sure where that's configured on your system. May 17, 2018 at 15:33

1 Answer 1

1

Currently, your Linux kernel is instructed to wait 90 seconds for the root device to become available. If it's not available by then, if gives up and delegates to busybox. You can increase the delay by:

  1. Editing /etc/default/grub to change the rootdelay value in the GRUB_CMDLINE_LINUX_DEFAULT line to a larger number. The unit is seconds.
  2. Updating GRUB2 by running update-grub from your terminal.

Note: To follow the procedure above the system must be able to boot successfully; It won't work from a LiveCD. If your system cannot boot successfully at this time, you can temporarily modify the rootdelay by pressing the "e" key within GRUB. This will put you in "edit mode" and allow you to change the kernel arguments; Press ENTER to boot with the updated arguments.

Tip: You may want to consider using BTRFS rather than using LVM (plus a filesystem) for the migration flow. Here's how it could work:

  1. Take snapshot of @ (root) subvolume
  2. Execute migration scripts.
    • On success:
      1. Do nothing, you're done; The changes were applied to the live system.
    • On failure:
      1. Swap the @ subvolume for the (read-write) snapshot of @ by renaming the subvolumes (using mv); Assuming you mount the @ subvolume by its name rather than subvolume ID.
      2. Reboot; No delay needed.
      3. You can now simply delete the old @ subvolume.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .