Kernel Omnislash (Unofficial) - Aprendendo a voar sem segredos!!!

[galactus]

Arkage e MSXManiac, vocês estão usando máquinas virtuais? Estão com os drivers da Nvidia instalados?

Eu já tive esses erros. Eu removo o pacote nvidia-common para não dar mais o erro da nvidia. E quando estou com o VirtualBox instalado, eu instalo o pacote DKMS. Com isso ele compila os módulos do VirtualBox para qualquer novo kernel instalado automaticamente! Também me evitando outro erro!

No mais ele sempre reclama disso:

Hmm. There is a symbolic link /lib/modules/2.6.34-omnislash1.4.4/build
 However, I can not read it: Arquivo ou diretório não encontrado
 Therefore, I am deleting /lib/modules/2.6.34-omnislash1.4.4/build

Mas instala!

[Arkage]

Boa tarde pessoal.
Seguinte... eu tentei remover o pacote nvidia-common como o galactus sugeriu e o erro permaneceu. Instalei o dkms e apareceu mais esse agora... heheheh

Explicando um pouco melhor o que ta acontecendo:
Como podem ver eu to tentando instalar direto do .deb lindo e maravilho já... dai ele faz todo o processo em 1 minuto mais ou menos (o.O)...
Não estou usando máquina virtual. Minha placa de video é uma Intel Mobile 915GM/GMS/910GML Express Graphics Controller (um note semi-velho de guerra).

Depois que terminar o processo ai de baixo, eu tento continuar com o tutorial do Hqx... mas não acho o initdr.img do omnislash.. só o vmlinuz.
Dai eu reboot o bichinho pra ver no que da... dai vem a mensagem na inicialização de KERNEL PANIC!!! uuhuuu! \o/
Acho que é isso...

Ah... Tentei me aventurar na compilação do kernel e incluindo os pacths, configs e arquivos mágicos do Omnislah... mas tive alguns erros... como por ex na hora do comando "cp /usr/src/linux-2.6.34.1/configx86 .config && make xconfig"...
Ele da uma mensagem educada (como todas as mensagens emocionais do linux) de que o não foi possível iniciar o servidor X... algo assim... não lembro bem pois eram 4 da madrugada.... hehehehe

Bem... é isso... continuo aguardando alguma luz!

Abraços!

//----//---- Saída do xterm ----//---//

root@campe-note:/home/campeao/Área de Trabalho/Omnislash/1.4.4# dpkg -i linux-headers-2.6.34-omnislash1.4.4_x86_i386.deb linux-image-2.6.34-omnislash1.4.4_x86_i386.deb
(Lendo banco de dados ... 155805 arquivos e diretórios atualmente instalados).
Preparando para substituir linux-headers-2.6.34-omnislash1.4.4 x86 (usando linux-headers-2.6.34-omnislash1.4.4_x86_i386.deb) ...
Desempacotando substituto linux-headers-2.6.34-omnislash1.4.4 ...
Preparando para substituir linux-image-2.6.34-omnislash1.4.4 x86 (usando linux-image-2.6.34-omnislash1.4.4_x86_i386.deb) ...
Examining /etc/kernel/preinst.d/
Done.
Desempacotando substituto linux-image-2.6.34-omnislash1.4.4 ...
Examining /etc/kernel/postrm.d .
Running postrm hook script /usr/sbin/update-grub.
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.34-omnislash1.4.4
Found linux image: /boot/vmlinuz-2.6.32-23-generic
Found initrd image: /boot/initrd.img-2.6.32-23-generic
Found linux image: /boot/vmlinuz-2.6.32-21-generic
Found initrd image: /boot/initrd.img-2.6.32-21-generic
Found memtest86+ image: /boot/memtest86+.bin
done
Configurando linux-headers-2.6.34-omnislash1.4.4 (x86) ...
Examining /etc/kernel/header_postinst.d.
run-parts: executing /etc/kernel/header_postinst.d/dkms 2.6.34-omnislash1.4.4 /boot/vmlinuz-2.6.34-omnislash1.4.4
run-parts: executing /etc/kernel/header_postinst.d/nvidia-common 2.6.34-omnislash1.4.4 /boot/vmlinuz-2.6.34-omnislash1.4.4

Configurando linux-image-2.6.34-omnislash1.4.4 (x86) ...

 Hmm. There is a symbolic link /lib/modules/2.6.34-omnislash1.4.4/build
 However, I can not read it: Arquivo ou diretório não encontrado
 Therefore, I am deleting /lib/modules/2.6.34-omnislash1.4.4/build


 Hmm. The package shipped with a symbolic link /lib/modules/2.6.34-omnislash1.4.4/source
 However, I can not read the target: Arquivo ou diretório não encontrado
 Therefore, I am deleting /lib/modules/2.6.34-omnislash1.4.4/source

Running depmod.
Examining /etc/kernel/postinst.d.
run-parts: executing /etc/kernel/postinst.d/dkms 2.6.34-omnislash1.4.4 /boot/vmlinuz-2.6.34-omnislash1.4.4
run-parts: executing /etc/kernel/postinst.d/nvidia-common 2.6.34-omnislash1.4.4 /boot/vmlinuz-2.6.34-omnislash1.4.4
run-parts: executing /etc/kernel/postinst.d/pm-utils 2.6.34-omnislash1.4.4 /boot/vmlinuz-2.6.34-omnislash1.4.4
Running postinst hook script update-grub.
Generating grub.cfg ...
Found linux image: /boot/vmlinuz-2.6.34-omnislash1.4.4
Found linux image: /boot/vmlinuz-2.6.32-23-generic
Found initrd image: /boot/initrd.img-2.6.32-23-generic
Found linux image: /boot/vmlinuz-2.6.32-21-generic
Found initrd image: /boot/initrd.img-2.6.32-21-generic
Found memtest86+ image: /boot/memtest86+.bin
done

root@campe-note:/home/campeao/Área de Trabalho/Omnislash/1.4.4#

[Hqxriven]

sudo mkinitramfs -o /boot/initrd.img-2.6.34-omnislash1.4.4 /lib/modules/2.6.34-omnislash1.4.4

depois

sudo update-grub

Vai criar o initrd e aí é só dar o boot... (faça esses comandos usando outro kernel)

[Arkage]

Poxa... era tão simples... :S
Isso que dar confiar no TAB... hehehehe
Obrigado pela ajuda! Agora ta tudo redondo! hehehe
Vou fazer uns teste e depois eu posto aqui!

Abraços!

[vampire_thunder]

Existe algum patch que transforma uma versão do Kernel em outra? Tipo da 2.6.33 para 2.6.34? Eu usava muito isso antigamente no Mame.

[MSXManiac]

sudo mkinitramfs -o /boot/initrd.img-2.6.34-omnislash1.4.4 /lib/modules/2.6.34-omnislash1.4.4

depois

sudo update-grub

Vai criar o initrd e aí é só dar o boot... (faça esses comandos usando outro kernel)

Eu sei meu caro
Alias o nvidia-common vc tem que comandar remoção completa, caso contrário ele sai da base do synaptic mas continua lá no diretório para ser executado, gerando o erro citado quanto ao nvidia-common
O problema meu caro reside na mensagem:

Configurando linux-image-2.6.34-omnislash1.4.4 (x86) ...

 Hmm. There is a symbolic link /lib/modules/2.6.34-omnislash1.4.4/build
 However, I can not read it: Arquivo ou diretório não encontrado
 Therefore, I am deleting /lib/modules/2.6.34-omnislash1.4.4/build


 Hmm. The package shipped with a symbolic link /lib/modules/2.6.34-omnislash1.4.4/source
 However, I can not read the target: Arquivo ou diretório não encontrado
 Therefore, I am deleting /lib/modules/2.6.34-omnislash1.4.4/source

Running depmod.

Ele não está relacionado ao nvidia-common até pq reinstalei os debs novamente tendo o cuidado de ter expurgado todas as instâncias do maledeto nvidia-common (fiz na unha e conferi um por um)! Essa mensagem permanece.
E ela ocorreu em todas as compilações que tenho tentado desde o 9.10 até agora, incluindo o recente uso dos debs fornecidos por vc! E nas  máquinas que instalei, todas tem chipset intel e nada de nvidia. Aliás o common é instalado por default independente da plataforma ou do chipset de cada mainboard!

Apesar de não parecer afetar nada, me deixa intrigado...
Ele parece ocorrer logo após os arquivos deb serem expandidos. Os diretórios relacionados são em algum ponto apagados pelo script de instalação não sei por qual motivo sendo depois marcado a falta deles e emitido o alerta! O que fica é o desafio de o porque isto ocorre, já que se vc visualizar o conteudo dos debs com o file-roller ou assemelhado, verá que os diretórios estão lá, com arquivos e o diabo a 4! Pq raios são apagados se depois são necessários para alguma coisa?

Já tinha conversado com vc sobre isso no começo do ano, mas com a internação e falecimento de meu pai e depois a minha internação consumiram aí uns preciosos 6 meses.
Não é coisa simples não e se me sobrar um tempinho vou fuçar algo. Mas tá difícil pq perdi um semestre inteiro da facult. Atestado te dá o direito de fazer as provas, mas não te dá nem o conhecimento e nem a prática das aulas perdidas!

Bom findi a todos!

[Hqxriven]

Configurando linux-image-2.6.34-omnislash1.4.4 (x86) ...

 Hmm. There is a symbolic link /lib/modules/2.6.34-omnislash1.4.4/build
 However, I can not read it: Arquivo ou diretório não encontrado
 Therefore, I am deleting /lib/modules/2.6.34-omnislash1.4.4/build


 Hmm. The package shipped with a symbolic link /lib/modules/2.6.34-omnislash1.4.4/source
 However, I can not read the target: Arquivo ou diretório não encontrado
 Therefore, I am deleting /lib/modules/2.6.34-omnislash1.4.4/source

Running depmod.

Essa mensagem é normal aparecer em kernels customizados. Tudo começou com as mudanças que ocorreram no kernel package e que caparam ele (inclusive separaram a funcionalidade que estava embutida do initrd que agora depende do usuário fazer manualmente - porém dá problemas no dkms)

Ela ocorre pq não há um compartilhamento de informações entre o image e o headers onde o image deveria perceber que o diretório /usr/src/linux-headers-2.6.34-omnislash1.4.4 existe após a instalação dos headers e por isso o link simbólico existe e não deve ser apagado.

Porém quando usamos o comando:

sudo mkinitramfs -o /boot/initrd.img-2.6.34-omnislash1.4.4 /lib/modules/2.6.34-omnislash1.4.4

Recriamos o initrd manualmente e recriamos o lib/modules e link simbólico build volta a aparecer (sem ele não conseguiríamos compilar nada manualmente)!!

Se vc for na pasta lib/modules/2.6.34-omnislash1.4.4 vai ver o link simbólico build lá...

Quanto a mensagem

Hmm. The package shipped with a symbolic link /lib/modules/2.6.34-omnislash1.4.4/source
 However, I can not read the target: Arquivo ou diretório não encontrado
 Therefore, I am deleting /lib/modules/2.6.34-omnislash1.4.4/source

Ela só aparece em uma compilação manual ou na instalação dos debs quando existe um link simbólico em /usr/src apontando para um kernel ali ou quando vc cria além de um kernel source um image e o header.

Porém apenas com os headers vc já consegue compilar tudo.

Espero que tenha conseguido explicar e mostrado que é uma mensagem que vc pode ignorar. Fique tranquilo...

[vampire_thunder]

Hqx, esvazie sua caixa de mensagens, rsrsrsrs

De qualquer forma, a mensagem que tentei enviar foi a que fiz um post atrás:

Existe algum patch que transforma uma versão do Kernel em outra? Tipo da 2.6.33 para 2.6.34? Eu usava muito isso antigamente no Mame.

[Hqxriven]

Hqx, esvazie sua caixa de mensagens, rsrsrsrs

Eu esvazio hoje ela enche em dois dias aproximadamente... No outro fórum passou de 100 mps 

Voltando a pergunta.

Sim isso existe, ocorre somente quando é lançado um kernel que ainda é rc e por isso o seu patch é para a versão estável.

Isso só ocorre nesse momento.

[galactus]

Hq, viu a "listinha" de Bugs corrigidos com o ext4 no kernel padrão do Ubuntu com a mais nova atualização dele?

Código: [Selecionar]

  * ext4, jbd2: Add barriers for file systems with exernal journals
    - LP: #588069
  * ext4: Eliminate potential double free on error path
    - LP: #588069
  * ext4: return correct wbc.nr_to_write in ext4_da_writepages
    - LP: #588069
  * ext4: Ensure zeroout blocks have no dirty metadata
    - LP: #588069
  * ext4: Patch up how we claim metadata blocks for quota purposes
    - LP: #588069
  * ext4: Fix accounting of reserved metadata blocks
    - LP: #588069
  * ext4: Calculate metadata requirements more accurately
    - LP: #588069
  * ext4: Handle -EDQUOT error on write
    - LP: #588069
  * ext4: Fix quota accounting error with fallocate
    - LP: #588069
  * ext4: Drop EXT4_GET_BLOCKS_UPDATE_RESERVE_SPACE flag
    - LP: #588069
  * ext4: Use bitops to read/modify EXT4_I(inode)->i_state
    - LP: #588069
  * ext4: Fix BUG_ON at fs/buffer.c:652 in no journal mode
    - LP: #588069
  * ext4: Add flag to files with blocks intentionally past EOF
    - LP: #588069
  * ext4: Fix fencepost error in chosing choosing group vs file
    preallocation.
    - LP: #588069
  * ext4: fix error handling in migrate
    - LP: #588069
  * ext4: explicitly remove inode from orphan list after failed direct io
    - LP: #588069
  * ext4: Handle non empty on-disk orphan link
    - LP: #588069
  * ext4: make "offset" consistent in ext4_check_dir_entry()
    - LP: #588069
  * ext4: Fix insertion point of extent in mext_insert_across_blocks()
    - LP: #588069
  * ext4: Fix the NULL reference in double_down_write_data_sem()
    - LP: #588069
  * ext4: Code cleanup for EXT4_IOC_MOVE_EXT ioctl
    - LP: #588069
  * ext4: Fix estimate of # of blocks needed to write indirect-mapped files
    - LP: #588069
  * ext4: Fixed inode allocator to correctly track a flex_bg's used_dirs
    - LP: #588069
  * ext4: Fix possible lost inode write in no journal mode
    - LP: #588069
  * ext4: Fix buffer head leaks after calls to ext4_get_inode_loc()
    - LP: #588069
  * ext4: Issue the discard operation *before* releasing the blocks to be
    reused
    - LP: #588069
  * ext4: check missed return value in ext4_sync_file()
    - LP: #588069
  * ext4: fix memory leaks in error path handling of ext4_ext_zeroout()
    - LP: #588069
  * ext4: Remove unnecessary call to ext4_get_group_desc() in mballoc
    - LP: #588069
  * ext4: rename ext4_mb_release_desc() to ext4_mb_unload_buddy()
    - LP: #588069
  * ext4: allow defrag (EXT4_IOC_MOVE_EXT) in 32bit compat mode
    - LP: #588069
  * ext4: fix quota accounting in case of fallocate
    - LP: #588069
  * ext4: check s_log_groups_per_flex in online resize code
    - LP: #588069
 [b] * ext4: don't return to userspace after freezing the fs with a mutex held
    - LP: #588069[/b]
  * ext4: stop issuing discards if not supported by device
    - LP: #588069
  * ext4: don't scan/accumulate more pages than mballoc will allocate
    - LP: #588069
  * ext4: Do not zero out uninitialized extents beyond i_size
    - LP: #588069
  * ext4: clean up inode bitmaps manipulation in ext4_free_inode
    - LP: #588069
  * ext4: init statistics after journal recovery
    - LP: #588069
  * ext4: Remove extraneous newlines in ext4_msg() calls
    - LP: #588069
  * ext4: Prevent creation of files larger than RLIMIT_FSIZE using
    fallocate
    - LP: #588069
  * ext4: check for a good block group before loading buddy pages
    - LP: #588069
  * ext4: Show journal_checksum option
    - LP: #588069
  * ext4: Use bitops to read/modify i_flags in struct ext4_inode_info
    - LP: #588069
  * ext4: Avoid crashing on NULL ptr dereference on a filesystem error
    - LP: #588069
  * ext4: Clear the EXT4_EOFBLOCKS_FL flag only when warranted
    - LP: #588069
  * ext4: restart ext4_ext_remove_space() after transaction restart
    - LP: #588069
  * ext4: Conditionally define compat ioctl numbers
    - LP: #588069
  * ext4: Fix compat EXT4_IOC_ADD_GROUP
    - LP: #588069
  * ext4: Make fsync sync new parent directories in no-journal mode
    - LP: #588069
Brincadeira hein!!! Depois o pessoal não sabe o motivo de perder dados e HD com ext4!  Acho que vou voltar para o ext3!

[Hqxriven]

Se eu te falar que o omnislash tem boa parte desses patches aí vc acredita...

Estão faltando (que eu me lembre):

ext4: Code cleanup for EXT4_IOC_MOVE_EXT ioctl

ext4: check s_log_groups_per_flex in online resize code

O ext4 está fogo, eu já sabia que faltava coisa pra caramba no kernel lucid...

Agora fiquei com vontade de fazer um omnislash novo e mais atualizado pq ainda estão faltando coisas ae

[MSXManiac]

Grato pela explicação...
Se eu entendi, o que importa é haver o link simbólico ok?
Mesmo que tenha a pasta sido deletada!
Especificamente neste caso não é?
Fiz uma compilação agora com o patch do Kolivas e ocorreu a mesma coisa!
Só não vale comparar pq eu botei o Hz em 10.000!
Vou remover o 1.4.4 e compilar ele também nos 10.000!
Agora cá entre nós, ou é só o Ubuntu ou o Gnome assim como o KDE tem engordado prá caramba! Ou todos né!

[Hqxriven]

Se eu entendi, o que importa é haver o link simbólico ok?
Mesmo que tenha a pasta sido deletada!
Especificamente neste caso não é?
Fiz uma compilação agora com o patch do Kolivas e ocorreu a mesma coisa!
Só não vale comparar pq eu botei o Hz em 10.000!
Vou remover o 1.4.4 e compilar ele também nos 10.000!
Agora cá entre nós, ou é só o Ubuntu ou o Gnome assim como o KDE tem engordado prá caramba! Ou todos né!

10.000 é pegar pesado!! Dá um desconto pro teu processador!! Ele vai ficar doido!!

O que importa é o link simbólico direcionado para o local certo (nesse caso os headers usr/src/linux-headers-2.6.34seukernel)

Gnome e o KDE estão pesadinhos mesmo... vou ver se consigo fazer novos ajustes pelo kernel...

Semana que vem acho que sai outro omnislash (duas semanas desmembrando o zen)

[MSXManiac]

10.000 é pegar pesado!! Dá um desconto pro teu processador!! Ele vai ficar doido!!

O que importa é o link simbólico direcionado para o local certo (nesse caso os headers usr/src/linux-headers-2.6.34seukernel)

Gnome e o KDE estão pesadinhos mesmo... vou ver se consigo fazer novos ajustes pelo kernel...

Semana que vem acho que sai outro omnislash (duas semanas desmembrando o zen)

É só para teste. O do Ubuntu esta aqui e é o que uso normalmente, principalmente quando o note está só na bateria!
Esqueci de te dizer que voltei à velha mania de botar a partição root como jfs e ele realmente é bem mais rápido que o ext4 e um pouco , bem pouco mais que o ext3. É a impressão que eu tenho né!

Quanto ao Gnome e ao KDE, assim como o Linux de um modo geral, o culpado invariavelmente é o GCC. Esse programadores de hoje são na maioria um bando de preguiçosos. Reescrevem a mesma rotina ou rotina com a mesma finalidade um monte de vezes. Sem falar que o compilador deveria se chamar engordador. Sinceramente o que precisamos é de uma linguagem tipo C mas que esteja tão próxima dos mnemônicos adotados no assembly e com recursos de varrer o fonte atrás de rotinas semelhantes ou com estrutura semelhante para realmente otimizar o código fonte.

Quem teve um MSX e se aventurou a desassemblar os joguinhos da Konami com certeza concordará comigo. Além de míseros 16 ou 32 Kb de RAM, eles criptografavam o texto na rotina além de reutilizá-las com diversos pontos de entrada/saída.

Abrax e boa semana à todos!

[dtomadon]

Tô pronto pra testar ,hehehehehe

Semana que vem acho que sai outro omnislash (duas semanas desmembrando o zen)