0

So, once I learned (here of course) that a 'live USB' can't be mounted nor written to, I stopped trying to update my Debian 12 install image with my files and started again with a fresh stick. Copied over the appropriate stuff, burned it onto the MBR with my faithful LILO and ... strange errors. A dozen reports about 'madam no arrays found' and eventually: 'ALERT! no root filesystem'. (There was absolutely nothing wrong with the root FS.)

Then I copied the kernel and initrd.img from the Debian 12 stick to the new stick, ran LILO again and ... victory! The stick boots. So obviously the previous initrd.img was missing something -- works fine with a HDD boot, but won't work on a USB stick. Can I diagnose that? Figure out what exactly was missing? I'd like to know more about how the initrd.img is created. Maybe rebuild the defective .img? Thing is that the Debian 12 files are the 6.1.0-18 version whereas my HDD runs 6.1.0-20 and I'd like the USB to be up to date.

Improve this question
2
  • See here. Everywhere you see Ubuntu, replace it with Debian. The overall process is the same.
    – eyoung100
    Commented Apr 30 at 17:33
  • I already have my bootable USB stick. What I'm asking is how to tweak my initrd.img so that what works on a HDD will also work on the USB. As I said, using my 'normal' initrd, it failed. Using the initrd that came with the 'live' Debian install USB did work. I want to know what the difference is and how to take charge of it.
    – Ray Andrews
    Commented Apr 30 at 23:35

1 Answer 1

Reset to default
1

I believe the issue is the combination of LILO and a USB device. I think LILO expects the device identity to be constant. USB devices can wander all over the place, especially with different computers.

I recommend using GRUB instead, and making sure it uses the "search" command to locate the disks, by UUID (or label). Also, make sure every filesystem is unique (i.e. don't clone disks) so the UUIDs are distinct.

As for the initrd... It sounds like the system you copied from used some RAID devices. This would use "mdadm" (which I believe you miscopied as "madam"). In general, the initrd should be generated in the context of the system it will boot. Thus, you install everything on the USB, mount it, mount (or bind mount) /proc, /dev, /sys, etc in that mount, and chroot to the mounted USB. Then and there, you should build the initrd. (Alternatively, if you can boot it, you can just do do and build a new initrd.)

If you really want the same initrd on both the USB and normal disk, you may need to have the same subset of packages installed that put things in /usr/share/initramfs-tools/. (Filenames therein are typically package names, which helps identify them.) I wouldn't recommend bothering.

You may also need to check the boot command line, to ensure it doesn't reference the RAID devices.

If you can boot the USB, and just want to rebuild the initrd, and assuming you are using initramfs-tools, this would be either:

# update-initramfs -u

or if that does nothing (because you don't already have an initrd):

# update-initramfs -c -k <your-installed-kernel-version>

To rebuild the USB initrd from the host, assuming your USB device is /dev/sdc, that its boot partition is /dev/sdc2, and its root partition is /dev/sdc3. And assuming you have an empty directory /mnt/usb. And assuming that you are already running as root.

# mount /dev/sdc3 /mnt/usb
# mount /dev/sdc2 /mnt/usb/root
# mount -tproc proc /mnt/usb/proc
# mount -tsysfs sysfs /mnt/usb/sys
# mount -obind /dev /mnt/usb/dev
# mount -ttmpfs tmp /mnt/usb/tmp
# mount -ttmpfs tmp /mnt/usb/run
# mount -ttmpfs tmp /mnt/usb/dev/shm
# chroot /mnt/usb

At this point, you are logically in the USB device (except that all the system services are running in the host, and some of the size restrictions are wrong. Now to update the initrd, as described above.

Unless you want to run to stay in the USB filesystem, you should probably exit or control-D to leave the chroot.

Then unmount everything with:

# umount /mnt/usb/dev/shm /mnt/usb/run /mnt/usb/tmp /mnt/usb/dev /mnt/usb/sys /mnt/usb/proc /mnt/usb/root /mnt/usb

Normally, you never need to run update-initramfs manually, as installation scripts do it automatically. This might fail if you install a kernel from source, or do things like building a new root, such as on a USB.

Improve this answer
3
  • There are issues with /dev/... assignment changing all over the place but I use boot by label which solves that perfectly. Nope, my USB boots fine now, the issue was in the ramdisk. Right about cloning tho -- learned that the hard way, especially using boot by label -- cuz the cloning duplicates the labels, so the mommy disk and the cloned disk can't be connected at the same time.
    – Ray Andrews
    Commented Apr 30 at 23:23
  • David: Sounds like what I need to do, but I need the details of how to do it.
    – Ray Andrews
    Commented May 1 at 3:57
  • 1
    David: I just finally tried your code above to update my initrd on the USB and it works fine. Didn't have the guts to try it before now.
    – Ray Andrews
    Commented Jun 7 at 17:23

You must log in to answer this question.

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