File System lost+found
Olá Pessoal, Na hora da instalação eu criei as partições. Porém após o término da instalação eu resolvi montar as partições do sistema. E agora fica me aparecendo o diretório lost+found ocupando 2% da File System. O que eu posso fazer pra não ser colocado pelo sistema esse lost+found, isso senão tiver problema o sistema ficar sem nessas partições que eu utilizo pra guardar aquivos ? Grato. = ] Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: File System lost+found
On Dec 20, 2007 10:56 AM, Ali3n [EMAIL PROTECTED] wrote: Na hora da instalação eu criei as partições. Porém após o término da instalação eu resolvi montar as partições do sistema. E agora fica me aparecendo o diretório lost+found ocupando 2% da File System. Esse diretório deveria ficar vazio, se está ocupando 2% da partição, deve haver algum problema. Existem arquivos nele? Se o Linux está criando arquivos nele, seria bom fazer um fsck e ver se há blocos danificados no disco. O que eu posso fazer pra não ser colocado pelo sistema esse lost+found, isso senão tiver problema o sistema ficar sem nessas partições que eu utilizo pra guardar aquivos ? Eu acho que você pode apagar o diretório sem problemas, mas ele será criado novamente assim que for necessário. -- Bruno Schneider http://www.dcc.ufla.br/~bruno/
Re: File System lost+found
Bruno Schneider wrote: On Dec 20, 2007 10:56 AM, Ali3n [EMAIL PROTECTED] wrote: Na hora da instalação eu criei as partições. Porém após o término da instalação eu resolvi montar as partições do sistema. E agora fica me aparecendo o diretório lost+found ocupando 2% da File System. Esse diretório deveria ficar vazio, se está ocupando 2% da partição, deve haver algum problema. Existem arquivos nele? Se o Linux está criando arquivos nele, seria bom fazer um fsck e ver se há blocos danificados no disco. O que eu posso fazer pra não ser colocado pelo sistema esse lost+found, isso senão tiver problema o sistema ficar sem nessas partições que eu utilizo pra guardar aquivos ? Eu acho que você pode apagar o diretório sem problemas, mas ele será criado novamente assim que for necessário. Quando você formata uma partição e cria um sistema de arquivo, por padrão ele reserva uma porcentagem da partição para o root. A pasta lost+found não está com estes 2% da partição. Para que você retire estes 2% do root digite o comando a seguir como root. tune2fs -m 0 /dev/[partição usada. Ex.: hda1,hda2...). Abraços -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: lost+found
Pessoal: valeram as dicas. Utilizei a sintaxe proposta e tudo ok. O mc (que eu não conhecia) também acabei instalando. sds. G.Paulo. On Thu, 18 Nov 2004 10:43:03 +0100 Nerling Marlon [EMAIL PROTECTED] wrote: -Original Nachricht- From: Marcos Lazarini [EMAIL PROTECTED] Date: Wed, 17 Nov 2004 19:55:47 +0100 To: debian-user-portuguese@lists.debian.org Subject: Re: lost+found Fred Ulisses Maranhao wrote: On Sun, 14 Nov 2004 15:51:31 -0200 G.Paulo [EMAIL PROTECTED] wrote: Pessoal: tenho uns arquivos no /lost+found que são originários de corrupção do filesystem já tem algum tempo. Ei-los: gert:/lost+found# ls -l total 0 srw-rw-rw-1 root root0 Ago 21 08:24 #30774 srwxrwx---1 root root0 Ago 21 08:24 #30780 Toda hora aparece um mail dizendo que estes arquivos foram encontrados (Anacron job 'cron.daily'). Mas eu não consigo visualizar o conteúdo dos arquivos nem apagá-los (veja que o nome não tem uma sintaxe convencional). Como apagar ou visualizar estes arquivos? talvez você tenha que proteger o # com uma \. senão o shell pode achar que é um caractere especial: rm /lost+found/\#30774 Boa dica Mais duas opcoes: rm -i /lost+found/* (interativo, deve pedir uma confirmação pra cada operacao - pra falar a verdade, eu nao confio muito nao; vai q ele apaga tudo? :-) ou rm /lost+found/#30774 (proteger atraves das o nome do arquivo) melhor ainda.. eu porem costumo usar o mc: #mc /lost+found e de la um F8 sobre o arquivo.. 'e pratico e rapido.. mas pra quem quer saber como as coisas realmente funcionam no Shell as duas dicas acima s~o muito quentes.. -- Marcos Lazarini -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
lost+found
Pessoal: tenho uns arquivos no /lost+found que são originários de corrupção do filesystem já tem algum tempo. Ei-los: gert:/lost+found# ls -l total 0 srw-rw-rw-1 root root0 Ago 21 08:24 #30774 srwxrwx---1 root root0 Ago 21 08:24 #30780 Toda hora aparece um mail dizendo que estes arquivos foram encontrados (Anacron job 'cron.daily'). Mas eu não consigo visualizar o conteúdo dos arquivos nem apagá-los (veja que o nome não tem uma sintaxe convencional). Como apagar ou visualizar estes arquivos? sds G.Paulo.
Re: lost+found
On Sun, 14 Nov 2004 15:51:31 -0200 G.Paulo [EMAIL PROTECTED] wrote: Pessoal: tenho uns arquivos no /lost+found que são originários de corrupção do filesystem já tem algum tempo. Ei-los: gert:/lost+found# ls -l total 0 srw-rw-rw-1 root root0 Ago 21 08:24 #30774 srwxrwx---1 root root0 Ago 21 08:24 #30780 Toda hora aparece um mail dizendo que estes arquivos foram encontrados (Anacron job 'cron.daily'). Mas eu não consigo visualizar o conteúdo dos arquivos nem apagá-los (veja que o nome não tem uma sintaxe convencional). Como apagar ou visualizar estes arquivos? talvez você tenha que proteger o # com uma \. senão o shell pode achar que é um caractere especial: rm /lost+found/\#30774 Paro por aqui, Fred
lost found
Bom dia Cara to atrás deste programa faz um bom tempoestorei a partição do meu hd de vaciloquero recuperar mais não encontro este programa se você poder me mandar ele fico muito agradecido... Valeu Aguardo retorno T
Re: integridade do sistema , como mantê-la? [explosão demográfic a em /lost+found]
On Tue, Jan 14, 2003 at 02:29:13PM -0200, [EMAIL PROTECTED] wrote: Olá pessoal. Olá, Se não for possível saber isto, há alguma ferramenta no sistema capaz de checar, pacote por pacote, a integridade da instalação (todos os arquivos do pacote estão onde devem estar)? talvez o md5sum dos pacotes possa ajudar: /# for FILE in `ls /var/lib/dpkg/info/*.md5sums` ; do md5sum -c $FILE ; done isto considerando que os seus arquivos md5sum dos pacotes instalados estão OK. acho que se não estiverem você pode baixá-los novamente. ETA, -- Mario O.de Menezes, Ph.D. Many are the plans in a man's heart, but IPEN-CNEN/SP is the Lord's purpose that prevails http://curiango.ipen.br/~mario Prov. 19.21
Re: integridade do sistema, como mantê-la? [explosão demográfica em /lost+found]
Otavio Salvador [EMAIL PROTECTED] writes: [EMAIL PROTECTED] writes: Preciso de ajuda. Por razões que ainda desconheço, meu computador tem corrompido o sistema de arquivos (ext3), de modo que um fsck povoa o /lost+found. Provavelmente trata-se de senilidade (não minha, espero, do disco rígido e/ou placa mãe :=)): um P100 do tempo que se dormia com a porta aberta :=). Os logs do sistema não acusam nada, isto me intriga. Se voce estah usando o kernel 2.4.20 volte para o 2.4.19 ou vah para o 2.4.21pre porque o 2.4.20 tem um bug no ext3 que causa danificacao neste sistema de arquivos. Bingo!!! Estou usando o 2.4.20. Vou pro 2.4.21pre, eu acho. Como ficar informado sobre os bugs? Algum serviço automático de informação? Ou devo ir pra kernel.org? A propósito, um bug de tal periculosidade ser publicado no kernel não é um mal sinal? Alguns testes básicos não teriam evitado este problema? Brigadão, Otávio. p.s.: porque não postaste na lista? esta mensagem pode ser útil a outros; estou replicando prá lá, ok? []s -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio -
Re: integridade do sistema, como mantê-la? [explosão demográfica em /lost+found]
Marcio Roberto Teixeira [EMAIL PROTECTED] writes: Se voce estah usando o kernel 2.4.20 volte para o 2.4.19 ou vah para o 2.4.21pre porque o 2.4.20 tem um bug no ext3 que causa danificacao neste sistema de arquivos. Bingo!!! Estou usando o 2.4.20. Vou pro 2.4.21pre, eu acho. Como ficar informado sobre os bugs? Algum serviço automático de informação? Ou devo ir pra kernel.org? Eu indico que voce vah ara o kernel 2.4.19 ate que o 2.4.21 tenha sido liberado como stable e jah tenha sido usado por um tempo. A propósito, um bug de tal periculosidade ser publicado no kernel não é um mal sinal? Alguns testes básicos não teriam evitado este problema? Eh por isso que em maquinas com dados criticos (servidores, ...) nao se atualiza o kernel a cada release. Geralmente soh se atualiza quando existe algum bug de seguranca ou necessita-se de algum driver ou funcao similar que tenha sido incluido em versoes posteriores a instalada. Geralmente quando sair um release novo deve-se aguardar um tempo antes de instala-lo porque sendo assim os mais aventureiros identificam os problemas e entao voce jah fica avisado dos mesmos. Eu estou usando o kernel 2.4.20 porem com ReiserFS e nao tive nenhum problema. Brigadão, Otávio. p.s.: porque não postaste na lista? esta mensagem pode ser útil a outros; estou replicando prá lá, ok? Falha minha :( []s -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://www.freedom.ind.br/otavio -
integridade do sistema, como mantê-la? [explosão demográfica em /lost+found]
Olá pessoal. Preciso de ajuda. Por razões que ainda desconheço, meu computador tem corrompido o sistema de arquivos (ext3), de modo que um fsck povoa o /lost+found. Provavelmente trata-se de senilidade (não minha, espero, do disco rígido e/ou placa mãe :=)): um P100 do tempo que se dormia com a porta aberta :=). Os logs do sistema não acusam nada, isto me intriga. Até que descubra e, se tiver que trocar o micro (ou parte dele), troque, preciso manter a integridade do sistema (um fsck diário me resolve, espero). E aí vem o meu problema. Como saber que arquivo foi jogado no /lost+found de forma a poder recuperá-lo? 45678 não ajuda muito :=) Se não for possível saber isto, há alguma ferramenta no sistema capaz de checar, pacote por pacote, a integridade da instalação (todos os arquivos do pacote estão onde devem estar)? Antecipadamente, agradeço -- Marcio Roberto Teixeira endereço eletrônico: [EMAIL PROTECTED] página pessoal (em construção): http://www.marciotex.tk chave (GnuPGP): http://www.marciotex.hpg.com.br/keypub_8709626B.asc Usuário tchê Debian/GNULinux Porto Alegre - RS - Brasil A vida é como uma boa prova escolar: é curta, com múltiplas escolhas. O world não é o Word. Uso LaTeX: viva o código aberto!
Re: lost+found
'As 21:02 de 9 May 99, [EMAIL PROTECTED] enviou o texto que respondo abaixo. Ola'! A minha placa e'uma Intel I430VX e no seu BIOS ela nao possui estes recursos de acesso 32 bits(acho que e' desabilitada por padrao). Talvez seja habilitada por padrao. :-) Sempre que configuro computadores, desabilito esta opcao, porque nao sei como um programa da CMOS rodando em modo real 16 Bits conseguira permitir o acesso de 32 bits a um HD. Nao, nao! Para um HD, 32 bits significa transferir conjuntos de 32 bits de dados de uma vez ao inves de 16, o que gera algum ganho de performance. Nenhuma relacao com os diversos modos de funcionamento dos microprocessadores. Obviamente, o firmware do HD precisa suportar esse recurso. A menos que eu esteja muito enganado, o SO pode, isso sim, configurar um acesso em modo protegido 'a controladora IDE, mas ai' ja' e outra historia. No Windows para Workgroups ambos os recursos eram identificados, respectivamente, como acesso a disco em 32 bits e acesso a arquivos em 32 bits, e era possivel habilitar uma, ambas ou nenhuma dessas opcoes. Esse suporte e' habilitado independente da Bios apos a inicializaçao do Linux, e a ativaçao desta opcao gera incompatibilidade com muitas controladoras mais antigas. Pois e'. E quando essa controladoras mais antigas fazem parte da propria motherboard cuja BIOS permite esse recurso... ;-) Eu solucionava o problema desabilitando os recursos 32 bits na BIOS. Ou seja, colocava os HDs no modo mais lento e arcaico possivel, mas resolvia: 32-bit Mode: OFF, Block Access: OFF, PIO Mode: 0 (zero) e assim por diante. Humm... nunca tive nenhum problema utilizando as opçoes Block Access e PIO Mode, algumas controladoras mais antigas nao suportam o Block Access (ou block mode) ou as vezes a controladora suporta mas a velocidade do disco rigido e' tao lenta que nao se nota ganho de performance. Alguns discos rigidos padroes XT que testei ha algum tempo em um 486 tiveram incompatibilidade com o block mode. Descobri problemas com o PIO Mode quando alguns drives CD-ROM simplesmente se recusavam a funcionar em modo auto. 'As vezes o auto detectava modo 4, mas o drive so' funcionava corretamente em modo 3, ou vice-versa. De qualquer modo, quando as coisas nao funcionavam bem, colocar os dispositivos em modos menores tinha resultado... (...) As placas novas e baratas possuem hardwares que sao chamados de for Windows. O que se faz e' retirar o processador embutido destas placas, fazendo com que o Processador principal da placa mãe tenha que controlar o funcionamento deste periferico. Assim, sua firmware e' carregada e controlada pelo RUWindows, e normalmente a placa requer um funcionamento em tempo real do processador, que acaba por diminuir toda a performance geral do sistema. (...) Ha' algum meio, talvez algum software, capaz de detectar a (in)existencia desses dispositivos? Ate'! []'s Alexander Gieg Alexander GiegSao Paulo / Brazil [EMAIL PROTECTED] ICQ: 2200285 http://www.geocities.com/TimesSquare/3222/ Nick: AlexG Amados, nao deis credito a qualquer Espirito: antes, provai os Espiritos se procedem de Deus. (1 Joao 4:1) - Leia: O Livro dos Espiritos, de Allan Kardec
lost+found
-- De: Alexander Gieg [EMAIL PROTECTED] Para: [EMAIL PROTECTED] Cc: debian-user-portuguese@lists.debian.org Assunto: Re: lost+found Data: Domingo, 9 de Maio de 1999 11:08 'As 9:40 de 8 May 99, Gleydson enviou o texto que respondo abaixo. Nao tenho dicas de como encontrar os nomes verdadeiros dos arquivos, mas me lembro que, na epoca em que trabalhava com manutencao de microcomputadores, muitas motherboards made-in-somewhere tinham o pessimo comportamento de, vez por outra, gravar dados em lugares errados nos HDs (ou talvez nao gravar, nao sei dizer) quando o acesso ao disco do sistema operacional estava funcionando em modo 32 bits (ie., Windows for Workgroups, Windows 95 etc.) e a motherboard tambem estava com os recursos de 32 bits para os HDs habilitados. Ola Alexandre, A minha placa e'uma Intel I430VX e no seu BIOS ela nao possui estes recursos de acesso 32 bits(acho que e' desabilitada por padrao). Sempre que configuro computadores, desabilito esta opcao, porque nao sei como um programa da CMOS rodando em modo real 16 Bits conseguira permitir o acesso de 32 bits a um HD. Esse suporte e' habilitado independente da Bios apos a inicializaçao do Linux, e a ativaçao desta opcao gera incompatibilidade com muitas controladoras mais antigas. Entao, vez por outra um arquivo era corrompido um pouco, e chegava uma hora em que uma parte da FAT era sobrescrita, resultando na perda de um numero consideravel de arquivos. OK, concordo. Eu solucionava o problema desabilitando os recursos 32 bits na BIOS. Ou seja, colocava os HDs no modo mais lento e arcaico possivel, mas resolvia: 32-bit Mode: OFF, Block Access: OFF, PIO Mode: 0 (zero) e assim por diante. Humm... nunca tive nenhum problema utilizando as opçoes Block Access e PIO Mode, algumas controladoras mais antigas nao suportam o Block Access(ou block mode) ou as vezes a controladora suporta mas a velocidade do disco rigido e' tao lenta que nao se nota ganho de performance. Alguns discos rigidos padroes XT que testei ha algum tempo em um 486 tiveram incompatibilidade com o block mode. Tente isso, e talvez seu sistema funcione sem falhas. Nao e' preciso dizer que, se o problema for *esse*, uma troca de motherboard seria um bom investimento. E, se vc fizer isso, aceite uma sugestao: nunca, mas nunca mesmo, compre qualquer motherboard que tenha x-pro no nome. Elas sao baratas e sao facilmente encontradas em qualquer loja que trabalhe com produtos paraguaios ou, como costumava dizer meu honesto ex-chefe para os incautos e credulos cliente: de Miami, mas os problemas e o pessimo desempenho nao compensam a economia. Garanto-lhe que e' uma precaucao muito sensata... :-) Concordo com voce e seu chefe, mas tambem ha em outro detalhe que e' bom saber: As placas novas e baratas possuem hardwares que sao chamados de for Windows. O que se faz e' retirar o processador embutido destas placas, fazendo com que o Processador principal da placa mãe tenha que controlar o funcionamento deste periferico. Assim, sua firmware e' carregada e controlada pelo RUWindows, e normalmente a placa requer um funcionamento em tempo real do processador, que acaba por diminuir toda a performance geral do sistema. Ha algum tempo atras fiz alguns testes em jogos para DOS no meu computador Pentium 100 e em um Pentium 200MMX. No meu micro, o jogo ficou uma beleza!(nao existe nenhuma placa sem inteligencia no meu micro). Quando rodei o jogo na outra maquina, o som falhava, acontecia falta de sincronismo da imagem do jogo, e acabou no travamento da maquina. Acho que o planejamento e a construçao destas placas deveria levar em conta nao so' a velocidade do processador mas tambem o desempenho de toda a placa. Nao adianta lançar uma placa de 400MHz e colocar a CPU para gerenciar em tempo real os recursos de outros perifericos embutidos na placa, porque grande parte do desempenho e' perdido porque o processador terá que gerenciar o funcionamento dos processadores embutidos nas placas que foram retirados com o objetivo de diminuir custos com a fabricaçao(nao sei para onde vai este dinheiro economizado, porque o preço deste tipo de placas costuma ser ate maior...). Talvez o kernel tenha algum tipo de solucao para esses problemas, mas ai' ja' esta' alem de meu limitados conhecimentos. Eu ainda estou em divida quando a este problema, mas estou pesquisando na documentaçao da Debian e se der sorte, acho algo sobre isto. Obrigado! Gleydson MailBR - O e-mail do Brasil! Use você também! http://www.mailbr.com.br
lost+found
-- De: Adriano Freitas [EMAIL PROTECTED] Para: [EMAIL PROTECTED] Cc: debian-user-portuguese@lists.debian.org Assunto: Re: lost+found Data: Domingo, 9 de Maio de 1999 14:13 Bom, o que eu posso falar para vc é que pode ter ocorrido algum problema logo na parte de particionamento do disco. Eu tive um problema desse tipo há alguns anos (hehe :) quando a minha partição de swap, por algum motivo alheio ao meu conhecimento, se apresentava maior do que realmente era. Com isso, quando o swap enchia, ele invadia a partição do linux e alguns arquivos eram destruídos. Ola Adriano, Durante o particionamento tenho certeza que nao ocorreu nenhum problema porque conheço bem este processo e quando noto alguma anormalidade, interrompo imediatamente o programa(coisa que nunca aconteceu comigo no Linux, mas ja' aconteceu no DOS enquanto fazia testes em HD's com problemas de leitura e gravaçao). Eu sou o responsavel pelo desenvolvimento do manual do particionador CFdisk-portuguese, Fdisk-portuguese e FIPS-Portuguese, desenvolvidos no Brasil, e trabalho com particionamento ha mais de 6 anos e foi o projeto Linux que me inspirou a desenvolver estes documentos. Acho que no seu caso, pode ter acontecido alguma alteraçao incorreta na tabela de partiçao do disco rigido, causado por uma falha na controladora da placa mae, na controladora do HD ou ainda por setores danificados no limite da partiçao swap. Outro detalhe: As memórias Shadow ativas da placa mãe podem interferir no acesso a disco do Linux, é recomendável desativalas antes de se executar o Linux. Ha algum tempo fiz alguns testes instalando a Debian em um disco rigido de 5.1 GB com alguns agrupamentos danificados (nao chegavam a estar danificados, mas por um problema na superficie fisica do disco, um arquivo de 1 MB levava 40 Segundos para ser lido), e o Kernel mostrava algumas mensagens de erro de tempo limite ao fazer o acesso em determinados pontos do disco, em especial a area Swap, que e' uma area que necessita ter um perfeito funcionamento para dar o correto suporte de memoria virtual ao sistema operacional. Mas mesmo com este problema na superficie do disco, o Kernel fez o gerenciamento correto do disco, nao corrompendo nenhum arquivo armazenado na partiçao. O que vc não deve fazer é rodar o e2fsck -f com a partição montada com permissão de escrita. OK. Teve uma outra vez que eu tive problemas no sistema de arquivos do linux. Certo dia durante uma sessão de NT :), eu testei o suporte de escrita na partição do Linux de um programa chamado Explore2fs. Infelizmente ele danificou algumas coisas e o e2fsck encontrou alguns erros que foram facilmente corrigidos. Este e' um problema que ate agora fiquei sem entender i qye aconteceu (voce pode notar pela mensagem que enviei), e o curioso e' que apos diversos testes em outros discos rigidos, acontece um problema destes em um disco rigido com 2 meses de uso e em perfeito estado. Só complementando, as partiçoes do disco estavam em perfeito estado após a catastrofe somente os arquivos foram afetados não apresentou nenhum problema, tanto na sua criaçao como alinhamento com o cilindro do disco. Uma caracteristica do CFdisk da Debian sobre os outros particionadores de disco e' detectar e altertar sobre o desalinhamento da partiçao com o Cilindro do disco ou alteraçoes anormais de tamanho, caso aconteça. Obrigado assim mesmo pela dica! Um abraço Gleydson MailBR - O e-mail do Brasil! Use você também! http://www.mailbr.com.br MailBR - O e-mail do Brasil! Use você também! http://www.mailbr.com.br
Re: lost+found
'As 9:40 de 8 May 99, Gleydson enviou o texto que respondo abaixo. Ola'! (...) Aconteceu que, da última vez utilizei o comando fsck.ext2 com a opção -f. Ele encontrou vários problemas com o sistema de arquivos e todos eles foram corrigidos para o diretório lost+found. Para minha surpresa, após reiniciar o sistema, havia perdido todos os sub-diretórios de /usr, /bin, /home e outros 2. Entrando em lost+found, verifiquei que lá existiam diversos sub diretórios no formato #100125 (que se não me engano são os inodos do disco), usando o ls nome do diretório, conseguia verificar outros diretórios dentro dele seguindo o mesmo formato #123456. Mas não conseguia utilizar o comando cd para entrar neste diretório e verificar seu conteúdo. Acho que o mesmo acontecia com o mv. (...) Nao tenho dicas de como encontrar os nomes verdadeiros dos arquivos, mas me lembro que, na epoca em que trabalhava com manutencao de microcomputadores, muitas motherboards made-in-somewhere tinham o pessimo comportamento de, vez por outra, gravar dados em lugares errados nos HDs (ou talvez nao gravar, nao sei dizer) quando o acesso ao disco do sistema operacional estava funcionando em modo 32 bits (ie., Windows for Workgroups, Windows 95 etc.) e a motherboard tambem estava com os recursos de 32 bits para os HDs habilitados. Entao, vez por outra um arquivo era corrompido um pouco, e chegava uma hora em que uma parte da FAT era sobrescrita, resultando na perda de um numero consideravel de arquivos. Eu solucionava o problema desabilitando os recursos 32 bits na BIOS. Ou seja, colocava os HDs no modo mais lento e arcaico possivel, mas resolvia: 32-bit Mode: OFF, Block Access: OFF, PIO Mode: 0 (zero) e assim por diante. Tente isso, e talvez seu sistema funcione sem falhas. Nao e' preciso dizer que, se o problema for *esse*, uma troca de motherboard seria um bom investimento. E, se vc fizer isso, aceite uma sugestao: nunca, mas nunca mesmo, compre qualquer motherboard que tenha x-pro no nome. Elas sao baratas e sao facilmente encontradas em qualquer loja que trabalhe com produtos paraguaios ou, como costumava dizer meu honesto ex-chefe para os incautos e credulos cliente: de Miami, mas os problemas e o pessimo desempenho nao compensam a economia. Garanto-lhe que e' uma precaucao muito sensata... :-) Talvez o kernel tenha algum tipo de solucao para esses problemas, mas ai' ja' esta' alem de meu limitados conhecimentos. Ate'! []'s Alexander Gieg Alexander GiegSao Paulo / Brazil [EMAIL PROTECTED] ICQ: 2200285 http://www.geocities.com/TimesSquare/3222/ Nick: AlexG Amados, nao deis credito a qualquer Espirito: antes, provai os Espiritos se procedem de Deus. (1 Joao 4:1) - Leia: O Livro dos Espiritos, de Allan Kardec
Re: lost+found
Bom, o que eu posso falar para vc é que pode ter ocorrido algum problema logo na parte de particionamento do disco. Eu tive um problema desse tipo há alguns anos (hehe :) quando a minha partição de swap, por algum motivo alheio ao meu conhecimento, se apresentava maior do que realmente era. Com isso, quando o swap enchia, ele invadia a partição do linux e alguns arquivos eram destruídos. O que vc não deve fazer é rodar o e2fsck -f com a partição montada com permissão de escrita. Teve uma outra vez que eu tive problemas no sistema de arquivos do linux. Certo dia durante uma sessão de NT :), eu testei o suporte de escrita na partição do Linux de um programa chamado Explore2fs. Infelizmente ele danificou algumas coisas e o e2fsck encontrou alguns erros que foram facilmente corrigidos. []'s Gleydson wrote: Ola, fiz há pouco tempo a instalação da Slink 2.1 para testes, e ontem ocorreu um problema com o sistema de arquivos da partição principal: Certas vezes quando iniciava a Debian, aparecia uma mensagem que o sistema não conseguia rodar o INIT e era mostrado o aviso de login do root. Só que a senha não era reconhecida. Após pressionar CTRlALTDEL, o sistema entrava em modo de manutenção, e assim era me pedida a senha do root e assim conseguia entrar no sistema. Assim eu podia rodar o fsck.ext2 e verificar o sistema de arquivos. Só que reiniciando o computador, o Linux reconhecia normalmente todos os sistemas de arquivos. As vezes mostrava estes erros, as vezes não. Aconteceu que, da última vez utilizei o comando fsck.ext2 com a opção -f. Ele encontrou vários problemas com o sistema de arquivos e todos eles foram corrigidos para o diretório lost+found. Para minha surpresa, após reiniciar o sistema, havia perdido todos os sub-diretórios de /usr, /bin, /home e outros 2. Entrando em lost+found, verifiquei que lá existiam diversos sub diretórios no formato #100125 (que se não me engano são os inodos do disco), usando o ls nome do diretório, conseguia verificar outros diretórios dentro dele seguindo o mesmo formato #123456. Mas não conseguia utilizar o comando cd para entrar neste diretório e verificar seu conteúdo. Acho que o mesmo acontecia com o mv. Não se preocupem porque fiz esta instalação como teste e não perdi nenhum arquivo pessoal pois tinha cópias de segurança, a partição já foi até excluída, e estou fazendo a nova instalação do sistema. Mas nunca tinha visto uma destruição no sistema de arqivos como esta. Antes o sistema funcionava normalmente (mesmo tendo algum problema algumas vezes que inicializava) e após utilizar o fsck.ext2 perder diversos diretórios que estavam funcionando? Alguém da lista sabe como recuperar um sistema de arquivos intactos após um problema como este? Pode-se confiar no utilitário fsck.ext2 durante um problema com o sistema de arquivos? E como restaurar, e como adivinhar quais são os nomes dos diretórios dentro de lost+found (os diretórios principais como /usr, /home, /bin é simples, mas dentro de /usr/doc por exemplo, existem diversos documentos e arquivos que dificilmente podem ser lembrados). Sinceramente, nunca tive uma perda como esta sem explicação utilizando o DOS/NDD. Alguém tem uma sugestão para uma melhor correção deste problema, caso venha a acontecer futuramente ou com qualquer pessoa da lista? Espero sugestões
lost+found
Ola, fiz há pouco tempo a instalação da Slink 2.1 para testes, e ontem ocorreu um problema com o sistema de arquivos da partição principal: Certas vezes quando iniciava a Debian, aparecia uma mensagem que o sistema não conseguia rodar o INIT e era mostrado o aviso de login do root. Só que a senha não era reconhecida. Após pressionar CTRlALTDEL, o sistema entrava em modo de manutenção, e assim era me pedida a senha do root e assim conseguia entrar no sistema. Assim eu podia rodar o fsck.ext2 e verificar o sistema de arquivos. Só que reiniciando o computador, o Linux reconhecia normalmente todos os sistemas de arquivos. As vezes mostrava estes erros, as vezes não. Aconteceu que, da última vez utilizei o comando fsck.ext2 com a opção -f. Ele encontrou vários problemas com o sistema de arquivos e todos eles foram corrigidos para o diretório lost+found. Para minha surpresa, após reiniciar o sistema, havia perdido todos os sub-diretórios de /usr, /bin, /home e outros 2. Entrando em lost+found, verifiquei que lá existiam diversos sub diretórios no formato #100125 (que se não me engano são os inodos do disco), usando o ls nome do diretório, conseguia verificar outros diretórios dentro dele seguindo o mesmo formato #123456. Mas não conseguia utilizar o comando cd para entrar neste diretório e verificar seu conteúdo. Acho que o mesmo acontecia com o mv. Não se preocupem porque fiz esta instalação como teste e não perdi nenhum arquivo pessoal pois tinha cópias de segurança, a partição já foi até excluída, e estou fazendo a nova instalação do sistema. Mas nunca tinha visto uma destruição no sistema de arqivos como esta. Antes o sistema funcionava normalmente (mesmo tendo algum problema algumas vezes que inicializava) e após utilizar o fsck.ext2 perder diversos diretórios que estavam funcionando? Alguém da lista sabe como recuperar um sistema de arquivos intactos após um problema como este? Pode-se confiar no utilitário fsck.ext2 durante um problema com o sistema de arquivos? E como restaurar, e como adivinhar quais são os nomes dos diretórios dentro de lost+found (os diretórios principais como /usr, /home, /bin é simples, mas dentro de /usr/doc por exemplo, existem diversos documentos e arquivos que dificilmente podem ser lembrados). Sinceramente, nunca tive uma perda como esta sem explicação utilizando o DOS/NDD. Alguém tem uma sugestão para uma melhor correção deste problema, caso venha a acontecer futuramente ou com qualquer pessoa da lista? Espero sugestões Gleydson [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
