O tempo de inicialização na instalação recente é muito lento, talvez devido a um fstab incorreto? não sabe o que fazer a seguir

1

Acabei de fazer uma instalação básica do ubuntu - selecionei o LVM, mas, além disso, o padrão era todo o caminho.

Minha máquina está demorando muito para inicializar, eu não tenho experiência com linux e tenho pesquisado.

Olhando para dmesg :

[    8.846613] audit: type=1400 audit(1480970603.520:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="webbrowser-app//oxide_helper" pid=2030 comm="apparmor_parser"
[    8.849130] audit: type=1400 audit(1480970603.520:11): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/sbin/cups-browsed" pid=2043 comm="apparmor_parser"
[    9.069385] Adding 8081404k swap on /dev/mapper/ubuntu--vg-swap_1.  Priority:-1 extents:1 across:8081404k SSFS
[   66.019923] random: nonblocking pool is initialized
[   68.827796] ata7.00: exception Emask 0x0 SAct 0x70003fff SErr 0x0 action 0x6 frozen
[   68.827803] ata7.00: failed command: READ FPDMA QUEUED
[   68.827809] ata7.00: cmd 60/20:00:68:b5:a4/00:00:08:00:00/40 tag 0 ncq 16384 in
                        res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)

Estou achando que é um problema com o SSD de alguma forma, vi algumas pessoas dizendo que tiveram problemas com o conteúdo de fstab :

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/ubuntu--vg-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sdb1 during installation
UUID=877bdd16-7292-43df-b8d0-2c15b0fd29b3 /boot           ext2    defaults        0       2
/dev/mapper/ubuntu--vg-swap_1 none            swap    sw              0       0

que eles corrigiram depois de analisar a saída de blkid :

/dev/sda1: UUID="877bdd16-7292-43df-b8d0-2c15b0fd29b3" TYPE="ext2" PARTUUID="29128885-01"
/dev/sda5: UUID="btlIPb-5JH7-PKen-NJd0-1LS2-O2WG-VJGO0i" TYPE="LVM2_member" PARTUUID="29128885-05"
/dev/sdb1: UUID="061D-D50F" TYPE="vfat"
/dev/mapper/ubuntu--vg-root: UUID="6da0bd40-c7ba-429c-872c-65baf117612f" TYPE="ext4"
/dev/mapper/ubuntu--vg-swap_1: UUID="19dda764-b7ff-48b1-ad3f-0c938c886b95" TYPE="swap"

Mas eu não sei como deve ser?

No entanto, quando executo systemd-analyze blame , obtenho isso , o que me faz acha que é a placa gráfica?

      1min 254ms gpu-manager.service
  1min 209ms ModemManager.service
  1min 142ms plymouth-quit-wait.service
   1min 76ms polkitd.service
      1.299s dev-mapper-ubuntu\x2d\x2dvg\x2droot.device
       707ms lvm2-monitor.service
       335ms apparmor.service
       265ms plymouth-read-write.service
       193ms systemd-logind.service
       192ms lightdm.service

Qualquer ajuda muito apreciada!

Depois de reinstalar duas vezes, parece que sempre recebo o mesmo problema, mas a culpa é muito diferente, o que me faz ter mais certeza de que se relaciona com a unidade - talvez haja algo errado ou requer algumas configurações específicas. SSD?) .. arquivos como estão agora:

  • culpe 2
  • blkid 2
  • dmesg 2
  • fstab 2

ATUALIZAÇÃO: Resolvido? -

Baseado no comentário de @jsalatas desativado o NCQ modificando / etc / default / grub:

GRUB_CMDLINE_LINUX="" -> GRUB_CMDLINE_LINUX="libata.force=noncq"

Isso certamente parou os erros, e ele iniciou o sistema em cerca de 12 segundos. dmesg3 (não sei quais são os Avisos da ACPI)

Espero que isso não afete outras unidades de eixo que pretendo adicionar (o Pool do ZFS que eu possa alternar para o RAID 10).

UPDATE 2 (FYI):

Eu estava adicionando mais memória RAM e uma nova CPU e decidi reinstalar ao mesmo tempo ... depois dessa reinstalação eu não tive mais esse problema!

além do mais ram e da mudança de CPU eu também mudei a porta que o SSD estava conectado .. Eu não tenho certeza, mas pode ter sido do SATA 3 para o SATA 2 (eu não penso assim, mas é possível - Eu só sei que eu mudei para o cabeamento mais puro.

    
por gordatron 05.12.2016 / 22:29

1 resposta

1

De acordo com link se você estiver recebendo mensagens assim

ata2.00: failed command: READ FPDMA QUEUED

significa que você precisa desativar o NCQ (Native Command Queuing). De acordo com o artigo, você pode fazer isso com o seguinte comando

echo 1 > /sys/block/sdX/device/queue_depth

em que você precisa substituir sdX com sua unidade atual (por exemplo, sda).

Como @gordatron mencionou, se / sys / block / sdX / device / queue_depth estiver faltando, você pode tentar desativar o NCQ globalmente para todas as unidades adicionando a opção libata.force=noncq em GRUB_CMDLINE_LINUX :

GRUB_CMDLINE_LINUX="libata.force=noncq"
    
por jsalatas 06.12.2016 / 01:34