Re: Fw: Does anyone have experience on installing Debian(5.0) on laptop Lenovo x1004?
On Wed, 09 Jun 2010, Jon Dowland wrote: On 09/06/2010 16:25, kzsyz wrote: it should be *Lenovo ThinkPad x100e, *sorry... There are a few blog posts reporting varying degrees of success: http://www.1ts.org/~kcr/story/6064 http://www.1ts.org/%7Ekcr/story/6064 - all but 3D acceleration (squeeze, kernel 2.6.32) http://lousycoder.com/blog/index.php?/archives/169-Getting-thinkpad_acpi-to-work-in-a-X100e-on-Debian-Lenny.html - a kernel patch needed to fix an acpi issue? I'm thinkpad-acpi upstream. Get the latest release from ibm-acpi.sf.net for use in the x100e, the above patch is not enough. It was a debugging patch, only. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100630212535.gd30...@khazad-dum.debian.net
Re: Barramento PCI chipset intel ICHxx N�O funciona no Linux
On Tue, 22 Jun 2010, Jeferson Wendland wrote: com placa m�e Intel DP43BF, essa motherboard tem placa de rede on-board e Algumas poucas placas m�e Intel s�o LIXO com BIOS que n�o suporta Linux. Por rid�culo que pare�a, isso *est�* documentado pela Intel (as outras placas listam Linux como OS suportado, e essas n�o). N�o sei se � o caso da DP43BF. Se uma atualiza��o de BIOS n�o resolver, ou n�o vai funcionar nunca, ou est� com defeito mesmo. S� resta doar para algu�m. PS: em hardware com PCIe, dispositivos PCI ficam atr�s de uma bridge PCIe-PCI. Qualquer coisa errada nessa bridge (hardware, config, etc) faz com que todos os dispositivos PCI parem de funcionar. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100625043035.gb19...@khazad-dum.debian.net
Re: Mirror Debian Brasil Lento
On Wed, 23 Jun 2010, Adauto Serpa wrote: Estou notando muita lentid�o no mirror do Brasil http://ftp.br.debian.org/debian eles est�o sobrecarregados ou com problemas ??? A conex�o da Telef�nica e da Embratel com a RNP anda um lixo. Pode ser que seja esse o problema... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100625043212.gc19...@khazad-dum.debian.net
Re: Questions about RAID 6
On Sun, 02 May 2010, Mike Bird wrote: On Sun May 2 2010 13:24:30 Alexander Samad wrote: My system used to become close to unusable on the 1st sunday of the month when mdadm did it resync, I had to write my own script so it did not do mulitple at the same time, turn off the hung process timer and set cpufreq to performance. A long time ago there were problems like that. Nowadays s/w RAID handles rebuild so well that we don't even have to set /proc/sys/dev/raid/speed_limit_max. Tried that with a fsck or quotacheck? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100609014716.ga21...@khazad-dum.debian.net
Re: Cyrus 2.2 imapd in AMD64
On Mon, 26 Apr 2010, Carlos Bergero wrote: ./tls_sessions.db: Berkeley DB (Btree, version 8, native byte-order) ./deliver.db: Berkeley DB (Btree, version 8, native byte-order) and there a a couple of cyrus DB files which readme upgrade ask to migrate with a cyrus tool which is not working atm, ./mailboxes.db: Cyrus skiplist DB (which it has a different name simply mailboxes, without the .db extension) ./annotations.db: Cyrus skiplist DB (which is not mentioned in the tutorial) So far im focused in trying to get this DB to the proper format version 9 in the standard Lenny install, and see what happens, without much success. db*_upgrade will upgrade (NOT DOWNGRADE) a berkeley database. Run it from the main environment directory. It is in the db*-util packages. Use the correct target version (for cyrus, see the package dependency list to know which libdb it uses). Just delete tls_sessions.db. It is the TLS session cache. You can consider deleting deliver.db. It is the cache used for duplicate suppression and to avoid sending vacation messages to the same recipient twice. There will be very little harm done (if any) should you delete it. Consider reading the documentation for berkeley DB, especially the stuff prepared by OpenLDAP and samba (look in their web pages). Screw that up, and your performance goes downhill. Consider reading the archives of the cyrus users ML, hunt down from any posts from @fastmail.fm and read them. They _REALLY_ know their stuff. All skiplist DBs are auto-upgraded by cyrus on access. If one wasn't, chances are it is corrupt and you have a big problem. After you manage to start cyrus, run cyrquota and cyrreconstruct over *ALL* mailboxes. I mean *ALL* of them. And this _will_ take time. You could do it with the system in use, but since it is a safety measure to insure there is no inconsistent data, well, it is best done before any read or write access is done to the mailboxes. And do remember cyrus has databases stored in the user dirs as well. Debian packages should have them skiplist or plaintext, which don't require manual intervention, but check it (seen database). Sieve requires conversion of _all_ scripts on all spools. Look for the massievec script and run it on every sieve script. This is _all_ in the cyrus documentation, although probably not organized like that... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100501155315.ga24...@khazad-dum.debian.net
Re: Does email server OS needs clamav?
On Mon, 07 Dec 2009, Sthu Deus wrote: I think ClamAV should run as clamav user, not root and the same remains for many other services that use their own user. I think the same. But! In Debian all/most the mail-related services are run under the root user... I was asking here how I can change it - seems nobody cares for it... This is simply not true. Certainly not for exim or postfix, which are the *only* MTAs worth considering for any professional usage, anyway. Both of these run with their own users, and in postfix' case, it does fine-grained privsep (like ssh does) and chrooting. At least postfix has also a targetted SELinux profiles, and can run fully locked down with some configuration to allow for Cyrus SASL authentication, if you need it. I have no reason to believe exim to be any different. amavisd-new refuses to run as root, and will run spamassassin and other such stuff as the amavis user. clamav will have clamd and freshclam running with its own users as well, and not as root. So, exactly what crap are you running on your Debian mail server? Of course, your linux server does not need an antivirus to protect itself, but to prevent your users to be infected. And remember that by centralizing the anti-malware checking in one point (your e-mail server) you are saving not just resources, but time and money to your company. Well. They still need to have antivirus software as they use internet... Have you ever heard of any Windows AV that filters *outgoing* email? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
NOTICE: Debian is moving sieve to its IANA allocated port (4190)
This is a general warning to those using Debian Squeeze, and Debian Sid. Debian Etch and Debian Lenny users are NOT affected. The IANA port allocated for ManageSieve is 4190/tcp, and the old port used by timsieved and other managesieve software in many distros (2000/tcp) is allocated for Cisco SCCP usage, according to the IANA registry[1]. Starting with the version 4.38 of the Debian netbase package, the sieve service will be moved from port 2000 to port 4190 in the /etc/services file. Any installs which used the sieve service name instead of a numeric port number will switch to the new port number as soon as the services are restarted/reloaded, and in some cases, immediately after /etc/services is updated. This will affect Cyrus IMAP. This may also affect other sieve-enabled software such as DoveCot. In order to avoid downtime problems, mail cluster administrators using Debian are urged to verify their Cyrus (and probably also DoveCot) installs, and take measures to avoid services moving from port 2000/tcp to port 4190/tcp by surprise in either servers or clients. It is worth noting that: 1. /etc/services will only be automatically updated if you never made any modifications to it. Otherwise, you will be presented with a prompt by ucf or dpkg asking you about the changes. 2. You can edit /etc/services and change the sieve port back to 2000 if you want (this is not recommended, though). 3. You can edit /etc/cyrus.conf and any other relevant config files for your mail/webmail cluster (e.g. on the sieve web frontends) ahead of time to force them all to a static port number. 4. You can configure cyrus master to listen on *both* ports (2000 and 4190) at the same time, and thus avoid the problem entirely. This also allows for a much more smooth migration from port 2000 to port 4190. [1] http://www.iana.org/assignments/port-numbers -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Does email server OS needs clamav?
On Mon, 07 Dec 2009, Nick Douma wrote: Have you ever heard of any Windows AV that filters *outgoing* email? Actually, most that I know do. At work, NOD32 integrates with Outlook and Thunderbird, and scans everything, even already delivered mail. I'm not sure if that last feature is really all that great though, I find it annoying. Well, that's nice to know. Thank you for the information! (and by scanning outgoing email, I do mean scan the ESMTP stream before it gets to the target, otherwise the damage is already done...) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: AntiSpam no servidor
On Wed, 02 Dec 2009, Anderson Bertling wrote: propriamente dito, mas a solução para anti spam, estou procurando algo que faça o seguinte, quando alguem manda um email sério o servidor deve devolve um email p o remetente onde solicita a confirmação(através de um link ou de uma chave tipo digite o que vc ve na imagem), com essa Isso se chama TMDA. E é considerado uma prática intolerável se usada em emails de uso geral, pelo estrago colateral que causa (mas, de repente, pode até ser bem aceita em determinadas comunidades fechadas. Eu só não conheço nenhuma). O google te ajuda a descobrir como implementar. Mas cuidado, a maior parte de nós vai colocar em blacklist permanente qualquer um que ouse trazer de volta o fantasma do antispam UOL. Se não entendeu, procure por antispam UOL. Não disponibilize TMDA para conta de email que não seja de uso extremamente restrito. Use SPF restrito para o domínio, implemente filtragem de SPF e domainkeys na entrada, e ponha uma série extremamente pesada de filtros conta bots e contra backscatter na frente (inclusive greylist), ou vai causar um problemão para os outros no dia em que um endereço atrás do TMDA for usado numa spam-run ou for inscrito por algum meliante numa lista de email. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Does email server OS needs clamav?
On Wed, 02 Dec 2009, Sthu Deus wrote: Do I need clamav mail check on mail server - if I would leave it to Clamav is fast (if you configure it right), and will let you reject a truckload of dangerous artifacts before they hit the content filters, saving on resources AND adding an extra layer of protection for the end users. If you use amavisd-new to plug clamav to the MTA, and you configure amavisd-new and clamav correctly so as to not lose mail on false positives, you can also use the spam/malware signature databases in www.sanesecurity.org, to aid spamassassin. Clamav is an order of magnitude faster than spamassassin for signature-based rules. their machines) - the every letter they get? - What does clamav protects: the email server or the end user (at its own machine)? Depends on how you use it. I don't know anyone who uses clamav to protect the server, you protect an Unix server by properly hardening it, the falsehoods of the file scanner industry have not taken root on Unix land yet. But an AV like clamav in the mail path _does_ protect the end user, as the artifacts will be stopped before they get close to the user. Everyone I know that deploy MTAs professionaly have either clamav or a commercial AV in the mail path, and often both. PS I want to remove it because I suppose that in case clamav blesses users' life and not server's - by removing clamav I can close one potential security whole. Yes, you do close a potential source security holes, but you will be doing so at the expense of your users' safety. At that point, you might as well drop any content filter like amavisd-new and spamassassin (which would also be a potential source of security holes), and use just plain postfix. You will have a lightning fast MTA, that adds almost _no_ value to your users since it will forward tons of spam and malware to their inboxes... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Does email server OS needs clamav?
On Fri, 04 Dec 2009, Sthu Deus wrote: Personally, I do not trust the local network I have the deal with - much more than the Internet... So, for me it is much better to protect the server - to let it working as it should providing its services rather than try to explain the people the primitive rules on IT-security - in other words, let it be up to them, separately. Sure. However, assuming it is also an outbound MTA, you should be aware that a AV-less, content-filter-less MTA will forward actively harmful data to the world at large, and thus it will be blacklisted in no time flat. And it will be a well deserved blacklisting, obviously. Your safer server _would_ be a danger to everyone else in that situation. Here at work, we go through great lengths to make sure no virus or spam can get through the MTAs, either inbound _or_ outbound. Anything we wouldn't let get inside, must NOT go outside either. There is more to it too: we have strict rate limiting and controls (I love postfix) to catch any internal box which is doing funny stuff. Our clients and servers are compelled to behave where technically possible. We can't always stop spam or phish, but we _can_ detect and stop a spam-run, and DoS attacks from the inside or outside do _not_ get through (while a massive one can bring down the MTA cluster, it will die there and not get past it). Every box (_all_ servers and _all_ clients) are forced to go through the MTA clusters for port 25 access. All our firewalls (and not just the border firewalls) block any sort of port 25 traffic which doesn't have one of the endpoints in the MTA clusters. That's called good neigbour policy, the internet would be a much better place if everyone did that (filter out crap that is trying to leave their networks). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: CONFIG_SYSFS_DEPRECATED
On Thu, 03 Dec 2009, Jochen Schulz wrote: Now when I try to boot, I get the message ... update kernel or disable CONFIG_SYSFS_DEPECATED This should be negligible. It is not. It will likely hang the box during boot as stuff wait for udev to create nodes that never show up. I don't know if it will eventually timeout, but if it will, it will take a _long_ time. Yes, please try to be more precise about what happens before the boot process hangs. Did you try pressing Ctrl-c or Ctrl-d to abort the For some reason or another, we don't always have SIGINT (^C) and SIGQUIT (^\) working properly on the console during early boot (when using sysvinit, I don't know about upstart). This is a long-standing issue, which I don't have the time to track down. If anyone would like to do it, it would be really helpful. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: CONFIG_SYSFS_DEPRECATED
On Sat, 05 Dec 2009, Patrick Wiseman wrote: On Sat, Dec 5, 2009 at 2:21 PM, Henrique de Moraes Holschuh h...@debian.org wrote: On Thu, 03 Dec 2009, Jochen Schulz wrote: Now when I try to boot, I get the message ... update kernel or disable CONFIG_SYSFS_DEPECATED This should be negligible. It is not. It will likely hang the box during boot as stuff wait for udev to create nodes that never show up. I don't know if it will eventually timeout, but if it will, it will take a _long_ time. [Apologies to Henrique for first replying to him; darn Gmail default!!] Not in my experience. I've been booting with this message for several weeks now, with no observable degradation in boot time. And if it did behave as you predict, deprecated is hardly sufficient warning! Well, I should have been far more precise about it. It can hang in certain configs. It did here, and I needed a live-cd to fix the issue. It could well depend on your arch, kernel config, and set of packages installed, as well as whether you're using an initrd or not. Too bad I didn't have the time to fix or track it, so I used a live-cd, downgraded udev to 146-something, got it to boot, fixed things up in the kernel, and it is now working properly. It was not reported to the BTS, since it would justly deserve an unreproducible needsinfo set of tags most likely, and I'd have no further info to contribute. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: exclusão
On Tue, 01 Dec 2009, Márcio H. Parreiras wrote: Nada feito. Entrou, vendeu a alma eternamente, não pode sair :-D Não é eterno :-) Se mandar o pedido de remoção correto pro robô, sai sem problemas. Agora, se a pessoa se inscreveu na lista com um endereço velho que está sendo encaminhado pro novo, e esqueceu disso, fica difícil. Precisa saber o endereço de email EXATAMENTE COMO FOI INSCRITO NA LISTA para conseguir sair. Use as páginas em http://lists.debian.org/debian-user-portuguese para pedir para ser removido. O sistema envia uma email de convirmação, que você *TEM* que responder (ou usar o link html se um for fornecido), para ser desinscrito. Note que nem dá para o listmaster te ajudar num caso de encaminhamento, já que ele não sabe qual endereço de email está realmente inscrito na lista para poder remover... Cabe a quem se inscreveu pedir a remoção corretamente (não estou defendendo, estou descrevendo a realidade como ela é, goste ou não goste). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: NTP do CAIS c/ 1 hr adiantado
On Wed, 14 Oct 2009, Alex Paulo Laner wrote: Tem um pacote que acerta o horário de verão tz-brasil - timezone autoconfiguration for Brazil Não precisa, se você o tz-data do volatile. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Sintaxe EXT3
On Wed, 14 Oct 2009, Fábio de Sousa wrote: Um dos problemas que acontece com frequência é a queda de energia... Li sobre o sistema de arquivos EXT3 e descobri que colocando no /etc/fstab a opção data=journal - a possibilidade de corromper arquivos diminui muito, já sabendo que a performace é bem menor... Você precisa também desligar o cache de escrita dos discos (a menos que o ext3 esteja conseguindo utilizar barriers). Desligue também o NCQ, ele piora a perfomance nesse caso na maioria dos discos. Alguém sabe a maneira correta de utilizar esta opção? Para a root filesystem, precisa passar rootflags=data=journal na linha de comando do kernel. Acho mais fácil usar o tune2fs e trocar o modo de jornal da filesystem logo de uma vez. Pude notar que em cada distro tem uma sintaxe diferente. Qual será a sintaxe que deverei usar? A sintaxe é a mesma em todas as distros. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: OT question about sound cards/chip-sets and high-end music systems
On Mon, 05 Oct 2009, Boyd Stephen Smith Jr. wrote: On Monday 05 October 2009 13:20:14 Johannes Wiedersich wrote: Boyd Stephen Smith Jr. wrote: It is purely digital. 16-bit (not sure if this is floating- or fixed-point), stereo, 44.1 kHz samples, IIRC. What's the difference between 16-bit floating-point and 16-bit fixed-point? I always thought those are just integers. On floating-point, you can encode a higher dynamic range, but the precison varies. Fixed-point has the same precision on the entire range. But you could have a function to map the integer range to a larger dynamic range too (this is called quantization). This sort of encoding should not be confused with regular floating-point. CDs use PCM, which _does_ have a quantization function. Here: http://en.wikipedia.org/wiki/Pulse-code_modulation Some audio codecs use floating-point, which is like a float or double or long double in the C programing language. Some bits are the exponent (usually with a bias) and some bits are the mantissa. Other audio codecs use fixed-point, where the 16-bits simply a signed integer (or possibly an unsigned integer modified by a bias). No codec worth its salt will use 16 bits, be it fixed point or floating point. Usually floating-point codecs will use standard precision or long precision floating point (which is 80 bits, I think). And most integer codecs will use 32-bit or 64-bit fixed-point arithmetric. They use that to decode the PCM stream (which is 16-bit). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Cryptsetup-luks
On Mon, 05 Oct 2009, Pedro Celio wrote: Obrigado pelo retorno e pelas dicas. Como eu faço para adicionar a camada FEC que sugeriu? Tem alguma ferramenta específica para isso? Tem algum material a respeito disso? Procura por programas que implementem codificação Reed-Solomon. No pacote dvbackup tem um, só que eles usam uma codificação tão absurdamente forte, que talvez aumente demais o tamanho do arquivo. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Cryptsetup-luks
On Sun, 04 Oct 2009, Pedro Celio wrote: Agora uma coisa que não consegui achar nas pesquisas e documentação do software é se ocorrer algum bad block ou algum problema lógico no sistema de arquivos do dispositivo criptografado, até que ponto isso pode interferir no processo de descriptografia do mesmo. Em geral não há realimentação de um setor para outro, então danos a um setor serão restritos ao mesmo. Mas é sempre necessário verificar para cada aplicação. No caso do dm-crypt, não tem realimentação. Leia isso: http://clemens.endorphin.org/LinuxHDEncSettings e isso: http://mareichelt.de/pub/notmine/linuxbsd-comparison.html Aliás, recomendo adicionar uma camada FEC (forward-error-correction) na mídia de backup caso a mesma seja usada para retenção. O FEC pode ficar, inclusive, em mídia separada (mas *tem* que ser cifrado também, óbvio). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Cryptsetup-luks
On Sun, 04 Oct 2009, Henrique de Moraes Holschuh wrote: On Sun, 04 Oct 2009, Pedro Celio wrote: Agora uma coisa que não consegui achar nas pesquisas e documentação do software é se ocorrer algum bad block ou algum problema lógico no sistema de arquivos do dispositivo criptografado, até que ponto isso pode interferir no processo de descriptografia do mesmo. Em geral não há realimentação de um setor para outro, então danos a um setor serão restritos ao mesmo. Mas é sempre necessário verificar para cada aplicação. No caso do dm-crypt, não tem realimentação. Leia isso: http://clemens.endorphin.org/LinuxHDEncSettings e isso: http://mareichelt.de/pub/notmine/linuxbsd-comparison.html Aliás, recomendo adicionar uma camada FEC (forward-error-correction) na mídia de backup caso a mesma seja usada para retenção. O FEC pode ficar, inclusive, em mídia separada (mas *tem* que ser cifrado também, óbvio). Leia também: http://en.wikipedia.org/wiki/Disk_encryption_theory O modo recomendado é aes-xts-essiv, ou seja algo do tipo: cipher=aes-xts-essiv:sha256,size=256,hash=sha256 pro LUKS. Se for para retencão, eu usaria tudo com 512, já que a rentenção tem que aguentar segura por uns 10 anos... Pode ser que no seu caso não faça diferença usar XTS ou CBC. CBC é mais rápido. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Hello! Please, I need your help! An advice of what I need to download to
On Sun, 04 Oct 2009, guido mezzalana wrote: The only problem I am getting is I have not sound! clickin on volume control is telling me: no volume control GS streamer plugins and/or devices found My lap is an IBM Thinkpad T21, so far Debian and Mepis is giving me the same issue, I like to point out with other free open source my lap is just fine! Kindly proceed to http://thinkwiki.org, where a lot of useful information about your thinkpad is there, just waiting for you to use it :) I suggest that you subscribe yourself to the linux-thinkpad ML, and ask there. Other T21 owners might help you better than we could, since the T21 is a very old box and some of its lore has already been lost. The address of the ML is in thinkwiki.org. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: dhclient DHCPREQUEST loop
On Wed, 30 Sep 2009, Michael Pobega wrote: I get this problem on some networks; it seems to me that some routers just don't play nicely with dhclient. I've tried multiple times to find the source, but I've yet to have any luck. Well, we'd need packet dumps (*full* packet dumps) from tcpdump to know, for both a stream that worked (e.g. from Windows) and one that didn't work for a particular router. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: checking for multicast traffic
On Wed, 16 Sep 2009, Mag Gam wrote: How do I send multicast traffic? How do I receive it? I higly suggest you learn about what multicast traffic is in the first place, you came across as very confused about the whole thing: http://en.wikipedia.org/wiki/IP_multicast How to send/receive multicast: http://ntrg.cs.tcd.ie/undergrad/4ba2/multicast/antony/index.html And you better not screw up and use the wrong multicast group, so kindly check IANA first before sending packets to any multicast group, or your network system admin might decide that your spleen would look better in his wall: http://www.iana.org/assignments/multicast-addresses/ And finally, the obvious: apt-cache search multicast will tell you about numerous Debian packages with multicast capability, maybe one of them does whatever you want to do with multicast. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: HDD,SSD,diagnostic,integrity verify tools.Free,Opensource.
On Sun, 26 Jul 2009, Osamu Aoki wrote: On Sat, Jul 25, 2009 at 12:07:35PM -0700, Luis Maceira wrote: What is the best tool available in the free,OpenSource world to verify the integrity of HDD but,specially SSD drives(the fading capacity problem with too many writes to the same blocks).It is not only a problem of filesystem check,it is more physical of the drive itself.Right now,I do not remember of any. smartd in smartmontools package - more physical of the drive fsck- filesystem check dd and badblocks - excercise the drive and to find out bad sectors on drives with bad firmware or that have run out of remapping area (will hasten the death of your SSD, though). When in doubt, stick to smartmontools like Osamu said. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: XOrg Config Problem on Thinkpad T60
On Thu, 18 Jun 2009, Boyd Stephen Smith Jr. wrote: 3. Even if binary blobs *were* the original form of the work and their author modifies them by twiddling bytes, they still might not be appropriate for inclusion in Debian main because of the inherent security issues. Most notably, out inability to audit them. That's nonsense. First, our inability to audit has never figured in any restrictions. Second, the sort of firmware that has no source are microcode to drive state machines in the hardware, and without the full engineering specs you need some *serious* reverse engineering effort to do anything with it anyway. It is also likely to have no security relevance outside of causing that particular hardware to misbehave: nobody uses stuff like this to drive a PCI or RDMA engine (which would be a real cause of concern on boxes without MMU firewalling). However, if you say there was an ASM version of the firmware, and it was not just the same binary data in a different container (i.e. it was a higher-level representation of the code), then it indeed belongs in non-free and I stand corrected about it being sourceless microcode. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: XOrg Config Problem on Thinkpad T60
On Wed, 17 Jun 2009, Andrei Popescu wrote:
I really wonder why this package is not a dependency of the
xserver-xorg-radeon{,hd} packages. If the installation of that package
solved
that problem for you I will file a bug against the xserver-xorg-video-*
packages that depend on it.
Packages in 'main' can not depend on packages in 'non-free' (or they
have to go to 'contrib'), they can only 'suggest' them:
If they _require_ a non-free package to work in the first place, they should
be in contrib and depend on the non-free package. It doesn't belong in
main.
However, AFAIK, the firmware for the radeons is not non-free. At first
glance, the license looks dfsg-compatible (but I am too sleepy to be sure
about it right now). And the binary blobs look like microcode to me, which
doesn't even _have_ source other than its own binaryness. But someone who
works in the X.org driver is going to be better able to tell if it is
microcode, or something that would have some sort of higher-level source
code.
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Upgrading mdadm-based RAID arrays
On Fri, 15 May 2009, Alex Samad wrote: I wouldn't make up raid devices with other raid device (I think its possible), but I seem to remember thats its not advisable. You're correct. Don't stack md devices if you want to be on the safe side. Nobody tests that regularly, and it has caused problems in the past. I would suggest though, when you get to around 5 or 6 drives you look at raid6 instead. Indeed, especially with such big drives. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RAID5 (mdadm) array hosed after grow operation (there are two of us)
On Wed, 29 Apr 2009, Boyd Stephen Smith Jr. wrote: In 20090429192819.gb1...@khazad-dum.debian.net, Henrique de Moraes Holschuh wrote: On Wed, 29 Apr 2009, martin f krafft wrote: also sprach Henrique de Moraes Holschuh h...@debian.org [2009.04.29.1522 +0200]: As always, you MUST forbid lvm of ever touching md component devices even if md is offline, and that includes whatever crap is inside initrds... One should thus fix LVM to be a bit more careful... It would need to start refusing devices with a raid superblock (all types), unless forced. The feature doesn't have to be perfect out of the box. It could initially just match 0.90 version superblocks and be extended later. 1.0 superblocks are widely used. Please don't do that. Either implement support for both, or use mdadm (which knows both). This kind of stuff really should not be done halfway, it can suprise someone into a dataloss scenario. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RAID5 (mdadm) array hosed after grow operation (there are two of us)
On Thu, 30 Apr 2009, Boyd Stephen Smith Jr. wrote: He who codes, decides. Either put forth the effort to design/write/review/test/apply the patch or don't be surprised if your preferences are not highly weighted in the resulting code. Will lvm upstream take something that makes lvm align pv data areas to RAID stripe boundaries and is actually less arcane that hit and miss games with pvcreate --metadatasize? I have a lot of stuff on my plate right now (including updating some Debian packages of mine that are getting cowebs and dealing with the entire mess that the new kde did to my main workstation) and I can't waste effort on something that wouldn't be accepted outright... even then, it will take a while for me to actually get my hands dirty with lvm code. That said, I think everyone participating in the thread so far has agreed that we don't want separately-maintained detection code in LVM that could get out of date, but for LVM to use the existing detection code when it is available on the system. Yes, please. mdadm is just as critical to system startup as lvm, there isn't a problem into having dependencies between the two. This kind of stuff really should not be done halfway, it can suprise someone into a dataloss scenario. Right now, LVM will stomp all over devices with either 0.90 or 1.0 superblocks. Even if it can only detect one or the other and not both, it will cause less data loss than now. There is an old adage in the security circles about the dangers of false sense of security, and it applies here. For me to agree with you, the feature of not corrupting inactive md components would have to be undocumented, so that nobody would trust it to exist and thus nobody would be bitten by the fact that it is implemented partially. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RAID5 (mdadm) array hosed after grow operation (there are two of us)
On Thu, 30 Apr 2009, martin f krafft wrote: also sprach Henrique de Moraes Holschuh h...@debian.org [2009.04.30.1615 +0200]: 1.0 superblocks are widely used. Please don't do that. Either implement support for both, or use mdadm (which knows both). This kind of stuff really should not be done halfway, it can suprise someone into a dataloss scenario. It should only be done in mdadm, especially since mdadm v3 adds user-space superblock formats. Where can I read about that, before I freak out needlesly? :-) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: KDE4 dual monitor window maximizing behaviour
On Mon, 20 Apr 2009, Boyd Stephen Smith Jr. wrote: In uptgl.32674$qh6@newsfe14.iad, Lancelot du Lac wrote: I can only join my voice to those who say this behavior is a pain. Since this bug appears in 3.5.10, I'm currently pinning 3.5.9 for kwin. (and I have to say it works well) However this much probably won't be possible once kde4 is uploaded into testing. I certainly hope this is fixed before the uploading of kde4 in Squeeze. I use TwinView, including its fake Xinerama, and I'm not seeing the bug. That said, I think I skipped from kwin in Etch to KDE 4.2 (initially from experimental). I'm now on KDE 4.2 from unstable and maximizing to a single monitor works fine, as done dragging windows between monitors. It is still broken, but less so than 3.5.10. KDE4 seems to have some split-brains problem. Maximizing does work (restricts itself to one viewport), but the thing doesn't seem to know it is working with a Xinerama'ed display everywhere it should. For one, it doesn't detect that it has two viewports in many places, like the desktop manager... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RAID5 (mdadm) array hosed after grow operation (there are two of us)
On Tue, 21 Apr 2009, Alex Samad wrote: Learned my lesson though - no real reason to have root on lvm - it's now on 3-disk RAID 1. all ways thought this, KISS Exactly. I have servers with 4, sometimes 6-disk RAID1 root partitions, because of KISS: all disks in the raid set should be equally configured (and these are boxes running raid1 on a partition for /, and raid10 on another for a lvm PV). As always, you MUST forbid lvm of ever touching md component devices even if md is offline, and that includes whatever crap is inside initrds... With the need to regenerate initrds due to mdadm, lvm, and other such easy-to-forget issues, we abolished the use of initrds in the datacenter. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: RAID5 (mdadm) array hosed after grow operation (there are two of us)
On Wed, 29 Apr 2009, martin f krafft wrote: also sprach Henrique de Moraes Holschuh h...@debian.org [2009.04.29.1522 +0200]: As always, you MUST forbid lvm of ever touching md component devices even if md is offline, and that includes whatever crap is inside initrds... One should thus fix LVM to be a bit more careful... It would need to start refusing devices with a raid superblock (all types), unless forced. Unless you write that patch, I would not expect it to ever happen. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Advice on raid/lvm
On Thu, 09 Apr 2009, Mark Allums wrote: Is there an advantage of software raid10 over multiple raid1 arrays joined with LVM? Capacity can be dynamically added with pairs of disks. Only one: simplicity. It would make it easier for someone to understand, in the beginning. Well, md-raid10 is actually raid 10, not stripping stacked on top of a mirror. It has the concept of near and far copies of raid blocks, and one of the possible configurations reduces to the same layout you get when you stripe data over two mirror sets. It is supposed to be able to perform a lot better than device-mapper on top of two md raid1 sets ever could, but I didn't test that to check. What I *dislike* in md-raid10 is that it is more difficult to chose the right disks to remove when you want to remove all possible disks from an array without losing data, and also that either the kernel or the tools didn't let me create a raid set with half the devices missing last time I tried that (but that may have been fixed already on latest mdadm + latest kernel). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Advice on raid/lvm
On Fri, 10 Apr 2009, Mark Allums wrote: I also think that RAID 10 is pretty simple to understand. Take four disks. Make two pairs. Mirror each pair (RAID 1), then stripe across the pairs (RAID 0). It's just a combination. That's just the most basic layout for raid-10... It can get a LOT more confusing (and probably less useful) than that. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Advice on raid/lvm
On Wed, 08 Apr 2009, Miles Fidelman wrote: One suggestion: think very carefully about whether you really want to do this. I second that. It is really not smart to have / (or /boot) in LVM if you can help it. I suggest that a small (1GB-4GB) partition for simple md-raid1 be used for / instead. That won't give you any headaches, including on disaster recovery scenarios. I'm currently in my third day of rebuilding a machine that had /boot and / on an LVM volume on raided disks. After one drive died, I ended up in a weird mode where LVM was mounting one of the component drives, rather than the raid volume - with the long result being that I'm reinstalling the o/s from scratch and hoping that my backups are good enough that I haven't lost any user data. If you forget to have THIS on lvm.conf when using software raid: filter = [ a|/md|, r/.*/ ] (or any other combination that makes sure lvm won't ever touch the md component devices) and lvm manages to put its filthy hands on one of the md component devices (e.g. because the raid didn't come up yet, or it was degraded and lvm found the component device first), you're screwed. Oh, and that needs to go inside the initrd as well, if you have / in lvm. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: ECC RAM failure data - jre
On Thu, 26 Feb 2009, ow...@netptc.net wrote: Most of the errors ECC is designed to correct are single bit errors that, upon refresh, are no longer there (soft errors). The usual Nowadays, server memory does a LOT better than single-bit error correction. As an example, see this: http://www.intel.com/Assets/PDF/appnote/292274.pdf -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Is there no way to RELIABLY disable mouse acceleration in Linux?
On Tue, 24 Feb 2009, Dave Ewart wrote: On Tuesday, 24.02.2009 at 06:09 -0800, Daniel Burrows wrote: On Tue, Feb 24, 2009 at 10:55:23AM +0100, Dirk noi...@gmail.com was heard to say: Everytime I start a game the mouse input is accelerated or just messed up... I turned xset m 0 0 into a cronjob now that runs the command 30 times every minute... I would be astonished if running xset in a cronjob did anything. Or that cron can do anything on a time resolution of less than one minute... or that xset m 0 0 (as opposed to xset m 1 1) did anything to disable mouse acceleration in a reliable way... That said, it is know that either KDE or GNOME screws this up and resets it often. I don't know which one (could be both). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: raid multilevel
On Mon, 02 Feb 2009, Thiago Silveira Alexandre wrote: Senhores... estou tentando criar uma configuração de raid multilevel mas estou com um problema. Depois de configurar meus RAID's 1 (espelhamento), tento criar um RAID 0 em cima desses dispositivos RAID's 1 só que da um erro, a mensagem é a seguinte: Não faça desta forma. Não é boa idéia empilhar md em cima de md, alguns bugs sinistros já aconteceram no passado com esse tipo de coisa, e algumas configurações vão colocar você em risco de estourar o stack (por exemplo, md+md+lvm+crypto+xfs). Ou use o raid10 logo de uma vez (recomendado), ou faça duas raid1 diferentes, use como PVs diferentes no mesmo vg, e faça o striping no LVM. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: On battery power, so skipping file system check when in AC power
On Sat, 14 Feb 2009, Clifford W. Hansen wrote: On Saturday 14 February 2009 09:15:46 Virgo Pärna wrote: Does anyone else also receives On battery power, so skipping file system check warning, when starting up a laptop with AC power connected? Especially in Lenny. -- Virgo Pärna virgo.pa...@mail.ee I also get this when on battery power, and it works fine when on AC power. I believe this is actually a good thing cause if you checking your disks and then run out of battery bad things(tm) can happen... It is actually a FUBAR piece of crap, it skips the fscks even when the filesystems are dirty (which is guaranteed to cause a much worse data loss if the filesystem is corrupt), and it causes /forcefsck to be ignored (which is unacceptable). There's a bug open about it, and we're going to fix it one way or the other. We just don't know what would be the best way yet, since fsck can't be told to ignore the fsck after N mounts or M days without a check right now. IMO, we may have to dump the whole idea entirely, and tell people how to tune their filesystems to drop the N mounts or M days stuff. When that is done, the system will fsck only when required. We may keep the battery check as an optional thing that must be explicitly enabled, since it can make a data loss episode a lot worse. And we can certainly provide an alternative way to do rolling fscks after some time has passed if fsck can't be fixed to let us do it the easy way. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Reporte SPAM dentro da lista
On Wed, 21 Jan 2009, Felipe Augusto van de Wiel (faw) wrote: O bounce é o envio da mensagem exatamente como ela chegou pra você mas pra outro endereço de e-mail, ou seja, _nenhum_ dos cabeçalhos é mudado, a mensagem é enviada para um novo destinatário mas o cabeçalho To: e outros permanecerá o mesmo da mensagem original. Bounce adiciona cabeçalhos Sender e derivados em MUAs que não sejam cretinos. Só para constar. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: reinserting USB plug via software
On Tue, 20 Jan 2009, Stackpole, Chris wrote: What commands would be the equivalent to pulling the USB connector out of the computer, waiting a second, and then putting it back in? rmmod uhci-hcd; rmmod ehci-hcd; sleep 1; modprobe ehci-hcd; \ modprobe uhci-hcd (you may also need ohci-hcd, but the above is the most common setup) If you do something stupid with that, like running it with usb-storage filesystems mounted, and the kernel happens to let you do it, you may suffer data-loss. You have been warned. It will bring down (logically) all USB buses, then bring them up again. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: D3 the chip in the firmware restart code?
On Sat, 10 Jan 2009, Memnon Anon wrote: Maybe I should just wait till this is fixed, but nevertheless I'd still like to know what D3 the chip means. Can anyone shed light on this one? Sure. It refers to PCI device power states. D0 is active, D3 is almost powered off (it is not completely powered off because the device's PCI interface will still be powered up and online so that the system can access the device's PCI config space, to e.g. power it up again). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: rkhunter --propupd option-SOLVED
On Sun, 04 Jan 2009, Paul Cartwright wrote: # which rkhunter /usr/local/bin/rkhunter You have a local installation of rkhunter that has nothing to do with Debian, or the Debian package... If you also have the Debian package installed, it might be the reason for your porblems. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: OT: laptop recomendations
On Sun, 04 Jan 2009, Dotan Cohen wrote: 2009/1/4 Henrique de Moraes Holschuh h...@debian.org: Why not the SL line, something special about them? They're IdeaPads. IdeaPad SL? That sounds like a joint venture between Dell and Tampax if I ever heard one. The ThinkPad SL is probably a good enough machine if you're into Microsoft operating systems, and don't want to pay for the really good stuff. But I am not part of the above demographics ;-) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: OT: laptop recomendations
On Sun, 04 Jan 2009, Koh Choon Lin wrote: I would be looking at a ThinkPad for my next laptop and hopefully, comes with full support from a free GNU/Linux distro. Full support? ThinkPad T or ThinkPad X are the best bets. After that, ThinkPad W or ThinkPad R. You are likely to meet an ALPS touchpad if you get a ThinkPad R, though. And BTW, the ThinkPads will waste up to 3W more in Linux than in Windows, so keep that in mind when you look at battery life figures. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: OT: laptop recomendations
On Sat, 03 Jan 2009, Koh Choon Lin wrote: Yes. And don't ever make the horrible mistake of getting any non-ThinkPad Lenovo laptop, nor the ThinkPad SL. The Linux support is non-existant, and it is nowhere near the quality of a true bloodline ThinkPad (models X, T, R, W). Why not the SL line, something special about them? They're IdeaPads. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: OT: laptop recomendations
On Sat, 03 Jan 2009, Koh Choon Lin wrote: If it's any indication then most companies I know work with thinkpads and Dells. Dell have Inspiron and Latitude while Lenovo has Thinkpad and Lenovo models. Would there be a difference in support? Yes. And don't ever make the horrible mistake of getting any non-ThinkPad Lenovo laptop, nor the ThinkPad SL. The Linux support is non-existant, and it is nowhere near the quality of a true bloodline ThinkPad (models X, T, R, W). If you're considering a Lenovo laptop that is not a ThinkPad X, T, R or W, just buy Dell. You'd be much better off. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: udev causing data loss?
On Tue, 30 Dec 2008, ghe wrote: Hmmm. That's an excellent point, and I don't know whether it's mkfs or fdisk that creates the UUID. mkfs. If you need UUID for block devices, use LVM or MD raid (you can have a RAID1 with only one disk). That said, devices often can be identified by (vendor,type,serial number) and udev also generates such nodes. If that's correct, reformatting a partition will (can) invalidate data in fstab and make your machine a real PITA at boot. That is correct. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: How often do the repositories get updated?
On Tue, 30 Dec 2008, Mark Allums wrote: In spite of the general desires of the average user, .28, and .27 kernels won't likely make it into Lenny. (Not bloody likely! might be 2.6.27.y is a long maintenance release, with a few kernel mantainers (not Debian kernel maintainers) already pledged to take care of it upstream well beyond the normal stable kernel lifetime, sort of like 2.6.16.y. So, it will most likely be backported. It is also compatible enough with 2.6.26 that it shouldn't be too horrible an upgrade, even for production boxes ;-) In fact it would have been a much better choice for Lenny than 2.6.26, were it not for the timing (2.6.27.y is only now, after 10 minor releases, starting to be trustable enough to use in production. So, it is way too late to make it for Lenny). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: hard crash on leap second
On Thu, 01 Jan 2009, Paul Cartwright wrote: What time server(s) do you use? ntp.conf shows: server 0.pool.ntp.org server 1.pool.ntp.org server 2.pool.ntp.org server 0.debian.pool.ntp.org server 1.debian.pool.ntp.org server 2.debian.pool.ntp.org server 3.debian.pool.ntp.org server wuarchive.wustl.edu server gilbreth.ecn.purdue.edu server ntp.cmr.gov server clock.psu.edu server constellation.ecn.uoknor.edu server ntp0.cornell.edu Dear deity, don't do that! It is a major abuse of the ntp servers, and it doesn't even work well as your logs clearly show..., so it is not like you're getting anything out of it. Please just use the four debian.pool servers, OR do a proper custom setup using *three* servers close to you network-wise (and with low jitter), and for which you have permission to connect. ntp works best with three to six upstream servers, and an end-user workstation has no business using more than three. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: reading USB port on old Thinkpad
On Sat, 13 Dec 2008, Douglas A. Tutty wrote: If you can't get the thumb drive to work, as for how to get the data off, try setting up networking. I guess that's what you mean by using the e-net cable. Its doesn't happen magically by plugging it in. You have to assign your box an IP address on whatever network you'll be using. Isn't that avahi stuff supposed to make it work magically? It better do exactly that and help our friend just have to plug a cross-over ethernet cable to get his two boxes connected... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: reading USB port on old Thinkpad
On Sat, 13 Dec 2008, ZephyrQ wrote: mix/edit/burn on my home machine. It has a USB port, but I've tried a few things (including some BIOS settings) and I can't get it to read my thumb drives (they work on all other machines, including the linux ones). It does not have a cd-burner on it and I've tried to use the It is old enough that it could be USB 1.0. Not many stuff nowadays will work with it, but you can buy an CardBus or PCMCIA card with USB 1.1 or USB 2.0 ports cheaply. Does your thinkpad have a working CardBus/PCMCIA slot? -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: OT: laptop recomendations
On Sat, 13 Dec 2008, Micha Feigin wrote: 100% is too much for normal work, the battery has a better lifespan if you limit it to 90% or so, but AFAIK this is only possible with (possibly newer) thinkpads. No, it is possible with every non-ancient real ThinkPad. And all new real ThinkPads. WARNING: The Thinkpad SL is NOT a real ThinkPad, so don't buy that one to run Linux. It is completely unsupported (it does have battery charge control in Windows). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: OT: laptop recomendations
On Fri, 12 Dec 2008, Daryl Styrk wrote: My t61 always stops at 96% You have set it to do that (maybe the last time when you ran Windows and the battery life maximizer system decided you didn't really need it at 100%.. it informed you of that, but you might not recall it), and it will retain that setting until you remove AC and all batteries. IBM thinkpads and Lenovo models older than the T61 will power down the EC when they are turned off, and AC is removed. The T61 and everything newer than that apparently power down the EC only if both AC and the batteries are unplugged. A Renesas H8S EC (which is what ThinkPads use since basically forever) draws a few micro watts when in sleep mode, so one can see why Lenovo decided to just not power it down to retain all settings and keep an eye on the battery pack permanently (the battery pack is a SBS battery pack, and therefore also has a microcontroller that is NEVER powered down. In fact, it knows when it was first used, how much of its lifetime it has spent charging and discharging, etc). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Q: List Policy
On Sat, 22 Nov 2008, Ron Johnson wrote: On 11/22/08 06:15, Henrique de Moraes Holschuh wrote: I thought kernel hackers were uber-geeks. How can they not implement decent mail filtering? If you use Mutt, you take upon yourself the responsibility to set up a server-side filter, and if you use a GUI, then setting up client-side filtering is trivially easy. That's an interesting question. I don't have any answers, but my best guess is that, just like Debian will remain a no-CC zone, the Linux kernel MLs have their own long-standing preferences. Like the don't attach stuff, send them in the main body rule, which AFAIK mostly exists because of how many popular MUAs used to behave (and I have no idea if they still do. Mutt, which I use, does the right thing to in-line attachments). I did not start in this thread with this opinion, but after reading it, it was pretty clear to me that to-cc-or-not-cc really is just a preference thing, like vi-or-emacs. Some of the reasons that make a person prefer one over the other will be technical, but there are enough of them on both sides to balance things out back into it is just a matter of preference. Like you can see in other replies to this thread, there are numerous technical ways to make sure you will not miss a message (or have annoying duplicates of it where you don't want them) with or without using Cc:. All solutions for either case (including the one I described) depend on cooperation from your MUA or mail filtering/delivery setup, which translates to not universionally available. As for the kernel hackers being uber-geeks, well, even if they were (I bet many aren't), this wouldn't make them uber-mail-geeks. There is a reason why it was necessary to add a file in the Linux kernel Documentation/ directory about how to configure your MUA to not mangle in-line patches. I believe there is an interesting field of study there. (Of course, even if you use a GUI, if you are a geek you should implement fetchmail/getmail, an MTA, a spam filter and procmail or mailfilter and IMAP, so that you can switch MUAs as easily as you switch underwear, or even access your mail from across the LAN or even Internet. But that's a different topic...) As I said, not everyone thinks this is a worthy use of their time, even if they have the skills to do it ;-) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Q: List Policy
On Sat, 22 Nov 2008, Steve Lamb wrote: Chris Bannister wrote: Quite right, but why discourage CCing on an open list? I can see the point in not CCing on a closed list. For the same reasons. Whether the list is open or closed is irrelevant to the harm that CCing people unbidden causes. A list being open or closed is also irrelevant to the fact that it is incumbent on the sender to ensure they receive replies, capable of finding replies or requesting copies if they cannot fulfill the previous two trivial tasks. Actually, to be very blunt: CCing people is absolutely the only way to deal with massive ammounts of email and very-high-traffic lists when you *care* about not ignoring email that you should have read. If you want an example of a CC policy radically different from Debian's, take a look at the development mailinglists for the Linux kernel and all related projects. There, the policy is that you are to *always* CC everyone that should (or might even remotely need to) get an email, in addition to sending it to the lists. Otherwise, the chances that such an email will be lost in the ocean of stuff, or never reach the right people. IMO the truth behind the CC policy in Debian lists is that it is the policy not to do so for a LONG time now, and a lot of people is bothered by CCs, so they resist any such changes (note: I am NOT judging whether they're right or wrong for doing that, if one could even classify such an issue in that way). IMO, the reason many people are bothered by the CCs is that the typical DM, DD and Debian user just plain don't *care* about stuff from debian-user/-policy/-private/* bothering him all the time. He'd rather ignore it completely until he decides to read that ML folder, if ever. Which is why we *DO* CC people directly every time it is clearly their problem/fault/responsibility. We have entire systems to make sure people can ask automated tools to add them to such cc's, even. But that certainly doesn't cover untargeted ML posts and replies to them. In the end, it boils down to the fact that most people have lame mail filtering setups that cannot sort delivery mailboxes in the right priority and do proper destination-based duplicate supression (so that you can get automated if it is also destined to a Debian ML, file into the ML folder, and have any further duplicates supressed), and are not in any hurry to deploy one. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: OFF-TOPIC O que é e ssa tal de memória FB-DDR2?
On Tue, 18 Nov 2008, Daniel wrote: tipo de memória e os slots livres e ele acusou memórias da Kingston FB-DDR2 PC2-5300 (333 Mhz), mas eu não sei o que é esse FB antes do DDR2. É algum outro tipo de memória?? Liguei na loja e o cara disse que Sobre a FB-DIMM (FB-DDR2): http://en.wikipedia.org/wiki/Fully_Buffered_DIMM Não compre componente de servidor (ou workstation no seu caso) em loja de esquina. Não vale à pena. No seu caso, já que já tem Kingston na placa e misturar memória de fabricantes diferentes é tentar o Murphy, eu ligaria na Kingston do Brasil e compraria direto deles (garantia vitalícia e válida no Brasil). E se prepare, porque essa memória *não* é barata. Leia o manual da placa mãe antes para não tentar uma configuração de tipo e quantidade de memória inválida (ou pouco eficiente). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: udev causing data loss?
On Sat, 15 Nov 2008, Boyd Stephen Smith Jr. wrote: Depends. Stuff in /dev/disk/by-uuid has never lead me astray. However /dev/sd* nodes are named in the order the device is detected by the kernel. It's not like that label is written to the disk. Correct. And hotplug/unplug of SATA, SAS, SCSI, and even hotplug-enhanced PATA will make your device go from sda (unplug+replug) to sde, for example. I believe that disks on a single SCSI bus are always detected in order by increasing SCSI id. However, /dev/sd* also includes USB and SATA devices, Hot(un)plug will hose that. If that is true, how does the user, how does the system know which disk is which one? The user starts using stuff like serial numbers or data written to the storage media to identify it :-) The system has no notion of should be. The system uses the device name you list in /etc/fstab. It's the administrator's responsibility to make sure that's what should be referred to. Indeed. And /dev/sd* in /etc/fstab is NOT an intelligent thing to do with today's hardware. Note that /dev/md* is fine, since md arrays HAVE data stored inside them that makes them go up in the desired place. Personally, I like using UUID= syntax to refer to my devices (/dev/disk/by-uuid doesn't list logical volumes), but it does make the lines in /etc/fstab a bit long. The LABEL= syntax is also a good one. Agreed. It seems I need to read up on this. Is there a good document that explains it? You can start with man udev, then a quick google for linux udev how-to, but I don't really know a definitive document. Nor do I, and we really should have this stuff well documented and widely available. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lenny, apt(titude), dependency issues, seg faults and corrupted .DEB packages
On Sat, 15 Nov 2008, Mark Allums wrote: Memtest86+ is a GPL'd memory testing suite that should work with anything in the i386-amd64 family. Yeah, but it's not actually that good at testing memory. Do you have a reference for that? I do. We never trust memtest negatives unless it has been running for over 48H, we have seen several false negatives. And I have never seen it manage to flag an error on ECC systems. I am not really sure it knows how to deal with every memory controller in use on servers out there, or that it DOES know how to talk right to, say, a i82875 like the one in my desktop. False positives, OTOH, are unknown of. If it says memory is bad, memory IS bad. Of course, it could be bad for a number of reasons, of which a bad memory chip in the module is only the most likely. We have seen it happen due to problems in peripherals that were screwing up with the DC power lines, and due to PSUs (for the same reason). Nope. I also can't find one after a bit of googling. I seem to remember that there were two or 3 people on gentoo-user that were able to find memory errors with a perl script that memtest86 couldn't find. Perhaps those were actually CPU errors with similar symptoms. On x86 (and AFAIK, amd64) it can easily happen due to address aliasing across different cache configurations or due to PCI horkage, yes. It is one of those kernel developer' nightmares. MS's memory tester is pretty terrible IMO, but the memtests are a little It flags errors faster than memtest in the opinion of some of our lab techs. Probably memtest is too conservative in what it does to the platform. better. At least, I was able to find errors with memtest86+ that MS didn't find. (Could have been false positives of some kind, I suppose.) Interesting. I will relay that to our lab people. Probably means they need to do both: 12H under MS, 24H or more under memtest. Ugh. One must always remember to use the latest version, sometimes the newer CPUs and chipsets aren't supported properly and there can be very subtle bugs. Yes, and to always use a verified-good gcc. A miscompiled memtest due to buggy gcc in Gentoo caused a *LOT* of problems sometime ago... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Lenny, apt(titude), dependency issues, seg faults and corrupted .DEB packages
On Sat, 15 Nov 2008, Nick Syrotiuk wrote: Well, it looks like I may have an intermittent problem. Yesterday I removed 2 Gb of memory (2 sticks, 1 Gb each) leaving 2 Gb in the box but I still had problems. It might be your PSU. Today, I booted the machine and I no longer had APT dependency issues. In fact, I can now install packages with ease. I installed memtester, let it run for 1 loop and the results were all okay. Leave it running overnight at the very least. 1 loop really is NOT enough to get the worst types of memory problems, it will flag only the ones where the chip is outright fried. Transient errors are quite possible in SDRAM, and will corrupt your data just the same. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What is the point of RAID?
On Fri, 14 Nov 2008, Boyd Stephen Smith Jr. wrote: On Thursday 13 November 2008, Douglas A. Tutty [EMAIL PROTECTED] wrote about 'Re: What is the point of RAID?': The other thing to consider as that you don't necessarily need the same performance/protection for the whole dataset on a system. Yeah, I can understand that. I use software raid-1 for /boot, software raid-0 for (a) directories I consider owned by package management, so that reinstalling from fast net or local mirror solves that problem and (b) throw-away data like /var/tmp, and hardware raid-5/6 (depending on # of drives) for real data like /home, /srv, /var, etc. At which point you might as well use two or more swap partitions with the same priority (and _not_ on top of a raid device), to get high-speed swap as if it were raid-0'ed. After all, a single drive crash WILL bring your system down anyway... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Electricity Cutoffs, EXT3 and Filesystems
On Sat, 08 Nov 2008, Volkan YAZICI wrote: On Sat, 8 Nov 2008, Henrique de Moraes Holschuh [EMAIL PROTECTED] writes: Is your storage sane? Or is it el-cheap-o crap that lies about when data really made it to the permanent media? Default IBM System x3650 configuration. (SAS disks.) Definately should not lie about flush cache being completed... hmm... -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Electricity Cutoffs, EXT3 and Filesystems
On Sun, 02 Nov 2008, Volkan YAZICI wrote: EXT3, I started to use EXT3 in those new servers. But unfortunately, after every electricity cutoff[1], EXT3 just crashes and waits prompt from me standing at boot. I start the servers with Knoppix (Gee!) and Is your storage sane? Or is it el-cheap-o crap that lies about when data really made it to the permanent media? [1] Yes, we have couples of UPS boxes around, but they are not capable of standing the load for many hours. And yes, this is Banana Make sure to have the UPS tell the load it needs to shutdown because the battery level is too low. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: What is the point of RAID?
On Fri, 07 Nov 2008, Mike Bird wrote: systems have RAID / and RAID /boot. Some have RAID swap, although there are performance tradeoffs to be considered for RAID swap. Well, I hope you ARE aware that the box will lock up hard or panic if anything happens to the device hosting the swap AND it needs to swap in or out. Better to swap to file inside the RAID array, or to not have a swap partition at all, if you are not going to protect it. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: problema com amavisd-new
On Wed, 05 Nov 2008, Felix Costa wrote: No inicio também achei estranho, pois apensar de sempre utilizar Debian em servidores de clientes, costumava baixar o fonte do amavis e instalar manualmente. Bom, eu quem fui o autor da coisa, e basta dizer que o amavisd-new estaria sem maintainer se eu não tivesse feito isso. Ficou MUITO mais fácil manter o pacote, apesar que ainda é um porre atualizar apartir dos diffs do upstream antigo pro novo e faz um tempo que tem outro DD cuidando disto. Mas depois que você se acostuma fica mais fácil, tudo que você tem a fazer é adicionar suas configurações personalisadas no arquivo 50-user. Exatamente. Quando a voltar a utilizar o bom e velho amavisd.conf já não poderei ajudar. É só copiar no diretório, com o prefizo zz- ou 99- para ser lido por último. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OT] cipsga.org.br fora do ar
On Sat, 25 Oct 2008, Marco Carvalho wrote: Alguém tem notícia do que pode ter acontecido com os servidores de DNS do cipsga.org.br? Os dois estão aparecendo como timeout: nserver: celepar1.cipsga.org.br nsstat: 20081022 TIMEOUT nslastaa:20081020 nserver: cipsga.ima.sp.gov.br nsstat: 20081022 TIMEOUT nslastaa:20080731 Com isso todos os sites hospedados no CIPSGA estão fora do ar, como por exemplo, o Guia Foca Linux. Do cipsga.ima.sp.gov.br, posso cuidar, e está no ar... Não programamos nenhum downtime para aquela máquina... E que eu saiba, ela é DNS do CIPSGA, então pelo menos metade deveria estar no ar (ou seja, lento mais funcionando se for o segundo DNS na lista de busca)... e está. Mas se a celepar1 não entrar no ar logo, vai expirar o cache da ima.cipsga.org.br, e sai tudo fora do ar de vez. Se alguém tiver contato com o Gleydson Mazioli ou com o Djalma Valois e puder ver o que está ocorrendo... Vou ver isso. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: ACPI power management broken since 2.6.23-1
On Sun, 19 Oct 2008, Anton Piatek wrote: Kernel 2.6.23-1 is the last kernel I seem to be able to run and have my laptop go to sleep. I am trying to figure out what i need to do to make the newer kernels sleep, but am a bit stuck. Can anyone give me some pointers to try and figure out what I might be missing to make it work? I admit I don't entirely understand how ACPI works... It helps wonders if you tell us what laptop you have (and a major hint: upgrade your laptop BIOS and firmware if an update is available from the vendor). Also, what is wrong with the sleep? Is it the sleep? Is it the resume? What happens that is wrong? If the screen is black, is the machine still alright but just with the backlight turned off? What is in the kernel log when the sleep/resume breaks? etc. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Filing bug reports in Debian (was Re: Debian Stole My Name!)
On Thu, 16 Oct 2008, Hal Vaughan wrote: 1) I'm a writer by avocation. Honestly, it's much easier for me to write a 5,000 word email than a 500 word one. I'll refer you to Churchill's quotation about how long it would take him to write a long speech vs. a short one. Have that added to your signature. Most people around here will assume you spent a lot of time writing many words instead of actually doing something about whatever the issue you are writing about is. And, as you noticed, that is detrimental when you want to make (or convey) a point of view, here. As for the send a patch, well, it is still true even if you are a writer: Write a proper, consise text that we could add to the BTS cover pages and to reportbug, explaining why Debian cannot deal well with the BTS being used as a help-desk. In that text, make sure to point the user to the proper channel for help-desk-level reports (i.e. the debian-user* mailinglists). File a bug against the package bugs.debian.org with that text, priority wishlist. THAT would improve things, I hope. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Hard Drive Spin Down
On Thu, 16 Oct 2008, Sam Leon wrote: Hmm, sounded like a good idea but with the drive unmounted and spun down, it still spins up right before a shut down or a reboot. :( Hmmm, very puzzling. I'd ask lkml. Not puzziling at all. Most HDs have utter crap inside that is too dumb to flush caches that are already flushed without waking up, and which is too dumb to wake up without spinning up the platter. Try actually hot-unplugging it from the logical bus (I don't mean unplugging it physically). hdparm can do it for ide (but it is NOT safe on all setups, do it on your own risk). If it is SATA or, it is PATA on a controller that is handled by libpata (i.e. the disk shows up as if it was a scsi disk, i.e. /dev/sd*), then you are supposed to be able to hotunplug safely using scsiadd -r, for example. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Filing bug reports in Debian (was Re: Debian Stole My Name!)
On Mon, 13 Oct 2008, Chris Bannister wrote: You have raised some interesting points. If you consider the BTS as a help desk, then I think you will be sorely disappointed. It seems that to file a bug report the submitter first has to research the problem, try and resolve it, and if possible, to provide a patch. I, too, am interested in other peoples views on this. You are correct. The project as a whole simply doesn't have the manpower, and often, the inclination to deal with helpdesk-level issue reports on the BTS (they should go to the mailinglists instead). Oh, there might exist exceptions, and I hope that most maintainers would try to handle any sort of BTS report, as long as there aren't too many of them showing up or a big backlog... but if the maintainer is overworked, he is likely to ignore such reports, or to be very terse (which people, expecting to get attention and help on the issue their raised, will ALWAYS take the wrong way) when replying to them. Helpdesk-level issue reports (i.e. one where there is still a huge ammount of non-package-specific detective work to be done to narrow down the problem) really ought to go to the user mailinglists or to the forums. There, it can be shaped up into a more precise issue report, and finally go to the development mailinglists and/or the BTS. Maybe this is not the nicer way things could work, but given the constrains in which Debian operates, the mailing lists are where we have more attention and human resources to help deal with something. I wish we could get this information out to people better, it is clear to me that we don't do it well enough. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: High frequency of laptop drive load/unload cycles: is Debian affected?
On Fri, 19 Sep 2008, Kumar Appaiah wrote: In short: is a default Debian installation affected by this bug? (I know I am not affected, but just wanted to make sure...). Yes. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: High frequency of laptop drive load/unload cycles: is Debian affected?
On Fri, 19 Sep 2008, Kumar Appaiah wrote: On Fri, Sep 19, 2008 at 1:35 PM, Kumar Appaiah wrote: In short: is a default Debian installation affected by this bug? (I know I am not affected, but just wanted to make sure...). Sorry, the question is made irrelevant now, thanks to this: (fixed bug): http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=448673 Ah, I thought you mean this one: http://www.thinkwiki.org/wiki/Problem_with_hard_drive_clicking where the BIOS itself keeps enabling the APM mode of the drive. I'd guess on the newest boxes, that will happen only if the kernel (libata with ACPI support) does not filter out the APM commands from the stream of crap the BIOS wants the ACPI OS to feed to the drives. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: System clock malfunction
On Sun, 07 Sep 2008, Girish Kulkarni wrote: On Sun, Sep 7, 2008 at 9:04 PM, Andrei Popescu wrote: You mean the BIOS shows the correct *local* time? In case you don't run Windows on the same machine you should set it to UTC and let Debian handle the time difference. Just make sure you have the right time zone by running 'dpkg-reconfigure tzdata'. Otherwise you should tell it that your clock is set to local time (via /etc/default/rcS). Oh, THAT simple?! Thanks Andrei and Michael. I do have 'UTC=yes' in /etc/default/rcS while my BIOS shows local time (IST). I don't run any other system on this laptop so decided to change the BIOS time (after reading http://bugs.debian.org/346342). It gets better. If your RTC is in UTC, you can remove the initscript calls for hwclock in the S runlevel, and get a marginally faster boot, too. Recent kernels know how to read a RTC in UTC and set the initial system time all by itself (although you may want to test for it first: look for this in /var/log/dmesg: setting system clock to). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: System clock malfunction
On Mon, 08 Sep 2008, Andrei Popescu wrote: On Mon,08.Sep.08, 11:55:24, Henrique de Moraes Holschuh wrote: [...] It gets better. If your RTC is in UTC, you can remove the initscript calls for hwclock in the S runlevel, and get a marginally faster boot, too. I have two scripts linked in rcS.d/ hwclock.sh and hwclockfirst.sh. Can I disable both? Yes. But not the ones on rc6.d and rc0.d. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Oddity In stty
On Sun, 31 Aug 2008, David L. Craig wrote:
On Sun, 2008-08-31 at 17:35 -0400, David L. Craig wrote:
I can't figure this out. Why does the first pipeline suceed but the second
fails?
I'm running an up-to-date Sid.
[EMAIL PROTECTED]:~$ fold -w `stty -a | head -1 | awk
'{print $7}' | tr -d ';'` /dev/null
[EMAIL PROTECTED]:~$ cat /dev/null | fold -w `stty -a | head -1 | awk
'{print $7}' | tr -d ';'`
stty: standard input: Invalid argument
fold: option requires an argument -- w
Try `fold --help' for more information.
[EMAIL PROTECTED]:~$
Well, I figured out a way around it: stty -a /dev/tty
Solaris behaves similarly. I'm surprised this isn't
documented behavior.
You can file a wishlist bug against coreutils, asking for the documentation
update...
--
One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie. -- The Silicon Valley Tarot
Henrique Holschuh
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a work-around for a umask bug in rssh/chroot ??
On Tue, 26 Aug 2008, Bob Goldberg wrote: running etch; rssh/chroot with users allowed sftp only I have my umask=007 in my rssh.conf; I have setgid=true on all home dir's. When a user uploads a file, that file does NOT have mode=660 as I would expect - instead it's 640. Did you check that the code is trying to create the file with file mode 777 (so that umask has full control of what will end up on the inode)? If it does, e.g, 644, your umask will never be able to get a 660 out of it. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Is there a work-around for a umask bug in rssh/chroot ??
On Wed, 27 Aug 2008, Bob wrote: On Aug 27, 9:00 am, Henrique de Moraes Holschuh [EMAIL PROTECTED] wrote: On Tue, 26 Aug 2008, Bob Goldberg wrote: running etch; rssh/chroot with users allowed sftp only I have myumask=007 in my rssh.conf; I have setgid=true on all home dir's. When a user uploads a file, that file does NOT have mode=660 as I would expect - instead it's 640. Did you check that the code is trying to create the file with file mode 777 (so thatumaskhas full control of what will end up on the inode)? If it does, e.g, 644, yourumaskwill never be able to get a 660 out of it. Henrique- TX for your reply... I'm not sure I understand where I would look for that... because this is a chroot'ed user, and they can only use sftp thru rssh - I had thought the mode settings associated with those packages would over-ride any others... now if a normal user creates a file - it IS 644... is that what you mean? What I mean is that Umask can only *CLEAR* bits. If sftp/rssh is trying to create a file of mode 0644, all your 0777 umask can do is cause it to become 0640. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Benefits (and risks) of using Sid
On Tue, 05 Aug 2008, andy wrote: This is just a general enquiry about the benefits of using Sid on a desktop or a workstation. Aside from obtaining up-to-the-minute software (and related patches), are there any other benefits to using Sid? I am Yes, but none that you can't get also from using testing and fetching whatever extra packages you need ASAP directly from Sid. aware of the risks - i.e. frequently broken applications - but to be honest, how often does this happen? Often enough. Really. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: 2.6.26 Kernel
On Fri, 25 Jul 2008, Andrei Popescu wrote: On Fri,25.Jul.08, 19:12:37, Thilo Six wrote: Dale wrote the following on 25.07.2008 17:49 Does anyone here have a idea what the eta is on Debian getting the 2.6.26 Kernel into unstable? Regards Dale There has been a discussion about that this week on -release. Search for :imminent 2.6.26 sid upload and 2.6.25-2 testing sync threads. A quick info for those who don't want to search the archives: kernel team wants to have .26, but release team wants to have some testing in unstable before ack. Sid users, test .26 ASAP ;) It is broken. The pile of fixes for 2.6.26.1 (and maybe 2.6.26.2) is huge. As expected. The safe thing to do is to remain on 2.6.25 for now. .13 has just been released, and .14 should be around the corner, since there is at least one important patch pending (which is also needed on 2.6.26 and 2.6.24, so even Etch 1/2 has the bug). It is probably best to just use 2.6.25 for Lenny. It is a very good kernel. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OFF] Calendário com visão anual ou semestral
On Sat, 19 Jul 2008, Ronaldo Reis Junior wrote: alguem conhece algum programa tipo agenda ou calendário com visão anual ou semestral? Algo que eu possa por exemplo colorir os dias para determinar webcalendar. http://www.k5n.us/webcalendar.php -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firefox 3?
On Thu, 03 Jul 2008, Ron Johnson wrote: Really? So far all has worked well for me. Or the errors have been too subtle for me to notice... Errors rendering fonts (size varies by 1px on various characters, it gets the height wrong on the address bar so you see only part of the characters sometimes), and random crashes -- this is 2.0.0.14 with xulrunner from Sid, i386. When you add the 3.0-rc2 (3.0 proper is not there for i386 yet, at least it was not there yesterday), you may get so many crashes, the thing won't even start. I am holding xulrunner and iceweasel pinned to 1.8 and 2.0.0.14 everywhere I can. At least for i386, xul 1.9+iceweasel 3.0-rc2 (Debian packages) are useless show-stoppers. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: terminal resize doesn't propagate to an application
On Tue, 01 Jul 2008, Ron Johnson wrote: IIRC, there's a (Debian-specific?) bug in ncurses regarding WINCH. Is it reported? That's an extremely annoying bug that is asking to be stomped with extreme prejudice... If you're running under su, it hits really really often. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: terminal resize doesn't propagate to an application
On Tue, 01 Jul 2008, Thomas Dickey wrote: On Tue, Jul 01, 2008 at 09:20:14PM +0200, Henrique de Moraes Holschuh wrote: On Tue, 01 Jul 2008, Ron Johnson wrote: IIRC, there's a (Debian-specific?) bug in ncurses regarding WINCH. Is it reported? That's an extremely annoying bug that is asking to be stomped with extreme prejudice... If you're running under su, it hits really really often. If you're su'd, signals generally are blocked. Even WINCH? That's surprising (to me, anyway). I just tried it and it seems to be working somewhat fine here (current Lenny, bash running in a xterm), in fact I didn't manage to trigger any WINCH-related bug while testing it, everything resized properly. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OT] the limits of googling
On Sat, 28 Jun 2008, Hugo Vanwoerkom wrote: What are the most recent laptops that run Linux *and* have a working analog (RJ-11) modem installed? Most thinkpads do have a built-in HSF (controller-less) V92 modem as an optional item you can ask while customizing it. I am not sure of the X300 or X61, but the T61 really should have it. Network is acting funny here, or I'd go to lenovo.com and custon-build a X61, T61 and X300 to check. I do know the T60 and T43 did have modems. My T43 has one, works with the Linuxant drivers (yes, binary only. I rarely use it, but the driver works well enough for emergencies, and the modem does V92 and Class 2 Fax properly). PS All the searching I have done lead me to believe that they don't exist. But how do you prove that with Google? They do exist. Google, as you said, isn't perfect. V92 modems are the kind of stuff that makes more sense to exist in a USB or ExpressCard form factor nowadays, though. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OT] the limits of googling
On Sun, 29 Jun 2008, Owen Townend wrote: I had this same issue when they started phasing out RS232 ports from laptops, the solution for me was to use a usb adapter. I believe the I am in the same boat. Lenovo is asking (through a pool) what ports are nice in a laptop, you could vote on the RS-232 as I did. The poll is in Lenovo's excellent Design Matters blog. Drop the parallel port, and you have enough real state for a RS-232 in DB9 format, and 4xUSB. Failing that, even a RJ45-format RS-232 port would be nice... However good those USB-serial adapters are, I have never found one that could speak all speeds properly, which can be VERY annoying on the field. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: making bootup fsck more user-friendly
On Fri, 13 Jun 2008, charlie derr wrote: Henrique de Moraes Holschuh wrote: On Fri, 13 Jun 2008, Johannes Wiedersich wrote: I guess the defaults are very conservative settings regarding reliability of your data and were implemented at a time when there was no journalling for data protection. Actually, kernel bugs, memory problems, corruption in the CPU to disk platter path, and media bitrot are the reasons for which scheduled fsck exist. Journals don't help or hinder it in any way. Otherwise, you'd fsck only on unclean shutdown, or after a known data-trashing event (like an erroneous write access to the raw device, or IO errors on the device, etc). I'd love an explanation about why only certain filesystem types seem to need this fsck as a regular event. Maybe I've got some details wrong, The only thing that makes periodic fsck rarely needed is a filesystem which uses strong enough CRC or ECC to protect ***all*** of its metadata, and for those with logs and journals, this ALSO requires it to deal properly with all possible failure modes for replay (otherwise it will corrupt itself). You'd still need to fsck it every time you suspect of kernel bugs in the filesystem code. A filesystem that does live fsck (not just data integrity testing, but an actuall full filesystem metadata integrity check like fsck does) is just doing the periodic fsck for you anyway, so it doesn't count. As an example: XFS has extremely well made test suites that SGI runs on the code in the kernel, so bugs (nowadays) are very rare in mainline *releases* (not -rc!). That doesn't mean your hardware will take care of the data XFS entrusted to it as it should have. We are NOT using it on high-end SGI hardware, after all. AFAIK, none of the for-production filesystems have full metadata protection yet, or live fsck capabilities. But I really might be wrong about this, so let's see if someone who knows better can point us to filesystems with that feature. But DO note that you can't have it both ways. The more resilient and safe a filesystem tries to be, the SLOWER it will have to be in order to enforce that. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: making bootup fsck more user-friendly
On Fri, 13 Jun 2008, Douglas A. Tutty wrote: On Fri, Jun 13, 2008 at 02:32:29PM -0300, Henrique de Moraes Holschuh wrote: Your / should be small, fsck-friendly, and resilient as all heck. If running fsck in your / takes enough time that you wouldn't afford to do it at every boot (in a recent system), then your / is too large in my book. The same holds for any other partition you can't easily umount to fsck in maintenance mode. Agreed. / only needs to be 300 MB or so with a separate /boot (if needed for the hardware). / with /boot easily fits in 512 MB and takes only a few seconds to fsck with ext3 and with data=journal still runs pleanty fast. Watch out that data=journal. It is far more kernel-bug prone than data=ordered, for the simple fact that almost everyone uses data=ordered, including those who mess with the ext3 code, so bugs can hide in the data=journal code paths a lot more easily. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: making bootup fsck more user-friendly
On Sat, 14 Jun 2008, Douglas A. Tutty wrote: If data=journal is subject to kernel bugs then you are saying that Linux doensn't have any filesystem suitable for non-UPS-protected systems. If Neither will be safe against that, unless you have write caching disabled OR write barriers enabled, and working right on the HBA (host/port controller) and disc/storage. It IS possible that data=journal should be safer in theory for certain operations, but I don't know enough about ext3 behaviour to answer that one. the devs don't properly audit the data=journal code then they shouldn't provide it as an option in a production kernel. It is as audited as the data=ordered code. It is less *used*. If you think this is even worse, you're right. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: making bootup fsck more user-friendly
On Fri, 13 Jun 2008, Johannes Wiedersich wrote: I guess the defaults are very conservative settings regarding reliability of your data and were implemented at a time when there was no journalling for data protection. Actually, kernel bugs, memory problems, corruption in the CPU to disk platter path, and media bitrot are the reasons for which scheduled fsck exist. Journals don't help or hinder it in any way. Otherwise, you'd fsck only on unclean shutdown, or after a known data-trashing event (like an erroneous write access to the raw device, or IO errors on the device, etc). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: making bootup fsck more user-friendly
On Fri, 13 Jun 2008, John Allen wrote: Use XFS, and it won't fsck when you boot :) Yeah, instead that stupid idea from SGI [fsck.xfs is a no-op] will require you to boot from another media to do a periodic xfs_repair on / if you want to make sure it is a proper xfs and not some corrupted mess that will eventually crash hard and cause massive data loss. For the other partitions, XFS is fine and often the best choice. But for the root? It is a Bad Idea. Your / should be small, fsck-friendly, and resilient as all heck. If running fsck in your / takes enough time that you wouldn't afford to do it at every boot (in a recent system), then your / is too large in my book. The same holds for any other partition you can't easily umount to fsck in maintenance mode. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID suggestions?
On Fri, 28 Mar 2008, Stephan Seitz wrote: On Thu, Mar 20, 2008 at 10:41:27PM -0300, Henrique de Moraes Holschuh wrote: Then DROP the idea of hw-raid. Get a damn good SATA/SCSI/SAS HBA, and use software raid. BTW, damn good means no VIA, SiS, nVidia, or other el-cheap-o half-broken SATA Can you give some examples for a good SATA HBA? No, sorry. Usually the ones with the latest SIL devices, or those with hybrid SAS/SATA bridges are good. While I???m quite convinced that software raid is more flexible than hardware raid (at least for RAID 1), I know that I can do hotplug stuff with my 3ware (or the PERC 5/i in our Dell servers). And the last time I A 3ware board is probably a damn good SATA HBA when in JBOD mode... checked with the kernel SATA support, hotplugging disks was not very well supported. Hmm? It works perfectly, it just complains a damn big lot if you hot-remove a disk *without* issuing a command to detach it from the logical SCSI bus first. What is damn bad is that any late interrupts from the SATA HBA, regardless of the reason, may cause the kernel to kill an IRQ line, and send the entire system into a spiral of ugly death. This is a general Linux issue re. interrupts, though. Maybe MSI-capable HBAs avoid this Linux shortcoming... Note that *any* PCI board using normal PCI IRQs are affected, this includes any HW RAID card. Only, HW RAID cards have something else between the SATA bridges and the host, which will usually eat up stray interrupts :-) With my 3ware controller I can use tw_cli or the GUI to rescan for a new disk or to remove it and I use this feature for backup. How would I do this with a ???normal??? SATA controller? Using the Linux SCSI layer, and mdadm. Look for the scsiadd and mdadm manpages, and also read the documentation on SCSI sysfs (which can do what scsiadd does using IOCTLs). Udev can be used for hotplug notification (insertion). The hot-UN-plug is the problem, the system doesn't differentiate it from a disk gone bad yet, IME, so you have to scsiadd -r the disk before you pull it out. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: disassembling machine code
On Fri, 21 Mar 2008, Daniel Burrows wrote: On Fri, Mar 21, 2008 at 01:39:09PM +0100, [EMAIL PROTECTED] was heard to say: On Wed, Mar 19, 2008 at 12:26:19PM -0700, PETER EASTHOPE wrote: [removed] I did not write this email. I don't have any problem with it, but I didn't write it. Whoever did: please refrain from forging other people's email addresses in your From header. Mutt may be a lesser piece of crap than most mailers, but it is still a piece of crap. It screws up when From: is missing, and acts as if you had send it. Please verify if that's what happened, and file a bug if you verified it. My ability to reportbug is very hampered right now (main workbox is down). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID suggestions?
On Tue, 18 Mar 2008, Luke S Crawford wrote: What we are looking for here is a good enough raid solution... something that costs significantly less than completely duplicating the $800 server or workstation in question, (meaning most good raid solutions you Then DROP the idea of hw-raid. Get a damn good SATA/SCSI/SAS HBA, and use software raid. BTW, damn good means no VIA, SiS, nVidia, or other el-cheap-o half-broken SATA There is no middle-ground in hardware raid. Either get the realy good stuff, or don't use it for RAID. You can probably get a middle-level hw-raid card, and use it as JBOD for Linux software-raid. This is useful especially for SATA. When doing software RAID, *DO* use mdadm array checks daily, or at the very least a SMART long test daily. This is all the protection you have against bit rot causing a non-recoverable mess in your array when you lose a disk: you have to find bad sectors early, and refresh them. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RAID suggestions?
On Tue, 18 Mar 2008, Gregory Seidman wrote: See, here's the thing. That I in RAID is for inexpensive. The idea is to increase reliability on the cheap. You could engineer an amazing HD with a Err, the I is for inexpensive *DISKS* not an inexpensive ARRAY CONTROLLER :-) be hideously expensive. Unless you are using RAID to improve I/O rather than for redundancy, putting expensive hardware into the equation defeats the purpose of a RAID in the first place. If you need redundancy, you need some level of failure tolerance, AKA resilience. Inexpensive RAID controllers will not give you enhanced resilience at all, they cause data-loss really easily. Some are so crappy, they completely destroy the write-ordering and ignore any cache-flush barriers issued by the O.S, and thus are much worse to your filesystem integrity than using a single disk would be in a scenario where you don't have a full disk failure. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: system is going crazy with disk-head parking
On Sun, 16 Mar 2008, tom arnall wrote: well, i did 'hdprm -B 255' and let the thing sit overnight. the next day the number of load cycles was ~300 as best i can remember. did the same thing with same results for 'hdprm -B 254'. You must make sure something else is not resetting it (like a thinkpad BIOS). Search for HD APM in http://www.thinkwiki.org for details on when a BIOS would usually do this. Read the linux-thinkpad mailinglist archives (its address is in the mailinglists page of http://www.thinkwiki.org) for more details. It is also useful to know which HD, and in which platform (motherboard/laptop) you're having problems on. Also, make sure you are running the latest BIOS released by your vendor. Oh, and if it is a thinkpad HD, *check for the availability of HD firmware upgrades*. Although, by now, it looks like your driver has spent 90% of its designed head unload lifetime, so I'd just call in for a replacement under warranty (complain it is making strange noises too often -- it is not a lie, as it will be making click noises due to the constant head unloading) if possible. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [OT] ATX-PSU and amperage on connectors...
On Thu, 21 Feb 2008, Michelle Konzack wrote: I am designing (with the help of Dallas/Maxim, NXP and LM) new DC-ATX- PSU's (with 24V DC entry to use it in Photopholtaik-Systems) and was searching for the amperage of the connectors of an ATX-PSU. Well, I recommend you go to extreme levels of output harmonics filtering, that alone will increase system stability a damn great deal. Some tests using memory bit-rot testing a few years go (either by Ars Technica, or Tom's, I don't recall) nicely illustrated why one would want to do so. And don't think for a single moment that you are designing for linear loads. Computers are [EMAIL PROTECTED]@[EMAIL PROTECTED] unhelpful loads, and the more efficient the power-saving features in use in a system, the worse its load profile is when it comes to harmonics. Does anyone know, where I can get the specifications for it? Yes. http://en.wikipedia.org/wiki/ATX, look at the external links section. and what about the SATA and old HDD connectors? Look for the SATA and PATA specifications, they are not ATX-related. How many ampers must a cable support? Cable choice depends on cable length, and acceptable voltage drop at given load levels. And you need to factor in in-rush and start current too if they are non-trivial (and they are non-trivial for disks, fans, and anything with high-drain CPUs or huge ammounts of RAM). If you want to ask why I need more or less exact values I respond: If you play the el-cheap-o game with the cables and electronics, you will get nice surprises when your systems face their first thermal challenge on the form of an unusual hot (or cool) day. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Where do you put your swap partition?
On Mon, 21 Jan 2008, Andres Migliazzo wrote: As far as now we have advanced in discussing where the swap partition should be (the location on the hard disk)... or even if is convenient to have a swap file or a disk partition... Are we in conditions to make a wrap up and a close up conclusion? Sure. 1. It is valid to have a swap partition, if you need swap space: they are much easier and faster to encrypt, and safer for hibernation or crash dumping. The trade-off is flexibility: it is easier to resize a file. If you never encript, hibernate, or crash dump to swap, you might as well use a file. 2. If the system pages enough for the swap partition's location to make a difference, you should try for more RAM when possible. With that in mind, it doesn't matter much where in the disk you place it, and using files would be just as fast. 3. The fastest area of a disk is vendor/model dependant due to sector alocation policy across platters (and one can look for it using dd or something else that gives you the read speed). If you care about it, measure your disk. 4. Place the swap area closer to the partitions of the disk which are used the most. Reducing head travel speed pays off a lot more than bothering with plate write speed. 5. Excess of swap space is better than too little, since disk is cheap. That said, you only really need as much swap as you will use in modern Linux, you don't have to resize it because you got more RAM or anything like that (unless you use it for hibernation). But more swap space lets the kernel play some performance enhancement tricks with it. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Where do you put your swap partition?
On Mon, 21 Jan 2008, Thomas Flaig wrote: Am Montag, 21. Januar 2008 15:50 schrieb Ron Johnson: On 01/21/08 03:16, Thomas Flaig wrote: Am Samstag, 19. Januar 2008 03:30 schrieb Ron Johnson: I think it's foolish to have a swap *partition* in the 21st century. But there are other reasons for a swap partition in the 21st century: You miss the distinction between swap partition and swap *file*. Ok: But I don't, and I really prefer a swap partition. It is much easier and faster to encrypt it to an ephemeral 64-bit blowfish key (fast, good enough for my modest security needs) using dm-crypt than to use an encrypting filesystem. Of course, if you never need swap anyway, then by all means just disable it. But there are a lot of usercases that ask for swap space, and there is nothing ridiculous about them. Many of which do include up-to-date hardware with a lot of RAM (working with 16GB datasets on a current 4GB laptop while travelling to a conference, for example!). There is also the space you need for hibernation, which is far safer to keep well away from live filesystems, so abusing the swap partition for this is a common choice. * There are some Un*x-like operating system which are able to save system dumps on a swap partition for debuging after system crash. Which un*x-like operation system can do this with a swap *file*? Recent Linux can. And it can do a *lot* more, actually. See Documentation/kdump/* in the Linux kernel tree. CONFIG_PM_STD_PARTITION=/dev/sdaX Does this also work for a swap *file*? Or do I need a swap partition? It can be made to work on files, yes. At least if you use tux-on-ice, which is moderately more sane than that userspace suspend thing. Not that the resume from hibernation in Linux is sane on ACPI systems (it is NOT), so I have to recommend sticking to sleep-to-RAM unless you really need hibernation. And protecting the hibernation data properly is a pain that requires passphrases, anyway, so that's two reasons to stay away from it. If it works with a swap *file* I would like to see an explanation how to do this or a link to a HOWTO. Stock userspace suspend might not be able to hibernate to a swap file. But check http://www.tuxonice.net/, it can do it. -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Where do you put your swap partition?
On Mon, 21 Jan 2008, John Hasler wrote: Ron Johnson writes: So, if a year down the road, you add more RAM and commensurately want to increase the swap space, you're stuck. Adding memory is not a reason to increase swap. No, but if you use the swap partition for hibernation, you might find yourself in trouble if Murphy hates you, even if you do use LZMA compression on the hibernation image. Otherwise, yes, in a modern Linux system, you really just need as much swap as you might need *extra* virtual memory. But more swap lets the kernel play some performance tricks (as in don't drop something from swap unless that data is invalidated). -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
