Início / user-32896

malat's questions

Martin Hope
malat
Asked: 2024-03-01 16:18:11 +0800 CST
  • 8

Aqui está o meu problema simples: como posso converter meia largura em largura total na linha de comando. Achei que isso estaria embutido na minha iconvlinha de comando, mas não encontrei nada aqui:

$ iconv  -l | grep -i full
-> nothing
$ iconv  -l | grep -i half
-> nothing

A entrada típica seria:

$ echo -n "Ａb９８７６５４３２１０" | iconv -f utf8 -t utf16be | hexdump -C
00000000  ff 21 00 62 ff 19 ff 18  ff 17 ff 16 ff 15 ff 14  |.!.b............|
00000010  ff 13 ff 12 ff 11 ff 10                           |........|
00000018
character-encoding
Martin Hope
malat
Asked: 2023-11-07 14:57:33 +0800 CST
  • 10

Estou trabalhando no sistema Debian e derivados. Gostaria de converter de uma entrada original ISO-IR-87 para UTF-8. Existe uma maneira fácil de fazer isso?

Para referência:

% iconv -l | grep "IR-8"
ISO-IR-8-1//
ISO-IR-84//
ISO-IR-85//
ISO-IR-86//
ISO-IR-88//
ISO-IR-89//

% dpkg -S /usr/bin/iconv
libc-bin: /usr/bin/iconv

% apt-cache policy libc-bin
libc-bin:
  Installed: 2.36-9+deb12u3
  Candidate: 2.36-9+deb12u3
  Version table:
 *** 2.36-9+deb12u3 500
        500 http://security.debian.org/debian-security bookworm-security/main amd64 Packages
        100 /var/lib/dpkg/status
     2.36-9+deb12u2 500
        500 http://deb.debian.org/debian bookworm/main amd64 Packages

recode parece estar funcionando no meu sistema (obrigado @frostschutz):

% echo -n 'ＡＢＣ' > t.txt
% recode -v UTF-8..JIS_X0208 t.txt
Request: UTF-8..:libiconv:..JIS_X0208
Shrunk to: UTF-8..JIS_X0208
Recoding t.txt... done
% recode -v JIS_X0208..UTF-8 t.txt
Request: JIS_X0208..:libiconv:..UTF-8
Shrunk to: JIS_X0208..UTF-8
Recoding t.txt... done
debian
Martin Hope
malat
Asked: 2023-06-28 19:54:08 +0800 CST
  • 5

Eu tenho lido a documentação do gitlab em:

No meu caso, tenho um caractere especial (dois pontos ':'), então também li:

Agora minha pergunta é: como faço para combinar os dois?

Por um lado eu tenho ( ref ):

job name:
  script:
    - |
      for file in *; do
        echo "$file";
        echo "${REPO}/${file}";
      done

E por outro lado eu tenho ( ref ):

  script:
    - 'for file in *; do curl --header "JOB-TOKEN: ${CI_JOB_TOKEN}" --upload-file "${file}" "${REPO}/${file}"; done'

Como faço para combinar os dois? A solução de longo prazo é lidar com o erro no meu forloop como ( ref ):

    - 'http_code=$(curl -o /dev/null -s -w "%{http_code}" --header "JOB-TOKEN: $CI_JOB_TOKEN" --upload-file "$file" "${REPO}/${file}")'
    - if [ $http_code -ne 201 ]; then echo "Upload failed: terminating" && false; fi;
yaml
Martin Hope
malat
Asked: 2022-07-08 06:34:54 +0800 CST
  • 0

Estou estrelando a página ld.sode manual do meu sistema estável Debian. Atualmente afirma :

$ man ld.so
[...]
NOTES
   Hardware capabilities
       Some shared objects are compiled using hardware-specific instructions which do not exist on every CPU.  Such objects should be installed in directories whose names define the required hardware ca‐
       pabilities, such as /usr/lib/sse2/.  The dynamic linker checks these directories against the hardware of the machine and selects the most suitable version of a given shared object.  Hardware capa‐
       bility directories can be cascaded to combine CPU features.  The list of supported hardware capability names depends on the CPU.  The following names are currently recognized:

O que me surpreende é a última frase:

Os seguintes nomes são atualmente reconhecidos

Isso atualmente não é verdade (ou pelo menos não mais), já que tudo o que posso encontrar é isso:

% cat /etc/ld.so.conf.d/*
/usr/lib/x86_64-linux-gnu/libfakeroot
# Multiarch support
/usr/local/lib/i386-linux-gnu
/lib/i386-linux-gnu
/usr/lib/i386-linux-gnu
/usr/local/lib/i686-linux-gnu
/lib/i686-linux-gnu
/usr/lib/i686-linux-gnu
# libc default configuration
/usr/local/lib
# Multiarch support
/usr/local/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu
# Legacy biarch compatibility support
/lib32
/usr/lib32
# Legacy biarch compatibility support
/libx32
/usr/libx32

É verdade que ld.somagicamente encontrará uma biblioteca em -digamos- /usr/lib/sse2/na minha máquina?

Referência:

% apt-cache policy manpages
manpages:
  Installed: 5.10-1
  Candidate: 5.10-1
  Version table:
 *** 5.10-1 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages
        500 http://deb.debian.org/debian bullseye/main i386 Packages
        100 /var/lib/dpkg/status

Para completar, aqui está a mesma saída de um chroot de 32 bits:

% cat /etc/ld.so.conf.d/*
/usr/lib/i386-linux-gnu/libfakeroot
# Multiarch support
/usr/local/lib/i386-linux-gnu
/lib/i386-linux-gnu
/usr/lib/i386-linux-gnu
/usr/local/lib/i686-linux-gnu
/lib/i686-linux-gnu
/usr/lib/i686-linux-gnu
# libc default configuration
/usr/local/lib
debian ld.so.conf
Martin Hope
malat
Asked: 2022-04-06 04:25:46 +0800 CST
  • 11

Estou olhando para a saída de:

% file -b /lib/x86_64-linux-gnu/*.so | grep ", for"  | colrm 1 130 | sort -u
=5018237bbf012b4094027fd0b96fc22a24496ea4, for GNU/Linux 3.2.0, not stripped
9f21d, for GNU/Linux 3.2.0, stripped
bee51, for GNU/Linux 3.2.0, stripped
, for GNU/Linux 3.2.0, stripped
sha1]=2e5abcee94f3bcbed7bba094f341070a2585a2ba, for GNU/Linux 3.2.0, stripped

O que há de especial no GNU/Linux 3.2.0? Isso está em um sistema Debian/bullseye (amd64).

Em outras palavras: qual API/funcionalidade foi introduzida no GNU/Linux 3.2.0 (modelo de thread, funções de segurança...) que é tão importante? A configuração explícita da versão necessária impedirá o usuário de usar alguns LD_ASSUME_KERNELvalores, portanto, suponho que haja uma boa razão para rejeitar valores antigos, como LD_ASSUME_KERNEL=2.4.19(por exemplo).

debian linux-kernel
Martin Hope
malat
Asked: 2022-03-31 04:18:51 +0800 CST
  • 0

Estou tentando entender a variável env LD_ASSUME_KERNELno meu sistema (Debian/bullseye+bpo).

De acordo com:

$ man pthreads

Eu deveria ser capaz de executar algo assim, no entanto, no meu sistema, aqui está o que recebo:

% LD_ASSUME_KERNEL=2.2.5 ldd /bin/ls
/bin/bash: error while loading shared libraries: libdl.so.2: cannot open shared object file: No such file or directory

Este é um nível um pouco baixo demais para eu entender o que está acontecendo. Não consigo entender se a LD_ASSUME_KERNELimplementação está um pouco quebrada no meu sistema ou se não consigo ler a documentação corretamente.

Algumas outras tentativas fracassadas:

% LD_TRACE_LOADED_OBJECTS=1 LD_ASSUME_KERNEL=2.2.5 ldd
        linux-vdso.so.1 (0x00007ffe3f7e0000)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f5399001000)
        libdl.so.2 => not found
        libc.so.6 => not found
        libc.so.6 => not found

e

% LD_TRACE_LOADED_OBJECTS=1 LD_ASSUME_KERNEL=2.4.19 ldd
        linux-vdso.so.1 (0x00007ffeaacb9000)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007f861cb18000)
        libdl.so.2 => not found
        libc.so.6 => not found
        libc.so.6 => not found

Enquanto:

% LD_TRACE_LOADED_OBJECTS=1 ldd
        linux-vdso.so.1 (0x00007ffc929a9000)
        libtinfo.so.6 => /lib/x86_64-linux-gnu/libtinfo.so.6 (0x00007fa319a29000)
        libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fa319a23000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fa31985e000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fa319aaa000)

Referências:

$ man pthreads
[...]
   Selecting the threading implementation: LD_ASSUME_KERNEL
       On systems with a glibc that supports both LinuxThreads and NPTL (i.e., glibc 2.3.x), the LD_ASSUME_KERNEL environment variable can be used to override  the  dynamic  linker's  default  choice  of threading implementation.  This variable tells the dynamic linker to assume that it is running on top of a particular kernel version.  By specifying a kernel version that does not provide the support required by NPTL, we can force the use of LinuxThreads.  (The most likely reason for doing this is to run a (broken) application that depends on some nonconformant behavior in  LinuxThreads.)
       For example:

           bash$ $( LD_ASSUME_KERNEL=2.2.5 ldd /bin/ls | grep libc.so | \
                           awk '{print $3}' ) | egrep -i 'threads|nptl'
                   linuxthreads-0.10 by Xavier Leroy

O mesmo vale para:

$ man ld.so
[...]
       LD_ASSUME_KERNEL (since glibc 2.2.3)
              Each  shared object can inform the dynamic linker of the minimum kernel ABI version that it requires.  (This requirement is encoded in an ELF note section that is viewable via readelf -n as
              a section labeled NT_GNU_ABI_TAG.)  At run time, the dynamic linker determines the ABI version of the running kernel and will reject loading shared objects that specify minimum ABI versions
              that exceed that ABI version.

              LD_ASSUME_KERNEL  can  be  used to cause the dynamic linker to assume that it is running on a system with a different kernel ABI version.  For example, the following command line causes the
              dynamic linker to assume it is running on Linux 2.2.5 when loading the shared objects required by myprog:

                  $ LD_ASSUME_KERNEL=2.2.5 ./myprog

              On systems that provide multiple versions of a shared object (in different directories in the search path) that have different minimum kernel ABI version requirements, LD_ASSUME_KERNEL  can
              be used to select the version of the object that is used (dependent on the directory search order).

              Historically,  the  most common use of the LD_ASSUME_KERNEL feature was to manually select the older LinuxThreads POSIX threads implementation on systems that provided both LinuxThreads and
              NPTL (which latter was typically the default on such systems); see pthreads(7).

% apt-cache policy manpages
manpages:
  Installed: 5.10-1
  Candidate: 5.10-1
  Version table:
 *** 5.10-1 500
        500 http://deb.debian.org/debian bullseye/main amd64 Packages
        500 http://deb.debian.org/debian bullseye/main i386 Packages
        100 /var/lib/dpkg/status

Como uma nota lateral, a saída é sempre a mesma para:

/lib/x86_64-linux-gnu/libc.so.6
LD_ASSUME_KERNEL=2.2.5 /lib/x86_64-linux-gnu/libc.so.6
LD_ASSUME_KERNEL=2.4.19 /lib/x86_64-linux-gnu/libc.so.6

Eu recebo:

GNU C Library (Debian GLIBC 2.31-13+deb11u3) stable release version 2.31.
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 10.2.1 20210110.
libc ABIs: UNIQUE IFUNC ABSOLUTE
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.
linux debian
Martin Hope
malat
Asked: 2020-02-28 01:07:04 +0800 CST
  • -1

Eu tenho acesso a um sistema Ubuntu que é assim:

$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
[...]
sda           8:0    0   1.8T  0 disk 
└─sda1        8:1    0   1.8T  0 part /mnt/dbc64c37-340a-49e5-8184-a69e01e5e231
nvme0n1     259:0    0   477G  0 disk 
├─nvme0n1p1 259:1    0   650M  0 part /boot/efi
└─nvme0n1p2 259:2    0 372.5G  0 part /

Eu configurei um Debian/sid schroot assim:

$ cat /etc/schroot/chroot.d/sid64 
[sid64]
description=Contains the SPICE program
aliases=sid
type=directory
directory=/home/malat/schroots/sid-root
users=malat
root-groups=root
profile=desktop
personality=linux
preserve-environment=true

Eu não mudei nada para /etc/schroot/default/fstab, e ao entrar no meu schroot sid64aqui está o que vejo:

$ schroot -c sid
(sid64)$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
[...]
sda           8:0    0   1.8T  0 disk 
└─sda1        8:1    0   1.8T  0 part
nvme0n1     259:0    0   477G  0 disk 
├─nvme0n1p1 259:1    0   650M  0 part 
└─nvme0n1p2 259:2    0 372.5G  0 part /var/lib/dbus

Se eu fizer manualmente:

$ sudo mount /dev/sda1 /mnt/dbc64c37-340a-49e5-8184-a69e01e5e231
$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda           8:0    0   1.8T  0 disk 
└─sda1        8:1    0   1.8T  0 part /mnt/bdc64c37-340a-49e5-8184-a69e01e5e231
nvme0n1     259:0    0   477G  0 disk 
├─nvme0n1p1 259:1    0   650M  0 part 
└─nvme0n1p2 259:2    0 372.5G  0 part /var/lib/dbus

Como posso montar automaticamente /mnt/dbc64c37-340a-49e5-8184-a69e01e5e231no meu schroot (este é meu disco principal onde meus dados estão localizados)?

Até agora eu tentei um ingênuo:

$ sudo mkdir /home/malat/schroots/sid-root/mnt/dbc64c37-340a-49e5-8184-a69e01e5e231
$ tail -1 /etc/schroot/default/fstab 
/dev/disk/by-uuid/dbc64c37-340a-49e5-8184-a69e01e5e231 /mnt/dbc64c37-340a-49e5-8184-a69e01e5e231 none rw,bind 0 0
$ schroot -c sid
(sid64)$ ls -al /dev/disk/by-uuid/dbc64c37-340a-49e5-8184-a69e01e5e231
lrwxrwxrwx 1 root root 10 Jan  8 01:00 /dev/disk/by-uuid/dbc64c37-340a-49e5-8184-a69e01e5e231 -> ../../sda1

assim como:

$ tail -1 /etc/schroot/default/fstab
/mnt/dbc64c37-340a-49e5-8184-a69e01e5e231 /mnt/dbc64c37-340a-49e5-8184-a69e01e5e231 none    rw,bind 0 0

Ambos não funcionaram para mim.

Eu também tentei um ingênuo:

$ sudo mount --rbind /mnt/dbc64c37-340a-49e5-8184-a69e01e5e231 /home/malat/schroots/sid-root/mnt/dbc64c37-340a-49e5-8184-a69e01e5e231
$ mount | grep dbc64c37
/dev/sda1 on /mnt/dbc64c37-340a-49e5-8184-a69e01e5e231 type ext4 (rw,nosuid,nodev,relatime,x-gvfs-show)
/dev/sda1 on /home/malat/schroots/sid-root/mnt/dbc64c37-340a-49e5-8184-a69e01e5e231 type ext4 (rw,nosuid,nodev,relatime)
$ schroot -c sid
(sid64)$ ls -al /mnt/dbc64c37-340a-49e5-8184-a69e01e5e231
-> empty !
mount udev
Martin Hope
malat
Asked: 2020-01-31 00:50:41 +0800 CST
  • 1

Estou lutando para montar um diretório CIFS remoto em um sistema Ubuntu no trabalho. A pasta remota parece estar funcionando bem na minha sessão do Windows 8.1 (também no trabalho).

Não consegui fazer a montagem normal funcionar:

$ sudo mount -v -t cifs //1.2.3.4/network ~/z -o username=malat,domain=MY,uid=$(id -u),gid=$(id -g),iocharset=utf8
Password for malat@//1.2.3.4/network:  *********
mount.cifs kernel mount options: ip=1.2.3.4,unc=\\1.2.3.4\network,iocharset=utf8,uid=1002,gid=1002,user=mmalaterre,domain=MY,pass=********
mount error(2): No such file or directory
Refer to the mount.cifs(8) manual page (e.g. man mount.cifs)

Mas eventualmente me deparei com esta ref :

$ sudo mount -v -t cifs //1.2.3.4/network ~/z -o username=malat,domain=MY,uid=$(id -u),gid=$(id -g),iocharset=utf8,nodfs
Password for malat@//1.2.3.4/network:  *********
mount.cifs kernel mount options: ip=1.2.3.4,unc=\\1.2.3.4\network,iocharset=utf8,nodfs,uid=1002,gid=1002,user=malat,domain=MY,pass=********

Pelo menos eu tenho algo funcionando agora:

$ mount | grep network
//1.2.3.4/network on /home/malat/z type cifs (rw,relatime,vers=2.1,cache=strict,username=malat,domain=MY,uid=1002,forceuid,gid=1002,forcegid,addr=1.2.3.4,file_mode=0755,dir_mode=0755,soft,nounix,nodfs,mapposix,rsize=1048576,wsize=1048576,bsize=1048576,echo_interval=60,actimeo=1)

No entanto, parece haver algo que não está funcionando (relacionado à opção DFS, eu acho). Aqui estão os sintomas:

$ cd ~/z
$ ls
folder1 folder2
$ ls folder1
subfolder1
$ ls folder2
ls: cannot access 'folder2': Invalid argument

Posso acessar a pasta folder2muito bem na minha sessão do Windows 8.1, portanto, isso não é um problema de permissão. Como posso acessar folder2da minha sessão Linux?

Aqui está a cauda de dmesg:

[1927958.534353] CIFS: Attempting to mount //1.2.3.4/network
[1927958.534403] No dialect specified on mount. Default has changed to a more secure dialect, SMB2.1 or later (e.g. SMB3), from CIFS (SMB1). To use the less secure SMB1 dialect to access old servers which do not support SMB3 (or SMB2.1) specify vers=1.0 on mount.
[1927960.069018] CIFS VFS: DFS capability contradicts DFS flag
[1927960.375111] CIFS VFS: Autodisabling the use of server inode numbers on new server.
[1927960.375115] CIFS VFS: The server doesn't seem to support them properly or the files might be on different servers (DFS).
[1927960.375117] CIFS VFS: Hardlinks will not be recognized on this mount. Consider mounting with the "noserverino" option to silence this message.

Atualização: se eu adicionar vers=1.0ao comando mount, os sintomas são um pouco diferentes:

$ cd ~/z
$ cd folder2
$ ls
subfolder2
$ cd subfolder2/
bash: cd: subfolder2/: Object is remote

Para referência:

$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 19.04
Release:        19.04
Codename:       disco

versão do núcleo:

$ uname -rvo
5.0.0-38-generic #41-Ubuntu SMP Tue Dec 3 00:27:35 UTC 2019 GNU/Linux

e

$ cat /etc/request-key.d/cifs.spnego.conf
create  cifs.spnego    * * /usr/sbin/cifs.upcall %k

Atualizar:

ubuntu mount
Martin Hope
malat
Asked: 2018-12-14 06:25:48 +0800 CST
  • 6

Por algum motivo, não consigo cd em um diretório remoto específico ao qual tenho acesso, ele falha com:

$ cd Data\ Services/
-bash: cd: Data Services/: Invalid argument

Foi assim que montei:

$ sudo mount -t cifs //big.acme.corp/network/ ~/z -o username=myuser,domain=mydomain,uid=$(id -u),gid=$(id -g),vers=1.0
Password for myuser@//big.acme.corp/network/:  *********

Posso acessá-lo muito bem no meu laptop Windows 8 (mesmo nome de usuário/senha).

para referência:

$ ls -ald "Data Services"
drwx--x--x 2 myuser myuser 0 Dec 13 09:21 Data Services

Pelo menos do meu lado, parece que esse atalho é visto como um diretório:

$ find Data\ Services -type d
Data Services
find: ‘Data Services’: Invalid argument

Como tal, não posso fazer muito com isso:

$ cat Data\ Services
cat: Data Services: Invalid argument

ou mesmo

$ hexdump Data\ Services
hexdump: Data Services: Invalid argument
hexdump: all input file arguments failed

Conforme sugerido abaixo, tentei novamente com o noperm:

$ sudo mount -t cifs //big.acme.corp/network/ ~/z -o username=myuser,domain=mydomain,uid=$(id -u),gid=$(id -g),noperm

O que me dá:

$ mount
...
//big.acme.corp/network/ on /home/myuser/z type cifs (rw,relatime,vers=1.0,cache=strict,username=big.acme.corp,domain=mydomain,uid=1002,forceuid,gid=1003,forcegid,addr=10.1.2.3,file_mode=0755,dir_mode=0755,nounix,mapposix,noperm,rsize=61440,wsize=65536,echo_interval=60,actimeo=1)

Isso não mudou nada:

$ strings Data\ Services
strings: Data Services: Invalid argument
fedora cd-command
Martin Hope
malat
Asked: 2018-10-01 23:33:06 +0800 CST
  • 0

Em uma nova instalação Debian/stable 9.5 em um MacBookPro10,1, estou tentando exibir informações de acpi na linha de comando.

Aqui está o que eu vejo:

$ find /proc/acpi/
/proc/acpi/
/proc/acpi/button
/proc/acpi/button/lid
/proc/acpi/button/lid/LID0
/proc/acpi/button/lid/LID0/state
/proc/acpi/wakeup

Mas acpiparece ver a bateria de qualquer maneira:

$ acpi -V
Battery 0: Discharging, 46%, 01:17:56 remaining
Battery 0: design capacity 8460 mAh, last full capacity 7415 mAh = 87%
Adapter 0: off-line
Cooling 0: Processor 0 of 17
Cooling 1: Processor 0 of 17
Cooling 2: Processor 0 of 17
Cooling 3: BAT0 no state information available
Cooling 4: Processor 0 of 17
Cooling 5: intel_powerclamp no state information available
Cooling 6: Processor 0 of 17
Cooling 7: Processor 0 of 17
Cooling 8: Processor 0 of 17
Cooling 9: x86_pkg_temp no state information available
Cooling 10: Processor 0 of 17

O que está faltando na instalação para obter as informações adequadas da bateria da /proc/acpiinterface?

linux debian
Martin Hope
malat
Asked: 2018-06-08 23:24:48 +0800 CST
  • 8

O status do UBIFS no Linux em cima do MLC NAND nunca foi exatamente perfeito . E embora essa entrada tenha sido removida do FAQ hoje em dia , o suporte para UBIFS em cima do MLC NAND agora foi oficialmente relatado como não suportado:

Tópico completo em patchwork.kernel.org:

Então, agora estou procurando uma substituição de sistema de arquivos de longo prazo para um MLC NAND, conforme encontrado em um MIPS Creator CI20 :

Este é um flash NAND Samsung K9GBG08UOA e não parece haver uma maneira de colocar este dispositivo no modo SLC.

Parece que jffs2 também não é uma alternativa:

Existe algum outro sistema de arquivos alternativo (possivelmente com desempenho comparável)?

linux filesystems
Martin Hope
malat
Asked: 2018-02-03 09:03:31 +0800 CST
  • 1

Estou tentando entender o que estou fazendo de errado aqui. Fiquei com a impressão de que make savedefconfigseria o caminho a seguir para reduzir uma configuração ao mínimo (equivalente).

Então, aqui está o meu passo, pegue um arquivo de configuração do pacote Debian diretamente:

$ dpkg -S /boot/config-4.14.0-3-powerpc
linux-image-4.14.0-3-powerpc: /boot/config-4.14.0-3-powerpc
$ apt-cache policy linux-image-4.14.0-3-powerpc
linux-image-4.14.0-3-powerpc:
  Installed: 4.14.13-1
  Candidate: 4.14.13-1
  Version table:
 *** 4.14.13-1 500
        500 http://ftp.fr.debian.org/debian sid/main powerpc Packages
        100 /var/lib/dpkg/status

Copie-o para a minha máquina principal:

$ scp macminig4:/boot/config-4.14.0-3-powerpc ./arch/powerpc/configs/my_defconfig

Verifique se a opção com a qual quero jogar ainda está lá:

$ grep CONFIG_SSB_B43_PCI_BRIDGE ./arch/powerpc/configs/my_defconfig
CONFIG_SSB_B43_PCI_BRIDGE=y

Agora vamos atualizá-lo, pois não está em perfeita sincronia com o git v4.14:

$ git checkout v4.14
$ make ARCH=powerpc my_defconfig
$ diff -u .config ./arch/powerpc/configs/my_defconfig | diffstat
 my_defconfig |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

Então, algumas pequenas alterações ocorreram, mas nada de ruim, pelo menos ainda posso ver minha opção:

$ grep CONFIG_SSB_B43_PCI_BRIDGE .config
CONFIG_SSB_B43_PCI_BRIDGE=y

Agora vamos tentar um saveefconfig:

$ make ARCH=powerpc savedefconfig
  HOSTCC  scripts/basic/fixdep
  HOSTCC  scripts/basic/bin2c
  HOSTCC  scripts/kconfig/conf.o
  SHIPPED scripts/kconfig/zconf.tab.c
  SHIPPED scripts/kconfig/zconf.lex.c
  HOSTCC  scripts/kconfig/zconf.tab.o
  HOSTLD  scripts/kconfig/conf
scripts/kconfig/conf  --savedefconfig=defconfig Kconfig

Se eu marcar agora, minha opção está perdida para sempre:

$ grep CONFIG_SSB_B43_PCI_BRIDGE defconfig 
-> nothing !

Por que algumas opções estão desaparecendo? Existe uma maneira de controlar savedefconfigpara preservar alguma opção?

linux-kernel configuration