1

trying to fix a cloned boot via chroot (new processor, hangs on boot). booted to a liveUSB and mounted the fs to /mnt. when i run update-initramfs -uv it blazes thru until near the end when it fails with the following:

...
Adding module /lib/modules/4.19.0-25-amd64/kernel/drivers/infiniband/hw/mlx4/mlx4_ib.ko
Adding module /lib/modules/4.19.0-25-amd64/kernel/drivers/infiniband/core/ib_uverbs.ko
Adding module /lib/modules/4.19.0-25-amd64/kernel/drivers/infiniband/hw/mlx5/mlx5_ib.ko
Adding config /etc/initramfs-tools/conf.d/resume
/usr/sbin/mkinitramfs: 333: /usr/sbin/mkinitramfs: cannot create /dev/null: Directory nonexistent
E: no ldd around - install libc-bin
Removing /boot/initrd.img-4.19.0-25-amd64.dpkg-bak
update-initramfs: failed for /boot/initrd.img-4.19.0-25-amd64 with 1.

i have never seen this and am not sure how to best proceed. isn't /dev a read-only directory? i tried running apt auto-clean and that didn't fix anything. i was going to run apt auto-remove but it wants to yard 4GB of data out and i'm not sure i want to let it do that just yet.

any advice how to best proceed?

EDIT: i also tried udevadm trigger --sysname-match=null which gave me running in chroot, ignoring request. and i tried the usual mknod -m 0666 /dev/null c 1 3 which told me no such file or directory. gotta love it.

EDIT2: here's how i mounted the relevant partitions:

root@debian: ~ # mount /dev/sda2 /mnt
root@debian: ~ # mount /dev/sda1 /mnt/boot/efi/
root@debian: ~ # mount --bind /proc /mnt/proc
root@debian: ~ # mount --bind /sys /mnt/sys
root@debian: ~ # mount --bind /dev /mnt/dev
root@debian: ~ # mount --bind /etc/resolv.conf /mnt/etc/resolv.conf
root@debian: ~ # chroot /mnt/ /bin/bash

there was a swap on sda3 but i don't think that's necessary for this to work.

2
  • Did edit2 work? if it did post it as an answer (or accept the answer that told you to do that)
    – Jasen
    Feb 7 at 8:39
  • no. edit 2 did not work. edit 2 is what i did to get to this point. :) i wish it worked. :P
    – WhiteRau
    Feb 7 at 14:26

2 Answers 2

3

This may Help

Reboot, to undo what you've already done, and then from a Debian Live Terminal:


Mount Needed Filesystems

  1. mkdir /mnt/debian
    • mount /dev/sda2 /mnt/debian
  2. cd /mnt/debian && mkdir -p boot/efi
    • mount /dev/sda1 /mnt/debian/boot/efi
  3. mount --types proc /proc /mnt/debian/proc
  4. mount --rbind /sys /mnt/debian/sys
  5. mount --make-rslave /mnt/debian/sys
  6. mount --rbind /dev /mnt/debian/dev
  7. mount --make-rslave /mnt/debian/dev
  8. mount --bind /run /mnt/debian/run
  9. mount --make-slave /mnt/debian/run
  10. Optional: swapon /dev/sda3
  11. Enable Networking: cp --dereference /etc/resolv.conf /mnt/debian/etc/

Some of the above may fail, as these are the ones Gentoo uses on their Minimal Installer. If so, ignore the failures where directories don't exist.

Continuing:

Recreate Shared Memory

  1. test -L /dev/shm && rm /dev/shm && mkdir /dev/shm
  2. mount --types tmpfs --options nosuid,nodev,noexec shm /dev/shm
  3. chmod 1777 /dev/shm /run/shm

We've now created the necessary mounts and can continue into the chroot to perform repairs:

Enter Chroot

  1. chroot /mnt/debian /bin/bash
  2. source /etc/profile
  3. export PS1="(chroot) ${PS1}"

Explanation

Your prompt will now read (chroot) root@debian # and you should be able to complete repairs. I believe your Cannot create /dev/null error was caused by not performing Steps 6 and 7 in the Needed Filesystems Steps (You need to "borrow" /dev from the LiveCD). See Understanding Bind Mounts for more information, but in short --rbind or a Recursive Bind, allows one to "attach" a directory outside of one filesystem to the inside of another file system including it's subdirectories. In the above list, we effectively "attached" /sys,/dev, and /run to our chroot. By using --rslave, or Recursive Slaving, we can now alter the directories and subdirectories inside the chroot, and preserve the changes outside the chroot, keeping both sides in sync. Being that the system is on a rescue stick/CD the changes arent preserved across reboots, but have been altered in the chroot, because it gets unmounted and synced before reboot.

3
  • this worked much better than my original workflow! thank you so much. it didn't click that i needed to --rbind the /dev folder. now that i see it: duh. :) thank you very much. this will be so much more useful moving down the road.
    – WhiteRau
    Feb 7 at 15:55
  • Glad it helped. Since you marked this as an answer, I have to ask : Do you like having the Explanation Section? I want to provide correct answers without boring people
    – eyoung100
    Feb 7 at 15:59
  • 1
    omigosh, YES! even though i've been using Linux for years, this is something i did NOT know well (obviously). your explanation really helped cement the knowledge and provide context for quite a few other things, actually. and it wasn't boring at all. i wish all 'nix docs were this good. :)
    – WhiteRau
    Feb 7 at 17:33
1

Note that the error is:

cannot create /dev/null: Directory nonexistent

In other word, it cannot create /dev/null because there is no /dev/ directory to create it in.

Something is very wrong with the /dev/ directory.

1
  • You are correct. the /dev mount he created in the original question was in fact empty. There's nothing "very wrong". The OP didn't realize that the mount he created is automatically populated by the kernel at boot, and isn't static.
    – eyoung100
    Feb 7 at 18:04

You must log in to answer this question.

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