On 2018-01-11 at 12:45, bw wrote: > On Thu, 11 Jan 2018, The Wanderer wrote: > >> On 2018-01-11 at 12:35, bw wrote: >> >> > On stretch local_block is a function in a script named local, maybe using >> > a stretch tool on jessie has things confused? or the initramfs-tools pkg >> > is hosed on the bad system. Sounds complicated, one version of grub but >> > separate boot partitions always gets me confused too. >> > >> > grep local_block /usr/share/initramfs-tools/scripts/local >> > local_block() >> > local_block "${dev_id}" >> >> That's local_block; this appears to be local-block. >> >> On my system (stable+testing, though with sysvinit rather than systemd): >> >> $ dlocate scripts/local-block >> mdadm: /usr/share/initramfs-tools/scripts/local-block >> mdadm: /usr/share/initramfs-tools/scripts/local-block/mdadm >> lvm2: /usr/share/initramfs-tools/scripts/local-block >> lvm2: /usr/share/initramfs-tools/scripts/local-block/lvm2 > > Okay, that is weird. I had no idea that a sysV system installed > different scripts, or why that is the case. > > # find / -name local-block* > # > ls -l /sbin/init > lrwxrwxrwx 1 root root 20 Nov 12 00:28 /sbin/init -> /lib/systemd/systemd
I don't think its being sysvinit has anything to do with it; I think it's just a matter of the specific packages involved. $ apt-file search scripts/local-block cryptsetup: /usr/share/initramfs-tools/scripts/local-block/cryptroot lvm2: /usr/share/initramfs-tools/scripts/local-block/lvm2 mdadm: /usr/share/initramfs-tools/scripts/local-block/mdadm and of course the output of apt-file should have nothing to do with what init system is active. Do you have any of those three packages on your system? If not, that would explain why you don't have any of these files. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
signature.asc
Description: OpenPGP digital signature