nova instalação de 16.04 boots 3.13.0-96 apesar do fato de nem estar presente em nenhum sistema de arquivos montado

Question

Uma nova instalação de 16.04 do mini.iso. Após a instalação básica, usei o apt-get para instalar o xorg, o openbox, o thunar e assim por diante, definir alguns grupos e redefinir a fonte tty. Sem DM. Nenhum DE além do próprio Openbox. Estou usando o LILO porque os erros do prober do SO que afetam o grub2 eram um pesadelo em um sistema com muitos sistemas operacionais instalados, incluindo alguns em mídia externa que podem ou não estar presentes. Voltarei ao grub2 quando tiver pouco desespero suicida, então não vamos lá se pudermos evitá-lo. Eu vi discussões de problemas semelhantes com o grub2 também, mas nenhuma das soluções funcionou para mim. Este parece ser um exemplo de uma classe comum de problemas semelhantes com 16.04 especificamente. O LILO funciona bem para 3 instalações de variações de 14.04 e um Win something (7 eu acho - eu só inicializei uma vez ou 2), mas em uma nova instalação do 16.04 ele inicializa mostrando uma fonte agradavelmente grande e multicolorida em tty7 e trava após esta saída: "iniciou a atualização do UTMP sobre alterações no nível de execução do sistema" Às vezes, antes, às vezes depois disso, haverá a saída "[email protected]", onde N é um número inteiro de 1 a 6, inclusive. Não tenho certeza se N é consistente. Às vezes esta mensagem é repetida com outros valores de N, os outros inteiros de 1-6. Eu acho que é só se eu acessar esses ttys com cntrl-alt-FN. Talvez 16.04 esteja tentando iniciar uma sessão x mesmo que eu não tenha dito ainda e, por algum motivo, falhe nesta etapa. Isso seria focado em tty7, enquanto o que parece ser uma inicialização não gráfica normal está ocorrendo em tty1? De qualquer forma, depois disso, encontro em tty1, o que parece ser, até onde eu sei, o fim de um processo normal de inicialização não-gráfica, com um prompt de login. Eu consigo logar normalmente. O Startx funciona normalmente. Não a princípio, mas isso foi porque ~ / .Xauthority era de propriedade root: root, que fixei. Na verdade, tudo que eu verifiquei parece funcionar normalmente, exceto que é o kernel errado. Eu confirmei isso com os dois: uname -r & amp; cat / proc / version . O mais curioso é que o 3.13.0-96 não está presente em nenhum lugar que eu espere que este sytem possa acessar. Mount mostra apenas a partição / montada. Fstab apenas diz para montar aquela partição. Eu não estou usando uma troca ou uma partição de inicialização. / boot contém apenas os kernels da série 4 que você esperaria. Então, a menos que esteja escondido em outro lugar no sistema de arquivos, ele deve estar montando uma das outras partições por tempo suficiente para pelo menos ler o kernel 3.13.0-96, mas o mount não mostra isso. Em um ponto eu pensei que isso era porque eu tinha alguns sistemas usando uma partição de inicialização comum e outros usando um diretório de boot e que isso estava confundindo o LILO, significando especificamente o comando lilo, que lê o /etc/lilo.conf, e aparentemente resolve os links simbólicos como vmlinuz nos diretórios raiz dos sistemas de arquivos e armazena qualquer que seja o alvo deles em algum lugar. Eu suponho que porque eu tenho entradas apontando para os links simbólicos, além de alguns apontando para kernels específicos e aqueles que apontam para os links simbólicos não funcionam depois de uma atualização do kernel até eu executar o lilo, e então eles funcionam. De qualquer forma, eu mudei isso, mudei todos os fstabs, copiei as coisas na partição de inicialização para os diretórios de inicialização nos sistemas que precisavam, deletei a partição de inicialização, executei lilo e tudo funciona bem nos 3 14.04s mas ainda assim o 16.04 inicializa o kernel 14.04.

Esta é a última vez que eu instalei o 16.04. Se ninguém tiver a solução para isso, posso tentar mais uma vez e verificar detalhadamente como se comporta antes de instalar qualquer coisa. Mas estou prestes a desistir disso. Obrigado pela leitura. Qualquer idéia seria apreciada. Até mesmo as que estão meio cozidas, porque passei por todas as minhas idéias razoáveis e mal-assadas e estou trabalhando em coisas cruas. < |; -)

= = = = = = =

Atualização:

Em alguns lugares como esse, as pessoas atribuem grande importância a "pontos" ou algo assim, e responder à sua própria pergunta é considerado trapaça ou rude. Então, eu não estou fazendo isso. Qual é o costume aqui? De qualquer forma, resolvi isso. Então, muitas vezes, articular um problema esclarece seu pensamento sobre ele, e acho que foi o que aconteceu. Então, devo contar para o benefício de pessoas que encontram isso em um mecanismo de pesquisa? Ou deixar para alguém marcar pontos com? Ou espere 24 horas ou algo assim?

    

Answer 1

O problema é que eu entendi mal a sintaxe do lilo.conf. Os caminhos especificados em cada sub-rotina NÃO são relativos à raiz do sistema de arquivos dado como root. Eles são relativos à raiz do sistema de arquivos que contém a instalação com o lilo.conf efetivo. Qualquer sistema operacional é "responsável" do lilo em outras palavras.

Especificamente, eles são os caminhos em vigor NO MOMENTO o comando "lilo" é executado, independentemente de o ponto de montagem ser algo em fstab ou algo arbitrário e temporário. Portanto, por exemplo, se você montar a raiz de outro sistema como "/ mnt / othersys" e, em seguida, executar o comando "sudo lilo", os caminhos da sub-rotina para o outro sys precisarão começar com "/ mnt / othersys /". Se a próxima vez que você atualizar um kernel, você montar de forma diferente, por exemplo, como "/ mnt / ubuntu1604", e você não conseguir alterar o lilo.conf para refletir isso, ele não funcionará. Se os caminhos acontecem, como no meu caso, apontar para algum lugar que existe um arquivo que corresponde ao nome do kernel (como em maiúsculas, eu os estava apontando de volta para a raiz do sistema de arquivos que contém o sistema operacional em que eu eles eram relativos à raiz especificada, e executando o "sudo lilo", com os alvos sendo os links simbólicos em /) ele APARECERÁ para ter sucesso, mas a informação de inicialização armazenada será apontada para o kernel e imagem errados.

Tudo isso porque o comando "lilo" encontra a localização física (ou o que é transmitido em uma unidade moderna que se recusa a disponibilizar o sistema operacional para seu funcionamento interno) dos arquivos de imagem e kernel especificados em termos de sistema de arquivos montado no momento em que o comando foi executado e armazena os locais FÍSICOS (novamente, não realmente, mas de qualquer forma em termos apenas os mecanismos internos do HD podem traduzir), não os locais de caminhos / nomes de arquivos. Então, na verdade, o lilo.conf, até onde eu posso ver, não faz nada entre as execuções do comando lilo. As informações necessárias na inicialização são armazenadas em outro local. O Lilo.conf é apenas um guia para o lilo na geração dessa informação.