ART's questions

Temos placa personalizada baseada em beaglebone black com 256 MB de RAM e 4 GB eMMC. Placa roda kernel Linux 4.9

estamos nos deparando com uma situação em que criamos um arquivo tempfse depois da validação, temos que movê-lo para a partição ext4 do eMMC. Arquivo nada além de umcertificate

em algumas situações, temos vários certificados em um diretório, portanto, precisamos mover todo o diretório de tempfs para a partição ext4 no eMMC.

Portanto, um dos problemas que nos preocupa é a atomicityoperação mv(movimento).

De acordo renamecom a chamada do sistema, a renomeação da página de manual do Linux é uma operação atômica. http://man7.org/linux/man-pages/man2/rename.2.html

No entanto, não temos certeza se a operação de renomeação envolve mover arquivos entre dois sistemas de arquivos, a atomicidade ainda está disponível ou não. Então, a pergunta é: está movendo o arquivo de tmpfspara ext4o atômico?

Obviamente, uma solução possível é manter os arquivos em uma pasta diferente na mesma partição (no mesmo sistema de arquivos, obviamente) e renomeá-lo usando mv. Para diretório usando a abordagem abaixo de renomeação

SRC_dir  --> TMP_DEST_dir
DEST_dir --> BAK_DEST_dir
TMP_DEST_dir --> DEST_dir
delete BAK_DEST_dir

Alguma sugestão de alternativas?

EDIT
Depois de receber a resposta, tentei seguir o código de teste na placa,

#include <stdio.h>
#include <errno.h>

int main()
{
    int retcode = 0;

    system("touch /tmp/rename_test");

    retcode = rename("/tmp/rename_test", "/home/fs_rename_test");

    if ( retcode < 0) {
        printf("errno : %d\n",errno );
        perror("Error occurred while renaming file");
        return 1;
    }

    return 0;
}

Que retornou após a saída. E confirmou que a renomeação não funciona no sistema de arquivos cruzado.

errno : 18
Error occurred while renaming file: Invalid cross-device link

Temos uma placa personalizada Beaglbone black com 256 MB de RAM e 4 GB eMMC.

Temos script para software flash na placa.
O script apaga a tabela de partições gpt usando os seguintes comandos

#Delete primary gpt (first 17KiB)
dd if=/dev/zero of=/dev/mmcblk0 bs=1024 count=17
#Delete secondary gpt (last 17KiB)
dd if=/dev/zero of=/dev/mmcblk0 seek=3735535 bs=1024 count=17

As partições são excluídas, no entanto, o script re-particiona o eMMC novamente no mesmo número de partições.
Depois disso, ele tenta formatar cada partição usando mkfs.ext4(e2fsprogs versão 1.42.13).

Agora, ao formatar uma partição mkfs.ext4, reclama que a partição possui um sistema de arquivos e foi montada em uma data específica no passado e pergunta se deve continuar?

/dev/mmcblk0p15 contains a ext4 file system labelled 'rootfs'
        last mounted on /mnt/rfs_src on Fri Feb 16 13:52:18 2018
Proceed anyway? (y,n)

Isso não estava acontecendo no passado, ou seja, com a versão e2fsprog, 1.42.8
o mesmo script costumava funcionar.

Da nota de lançamento de e2fsprog-1.42.13vejo que last mountedé adicionado a alguma estrutura.

Agora a pergunta é como podemos remover essas last mountedinformações da partição?

Eu tentei wipfs -a, mas tem o mesmo comportamento. Uma maneira de zerar enquanto eMMC, no entanto, isso levará muito tempo.

Alguma sugestão/indicadores?

Temos placa personalizada Beaglebone black com 256 MB de RAM e 4 GB eMMC.

Atualizamos do Linux-3.12 para o Linux-4.4 e do busybox-1.20.2 para o busybox-1.26.2.
Agora, no busybox-1.26.2, estamos vendo um problema que não estava lá no busybox-1.20.2

Eu adicionei o seguinte código em um dos últimos scripts de inicialização.

if [ -f /home/ankur ] ; then
    count=50
    rm /home/ankur
    echo "----Check Whoami----"
    whoami  #prints root
    reboot
    echo "--------------------"
    while [ true ]
    do
       count=$((count - 1 ))
       echo "Count = $count"
       if [ $count -le 0 ];then
            break;
       fi
       echo "Sleep 1"
       sleep 1
    done
fi

Toquei no arquivo /home/ankure reiniciei a placa.
O que observei é que o sistema não reiniciou, mas o contador caiu para 0 e, em seguida, outro script de inicialização foi executado e a placa foi reiniciada.

Portanto, parece que o busybox está recebendo sinal, rebootmas manipulando somente após a execução dos scripts init.

Agora, minha pergunta, existe um caminho para reboota placa antes da conclusão de todos os scripts de inicialização. Existe alguma configuração de caixa ocupada que desabilitará esse bloqueio de reinicialização?

reboot -f(forçar a reinicialização sem passar pelo init) funciona, mas também precisamos executar o script de parada, portanto, não podemos usá-lo.