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
Attachment:
signature.asc
Description: OpenPGP digital signature