Como a onipresença pode ser forçada a não instalar o grub?

Minhas partições do disco rígido:

• esp -> sda1
• archlinux -> sda2
• swap -> sda3
• sda4 -> seria um lugar para o ubuntu

Vou instalar o ubuntu no sda4; Atualmente, meu processo de inicialização é controlado pelo systemd-boot, que é instalado no archlinux via software bootctl. Está tudo bem e eu gostaria de mantê-lo.

Ao instalar o Ubuntu, ele tentará instalar o grub no sda ou sdaX. Veja o menu suspenso nesta captura de tela:

Eu quero instalar o Ubuntu no sda4 sem lidar com o grub. Depois, apontarei para o arquivo vmlinuz do Ubuntu e o arquivo initrd criando um novo arquivo de entrada no archlinux no sistema de configuração systemd-boot.

sudo ubiquity -b

Acabou de instalar o 16.10 inicializando diretamente o ISO no sda com o loopmount do grub. Uma vez no instalador entrou no terminal e usou o comando acima. Algo mais instalar parecia normal. Não percebi até que eu tinha clicado, mas a caixa de combinação certa de onde instalar o grub estava ausente. E durante o processo de instalação, normalmente diz a instalação do grub, mas isso nunca foi mostrado.

Normalmente, uma instalação no sdb ou qualquer segunda instalação substitui minha pasta / EFI / ubuntu pela inicialização da minha instalação principal. Desta vez, consegui inicializar novamente na minha instalação principal

E a execução sudo update-grubainda encontrou a nova instalação, embora o grub "não esteja instalado". Também não notou grub.cfg em / boot / grub.

Não conheço um método para impedir a instalação do Grub. Mas você pode evitar ter /dev/sdae outras partições de sua unidade / dev / sda tocadas no Grub.

Insira um segundo USB no computador. Selecione-o como o dispositivo de inicialização durante a instalação. Agora instale o Ubuntu no seu / dev / sda4. O processo de instalação não tocará nos setores de inicialização do / dev / sda ou em qualquer outra partição, exceto no /dev/sda4.

Eu sei que no Linux Mint 18.3 Cinnamon, que é baseado no Ubuntu 16.04, o seguinte comando funciona:

ubiquity --no-bootloader

Aparentemente, esse é um apelido para a opção -be é conhecido por funcionar no Linux Mint 18.3 Cinnamon.

Não verifiquei se a --no-bootloadertag funciona ubiquityno vanilla Ubuntu 16.04 (e versões posteriores). Talvez alguém executando o Ubuntu 16.04 (ou qualquer versão) possa verificar e comentar aqui com o número da versão e se o comando ubiquity --no-bootloadercommand funciona? Se funcionar, após a autenticação usando o autenticador da GUI, o Ubiquity será carregado. Se não funcionar, após a autenticação usando o autenticador da GUI, você retornará ao terminal e uma mensagem de erro será impressa dizendo ubiquity: error: no such option: [...].

Captura de tela das opções de onipresença no Linux Mint 18.3 Cinnamon:

impressão de opções de onipresença do terminal no Linux Mint 18.3 Cinnamon

Veja também:

http://averagelinuxuser.com/install-linux-mint-without-a-bootloader/

Você não pode forçar a não instalação do carregador de inicialização, por padrão.

Embora o @oldfred tenha mencionado que existe uma -bopção para a onipresença, embora não seja documentada, isso não é óbvio e pode ser assustador para a maioria dos usuários finais usá-lo. Embora, opção semelhante já existia antes.

Costumava haver

No passado, o Ubuntu tinha uma opção avançada que permite ao usuário personalizar a instalação do gerenciador de inicialização. Entre as versões do Ubuntu LTS, a opção avançada foi vista pela última vez na versão Lucid Lynx (10.04). A opção foi removida desde então, por qualquer motivo que eu não acompanhei.

Captura de tela antiga como prova:

Instale na mesma partição

Em uma etapa específica, é possível selecionar apenas um dispositivo que não seja o dispositivo principal /dev/sdapara a instalação do carregador de inicialização. Por exemplo, o Ubuntu será instalado na /dev/sda4partição, portanto, o gerenciador de inicialização também deverá ser instalado /dev/sda4.

Ao fazer isso, o usuário terá:

• O novo carregador de inicialização /dev/sda4ficará oculto, a menos que a máquina seja inicializada com a opção de carregar em cadeia na partição para revelá-la

• O gerenciador de inicialização existente em /dev/sdamanipulará a detecção do sistema operacional recém-instalado em /dev/sda4, sem precisar confiar no novo gerenciador de inicialização

• o usuário precisará atualizar o carregador de inicialização a /dev/sdapartir do primeiro sistema operacional instalado, a fim de detectar sistemas instalados posteriormente em outras partições

A menos que haja algum motivo crítico para não lidar com o gerenciador de inicialização, não vejo nenhum efeito colateral de instalar os gerenciadores de inicialização subsequentes nas respectivas partições.

O primeiro gerenciador de inicialização gerencia tudo

Pessoalmente, tenho várias distribuições (principalmente sabores do Ubuntu e derivados similares) instaladas na mesma máquina, com o primeiro carregador de inicialização /dev/sdae outros carregadores de inicialização nas respectivas partições. A única ressalva é que o carregador de inicialização deve ser atualizado a partir do primeiro sistema operacional instalado.

Além da ressalva, com menos problemas, sempre se pode esquecer os novos gerenciadores de inicialização e deixar que o gerenciador de inicialização existente gerencie a detecção.

TL; DR Instale um novo carregador de inicialização na mesma partição em que o sistema será instalado; O novo carregador de inicialização está oculto do usuário, a menos que seja carregado em cadeia para essa partição.

Relacionado : Eu escrevi essa resposta mais antiga que explica uma configuração de inicialização dupla, mencionando os-probere solução alternativa ao carregar em cadeia a partição.