Ubuntu 12.04 LTS: Configurando Pentaho na inicialização

Posted on março 27, 2013. Filed under: Linux, Pentaho, Ubuntu | Tags:, , , , |

Introdução

O objetivo deste artigo é disponibilizar scripts de inicialização para os serviços do Pentaho BI Server e Pentaho Administration Console. Os scripts foram feitos para uso no Ubuntu Server 12.04 LTS.

Instalação do Pentaho

Recomendo o link abaixo para instalação do Pentaho BI Server no Ubuntu 12.04 LTS. Apesar do link estar se referindo ao Ubuntu Desktop, realizei a instalação normalmente em um Ubuntu Server.

http://akbarahmed.com/2012/05/24/install-pentaho-bi-server-4-5-on-ubuntu-12-04-lts-desktop/

Script init para o Pentaho BI Server

Criar o script de init abaixo em /etc/init.d/pentaho:
(PS: Configurar as variáveis de ambiente JAVA_HOME, JRE_HOME e PENTAHO_HOME de acordo com sua instalação)

#!/bin/bash
### BEGIN INIT INFO
# Provides: start-pentaho stop-pentaho
# Required-Start: networking
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Description: Pentaho BI Platform
### END INIT INFO

export JAVA_HOME="/usr/lib/jvm/jdk1.6.0_31"
export JRE_HOME="/usr/lib/jvm/jdk1.6.0_31/jre"
export PENTAHO_HOME="/opt/pentaho"

start(){
        echo "Iniciando aplicacao biserver"
        $PENTAHO_HOME/biserver-ce/start-pentaho.sh > /tmp/pentaho.out 2>&1
        echo "ok"
}

stop(){
        echo "recebi: $1"
        echo "Finalizando aplicacao biserver"
        $PENTAHO_HOME/biserver-ce/stop-pentaho.sh
        echo "ok"
}

case "$1" in
start)
        start $2
        ;;
stop)
        stop $2
        ;;
*)
        printf "\nUsage: $0 \n
                start | stop            : Inicia ou finaliza a aplicacao biserver\n"
        ;;
esac
exit 0

Instalando os links de init:

# update-rc.d pentaho defaults
 Adding system startup for /etc/init.d/pentaho ...
   /etc/rc0.d/K20pentaho -> ../init.d/pentaho
   /etc/rc1.d/K20pentaho -> ../init.d/pentaho
   /etc/rc6.d/K20pentaho -> ../init.d/pentaho
   /etc/rc2.d/S20pentaho -> ../init.d/pentaho
   /etc/rc3.d/S20pentaho -> ../init.d/pentaho
   /etc/rc4.d/S20pentaho -> ../init.d/pentaho
   /etc/rc5.d/S20pentaho -> ../init.d/pentaho

Script init para o Pentaho Administration Console

Criar o script de init abaixo em /etc/init.d/pentaho-adm:
(PS: Configurar as variáveis de ambiente JAVA_HOME, JRE_HOME e PENTAHO_HOME de acordo com sua instalação)

#!/bin/bash
### BEGIN INIT INFO
# Provides: start-pentaho-adm stop-pentaho-adm
# Required-Start: networking
# Required-Stop:
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Description: Pentaho BI Platform Administration Console
### END INIT INFO


export JAVA_HOME="/usr/lib/jvm/jdk1.6.0_31"
export JRE_HOME="/usr/lib/jvm/jdk1.6.0_31/jre"

export PENTAHO_HOME="/opt/pentaho"

start(){
        echo "Iniciando aplicacao administration-console"
        cd $PENTAHO_HOME/administration-console && ./start-pac.sh > /tmp/pentaho_console.out 2>&1 &
        echo "ok"
}

stop(){
        echo "recebi: $1"
        echo "Finalizando aplicacao administration-console"
        cd $PENTAHO_HOME/administration-console && ./stop-pac.sh
        echo "ok"
}

case "$1" in
start)
        start $2
        ;;
stop)
        stop $2
        ;;
*)
        printf "\nUsage: $0 \n
                start | stop : Inicia ou finaliza o administration console\n\n"
        ;;
esac
exit 0

Instalando os links de init:

# update-rc.d pentaho-adm defaults
 Adding system startup for /etc/init.d/pentaho-adm ...
   /etc/rc0.d/K20pentaho-adm -> ../init.d/pentaho-adm
   /etc/rc1.d/K20pentaho-adm -> ../init.d/pentaho-adm
   /etc/rc6.d/K20pentaho-adm -> ../init.d/pentaho-adm
   /etc/rc2.d/S20pentaho-adm -> ../init.d/pentaho-adm
   /etc/rc3.d/S20pentaho-adm -> ../init.d/pentaho-adm
   /etc/rc4.d/S20pentaho-adm -> ../init.d/pentaho-adm
   /etc/rc5.d/S20pentaho-adm -> ../init.d/pentaho-adm
Ler Post Completo | Make a Comment ( None so far )

Dicas do comando find

Posted on setembro 3, 2012. Filed under: Linux, Tips | Tags:, |

Introdução

Neste artigo vamos informar alguns exemplos práticos do comando find. São exemplos que resolvem problemas que temos no dia a dia. Voltado para quem trabalha com administração de servidores Linux.

  • Encontrando arquivos que estão com problema de encoding no nome.
  • find . ! -regex '.*'

    Esse interessante comando do find, apesar de não ser específico para isso, irá listar todos arquivos que estão com erro de encoding no nome. Para mais informações como corrigir o encode do nome do arquivo, acesse:
    http://selectoid.wordpress.com/2009/07/23/a-commandline-preciousness-for-converting-filename-encoding-in-linux-convmv/

  • Removendo arquivos que foram criados/modificados a mais de x dias. No caso abaixo, serão removidos os arquivos modificados/criados à mais de 30 dias.
  • find . -type f -mtime +30 -exec rm -f {} \;
  • Procurando um pattern (require_once) dentro de arquivos que possuem a extensão .php, entrando nos níveis de diretório abaixo, de forma recursiva.
  • find . -name "*.php" -exec grep -Hi "require_once" {} \;
  • Esta dica é para você que precisa limpar um diretório que contém muitos arquivos. Usar somente o comando rm -f * no diretório irá gerar erro de lista de arquivos muito grande. A alternativa é usar o comando find combinado com o comando xargs, que irá limpar o diretório completo. O xargs irá passar os arquivos para o comando rm por partes.
  • find . -type f -print0 | xargs -0 rm
  • Procurando arquivos em apenas 2 níveis de sub-diretórios.
  • find . -maxdepth 2
  • Procurando arquivos/diretórios que possuem determinado dono de arquivo.
  • find . -user www-data
  • Procurando arquivos/diretórios que possuem determinado grupo de arquivo.
  • find . -group www-data
  • Procurando arquivos/diretórios que possuem determinado permissão.
  • find . -perm 644
  • Fazendo busca somente em diretórios.
  • find . -type d
  • Fazendo busca somente em arquivos.
  • find . -type f

Conclusão

É claro que esses exemplos não devem ser utilizados de forma rígida. O comando find é muito flexível, portanto fique livre para combinar seus parâmetros. As dicas acima podem ajudar em muitas situações diferentes.

Ler Post Completo | Make a Comment ( None so far )

Upgrade do Ubuntu Server para 12.04 LTS

Posted on julho 18, 2012. Filed under: Linux, Ubuntu | Tags:, , |

Introdução

Neste artigo vamos explicar o processo à ser realizado para fazer o upgrade no Ubuntu server, para à última versão, 12.04 LTS (Precise). Precisei fazer o upgrade do ubuntu server, da versão 10.10 (Maverick) para a útlima, 12.04 LTS (Precise). No caso, fiz o upgrade primeiramente para a versão 11.04 (Natty), depois para a versão 11.10 (Oneiric) e finalmente para 12.04. Pelo que andei pesquisando, pude observar que alguns textos dizem que é possível fazer o upgrade diretamente de qualquer versão para à última LTS. Porém não quis arriscar em servidores de produção. Portanto, fiz a atualização de forma gradual.

Além do processo de upgrade, procurei passar para vocês, como resolvi alguns erros que apareceram durante o procedimento. Vale salientar, que este artigo se refere somente à versão server do Ubuntu. A versão desktop pode ser feita através de um procedimento diferente.

Procedimento

  • Logar no Ubuntu server como root
  • update no apt-get
  • # apt-get update

  • Instalação/Atualização do update-manager-core
  • # apt-get install update-manager-core

  • Editar o arquivo /etc/update-manager/release-upgrades e alterar Prompt=lts para Prompt=normal:


    [DEFAULT]
    # Default prompting behavior, valid options:
    #
    # never - Never check for a new release.
    # normal - Check to see if a new release is available. If more than one new
    # release is found, the release upgrader will attempt to upgrade to
    # the release that immediately succeeds the currently-running
    # release.
    # lts - Check to see if a new LTS release is available. The upgrader
    # will attempt to upgrade to the first LTS release available after
    # the currently-running one. Note that this option should not be
    # used if the currently-running release is not itself an LTS
    # release, since in that case the upgrader won't be able to
    # determine if a newer release is available.
    Prompt=normal

  • Iniciar o processo de upgrade
  • # do-release-upgrade

    Observações:

    • Caso esteja atualizando via ssh, será alertado sobre o risco de ocorrer algum problema durante o upgrade e você perder a conexão. De qualquer forma, um ssh alternativo é aberto na porta 1022. Sempre que possível, executar o upgrade diretamente no terminal físico do servidor.
    • Durante o upgrade, você será alertado sobre alguns processos que precisam ser re-inciados devido à atualização de pacotes. Pode autorizar tranquilamente a re-inicializaçao desses processos.
    • Alguns pacotes, ao serem atualizados para novas versões (apache, php, samba, etc.), terão novos arquivos de configuração. O mecanismo de upgrade do Ubuntu irá perguntar o que deseja fazer com os novos arquivos. (Manter o atual, sobrescrever com o novo, fazer um diff, etc.) Eu aconselho a sempre instalar o arquivo de configuração da nova versão do pacote. E depois do upgrade ajustar os parâmetros de acordo com sua necessidade. Portanto, antes do upgrade, faça um backup dos seus principais arquivos de configuração. Exemplo: /etc/php5/apache/php.ini, /etc/apache2/apache2.conf, /etc/samba/smb.conf
    • Durante o upgrade, normalmente para a versão 11.10 (Oneiric), o grub acusa que precisa ser instalado novamente e te mostra as opções dos possíveis locais onde pode ser instalado. Aconselho a instalar no MBR do seu disco (ex: /dev/sda).
    • Durante o upgrade, passando pela versão 11.10 (Oneiric), existe um bug que faz o comando fuser usar 100% de CPU, fazendo fork de forma incontrolada. Percebi esse problema, pois o sistema acusa direto que não conseguia alocar memória. O fuser é disparado por um processo do php que roda no crontab. Antes de continuar com o upgrade para à versão 12.04, para não ter imprevistos, faça a devida mudança no arquivo /etc/cron.d/php5:

      Trocar a linha:
      09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) ! -execdir fuser -s {} 2>/dev/null \; -delete

      Para:
      09,39 * * * * root [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -depth -mindepth 1 -maxdepth 1 -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete

    • Em um dos servidores que fiz o upgrade, tive um problema no terminal físico dele. A tela ficava em preto e não conseguia visualizar nada nela. Fiz diversas mudanças em arquivos de configuração do grub e do console. As duas configurações abaixos resolveram o meu problema:

      No arquivo /etc/default/grub, trocar a linha:
      GRUB_CMDLINE_LINUX_DEFAULT="quiet"

      Para:
      GRUB_CMDLINE_LINUX_DEFAULT="quiet nomodeset"

      No arquivo /etc/default/console-setup, trocar a linha:
      FONTFACE="VGA"

      Para:
      FONTFACE="Fixed"

Ler Post Completo | Make a Comment ( 2 so far )

Alta disponibilidade no Linux com heartbeat

Posted on abril 17, 2012. Filed under: Linux | Tags:, , |

Introdução

Neste artigo vamos demonstrar como configurar o software heartbeat com a finalidade de criar um sistema de Alta disponibildade no Linux. Vamos usar dois servidores numa solução master/slave onde o heartbeat ficará monitorando a disponibilidade dos nós configurados. Este artigo, de certa forma, serve como um complemento para o artigo Replicação Master-Master no MySQL.

Cenário

Dois servidores:

servidor1 192.168.10.1
servidor2 192.168.10.2

Ip Vip: 192.168.10.10

Para exemplo deste artigo vamos usar como nome dos servidores: “servidor1” e “servidor2”. Os nomes devem corresponder aos nomes das próprias máquinas (hostname).

O IP Vip corresponde ao ip que será compartilhado entre os dois servidores. Através do IP vip na verdade estaremos acessando o servidor que estiver como master no momento do acesso. Esse comportamento será controlado pelo heartbeat.

Insira as linhas abaixo no arquivo /etc/hosts nos dois servidores:

192.168.10.1 servidor1
192.168.10.2 servidor2

Para configurar o heartbeat de forma eficaz, dedique uma interface de rede nos dois servidores que serão conectados diretamente através de um crossover. É através dessa interface que o heartbeat determinará a disponiblidade dos nós.

Instalando heartbeat

A instalação do heartbeat em sistemas baseados em debian é bem simples:

$ sudo apt-get install heartbeat

Configuração do hearbeat

1. Arquivo /etc/ha.d/ha.cf

O conteúdo deve ser idêntico nos dois servidores:

use_logd yes
keepalive 1
deadtime 10
warntime 5
initdead 120
bcast eth4
node servidor1
node servidor2
auto_failback off

Descrição dos parâmetros:

use_logd yes – habilita log do heartbeat.
keepalive 1 – tempo em segundos entre um “heartbeat” e outro.
deadtime 10 – Tempo que o heartbeat aguarda por uma resposta até determinar que o nó esta morto.
warntime 5 – Tempo que o hearbeat aguarda por uma resposta para disparar um aviso de atraso (late warning).
initdead 120 – Quando você reinicia todas as máquinas do cluster ao mesmo tempo, pode haver uma diferença de tempo entre as máquinas até que subam todos os serviços. Esse parâmetro cuida dessa situação. Esse tempo é contado somente quando o heartbeat inicia o seu serviço.
bcast eth4 – eth4 seria a interface usada pelo heartbeat para o envio de broadcast. É através dessa interface que o heartbeat ficará “pingando” os outros nós do cluster. Normalmente esta interface é cross. Pode ser que o valor desse parâmetro mude de servidor para servidor dependendo do nome da interface que foi usada no cross.
node – nomes dos servidores presentes no cluster.
auto_failback off – Com o auto_failback on, quando ocorre uma queda no primeiro nó (master neste momento), o segundo nó assume como master. Quando o primeiro nó voltar da queda, o segundo nó passa o master para o nó 1 novamente. Com a opção off, o primeiro nó ao voltar da queda sobe como slave.

2. Arquivo /etc/ha.d/authkeys

Este arquivo deve ser idêntico para todos os servidores no cluster. Ele controla a autenticação do heartbeat. O dono do arquivo deve ser o root com a permissão 600. No exemplo abaixo, “qualquertexto” pode ser qualquer string da sua escolha, com tanto que esteja idêntica em todos servidores. Além do sha1, outros tipos de autenticação podem ser md5 e crc.

auth 1
1 sha1 qualquertexto

3. Arquivo /etc/ha.d/haresources

servidor1 192.168.10.10 apache2

Este arquivo também deve ser idêntico em todos os servidores do cluster. O primeiro parâmetro é o hostname do nó que você considera como master primário. Ao subir o heartbeat na primeira vez, esse será o nó que assumirá como master.

O segundo parâmetro é o ip vip do cluster, ou o ip “compartilhado” que estará sempre ativo independente do nó que estiver como master. Esse é o ip que você passará para outros servidores/serviços que irão acessar o “cluster”.

O terceiro e consequentes parâmetros são os nomes dos serviços que o heartbeat irá controlar. No caso apache2, como mostra o exemplo abaixo, estará ligado somente no nó master. Nos outros nós estarão desligados. Neste caso, quem controla o start/stop do serviço não será mais o linux através do rc.d e sim o heartbeat. Portanto, todos os serviços configurados no heartbeat devem ser eliminados da inicialização do Linux (rc.d).

PS: O script start/stop do serviço continua no init.d, deve ser removido somente da inicialização (rc.d).
Exemplo:

# update-rc.d -f apache2 remove

Você pode adicinar quantos serviços forem necessários para o devido funcionamento do cluster. Uma exemplo de serviço, seria um script que fica sincronizando arquivos de configuração entre os nós do cluster através de rsync. Quando você muda a configuração em um nó ele automaticamente replica para o outro nó. Exemplo:

servidor1 192.168.10.10 apache2 synconfig

No caso você deve criar um serviço chamado synconfig em /etc/init.d ! Ele irá chamar um daemon que fica sincronizando arquivos através de rsync. O serviço deve receber pelo menos os parâmetros start e stop.

Espero ter ajudado com essa contribuição. Fiquem livres para comentários e boa sorte.

Ler Post Completo | Make a Comment ( 3 so far )

Replicação Master-Master no MySQL

Posted on março 23, 2012. Filed under: Linux, MySQL | Tags:, , , |

Introdução

Neste artigo vamos demonstrar como configurar replicação Master-Master entre dois servidores MySQL. Este tipo de replicação normalmente é usado em um sistema de failover/cluster.

Preparando

O primeiro passo é sincronizar os bancos de dados, utilizados na replicação, entre os dois servidores do MySQL. Podemos usar o mysqldump nesta tarefa.

No servidor A:
# mysqldump -u root -p --databases base1 base2 > servidorA-dump.sql

No servidor B:
# mysql -u root -p < servidorA-dump.sql

Vamos assumir os seguintes endereços IPs para os servidores:

Servidor A: 192.168.0.1
Servidor B: 192.168.0.2

Configurando Permissões de Usuário

O processo de replicação do MySQL exige uma conexão ativa entre os dois servidores em ambos os lados. É preciso definir um usuário/senha para essa conexão.

No servidor A:
GRANT ALL PRIVILEGES ON *.* TO replicacao@192.168.0.2 IDENTIFIED BY 'repl123' WITH GRANT OPTION;

No servidor B:
GRANT ALL PRIVILEGES ON *.* TO replicacao@192.168.0.1 IDENTIFIED BY 'repl123' WITH GRANT OPTION;

Perceba que setamos os pervilégios do usuário replicacao para todos os bancos de dados no MySQL. Porém você pode definir somente as bases que serão incluídas na replicação ao invés de incluir todas bases.

Configurando o MySQL

As configurações abaixo devem ser incluídas na seção [mysqld] do my.cnf

Servidor A:

server-id = 1
auto-increment-increment = 2
auto-increment-offset = 1

log-bin
binlog-do-db = base1

master-host = 192.168.0.2
master-user = replicacao
master-password = repl123
master-port = 3306
master-connect-retry = 60

Servidor B:

server-id = 2
auto-increment-increment = 2
auto-increment-offset = 2

log-bin
binlog-do-db = base1

master-host = 192.168.0.1
master-user = replicacao
master-password = repl123
master-port = 3306
master-connect-retry = 60

A definição dos parâmetros auto-increment-increment e auto-increment-offset evitam colisão entre campos auto_increment. Mantenha o mesmo valor no campo auto-increment-increment para os dois servidores. O campo auto-increment-offset mantenha sequencialmente entre os servidores. No caso, 1 e 2.

O campo server-id também deve ser único entre os dois servidores. No caso, 1 e 2.

No exemplo de configuração acima estamos replicando somente o banco chamado base1. Caso precise replicar mais de uma base de dados, você pode inserir quantas linhas do parâmetro binlog-do-db forem necessárias:

binlog-do-db = base1
binlog-do-db = base2
binlog-do-db = base3
...

Caso você não especifique nenhum parâmetro binlog-do-db, todas as base de dados serão replicadas. Você tem também a opção de especificar o parâmetro binlog-ignore-db para ignorar quais base de dados não serão replicadas. É o processo inverso ao do parâmetro binlog-do-db:

binlog-ignore-db = mysql
binlog-ignore-db = information_schema

Iniciando a replicação

Reinicie o MySQL nos dois serviores:
# /etc/init.d/mysql restart

Neste momento a replicação deve ter iniciado. Se por algum motivo não tiver sido iniciado (Verificar erro no arquivo de log do mysql). Entre nos dois servidores e execute o comando:

mysql> start slave

Testando

Entre no MySQL nos dois servidores e execute o comando:
mysql> show slave status\G

Verifique os parâmetros Slave_IO_Running e Slave_SQL_Running. Ambos devem estar com o valor “YES”. Caso não esteja, refaça o processo.

Outro teste importante, é fazer alterações na base de um servidor e verificar se a mudança foi replicada para o outro servidor e vice-cversa.

Conclusão

Configurar uma replicação master-master no mysql é relativamente simples conforme demonstrado neste artigo. Outros ambientes de replicação também não são complicados. Com poucos ajustes na configuração acima você consegue adicionar mais que 2 servidores na replicação de master para master. Espero que tenha ajudado. Obrigado.

Ler Post Completo | Make a Comment ( 13 so far )

Linux, Instalando um novo Kernel através de Livecd

Posted on março 16, 2012. Filed under: Linux, Tips | Tags:, , , , |

Introdução

Existem certas situações que precisamos atualizar o kernel do sistema devido à problemas no boot. No meu caso, após restaurar um sistema de uma máquina antiga para um servidor mais novo, através de uma imagem dd, tive problemas para bootar o sistema no novo servidor devido ao kernel do sistema antigo não identificar o novo hardware.

Para solucionar essa questão, tive que instalar um novo kernel do Linux no servidor novo. Para ajudar utilizei um Livecd do Ubuntu. Segue abaixo o procedimento que usei para instalar o novo kernel.

Procedimento

  • Bootar o Livecd do Ubuntu.
  • Instalação de um novo kernel no livecd.
  • $ sudo apt-get update
    $ sudo apt-get install linux-image

    Somente com o boot do livecd não temos todos os arquivos do kernel disponíveis em /boot. Para isso instalamos um novo kernel dentro do livecd. Após a instalação acima, o importante é verificar que o arquivo vmlinuz-<versao kernel> existe no diretório /boot e os módulos do kernel dentro de /lib/modules/<versao kernel>.

    Pode ser que ocorra um erro nesse processo de instalação do kernel no livecd. Ignore o erro e continue o processo, pois o que interessa são os arquivos vmlinuz e os módulos do kernel. (Mesmo com o erro eles são instalados corretamente).

  • Montando a partição de boot.
  • $ sudo mkdir /mnt/boot
    $ sudo mount /dev/sda1 /mnt/boot

    No caso acima o /dev/sda1 é a partição onde estão os arquivos de kernel do seu servidor e do gerenciador de boot do grub. É nesse diretório que vamos instalar o novo kernel.
    Lembre-se que o acesso às partições variam de acordo como esta instalado o seu Linux.

  • Montando a partição raiz.
  • $ sudo mkdir /mnt/raiz
    $ sudo mount /dev/sda2 /mnt/raiz

    No caso acima o /dev/sda2 é a partição root do seu sistema. Precisamos montar essa partição para copiar os módulos do novo kernel.
    Lembre-se que o acesso às partições variam de acordo como esta instalado o seu Linux.

  • Copiando os arquivos
  • $ sudo cp /boot/vmlinuz-<versao kernel> /mnt/boot/
    $ sudo cp /boot/System.map-<versao kernel> /mnt/boot/
    $ sudo cp -a /lib/modules/<novo versao kernel> /mnt/raiz/lib/modules/

    Copiando a imagem do kernel, o System.map e os módulos, respectivamente, para os diretórios do seu servidor Linux.

  • Criando o initrd
  • Temos que criar um novo initrd para o novo kernel. Vamos aproveitar o initrd do kernel atual do seu sistema Linux para criar o novo. O initrd vai ajudar o novo kernel montar corretmente a partição root do seu Linux.
    Perceba que removemos os módulos do kernel atual que esta no initrd antes de copiar os módulos do kernel novo.

    $ sudo mkdir ~/initrd
    $ cd ~/initrd
    $ sudo gzip -dc /mnt/boot/initrd.img-<versao kernel atual> | cpio -id
    $ sudo rm -rf lib/modules/<versao kernel atual>
    $ sudo cp -a /lib/modules/<novo versao kernel> lib/modules/
    $ find . | cpio --quiet --dereference -o -H newc | gzip -9 > /mnt/boot/initrd-<novo versao kernel>

  • Criando nova entrada no menu do grub
  • Para concluir nosso processo, vamos criar uma nova entrada no menu.lst do grub para que seja possível bootar o novo kernel. Edite o arquivo /mnt/boot/grub/menu.lst e inclua uma nova opção no menu:

    title Novo Kernel
    root (hd0,0)
    kernel /vmlinuz-<novo versao kernel> root=/dev/sda2 ro quiet
    initrd /initrd.img-<novo versao kernel>

  • Bootando o novo kernel
  • Pronto, você já esta pronto para testar o novo kernel e bootar corretamente o seu sistema Linux. Desmonte as partições e reinicie o sistema, dessa vez, boote sem o livecd. No menu do grub escolha a nova opção e boa sorte!

    $ sudo umount /mnt/boot/
    $ sudo umount /mnt/raiz/
    $ sudo shutdown -r now

  • Referências
  • http://askubuntu.com/questions/94156/installing-with-a-different-kernel
    http://www.indiangnu.org/2009/how-to-create-editextract-initrd-in-ubuntudebian-and-redhatfedora-linux/

Ler Post Completo | Make a Comment ( 2 so far )

Liked it here?
Why not try sites on the blogroll...