Perguntas[debian](unix)

Um servidor Debian é usado por várias pessoas. Cada usuário usa sua própria conta. Os usuários carregam e usam grandes arquivos binários em /opt/cache. Se /opt/cacheestiver cheio, os carregadores fazem rm -r $(ls -t | tail)para remover os binários mais antigos (que podem ser agrupados em subpastas).

Os usuários geralmente não conseguem limpar o cache por causa de arquivos com 644permissões. Posso, de alguma forma, permitir que todos os usuários excluam o conteúdo de /opt/cache, independentemente do que foi carregado nele?

Fiz o seguinte para fazer com que todos os arquivos fossem atribuídos ao cache_usersgrupo, mas isso não ajuda se os arquivos não forem graváveis ​​no grupo:

chown blabla:cache_users /opt/cache
setfacl -Rdm u::rwx,g::rwx,o::rwx /opt/cache
chmod 2775 /opt/cache

enquanto eu estava instalando o Davinci resolve no debian eu tive um problema

unsupported GPU processing mode

embora eu realmente não saiba como resolver, usei um tutorial do youtube e quando instalei os pacotes atuais

fakeroot xorriso nvidia-driver nvidia-opencl-icd libcuda1 libnvidia-encode1

e depois de tudo isso o problema ainda existe na resolução Davinci

mas agora quando eu inicio o debian aparece uma tarefa FALHOU dizendo

[FAILED] Failed to start systemd-modules-load.service - load kernel Modules.
see 'systemctl systemd-modules-load.service' for details

depois disso removi os pacotes que instalei antes de usar

sudo apt remove ...
sudo apt autoremove

mas o aviso ainda existe

como faço para remover esse aviso?

a propósito, executei o comando que eles sugeriram e obtive o seguinte

× systemd-modules-load.service - Load Kernel Modules
     Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; static)
     Active: failed (Result: exit-code) since Wed 2025-02-05 23:21:42 +03; 15min ago
       Docs: man:systemd-modules-load.service(8)
             man:modules-load.d(5)
    Process: 303 ExecStart=/lib/systemd/systemd-modules-load (code=exited, status=1/FAILURE)
   Main PID: 303 (code=exited, status=1/FAILURE)
        CPU: 4.095s

Feb 05 23:21:41 debian systemd-modules-load[646]: modprobe: ERROR: could not insert 'nvidia_current_modeset': No such device
Feb 05 23:21:41 debian systemd-modules-load[320]: modprobe: ERROR: ../libkmod/libkmod-module.c:1047 command_do() Error running install command 'modprobe nvidia ; modprobe -i nvidia-current-modeset ' for module nvidia_modeset: retcode 1
Feb 05 23:21:41 debian systemd-modules-load[320]: modprobe: ERROR: could not insert 'nvidia_modeset': Invalid argument
Feb 05 23:21:42 debian systemd-modules-load[666]: modprobe: ERROR: could not insert 'nvidia_current_drm': No such device
Feb 05 23:21:42 debian systemd-modules-load[303]: Error running install command 'modprobe nvidia-modeset ; modprobe -i nvidia-current-drm ' for module nvidia_drm: retcode 1
Feb 05 23:21:42 debian systemd-modules-load[303]: Failed to insert module 'nvidia_drm': Invalid argument
Feb 05 23:21:42 debian systemd[1]: systemd-modules-load.service: Main process exited, code=exited, status=1/FAILURE
Feb 05 23:21:42 debian systemd[1]: systemd-modules-load.service: Failed with result 'exit-code'.
Feb 05 23:21:42 debian systemd[1]: Failed to start systemd-modules-load.service - Load Kernel Modules.
Feb 05 23:21:42 debian systemd[1]: systemd-modules-load.service: Consumed 4.095s CPU time.

quando eu corro

lspci | grep vga

a saída está vazia mesmo usando sudo

saída para

lspci

é

00:00.0 Host bridge: Intel Corporation Comet Lake-U v1 4c Host Bridge/DRAM Controller (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation CometLake-U GT2 [UHD Graphics] (rev 02)
00:04.0 Signal processing controller: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Thermal Subsystem (rev 0c)
00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model
00:12.0 Signal processing controller: Intel Corporation Comet Lake Thermal Subsytem
00:14.0 USB controller: Intel Corporation Comet Lake PCH-LP USB 3.1 xHCI Host Controller
00:14.2 RAM memory: Intel Corporation Comet Lake PCH-LP Shared SRAM
00:14.3 Network controller: Intel Corporation Comet Lake PCH-LP CNVi WiFi
00:15.0 Serial bus controller: Intel Corporation Serial IO I2C Host Controller
00:16.0 Communication controller: Intel Corporation Comet Lake Management Engine Interface
00:17.0 SATA controller: Intel Corporation Comet Lake SATA AHCI Controller
00:19.0 Serial bus controller: Intel Corporation Comet Lake Serial IO I2C Host Controller
00:19.2 Communication controller: Intel Corporation Device 02c7
00:1d.0 PCI bridge: Intel Corporation Comet Lake PCI Express Root Port #13 (rev f0)
00:1f.0 ISA bridge: Intel Corporation Comet Lake PCH-LP LPC Premium Controller/eSPI Controller
00:1f.3 Audio device: Intel Corporation Comet Lake PCH-LP cAVS
00:1f.4 SMBus: Intel Corporation Comet Lake PCH-LP SMBus Host Controller
00:1f.5 Serial bus controller: Intel Corporation Comet Lake SPI (flash) Controller
01:00.0 Non-Volatile memory controller: Intel Corporation SSD 670p Series [Keystone Harbor] (rev 03)

ATUALIZAÇÃO: não tenho uma placa de vídeo nvidia, sei disso desde o começo, só quero me livrar desse aviso

ATUALIZAÇÃO: sou um pouco novato nessas coisas. Primeiro eu não sabia qual placa de vídeo eu tinha, só queria instalar o davinci resolve e resolver o problema. Agora estou preso nisso.

ATUALIZAÇÃO: isso significa que não posso instalar o davinci resolve? Existe alguma maneira de desfazer o que fiz?

Pesquisei e encontrei 3 maneiras de verificar a versão:

lsb_release -a

No LSB modules are available.
Distributor ID: Debian
Description:    Debian GNU/Linux 12 (bookworm)
Release:    12
Codename:   bookworm

gato /proc/versão

Linux version 6.1.0-30-amd64 ([email protected]) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 6.1.124-1 (2025-01-12)

gato /etc/versão_debian

12.9

Mas estou recebendo 3 versões diferentes. Como posso saber qual é a correta?

Tenho um bug meio estranho. Tento montar o compartilhamento smb/cifs do windows server 2019 como servidor usando o Debian como cliente. O comando exato a seguir funciona no Debian 11.11, mas não no 12.9 com myuser como usuário de domínio:

mount -v -t cifs "//host/Backup/myhost" /mnt/backup-myhost/ -o "username=myuser,password=mypassword,domain=mydomain"

que dá tanto na saída detalhada

mount.cifs kernel mount options: ip=1.2.3.4,unc=\\host\Backup,user=myuser,domain=mydomain,prefixpath=myhost,pass=*******

O Debian 12.9 apresenta o erro adicional mount error(13): Permission denied

Também tentei várias opções "sec" e "version". As permissões de /mnt/backup-myhost/ são 755 em ambas. O servidor Windows diz que o usuário "root" (sic!) tenta conectar, mas o mount usa "myuser".

Aqui está a última parte da saída do dmesg do Debian 12.9, mas não consigo ver uma causa mesmo depois de comparar com o Debian 11.11:

...
[499614.187245] CIFS: fs/smb/client/transport.c: wait_for_free_credits: remove 1 credits total=0
[499614.187248] CIFS: fs/smb/client/transport.c: Sending smb: smb_len=372
[499614.188538] CIFS: fs/smb/client/connect.c: RFC1002 header 0x48
[499614.188542] CIFS: fs/smb/client/smb2misc.c: SMB2 data length 0 offset 0
[499614.188543] CIFS: fs/smb/client/smb2misc.c: SMB2 len 73
[499614.188545] CIFS: fs/smb/client/smb2ops.c: smb2_add_credits: added 1 credits total=1
[499614.188556] CIFS: fs/smb/client/transport.c: cifs_sync_mid_result: cmd=1 mid=2 state=64
[499614.188560] CIFS: Status code returned 0xc0000070 STATUS_INVALID_WORKSTATION
[499614.188562] CIFS: fs/smb/client/smb2maperror.c: Mapping SMB2 status code 0xc0000070 to POSIX err -13
[499614.188563] CIFS: fs/smb/client/misc.c: Null buffer passed to cifs_small_buf_release
[499614.188566] CIFS: VFS: \\host Send error in SessSetup = -13
[499614.188569] CIFS: fs/smb/client/connect.c: VFS: leaving cifs_get_smb_ses (xid = 111) rc = -13
[499614.188572] CIFS: fs/smb/client/dfs_cache.c: cache_refresh_path: search path: \host\Backup
[499614.188576] CIFS: fs/smb/client/dfs_cache.c: get_dfs_referral: get an DFS referral for \host\Backup
[499614.188586] CIFS: fs/smb/client/connect.c: VFS: leaving mount_put_conns (xid = 110) rc = 0
[499614.188588] CIFS: VFS: cifs_mount failed w/return code = -13

Existe algum script de shell que atualize meus arquivos para mim?

# apt update
Notice: Missing Signed-By in the sources.list(5) entry for 'https://storage.googleapis.com/cros-packages/133'
Notice: Missing Signed-By in the sources.list(5) entry for 'http://opensource.nchc.org.tw/debian'
Notice: Consider migrating all sources.list(5) entries to the deb822 .sources format
Notice: The deb822 .sources format supports both embedded as well as external OpenPGP keys
Notice: See apt-secure(7) for best practices in configuring repository signing.

Passei horas tentando descobrir isso e simplesmente desisti.

Meus arquivos só têm linhas "deb...".

E aqui está

$ cd /usr/share/keyrings && ls
cros.gpg                                        debian-archive-bullseye-stable.gpg
debian-archive-bookworm-automatic.gpg           debian-archive-buster-automatic.gpg
debian-archive-bookworm-security-automatic.gpg  debian-archive-buster-security-automatic.gpg
debian-archive-bookworm-stable.gpg              debian-archive-buster-stable.gpg
debian-archive-bullseye-automatic.gpg           debian-archive-keyring.gpg
debian-archive-bullseye-security-automatic.gpg  debian-archive-removed-keys.gpg

Também registrei https://issues.chromium.org/issues/392237686 porque /etc/apt/sources.list.d/cros.list não deveria ser responsabilidade da equipe do Chrome atualizar, e não minha?

Para o meu trabalho, estou usando uma série de dispositivos montando o Debian 9 stretch. Ouvi falar da vulnerabilidade do rsync, que nossos dispositivos usam. Li no anúncio do Debian que o Bullseye (11) não é afetado. No entanto, no anúncio sobre o mesmo tópico para o Ubuntu, é dito que as versões afetadas upstream do rsync são de 3.1.0 a pelo menos 3.2.7, ou seja, de 2014 até agora, então eu esperaria que as versões upstream do Debian também fossem afetadas. Por exemplo, posso ver que meus dispositivos usam o rsync 3.1.2. Então minha pergunta é: posso ter certeza de que as versões pré-Bullseye do Debian não são afetadas (devido a, eu acho, diferentes patches aplicados em relação ao Ubuntu?), ou devo compilar a partir da fonte a nova versão do rsync, para ter certeza?

Estou no Debian 12 e hoje enquanto estava instalando o Davinci Resolve aconteceu que a seguinte notificação apareceu

a raiz do sistema de arquivos tem apenas 500 MB

embora eu tenha cerca de 400 GB, na verdade não entendo como o Linux usa esse espaço e agora sinto que meu computador pode estar em perigo e temo não conseguir instalar algo no futuro

Alguém poderia me dizer como gerenciar meu uso de espaço? Usei o comando current para ter certeza de que entendi bem as coisas.

$ sudo lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
loop0         7:0    0     4K  1 loop /snap/bare/5
loop1         7:1    0   104M  1 loop /snap/core/16928
loop2         7:2    0  73.9M  1 loop /snap/core22/1722
loop3         7:3    0  73.9M  1 loop /snap/core22/1663
loop4         7:4    0  66.2M  1 loop /snap/core24/490
loop5         7:5    0 104.2M  1 loop /snap/core/17200
loop6         7:6    0  66.2M  1 loop /snap/core24/609
loop7         7:7    0  91.7M  1 loop /snap/gtk-common-themes/1535
loop8         7:8    0 448.6M  1 loop /snap/telegram-desktop/6470
loop9         7:9    0  44.4M  1 loop /snap/snapd/23545
loop10        7:10   0 448.6M  1 loop /snap/telegram-desktop/6474
loop11        7:11   0  44.3M  1 loop /snap/snapd/23258
nvme0n1     259:0    0 476.9G  0 disk 
├─nvme0n1p1 259:1    0   512M  0 part /boot/efi
├─nvme0n1p2 259:2    0  27.9G  0 part /
├─nvme0n1p3 259:3    0   7.5G  0 part [SWAP]
└─nvme0n1p4 259:4    0   441G  0 part /home

embora eu realmente não entenda nada dessa saída

atualização: saída de

df -h

Filesystem      Size  Used Avail Use% Mounted on
udev            3.8G     0  3.8G   0% /dev
tmpfs           769M  2.3M  766M   1% /run
/dev/nvme0n1p2   28G   26G  308M  99% /
tmpfs           3.8G  1.1M  3.8G   1% /dev/shm
tmpfs           5.0M  8.0K  5.0M   1% /run/lock
/dev/loop5      105M  105M     0 100% /snap/core/17200
/dev/loop4       67M   67M     0 100% /snap/core24/490
/dev/loop0      128K  128K     0 100% /snap/bare/5
/dev/loop7       92M   92M     0 100% /snap/gtk-common-themes/1535
/dev/loop2       74M   74M     0 100% /snap/core22/1722
/dev/loop1      104M  104M     0 100% /snap/core/16928
/dev/loop6       67M   67M     0 100% /snap/core24/609
/dev/loop3       74M   74M     0 100% /snap/core22/1663
/dev/nvme0n1p4  434G   25G  387G   7% /home
/dev/loop8      449M  449M     0 100% /snap/telegram-desktop/6470
/dev/loop10     449M  449M     0 100% /snap/telegram-desktop/6474
/dev/loop9       45M   45M     0 100% /snap/snapd/23545
/dev/loop11      45M   45M     0 100% /snap/snapd/23258
/dev/nvme0n1p1  511M  5.9M  506M   2% /boot/efi
tmpfs           769M  2.5M  766M   1% /run/user/1000

saída de

sudo du -mx -d 1 / | sort -n

1   /.cache
1   /lost+found
1   /media
1   /mnt
1   /snap
1   /srv
1   /tmp
12  /etc
137 /boot
1410    /root
6540    /opt
7294    /var
10845   /usr
26235   /

atualização: 21 de janeiro de 2025 depois de ler todos os comentários e perceber o quão complicado, difícil de obter e muito caro isso vai levar

Vou pegar todas as minhas coisas importantes e reinstalar o Debian

a única coisa que resta é saber qual a melhor partição hoje em dia para não entrar nisso novamente no futuro

Vocês sugerem algo especial sobre isso?

Tenho um host debian configurado como NAS usando 6 discos em uma configuração RAID 5. A configuração atual é a seguinte:

# mdadm -D /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Fri Mar 12 11:42:23 2021
        Raid Level : raid5
        Array Size : 19534424640 (18.19 TiB 20.00 TB)
     Used Dev Size : 3906884928 (3.64 TiB 4.00 TB)
      Raid Devices : 6
     Total Devices : 6
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Sat Jan 18 17:44:06 2025
             State : clean
    Active Devices : 6
   Working Devices : 6
    Failed Devices : 0
     Spare Devices : 0

            Layout : left-symmetric
        Chunk Size : 64K

Consistency Policy : bitmap

              Name : data:0
              UUID : 2265a382:cb20817f:de0f543b:a830605c
            Events : 547472

    Number   Major   Minor   RaidDevice State
       9       8       33        0      active sync   /dev/sdc1
       8       8       17        1      active sync   /dev/sdb1
      10       8       81        2      active sync   /dev/sdf1
      11       8       97        3      active sync   /dev/sdg1
       6       8       65        4      active sync   /dev/sde1
       7       8       49        5      active sync   /dev/sdd1

sdbe sddsão discos de 8 TB, todos os outros membros RAID são de 4 TB. Agora, quero substituir os quatro discos de 4 TB por novos discos de 16 TB, converter a configuração RAID5 atual para RAID6 e aumentar o tamanho do dispositivo usado para 8 TB (o novo máximo, até que eu possa substituir os dois discos de 8 TB restantes por outros de 16 TB).

Agora estou procurando um procedimento para fazer isso com segurança, sem perda de dados e o mais livre de problemas possível. Durante o procedimento, o tempo de inatividade é aceitável, a perda de dados não. Como todos os slots SATA estão em uso no momento, não posso adicionar os novos discos enquanto os antigos ainda estiverem online. Terei que substituir um após o outro. Como tal, acho que seria sensato converter o RAID5 existente para RAID6 primeiro e, em seguida, trocar os discos um por um. Isso adicionaria outra camada de redundância durante o processo de reconstrução.

Depois de pesquisar online, o seguinte é o procedimento que eu criei. Alguém pode confirmar se essa é a maneira mais sensata de fazer isso, ou há etapas que estou esquecendo / há maneiras mais fáceis de fazer isso, dadas minhas restrições (atualização no local).

Meu plano atual:

1. faça backup de todos os dados de /mnt/md0
2. verificar integridade do backup
3. desmontar /mnt/md0
4. reduza o sistema de arquivos em /dev/md0 para o tamanho mínimo possível, veja https://access.redhat.com/articles/1196333 para o procedimento
   1. e2fsck -f /dev/md0verificar sistema de arquivos, -f força a verificação mesmo se estiver limpo
   2. resize2fs -P /dev/md0estimar tamanho mínimo
   3. resize2fs -p -M /dev/md0reduzir ao tamanho mínimo (-M) e imprimir o progresso (-p)
   4. e2fsck -f /dev/md0verifique o sistema de arquivos novamente para ter certeza de que está limpo
5. verifique o novo tamanho atual do sistema de arquivos:dumpe2fs -h /dev/md0 |& awk -F: '/Block count/{count=$2} /Block size/{size=$2} END{print count*size}'
6. falha em um dos discos de 8 TB no array RAID5:

   mdadm /dev/md0 --fail /dev/sdd
   

   falhamos em um disco de 8 TB porque isso garante que o mdadm não decidirá que a unidade é muito pequena (por algum motivo) quando a adicionarmos novamente mais tarde
7. Estime o novo tamanho do array RAID5, tentando executar este comando e verificando a mensagem de erro:

mdadm --grow /dev/md0 --raid-devices=5

8. Verifique se o sistema de arquivos é pequeno o suficiente para caber. Então, encolha o dispositivo de bloco:

mdadm --grow /dev/md0 --array-size [new_size]

9. reduzir a matriz RAID5 de 6 para 5 discos

mdadm --grow /dev/md0 --raid-devices=5 --backup-file=/root/md0_raid5_shrink.bak

10. aguarde o RAID5 terminar a reconstrução
11. adicione o disco removido como um hotspare

mdadm --add /dev/md0 /dev/sdd

12. aumentar a matriz RAID5 para RAID6 com 6 discos

mdadm --grow /dev/md0 --raid-devices 6 --level 6 --backup-file=/root/md0_raid5_to_raid6.bak

13. aguarde o RAID6 terminar a reconstrução
14. substitua cada disco de 4 TB um por um por discos de 16 TB, esperando que o RAID6 termine de reconstruir a cada vez, isso deve nos permitir manter a redundância durante a migração
    1. mdadm --fail /dev/md0 /dev/sdX
    2. mdadm --remove /dev/md0 /dev/sdX
    3. desligar e substituir disco
    4. mdadm --add /dev/md0 /dev/sdX
    5. aguarde o RAID6 terminar a reconstrução
15. aumentar o array RAID6 até o tamanho máximo (limitado pelos dois discos de 8 TB)

mdadm --grow /dev/md0 --size=max

16. aumentar o sistema de arquivos em /dev/md0 para o tamanho máximo

resize2fs /dev/md0

17. remontar /mnt/md0

Minhas perguntas são as seguintes:

1. Esta é a maneira recomendada de atualizar um array RAID5 para RAID6?
2. Já que quero evitar fazer uma pergunta sim/não: Se meu procedimento faz sentido, há maneiras de melhorá-lo para evitar o risco de perda de dados/ter que restaurar do backup? Há uma maneira mais rápida de fazer isso?
3. Tenho um arquivo de configuração gerado automaticamente no /etc/mdadm/mdadm.conf. Terei que alterá-lo de alguma forma? Isso acontecerá automaticamente ou não tem relação com todo o processo?

Mais algum contexto / outras informações:

• O sistema de arquivos em /dev/md0 é ext4.
• A raiz do sistema / está em /dev/sda, que não é impactada pela migração
• A maioria dos guias fala sobre adicionar um novo spare primeiro e depois migrar de RAID5 para RAID6. Isso não é (facilmente) possível neste caso porque todos os slots SATA já estão em uso.

Para um laptop HP Pavilion g4-1387la foi instalado o Debian 12 Desktop

As conexões Ethernet e Wi-Fi são possíveis.

Mas quando somente o WIFI é usado (sem cabo ethernet conectado) existe o problema de que a velocidade da internet é muito lenta. Eu coloquei as mesmas configurações de conexão WIFI de acordo com outros laptops na mesma LAN, todos eles baseados em outras distribuições Linux. Claro que o ipv4 é único

A placa sem fio é a seguinte (avise-me se precisar de mais dados - indique-me o comando a ser executado para compartilhar as informações):

lspci -vq | grep -i wireless
02:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4313 802.11bgn Wireless Network Adapter (rev 01)
Subsystem: Hewlett-Packard Company BCM4313 802.11bgn Wireless Network Adapter

Eu tive um problema semelhante sobre uma conexão WIFI através do PeppermintOS baseado no Debian de acordo com:

• https://sourceforge.net/p/peppermintos/pepos/net/thread/b3d502f094

A seguir a figura principal para melhor entendimento:

Observe a instalação dos 2 pacotes seguintes (entre outros):

• firmware-b43-instalador
• firmware-b43legacy-instalador

Agora, para o Debian existe o seguinte conjunto de pacotes:

Depois de instalar os pacotes firmware-b43-installerand firmware-b43legacy-installere mais, como mostrado na Figura anterior, na mesma máquina quando o pingcomando é executado para outro PC na mesma LAN, ele é rápido como se o mesmo comando fosse executado em outro PC na mesma LAN, mas infelizmente quando é aberto qualquer navegador da Web, ele pode funcionar rápido apenas por alguns segundos , mas aleatoriamente fica lento. É muito estranho.

Como resolver essa situação?

Só por precaução, na figura mostrada sobre o Debian foi utilizado Ethernet e o WIFI está desabilitado pelo modo avião

O Debian 12 estável fornece o LibreOffice versão 7.4.7.2. O LibreOffice.org oferece a versão 24.8.

Entendo que o Debian stable tenta fornecer versões estáveis ​​de software. Isso significa que as últimas 17 versões do LibreOffice não eram estáveis?