1 HD 1 SSD, depois de instalar o Ubuntu em / sdb O Linux Mint em / sda1 não está no UEFI / Bios embora sda2 e sda3 sejam? isso é recuperável se assim como?

0

Parece-me instalar o Ubuntu em sdb após a primeira instalação do Linux Mint em sda não deveria ter efeito sobre ele, estou desapontado com o tempo gasto configurando o Linux mint, acho que posso reinstalar, mas não quero agora bagunça o Ubuntu em sdb , suspiro.

Na verdade, no BIOS / UEFI ele mostra 2 "Ubuntu" no SSD, e não mostra o HD, então é como se eu estivesse inicializando o SSD que tem / tinha o Linux mint, mas ele inicializa HD que tem "Ubuntu" ....

Reafirmando: nas Opções de Inicialização eu vejo apenas o SSD (/ sda) "SATA3_1" (vejo SATA3_1: SanDisk SDS; ubuntu (SATA3_1: Sandisk SDS) e outro duplicado da última opção, nada para o HD onde eu Ubuntu instalado (embora ele inicializa para o HD), como se o Ubuntu instalar em / sdb, escreveu o MBR para / sda é possível?

Editar 1:

hmm, agora vejo isso: Como fazer o boot do Ubuntu e Linux Mint update-grub no Ubuntu não consertou nada, então acho que vou tentar o reparo da inicialização, suspiro

Editar 2:

Bem, essa postagem é de cerca de 2011, com inicialização USB e reparo de inicialização executada, 1 clique não corrige e o link pastebin é genérico, nada é enviado, mais, vejo uma opção para "colocar o sinalizador de inicialização em sda1 sda2 etc
no entanto, temo usá-lo, pois não quero consertar o Linux Mint apenas para quebrar o Ubuntu ...

Editar 3

fdisk -l 
Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt

Device       Start       End   Sectors   Size Type
/dev/sda1     2048   1050623   1048576   512M EFI System
/dev/sda2  1050624   2050047    999424   488M Linux filesystem
/dev/sda3  2050048 234440703 232390656 110.8G Linux filesystem


Disk /dev/sdb: 298.1 GiB, 320072933376 bytes, 625142448 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt


Device       Start       End   Sectors   Size Type
/dev/sdb1     2048   1050623   1048576   512M EFI System
/dev/sdb2  1050624   2050047    999424   488M Linux filesystem
/dev/sdb3  2050048 625141759 623091712 297.1G Linux filesystem 

boot-info (parcial)

============================= Resumo das informações da inicialização: ============== =================

= > Nenhum carregador de boot está instalado no MBR de / dev / sda.  = > Nenhum carregador de boot está instalado no MBR de / dev / sdb.  = > Nenhum carregador de boot conhecido está instalado no MBR de / dev / sdc.

sda1:

por F8wlWch1 06.05.2017 / 18:30

1 resposta

2

Primeiro, um comentário amplo: você está tentando aplicar o conhecimento de inicialização específico do BIOS a um computador baseado em EFI. Esta prática mais ou menos garante que você acabará cometendo erros, porque os processos de boot BIOS e EFI são muito diferentes. Em particular, você deve parar de pensar em "inicializar um disco" e pensar em termos de EFI - sob o EFI, o firmware inicializa um arquivo , que reside em um Partição do sistema EFI (ESP). Um único ESP pode conter carregadores de inicialização para vários sistemas operacionais.

Agora, seu problema específico é resultado de alguns fatores de interação:

  • Infelizmente, como o Mint é derivado do Ubuntu, mas os desenvolvedores do Mint não acharam adequado diferenciar sua versão do GRUB (o gerenciador de inicialização do Ubuntu / Mint), os carregadores de boot das duas distribuições tentam viver no mesmo lugar. Assim, qualquer um que tenha sido instalado mais recentemente assumirá o controle do processo de inicialização.
  • Embora cada um dos seus discos tenha seu próprio ESP, o instalador do Ubuntu (e, portanto, do Mint) tem um bug que o faz usar o primeiro ESP encontrado, mesmo que não esteja no disco principal da distribuição ou se você tentar forçá-lo a usar outra coisa. Por favor, clique no link para o bug. Se você tiver uma conta do Launchpad, pode clicar no link para dizer que isso afeta você, o que aumentará o "aquecimento" do bug e aumentará a probabilidade de ele ser corrigido.

Como resultado de tudo isso, você tem um GRUB instalado (em /dev/sda1 ), e é atualmente controlado através do Mint - mas se e quando um A atualização do GRUB vem através do Ubuntu, o controle provavelmente mudará para o Ubuntu. (Isso é o que eu chamo de "golpe de inicialização" - veja minha página sobre este assunto - mas com o acrescentou que ambas as distribuições estão tentando escrever os mesmos arquivos.) Se você atualizar o GRUB do Mint, o controle retornará ao Mint.

Você pode separar, pelo menos parcialmente, os carregadores de boot de dois sistemas operacionais:

  1. Em Mint, edite /etc/fstab para que monte o ESP de /dev/sdb em vez do ESP de /dev/sda para /boot/efi .
  2. Em Mint, desmonte o ESP ( sudo umount /boot/efi ).
  3. Em Mint, monte o ESP recém-ajustado ( sudo mount -a ) e verifique com df para ter certeza de que a partição correta está montada.
  4. No Mint, reinstale o GRUB no ESP ( sudo grub-install , provavelmente seguido por sudo update-grub ).
  5. Se você quiser que o Ubuntu controle o processo de inicialização, reinicialize no Ubuntu e digite sudo grub-install (e talvez sudo update-grub ) para obter controle. (Como alternativa, você pode digitar sudo efibootmgr -v para ver as opções atuais do carregador de inicialização e ajustar a ordem de inicialização com sudo efibootmgr -o #[,#,#...] , mas precisará descobrir os números ( # ) do pedido com base no efibootmgr -v output.Isso exigirá a identificação de discos pelos valores GUID da partição.)
  6. Lembre-se de que os golpes de inicialização provavelmente acontecerão no futuro.

IMHO, no entanto, o GRUB é apenas adequado às suas necessidades. O problema é que a operação de tempo de inicialização do GRUB é muito dependente das configurações pré-configuradas. Ou seja, o menu GRUB é construído pelo script update-grub . Este script é executado após as atualizações do GRUB e do kernel, mas se você atualizar o kernel no sistema operacional que não controla o GRUB, essas atualizações não aparecerão no menu GRUB até que você execute manualmente update-grub no sistema operacional que controla o GRUB ou até você atualizar um kernel ou GRUB nesse sistema operacional. Há também a questão dos golpes de inicialização, que podem ser controlados (veja minha página sobre o assunto), mas é fácil ficar confuso sobre o que está no controle, porque as versões Ubuntu e Mint do GRUB são praticamente idênticas.

Você pode querer olhar para o meu gerenciador de inicialização do rEFInd como uma alternativa. Ao contrário do GRUB, o rEFInd procura por carregadores de inicialização e kernels em cada inicialização, para que ele recupere seus kernels depois que eles forem atualizados, independentemente da distribuição usada para instalar o rEFInd. Você ainda teria potencial para golpes de boot, mas pelo menos se acontecer, seria óbvio. Além disso, você provavelmente precisaria fazer alguma reconfiguração, incluindo a execução de mkrlconf na distribuição que você fez para não instalar o rEFInd e talvez editar /boot/efi/EFI/refind/refind.conf para ajustar algumas configurações e ocultar o (provavelmente agora indesejados) entradas do GRUB.

    
por Rod Smith 07.05.2017 / 21:37