Resolving Kali (udev/systemd) Boot Failure (part duex), Easiest Method
After several more hours of searching for, and work on, solutions for this problem I’ve found one that seems to work fairly consistently. This mess of a dumpster fire is burning slightly lower this fine day. I would strongly recommend trying this method first since it seems to have consistent results through a cleaner process in general.
While this is used in Kali, this method should work with other flavors as well where the problem is similar. Naturally, mileage will vary.
BRIEF NOTE: This method is still not working correctly with an encrypted LVM (at least it isn’t with mine) I’ll update this as soon as I find a solution… if I find a solution.
This method involves booting to a live CD, mounting your underlying file system into a chroot environment and performing updates. So here it goes!
- First, download a Kali ISO and launch the system into it. Choose the appropriate “Live” option for you.
- Once you’re booted you should open a command line. The rest of the work will take place from it.
- Now you’re going to want to find your volume group name
VG #PV #LV #SN Attr VSize VFree
kali-vg 1 2 0 wz--n- <49.76g 32.00m
- Great you now have the volume group to work with, kali-vg.
- Next make your new root directory. Following other people s guides (see references below). I’ve just used /mnt/root as seen below.
# mkdir /mnt/root
- Next, you’re going to run a bunch of commands that are going to activate your volume group and mount the disk based file systems into the live instance. I’m including these in a big block below.
- Replace kali-vg with YOUR volume group information.
- You may have different volume/drives associated. I can’t account for all possibilities so just remember you might have to change things on your end.
- You’ll notice that I mount a volume group AND a standard device (sda1) partition. That is because by default a Kali install with LVM will install a boot volume on sda1 and your LVM will be on sda5 (extended partition structure). You’ll need to mount BOTH your root volume group and the boot volume in appropriate locations. Failure to do so will cause this to fail and probably result in breakage.
- Once the core volumes are mounted. You need to change into that directory to continue.
- Some of the guides that you’ll find on the internet will not mount everything I’ve specified, however, I’ve found you need ALL of the ones I’ve specified to allow an over-the-net update using apt to happen.
# vgchange -ay kali-vg
2 logical volume(s) in volume group "kali-vg" now active
# mount /dev/mapper/kali--vg-root /mnt/root
# mount /dev/sda1 /mnt/root/boot
# cd /mnt/root
# mount -t proc proc proc/
# mount -t sysfs sys sys/
# mount -o bind /dev dev/
# mount --bind /run /mnt/root/run
# chroot /mnt/root
If everything went well you should be sitting back at a command prompt with no errors.
- Now you should be able to run updates like you normally would against your underlying system. With any luck, this will update all your outstanding packages including the bugged ones as well as re-run the necessary commands to update your boot image.
- Once the update completes, it’s on to upgrade.
Depending on how outstanding updates on your system were this is a good time to take a break. Get a drink, find some coffee, a snack… take a nap… whatever you fancy. If all went well, when you come back you should be presented with a cursor at a command prompt with no errors.
- Finally. to cleanly or mostly cleanly reboot you need to exit and unmount from your current activities. Trying to reboot from chroot will result in an error. Change out of the mounted volume and unmount all devices (as shown below) and then reboot.
[email protected]:/# reboot
Running in chroot, ignoring request.
[email protected]:/# exit
[email protected]:/mnt/root# cd
[email protected]:~# umount --all
umount: /run/live/medium: no mount point specified.
umount: /run: not mounted.
umount: /dev: not mounted.
[email protected]:~# reboot
Once the system comes back up, you should be presented with a shiny… well maybe slightly rusty, but certainly washed, Kali instance. Like you expected BEFORE the pre 240-4 version of udev/systemd broke your instance.
Happy CTFing! ;-]