Mr. T's questions

Eu li a documentação do curtin e da instalação automática e não consigo entender por que esse script de instalação automática está funcionando no meu laptop de desenvolvimento, mas não na instalação do vbox (versão 7.0.8 no host Ubuntu). A princípio pensei que o problema fosse uma referência a /dev/mmcblk0(o virtualbox usa /dev/sda), mas depois de fazer várias configurações diferentes, não acho que esse seja realmente o problema por causa da mensagem de erro que isso gera. O éautoinstall config did not create needed bootloader partition

Minha teoria é que essa instalação automática funciona no laptop porque o laptop é UEFI, mas não no Virtualbox porque não é. Encontrei algumas sugestões em outro lugar sobre como fazer uma instalação automática que funciona para UEFI funcionar no MBR, mas nenhuma que seja capaz de fazer as duas coisas.

Esse é o problema com esse layout de particionamento de instalação automática? Existe alguma solução? Não posso usar os layouts integrados (lvm etc) devido aos requisitos específicos deste projeto. Sei que poderia alterar as configurações do Virtualbox para inicialização EFI, mas este ISO terá que ser instalado em uma ampla variedade de máquinas, algumas das quais podem não suportar EFI.

Aqui está meu layout de particionamento atual, que está funcionando em um laptop com um dispositivo em/dev/mmcblk0

Como esse script precisa ser modificado para funcionar em qualquer sistema? E sim, a partição /boot realmente precisa ser tão grande para esta configuração.

autoinstall:
  version: 1
  storage:
    config:
    - ptable: gpt
      wipe: superblock-recursive
      preserve: false
      name: ''
      grub_device: false
      type: disk
      id: disk-mmcblk0
      match:
        size: largest
    - device: disk-mmcblk0
      size: 1127219200
      wipe: superblock
      flag: boot
      number: 1
      preserve: false
      grub_device: true
      type: partition
      id: partition-0
    - fstype: fat32
      volume: partition-0
      preserve: false
      type: format
      id: format-0
    - device: disk-mmcblk0
      size: 5GB
      wipe: superblock
      number: 2
      preserve: false
      type: partition
      id: partition-1
    - fstype: ext4
      volume: partition-1
      preserve: false
      type: format
      id: format-1
    - device: disk-mmcblk0
      size: -1
      wipe: superblock
      number: 3
      preserve: false
      type: partition
      id: partition-2
    - volume: partition-2
      key: password
      path: /dev/mapper/dm_crypt-0
      preserve: false
      type: dm_crypt
      id: dm_crypt-0
    - name: ubuntu-vg
      devices:
      - dm_crypt-0
      preserve: false
      type: lvm_volgroup
      id: lvm_volgroup-0
    - name: ubuntu-lv
      volgroup: lvm_volgroup-0
      size: -1
      wipe: superblock
      preserve: false
      path: /dev/ubuntu-vg/ubuntu-lv
      type: lvm_partition
      id: lvm_partition-0
    - fstype: btrfs
      volume: lvm_partition-0
      preserve: false
      type: format
      id: format-2
    - path: /
      device: format-2
      type: mount
      id: mount-2
      options: 'noatime,discard,compress=zstd:1'
    - path: /boot
      device: format-1
      type: mount
      id: mount-1
    - path: /boot/efi
      device: format-0
      type: mount
      id: mount-0

Eu tenho uma configuração lvm criptografada padrão do Ubuntu. /dev/sda3é criptografado com LUKS. Dentro desse contêiner LUKS está um LVM (at /dev/mapper/dm_crypt-0) e dentro desse LVM está um sistema de arquivos montado de /dev/ubuntu-vg/ubuntu-lvpara/

Como posso converter o ponto de montagem conhecido /em /dev/sda3uma linha no bash, de preferência sem root? Eu ficaria feliz em instalar um utilitário separado se pudesse fazer isso.

Eu descobri df|tail -n +2|cut -f 1 -dcomo me pegar /dev/mapper/ubuntu--vg-ubuntu--lv, mas como faço para sair /dev/sda3disso?

Estou criando um ISO personalizado com instalação automática para instalar automaticamente o Ubuntu Server em nossas máquinas. É claro que precisamos instalar alguns pacotes apt como parte da personalização. O problema é que esta instalação precisa ser feita totalmente offline, então não posso simplesmente adicioná-los à lista de pacotes do apt e fazer com que a magia da subiquidade cuide de tudo.

Estou usando esse método para compactar o arquivo de instalação/autoinstalação do usuário na iso e está funcionando bem.

Como posso baixar pacotes apt com antecedência, incluí-los no iso e fazer com que o subiquity os encontre e instale automaticamente?

Estou tentando fazer uma instalação ISO personalizada para Ubuntu com a opção de pré-configuração do Cubic e Ubiquity. Eu tenho arrancado meus cabelos tentando fazer com que ele particione automaticamente todo o disco como um LVM criptografado, como o instalador da GUI permite. Eu tentei quase uma dúzia de exemplos de configurações de pré-configuração que encontrei on-line, todas as quais terminam com erro do instalador durante o particionamento porque:

No modifications can be made to the device: Encrypted Volume (sda1p2_crypt) for the following reasons: In use by LVM module group cryptou qualquer que seja o nome da receita para o grupo LVM. Presumo que essas receitas funcionaram para versões anteriores do Ubuntu.

A princípio, pensei que esse erro era apenas porque o disco tinha algum particionamento pré-existente com LVMs criptografados, então executei um sgdisk -Z /dev/sda, reiniciei e tentei novamente, mas os problemas persistiram.

Posso, é claro, particionar manualmente o disco com a GUI do instalador.

Aqui está uma seção de amostra da pré-configuração:

d-i partman-auto/method string crypto
d-i partman-lvm/device_remove_lvm boolean true
d-i partman-lvm/confirm boolean true
d-i partman-auto-lvm/guided_size string max
d-i partman-auto-lvm/new_vg_name string crypt
d-i partman-auto/choose_recipe select root-encrypted
d-i partman-auto/expert_recipe string                         \
      root-encrypted ::                                       \
              500 500 500 ext4                                \
                      $primary{ } $bootable{ }                \
                      method{ format } format{ }              \
                      use_filesystem{ } filesystem{ ext4 }    \
                      mountpoint{ /boot }                     \
              .                                               \
              2000 2000 2000 linux-swap                       \
                      $lvmok{ } lv_name{ swap }               \
                      in_vg { crypt }                         \
                      $primary{ }                             \
                      method{ swap } format{ }                \
              .                                               \
              500 10000 1000000000 ext4                       \
                      $lvmok{ } lv_name{ rootpart }           \
                      in_vg { crypt }                         \
                      $primary{ }                             \
                      method{ format } format{ }              \
                      use_filesystem{ } filesystem{ ext4 }    \
                      mountpoint{ / }                         \
              .                                               
d-i partman-md/device_remove_md boolean true
d-i partman-basicfilesystems/no_mount_point boolean false
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true

Outro que produz o mesmo erro. Neste, não estou usando uma receita customizada, apenas opto pela receita embutida.

#Get around the prompt for UEFI-only
d-i partman-efi/non_efi_system boolean true
d-i partman/default_filesystem string ext4

# In addition, you'll need to specify the method to use.
# The presently available methods are:
# - regular: use the usual partition types for your architecture
# - lvm:     use LVM to partition the disk
# - crypto:  use LVM within an encrypted partition
d-i partman-auto/method string crypto
d-i partman-crypto/passphrase password mypassword7
d-i partman-crypto/passphrase-again password mypassword7

# If one of the disks that are going to be automatically partitioned
# contains an old LVM configuration, the user will normally receive a
# warning. This can be preseeded away...
d-i partman-lvm/device_remove_lvm boolean true
# The same applies to pre-existing software RAID array:
d-i partman-md/device_remove_md boolean true
# And the same goes for the confirmation to write the lvm partitions.
d-i partman-lvm/confirm boolean true
d-i partman-lvm/confirm_nooverwrite boolean true

# For LVM partitioning, you can select how much of the volume group to use
# for logical volumes.
d-i partman-auto-lvm/guided_size string max

# You can choose one of the three predefined partitioning recipes:
# - atomic: all files in one partition
# - home:   separate /home partition
# - multi:  separate /home, /var, and /tmp partitions
d-i partman-auto/choose_recipe select atomic

# This makes partman automatically partition without confirmation, provided
# that you told it what to do using one of the methods above.
d-i partman-partitioning/confirm_write_new_label boolean true
d-i partman/choose_partition select finish
d-i partman/confirm boolean true
d-i partman/confirm_nooverwrite boolean true

Qual é a configuração do partman necessária para fazer isso funcionar?

No Cubic, como alguém pode personalizar um Xubuntu 22.04 Live USB/iso para ter um usuário padrão? O objetivo final é:

• Não solicitar nome de usuário/senha durante a instalação, em vez disso, apenas use o padrão que forneço.
• Definir o usuário para fazer login automaticamente
• Não me importo se o usuário "ao vivo" ainda for ubuntu, mas o nome de usuário principal instalado deve ser aquele que defini.

Eu preferiria uma solução que pudesse fazer no chroot (já que tenho um script que faz várias outras personalizações automaticamente).

Meu AHA-2940 aparece via, lspcimas nenhuma das unidades conectadas aparece no formato lsblk. O que preciso fazer para que meu sistema reconheça essas unidades?

Estou tentando sandbox todos os meus aplicativos por padrão usando firejail. O Firejail não oferece suporte a aplicativos de snap.

Parece que, por padrão, se solicitado por um snap, o snapd concederá ao snap acesso de leitura/gravação ao diretório inicial do usuário. Isso significa que, por padrão, se houver uma vulnerabilidade explorada em um aplicativo snap "sandboxed" com acesso à rede, seria trivial para um invasor pegar todos os arquivos em $HOME, incluindo chaves GPG, chaves SSH e, é claro, os arquivos do usuário. documentos e outros arquivos.

Fazer algumas pesquisas on-line me levou a ser capaz de fazer um snap disconnect <snap>:<plug interface> <snap>:<slot interface>que, em teoria, bloquearia o acesso ao diretório inicial. Infelizmente, esta é uma abordagem 'tudo ou nada' (sem capacidade de definir quais pastas em home permitir/negar) e deve ser aplicada a cada snap individualmente após a instalação.

Existe uma maneira de aplicar uma política "sem acesso $ HOME" por padrão a todos os snaps? Em caso afirmativo, existe uma maneira de permitir o acesso a alguns diretórios em $HOME enquanto nega o acesso a outros? Meu entendimento é que o apparmor não pode ser usado para isso devido à maneira como os contêineres de encaixe são projetados.

Plano alternativo: Existe algum truque através do qual eu poderia remontar uma parte da página inicial (digamos /home/folderforsnaps) e enganar os snaps para pensar que é o diretório inicial?

Estou arrancando os cabelos tentando resolver esse problema de permissões em que os arquivos criados pelo convidado não podem ser acessados ​​no host.

Configurar:

Eu tenho um host Ubuntu 20.04 e um convidado Ubuntu 20.04 rodando através do KVM. Eu tenho uma configuração de montagem compartilhada no modo mapeado . O diretório do host pode ser /home/user/VMs/shared/syncthing/acessado por meio do guest vm em /hostmount. Estou montando de dentro do convidado com sudo mount -t 9p -o trans=virtio,version=9p2000.L /hostmount /hostmount. A VM convidada é iniciada usando virt-manager na conta normal user.

Status atual:

• O host pode criar arquivos no compartilhamento que podem ser lidos e modificados pelo convidado.
• O convidado pode criar arquivos no compartilhamento, mas eles não podem ser lidos ou modificados pelo usuário do host.

Se eu for touch /hostmount/test.filede dentro do convidado como usuário regular user, no lado do host, vejo as seguintes permissões para ls –l test.file:

-rw------- 1 libvirt-qemu kvm 0 Feb 4 02:51 /home/user/VMs/shared/syncthing/test.file

Situação Desejada:

Claro, eu poderia chowno arquivo após a criação, mas como faço:

• Forçar a VM convidada a criar arquivos como userno host
• Conceda userno host acesso a arquivos criados por guest vm ( libvirt-qemuno host)

Eu tentei as sugestões desta resposta . Eles funcionam em arquivos pré-existentes, mas não funcionam quando o convidado cria novos arquivos.

Eu tenho uma máquina Ubuntu 14.04 que é usada para criar imagens e limpar discos rígidos, principalmente conectados por meio de docas USB 3.0. Eu encontro um problema em que, depois que um certo número de discos rígidos é inserido e removido, ele não detecta mais novos discos rígidos. Desconectar e reconectar as docas não corrige o problema, mas reiniciar a máquina sim. Eu acho que isso ocorre porque alguns dos discos rígidos estão com defeito, então talvez as gravações estejam paradas em uma fila que nunca foi concluída porque as unidades foram removidas.

Qual é uma maneira segura de dizer ao Ubuntu para verificar novamente as unidades e redefinir essas filas sem causar problemas com os volumes montados existentes?

Estou com uma situação estranha na minha máquina. Eu tenho várias unidades USB 3.0 externas fazendo grandes quantidades de IO (cerca de 70-100 MBps cada, copiando imagens de disco ou usando ferramentas como dd), mas IO muito baixo na unidade SSD do meu sistema.

Posso executar uma operação de E/S alta em cada uma dessas unidades, mas quando estou usando mais de 3 unidades, meu sistema fica inutilmente lento, embora o uso de CPU, memória e E/S do sistema seja baixo. Posso fazer ioniceas operações, o que ajuda um pouco, mas ainda encontro o mesmo gargalo.

Onde pode estar esse gargalo?

Especificações:

Processador i7 12GB de memória,
drive de sistema interno é SSD
todos os externos são USB 3.0 5400-7200RPM,
Ubuntu 14.04 x64.

Quando o gargalo é atingido, o uso de RAM é <50% de swap com <1 GB usado, IO do sistema é exatamente o que é necessário para executar o Ubuntu sem executar nenhuma operação pesada lá, CPU é <30% de uso em todos os núcleos.