Meu sistema atual é:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 8.1 (jessie)
Release: 8.1
Codename: jessie
com o kernel:
$ uname -a
Linux debian 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux
Eu atualizei para o novo kernel com:
$ sudo apt-get install linux-image-3.16.0-4-amd64
....
Setting up linux-image-3.16.0-4-amd64 (3.16.7-ckt11-1+deb8u2) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64
/usr/share/initramfs-tools/hooks/fsck: syntax error at line 60: 'MNT_FSNAME=$' unexpected
/usr/share/initramfs-tools/hooks/keymap: syntax error at line 57: 'value=$' unexpected
/usr/share/initramfs-tools/hooks/resume: syntax error at line 44: 'RESUME=$' unexpected
/usr/share/initramfs-tools/hooks/zz-busybox: syntax error at line 33: '$' unexpected
/usr/share/initramfs-tools/scripts/init-premount/plymouth: syntax error at line 19: '$' unexpected
/usr/share/initramfs-tools/scripts/init-top/all_generic_ide: syntax error at line 16: '$' unexpected
....
Eu notei erros do script /usr/share/initramfs-tools/hooks/fsck , eu verifiquei e observei que ele começa com #!/bin/sh e a linha 60 é:
MNT_FSNAME=$(resolve_device "$MNT_FSNAME")
Bem, vejo que o erro é da sintaxe de substituição de comandos. Meu /bin/sh é um link simbólico para dash e dash , claro, suporta essa sintaxe.
Meu sistema também tem sh de baús de ferramentas de herança , que foi instalado em /usr/5bin/sh , e esse shell não suporte $(...) sintaxe. Então parece que o script foi executado com esse shell em vez de /bin/sh como seu shebang.
O que faz esse comportamento estranho e como resolvê-lo?
Atualizado
Há também um /sbin/sh , que é um link simbólico para /usr/5bin/sh . O problema foi resolvido depois que eu removi este link. Portanto, o processo que atualiza o initramfs parece usá-lo em vez de /bin/sh .
O motivo é o script que executou o hook initramfs chamado com /sbin/sh , que é o antigo shell Bourne de caixas de ferramentas de herança no meu sistema, em vez de /bin/sh .
Um strace pode verificá-lo:
$ strace -fe execve apt-get install linux-image-3.16.0-4-amd64
...
22900 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=22918, si_status=0, si_utime=0, si_stime=0} ---
22919 execve("/sbin/sh", ["sh", "-n", "/usr/share/initramfs-tools/hooks"...], [/* 40 vars */]) = 0
...
O problema no Linux é que muitos scripts precisam de recursos bash não portáteis, mas não sinalizam isso em seus #! linha.
Existem outros problemas semelhantes, por ex. scripts que chamam "awk" em vez de "gawk", mas dependem dos recursos do gawk.
Existem scripts que chamam utilitários usando GNUisms como opções longas não portáteis.
Algumas pessoas chamam isso de "dependência de fornecedor" do Linux. A razão pela qual isso acontece é provavelmente a documentação do Linux. As páginas do manual do Linux não mencionam "recursos" não portáteis e não incentivam as pessoas a usar apenas as opções portáteis.
Voltar para o shell. Usar a concha de herança não é uma boa idéia, pois não é realmente portátil. O fato de ainda usar sbrk () para alocar memória em vez de malloc () causa vários problemas em várias plataformas. Pode haver problemas ocultos relacionados a esse fato em algumas distribuições do Linux. Por exemplo não funciona no Cygwin por este motivo. A concha de herança não corrigiu nenhum dos bugs conhecidos da shell SVr4 e isso parece ser causado pelo fato de que o desenvolvimento parou depois de meio ano.
Se o shell de herança fosse portátil, ele poderia ser usado como uma ferramenta de teste para verificação de scripts manuais - para scripts que precisam ser executados em qualquer lugar. Para uso diário, a concha de herança não é a decisão certa.
BTW: se você gosta de uma versão portátil do shell Svr4 Bourne para fins de teste, eu recomendo o Bourne Shell compilado como "osh" no Schily-toolset. Se você gosta de usar um Bourne Shell para uso diário, eu encorajo as pessoas a conferir o Bourne Shell "bosh" do Schily Toolset. Inclui o primeiro editor de histórico e, portanto, não fará com que você grite o tempo todo que estiver tentando usá-lo.