Re: simple way to securely destroy deleted files in a file system
Take a look at shred (coreutils), wipe and secure-delete. -t -- 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/4c3f4fd1.50...@stammed.net
Re: installing a second hard disk?
Charles Kroeger wrote: My question was since this backup is on an ext3 formatted USB stick, if my hard drive was reformatted with ext4, could the backup [image] on the USB stick be 'copied' back to the new ext4 partition, without problems, as it were. If that software is filesystem agnostic, it will obviously require you to wipe out the ext4 filesystem to copy the saved ext3 filesystem back. As we said already, you can then upgrade the ext3 filesystem to ext4. Alternatively, you can find a way to mount the image with a loop device in order to copy the files from the saved filesystem to the new ext4 filesystem. Since you're using proprietary software, I must note that you might have a hard time with this alternative solution. You should get better help from that software developer. -t -- 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/4c396804.4080...@stammed.net
Re: installing a second hard disk?
Charles Kroeger wrote: If you had an image of a partition that used the ext3 file system and tried to install this image unto a freshly partitioned hard drive with an ext4 file system, would the image be destroyed or corrupted? I'm sorry I really don't understand, please define what you mean by installing the image. Random guesses: - If you want to restore the image then upgrade the ext3 filesystem to ext4, there's no problem; you can find some procedures around the net, although generally just mounting the filesystem as ext4 will do the trick. Note however that only newer files will take advantage of most ext4 features (extents,..). - If you want to restore the ext3 filesystem image in a separate partition than the one containing the existing (and new) ext4 filesystem, then there's no problem either, you can mount any filesystem on any other filesystem, as long as they have enough POSIX features (AFAIK). -t -- 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/4c38d9aa.4020...@stammed.net
ext3 to ext4 conversion
Charles Kroeger wrote: My question is if the hard drive is reformatted with the ext4 file system and I re-install that 'image' [ext3 file system] will the data be corrupted? This doesn't really help, I'll assume you just want to convert your ext3 filesystem (saved in an image file) to ext4. You have two possibilities: - Upgrade the existing filesystem[1]. - Create a new filesystem and copy the files into it[2]. 1: https://ext4.wiki.kernel.org/index.php/Ext4_Howto#Converting_an_ext3_filesystem_to_ext4 2: Use Alan's instructions to mount the image file with a loop device, and copy them in your new ext4 filesystem. -t -- 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/4c38fa58.6050...@stammed.net
Re: [info] grub2
Bob Proulx wrote: Well... If you (and Camaleón) feel that strongly about it then discussing it here should just be a launching point to taking the discussion to upstream. Don't be shy about giving them feedback! Otherwise how will they know? I am sure they will have considered this already but every vote is going to help sway them over to your way of thinking. However I would expect that in return they would try hard to get you to upgrade. They could do that, but I personally don't think it makes much sense. Distributions that are still using grub1 should also distribute its documentation - at least Debian does (see the grub-legacy-doc package). -t -- 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/4c38fca8.5040...@stammed.net
Re: installing a second hard disk?
Just plug it in and format it. If it's not supposed to be bootable and you only plan to format one block device on it (a filesystem, a physical volume, an encrypted volume, ...), you don't have to partition it (I usually don't) although some software *might* get confused by disks without labels. If you're going for one, consider GUID instead of DOS partition tables (look for GPT). There's a hell lot of confusion about ext4, so I wouldn't trust much recommendations unfortunately, you might want to dig the facts for yourself. You can find many other ext3 vs ext4 threads here and there if you really want to read those debates, just make sure to double check the facts and see if the discussion is recent enough. I personally use ext4 without hesitation, for what it's worth. If your question was more related to the layout of your setup, feel free to give us more information about what you want exactly. If you wanted some pointers about the tools you should use to accomplish this, please say so. -t -- 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/4c37ee37.5020...@stammed.net
Re: Key logger
Andre Majorel wrote: Can anyone recommend a key logger for Debian ? I don't need replay or any fancy functions, just stats about which keys get pressed the most. Support for X is essential, support for the console is not. Even raw keycodes would do. I saw that one[1][2] in the last Debian Project News. Haven't tested it, but it looks like your best bet atm, considering all the other hacks available. It's new, so you might have to backport it if you're using Lenny. 1: http://packages.debian.org/sid/logkeys 2: http://code.google.com/p/logkeys If you only need raw keycodes, just dump /dev/input/eventX, reading it is trivial. -t -- 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/4c34e96e.5040...@stammed.net
Re: Debian support on newer 4K Advanced format drives (rather than 512 bytes)
lee wrote: Well, I wonder what the manufacturers thinking behind lieing about the sector size is. [...] XP, AFAIK. -t -- 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/4c31347b.50...@stammed.net
Re: ftp.us.debian.org really slow/nonresponsive
Boyd Stephen Smith Jr. wrote: I suggest cdn.debian.net for the official archive and security.geo.debian.org for the security archive. Both are GeoIP-based to find the closest mirror to you, although cdn goes an extra step and also takes into account how up-to- date and heavily-loaded the mirror is. Note that security.geo.debian.org will be dropped on july [1]. It's now active at the normal address (security.debian.org). 1: http://dsa.debian.org/dsablog/2010/05/Dropping_security.geo.debian.org_zone/ -- 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/4c1268cf.3020...@stammed.net
Re: Differentiated writable permissions
Anand Sivaram wrote: I dont think you could do that in filesystem level, since when 'w' permission is given the user could create both files and directories, but without 'w' permission the user cant do both. May be you could give readonly permission to all directories except one where this user could create any type of files including directories and normal files. POSIX won't allow it, but another layer could (a virtual filesystem, mandatory access control systems, ...) The reason nobody seems to care very much is that determining the file type is very difficult to do reliably. Obviously filename extensions are useless, but format signatures can also be easily faked. Even the human eye can be fooled by some steganographic contents, and a directory structure could take the form of an archive. Restricting file types to a directory is just not something you usually do. But maybe there are special use cases. -t -- 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/4c08d6eb.2000...@stammed.net
Re: Glob of Upgrades
Freeman wrote: Anyone else notice an unusually large number of upgrades in squeezee over the past 24 hours? I had 6 or 7 12 hours ago and 352 this morning, the most I've seen at once. R-C bugs regarding testing have also leaped to 716 from the low 500's recently. No mentions in Debian Project News or the developers lists and announce lists. Probably some big lib transition. I didn't notice anything. -t -- 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/4c08da25.4060...@stammed.net
Re: lilo removal in squeeze (or, please test grub2)
Stephen Powell wrote: Report? What report? That was actually meant to be a quick off-list note about your post in 505609 which I thought deserved at least two nice words. ;-) -t -- 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/4c099f66.3000...@stammed.net
Re: Requesting Backports
James Stuckey wrote: Is there an official way to request backports? Or, what is the easiest way to make packages for lenny when using squeeze? You'll probably get more valuable feedback there[1]. 1: http://lists.backports.org/mailman/listinfo -t -- 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/4c07dd81.6080...@stammed.net
Re: Backports kernel
Proskurin Kirill wrote: One question: It is safe to use backported kernel in production? Officially, it is not, but the backporters community is supportive enough. You should probably check this[1] out first, however. 1: http://www.linuxfoundation.org/collaborate/workgroups/driver-backport -t -- 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/4c0644e4.20...@stammed.net
Re: lilo removal in squeeze (or, please test grub2)
Stephen Powell wrote: Actually, that is largely a myth. Lilo's only release-critical bug turned out not to be a bug at all. It was this bug that gave rise to the belief that stock kernels were getting too big for lilo to load. But the problem was that a new kernel was installed without lilo being run. And this is apparently the result of changes made to the stock kernel maintainer scripts that cause do_bootloader = yes in /etc/kernel-img.conf to not be honored anymore, as it once was. Whether this is a bug or a feature in the kernel maintainer scripts I am not sure. But I am sure that this is not a lilo bug. Too bad it already made the news[1]. 1: http://lists.debian.org/debian-news/2010/msg6.html -t -- 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/4c064424.1060...@stammed.net
Re: lilo removal in squeeze (or, please test grub2)
Stan Hoeppner wrote: LILO isn't broken and it works well enough for may folks such as myself. We should have the option of keeping it, as an installable package, until _we_ feel we need to change to something else. It's as much a philosophical issue as it is a practical one. There is no legitimate reason LILO can't be left in the distro as an optional package, just as it is now with Lenny. It's difficult to be positive when unnecessary change is being forced down one's throat. In the worst case, people will maintain unofficial packages in unofficial repositories. In fact, I'm not even sure there's still much to maintain with the package.. just keep it around. It's very true, official support is best, but I wouldn't go as far as saying the change is forced. This is all still open and hackable software, in the end, and hack here means pinning lilo and grub-pc, which should be it. It will still be manageable by apt. -t -- 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/4c051719.7080...@stammed.net
Re: apt-get
Both can achieve basically the same thing, but the real difference (IMO) is in their respective goals/directions/purposes. apt-* tools have become relatively complex over the years, and can be considered a low-level interface to APT. To be clear, they're not *that* complex, but you get the idea. One could say that they are mainly useful for scripting or uncommon tasks. aptitude is a higher level CLI and CUI (ncurses) tool that wraps around apt-* tools. You can see that many little things make it more useable for a user. For example, issuing 'aptitude update' will automatically check the cache and output the number of upgrades available so that you don't have to issue '(safe|full)-upgrade' to find out. Every output is basically reworked to be more readable/useful for a human (another example: 'apt-cache show' vs 'aptitude show'). Inputs are supposedly more intuitive as well (compare 'apt-cache search' and 'aptitude search'). This is all obviously very subjective, and one might be perfectly OK without aptitude's help, but once again, you get the idea: aptitude wraps/aggregates everything a *user* might need in a single place and provides a more suitable interface for a *user*. As such, it's mostly useless for another program, and thus should probably not be used for scripting. Some people may have other opinions, and a technical comparison is still meaningful in some cases (is the dependency-resolver still different for the two?); I'm just not sure it's worth the trouble - one should just use what he knows will work best for the task at hand, because the real difference will most certainly be about comfort. -thib -- 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/4c0386bf.6050...@stammed.net
Re: lilo removal in squeeze (or, please test grub2)
Stan Hoeppner wrote: My gut instinct is that due to the above reasons and possibly others, the next dist upgrade is going to hose all my production servers whilst trying to forcibly convert them to Grub2. Is my instinct correct? Like any dist upgrade, squeeze will have release notes with upgrade instructions and I'm quite confident everything concerning lilo will be covered. There are probably many upgrade test patterns they'll have to try, that's true, but I would hope the transition goes smoothly for most systems. -t -- 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/4c026266.8020...@stammed.net
Re: Debian alternative kernels [OT]
consul tores wrote: No, the tendency to imitate Windows as a desktop. Yes, there are many alternative desktops and windows managers, but i have only one compaq presario laptop to use, which is working perfectly using Lenny-Kde; and 3 days ago i received a new tool, a lenovo thinkPad Edge, on which Debian Lenny can not recognize the video card, wireless card, and possibly another hardware. The point is that in my laptop, i used to use kde 3.5 (Lenny), and now i have to use testing or sid; when i could use the testing/sid base plus Kde 3.5, if it were existed a monolithic kernel+base testing/sid adding kde 3.5. Okay, well, if I understand correctly the problem is about drivers availability and KDE? A workgroup[1] backports drivers for major Linux releases, so efforts about recent drivers and stable distributions issues are beeing taken; support should go to them. 1: http://www.linuxfoundation.org/collaborate/workgroups/driver-backport Upstream has stopped maintaining the KDE3 suite however (I believe), so there's really nothing any distro can do about it. I must admit I didn't really follow the KDE4 debate, but I'd blindly trust Debian not to package broken software as important as a major DE. Maybe you can find some ports, but I think you'd probably be better off trying to improve the KDE4 suite by submitting them your ideas about what bothers you (as long as they do not belong better to another project). Please ignore that if I seem to have misunderstood you. Please, try to understand that i am not an expert in this field, i am only a Debian user, my field of work is Agriculture! Yep, okay, I just hope I can make you find your peace with Linux after all. My opinion is the one of a user as well, by the way, I'm really no expert either. So, in the end, no, I don't quite see how the BSDs model would do a better job at maintaining older software in an unstable tree. This discussion is a bit confusing, to be honest (again I'm sorry if I misunderstand you). As it's quite rapidly drifting OT, it'd probably be more appropriate to continue this off-list or in another thread, if you really want to. -t -- 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/4c00639f@stammed.net
Re: lilo removal in squeeze (or, please test grub2)
Stan Hoeppner wrote: In what way is it a vast improvement over LILO? I've never had a problem with LILO. It's always just worked, which is what a bootloader should do. So how exactly would grub be a better choice for me? Nobody should be arguing that it's a better choice for someone who doesn't *need* it, but it's certainly modular and possibly can make itself tiny enough for people without special requirements (about the second sector, usually). Since there's few alternatives however, it should at least be considered by everyone. [snip] What choice? Apparently the Debian team have decided there will be no bootloader choice when Squeeze becomes Stable. Supposedly at that point it's Grub2 or your system no longer boots. That's not much of a choice is it? Since lilo is/will be incompatible with Debian stock kernels, I think there's no point in providing it in a standard d-i. Now of course, we can still reasonably argue about two things: * Should it still be available and maintained in the official archive? This would mean adding big flashy debconf warnings stating that it's not compatible with a stock kernel. It's about newbies confusion and time spent maintaining an obsolete piece of software (sorry if sounds bad, but it really looks like it is, considering its development). I certainly hope it's a reasonable possibility. * If yes, should it still be presented as an expert option in d-i? Why not, I guess. If not, should extlinux be extensively tested to be provided as an alternative choice in d-i? I really don't know how much work would be needed for this. -thib -- 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/4c007f92@stammed.net
Re: lilo removal in squeeze (or, please test grub2)
Samuel Thibault wrote: [snip] Grub1 could because it was small enough to fit in a well-known usable area in the ext2fs filesystem, but grub2 can not any more. In the filesystem, you're sure? I'm curious, what part? [snip] -t -- 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/4bfe750d.6060...@stammed.net
Debian alternative kernels [OT]
consul tores wrote: Yes, Linux (kernel) is very tweakable, but normal users are not able to compile their own kernel; i am more remembering when i could install using 3 diskettes, and now i can not do it anymore. If, we consider that the environment has changed; we have Red Hut, Ubuntu and Suse; pushing to include every thing into the kernel, what is the best for them, then we have a huge kernel; which is not the best for older ordenators, but it is the best for newer boxes. As we can see, Linus is been pushed to built a huger kernel. I'm sorry but this is quite wrong. Nobody's forcing anyone; on the contrary, kernel developers *want* to integrate many things in mainline, and for very good reasons. See this file[1] for some (about the driver model). 1: linux/Documentation/stable_api_nonsense.txt See it's not the big distributions pushing stuff in the kernel, it's mainly (among other things) new drivers to support more hardware, including very old machines. Everything is extremely well organized and modularized, and you're able to build a kernel with just what you need. Again, if you can't, someone else can, that's what distributions are for; but you can't expect a *general-purpose* distribution to strip off their kernels and drop support for a range of hardware for no reason at all. As Stefan said, Linux does a very very good job on embedded systems, you can't deny that. If, Debian has a very tested own kernel (Hurd), it should be focused to its users, who probably are using older hardware, and maybe are not using non-free software. This is why, i think that having a Debian kernel, the users could be covered against global decisions. The Hurd is not Debian, it's GNU. Again, there's no global decisions at the kernel-level (at least not about what you're referring to), the distributions make the decisions of how they want to distribute the kernel; if you're not happy with the Debian kernels, well, maybe you ought to search for a more specific distribution (Debian itself has enough derivatives). Don't forget we're talking on the -user mailing list of one of the most universal projects. The thing is, the Hurd won't change that. If it seems tinier, well it's probably because it currently has less complete support. Microkernels don't exactly require less code in general AFAIK, it's a matter of architecture and where and how the code runs. I don't believe we should even think about having the monolithic vs micro kernel discussion here by the way; both Linux and the Hurd are very cleanly written and do what they can the best they can, given their respective design limitations. [snip] No, not the development model; i am refering to the structure, a monolitic base system, which is very small and stable. Well, it's usually seen as such because it's tied with its core userland. Debian uses GNU instead, so *in that regard*, I don't believe Linux and the FreeBSD kernel alone are *that* different. I would rather compare them by their development models, philosophies or simply licenses, for example. Someone might be able to troutslap me one that one. Yes, i think in the same way, we need to test Hurd in an efective way. it could help to manage the actual tendency to emulate Windows, obtaning a sipler/efective/funtional OS. I could be wrong, but it seems the most of us are prefering stability. A tendency to emulate Windows at the kernel level? I don't think so. This matter is a matter of the userland; and there are many, many alternatives to GNOME and KDE already - heck, even living without a prebuilt and integrated DE isn't so hard. Anyway, testing the Hurd is certainly a noble thing to do, but even if it gains traction, it won't get a mysterious anti-WIMP DE that Linux already has. It's other needs it answers to. -t -- 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/4bff4052.9000...@stammed.net
Re: lilo removal in squeeze (or, please test grub2)
consul tores wrote: Could you say why? I misunderstood you, or simply wasn't aware of the terminology, sorry. I mistakenly thought you were suggesting the creation of an entirely new Debian kernel. We have lost the posibility to install from disquette, we have to add an initrd, SElinux have been added by default because of Linus, Linus kernels define what to do, and ad infinitum. Linux is still extremely tweakable, and you are free to build the kernel whichever way you want to. If you can't, maybe a specific distribution of it will fit your needs -- the fact that its default configuration doesn't [fit] doesn't necessarily mean Linus is evil, but that maybe the general needs of most people are shifting. He doesn't have absolute power over everything. Beeing actually aware of what's going on there is also a must to understand the choices beeing taken. I'm not strictly suggesting you aren't, but you must admit that going on a revolution because a full featured modern kernel *in its default configuration* won't fit a disquette lacks some sense. They had their reasons to drop that feature. I'm not sure you'd like to debate your other examples here, but to avoid any confusion: no you don't *have* to use initrds -- complaints for using them by default even though you don't need them for your particular setup should go to the distributors, not Linus. Not sure they would be valid though (they *are* necessary for many setups for technical reasons that don't have much to do with the kernel). Do you know how BSDs work? Have you try Hurd? Are you referring to the BSDs development model? Anyway, progress on kfreebsd *is* impressive, and it indeed looks like it might become a very good alternative for Debian in the near future, but I wouldn't say the same for the Hurd. It's actually very interesting, but currently lacks much needed traction. Well you can see some reasons to built Debian kernels. Absolutely, choice is always good. -t -- 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/4bfd106a.8010...@stammed.net
Re: lilo removal in squeeze (or, please test grub2)
Stefan Monnier wrote: for much. But I am opposed to the removal of lilo. Both grub-legacy and grub-pc use sectors on the hard disk outside of the master boot record (cylinder 0, head 0, sector 1). In other words they use cylinder 0, head 0, sector 2 and possibly subsequent sectors on cylinder 0 head 0. Really? Never heard of it, and it sounds very odd: why would they do that when they can (and do, AFAICT) use sectors on specified partitions? Is that documented/discussed somewhere? It is, yes. At least I remember reading about it for grub1. Actually you don't *have* to use that space, it's just that it's convenient to store an intermediary stage (called 1.5) there, which typically holds filesystem drivers. The reason for this extra space is that traditionally, the first partition on a DOS partition table can only start at the second cylinder (correct me if I'm wrong), so boot loaders just used to use the remaining space from the first cylinder so they didn't have to ask anything to anybody, since it was always sufficient. For grub1 at least, the 'install' command (not the same as the 'grub-install' script) was well documented and allowed to tweak this by manually specifying an address for the next stage (be it 1.5 or directly 2) that you would allocate yourself with a partition just like you're suggesting (I think there is about zero tools helping you with this however). Note that pointing to a stage2 file directly makes grub behave much like lilo; you would put a filesystem on the partition and then you have tools to update the address in stage1 automatically when you upgrade. Maybe someone can point to similar documentation for grub2, as I'd bet it still allows it. So yes, the first cylinder situation is a mess, and silly backup software are not the only programs carelessly using the extra space in it without checking for bootloader stuff; for example Windows stores information about its LDM thingy (Logical Disk Manager or Dynamic Disks, comparable to LVM and dmraid, but crappy) in there too, making dual-boot with software RAID a real PITA. To be fair, there's never been an authority dictating that the space was reserved to boot loaders (AFAIK), so there's really no-one to blame. Fortunately, GPT answers this with new conventions. Each of these pieces of software can have their own partition and partition type and many already support it out of the box (grub2 included). I think administrators should really consider GPT for their new setups now; it has definitely more advantages than just allowing for big partitions, and it's darn simple (not sure how anybody could defend the I stick to what I know point here). Note that this partition scheme doesn't need EFI hardware, it's entirely backward compatible with PC/BIOS systems (you can even have hybrid GUID/DOS partition tables if you're really stuck with crappy software). -thib -- 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/4bfd754e.1050...@stammed.net
Re: lilo removal in squeeze (or, please test grub2)
consul tores wrote: Again, and again; Debian depends of Linus Torvals; maybe it is time to seriously think about Debian kernels! Madness. -t -- 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/4bfcace6.1080...@stammed.net
Re: Moving /tmp to a separate partition. Advice?
Rob Owens wrote: I'm not sure. ext2 has no journal, so I'd assume it's faster, but I really don't know. ext4 can be configured not to use a journal nor barriers. There's really no point in using ext2 these days, I think. -thib -- 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/4bfac6f3.8090...@stammed.net
Re: console-tools vs. console-setup
bernard.schoenac...@free.fr wrote: bonjour, le premier qui moufte ... bref, ne pas prendre le paquet kbd mais kbd-compat car autrement l'ensemble des dépendances est déconstruit kbd-compat est un layer pour wrap console-tools avec des scripts qui imitent kbd, pas l'inverse. Ici, le but est de retourner à kbd (l'histoire des deux packages est relativement bizarre.) -t -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4bf80ee0.80...@stammed.net
Re: Is this possible ?
exp...@hope.cz wrote: Is this possbile? Look at IP address spoofing techniques, it's a broad subject. I would consider identifying the client at the application level though (add support for this to your protocol), if possible. -thib -- 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/4bf56dbf.4090...@stammed.net
Re: LVM spanning multiple encrypted drives
B. Alexander wrote: I started looking in this direction myself last night. I am, for the life of me, unable to figure why or how drives are designated as early versus non-early. With the exception of adding noearly to the options in /etc/cryptab. However, I am unable to find a single partition on a single encrypted machine that uses this option. So theoretically, all of the drives should be designated as early. I also haven't done this in a couple of years, so maybe the encryption system has matured in the meantime. Supposedly all crypto devices are created as early as possible; the non-early script (which does exactly the same thing as the -early script) probably only creates the devices on LVs. The fact that there are two distinct scripts suggest that the procedures are only called twice, which would not be really flexible for fancy setups (should be more event-based) -- but I might be wrong and the definition of early could be more specific. I can't seem to find anything in the /lib/cryptsetup/cryptdisks.functions, however. It just systematically ignores the devices explicitely marked as noearly in the /etc/crypttab when called by the -early script (checked with $INITSTATE). So, I suppose it silently ignores all the failures in the hope a subsequent call will handle the remaining devices. In your case, you have to figure out why some devices are not handled by the first call. I see there are already many trace messages waiting for $VERBOSE to be set to yes, it might just be a matter of looking at the log. Have fun. [snip] I'm really not comfortable with modifying something like that, not because I can't, but rather because I don't want to tweak something and have it break on the next upgrade. [snip] Yep, I was referring to the cross-distro Dracut effort; but it's still new, and after thinking about it, I would trust Debian to either provide backward compat' or make a big fuss about it if the switch is ever considered. -t -- 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/4bf118a1.3060...@stammed.net
Re: monitoring internet availability and sending sms alert?
Adam Hardy wrote: Sure. I mean on the box at home that I'm monitoring from the online server. Aaaah, just realised I don't have a fixed IP ?$*!(*)*!!! Alternatively, you can call a heartbeat script on the server from the box at home. A simple cgi would do. -thib -- 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/4bf11d03.9060...@stammed.net
Re: LVM spanning multiple encrypted drives
B. Alexander wrote: [snip] The fix is probably simple, but I haven't found the right combination of secret sauce to get all drives decrypted before the system issues vgchange -a y, which results in a panic or other Bad Things. I'd say the design of your setup is the problem. Obviously, this doesn't answer your question, but consider encrypting the logical volume instead of the physical volumes. It makes much more sense to me. Does anyone know the right way to get the drives decrypted first? The fun might take place in your init scripts or in your initramfs, depending on your configuration. Unfortunately, things are currently moving in this domain, and I'm not sure about Debian's position here -- thus I cannot recommend you a hack over any other. Maybe someone can. I (very) quickly overviewed the initscripts, it looks like the same code in /lib/cryptsetup/cryptdisks.functions is called twice by cryptdisks-early (before lvm2), and then by cryptdisks (after lvm2). Supposedly, the -early script can't decrypt some devices, I just don't know why. By the looks of it all, I wouldn't be surprised if there were some dependency problems for unusual setups; is the problematic device a raid volume or something? If you mount your filesystems in your initramfs (which should really be done only for the root fs), you might be able to put some hooks in /etc/initramfs-tools. I'm not really comfortable with it, so you should read the initramfs-tools(8) manual page or wait for more help. -thib -- 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/4bf02141.50...@stammed.net
Re: How to flush cache of certain disk?
Alexander Batischev wrote: But all you said made me hard thinking about the way I mount and unmount my removable media. Maybe I should forget about sync and use 'umount /mnt/sd[a-z]' instead, or even write little script which will ask me which device I want to unmount… [snip] Which is what eject(1) is. It will search mountpoints in /dev, /media and /mnt by default btw, so it's just eject sd[a-z] for your example. You might want to use /media and volume names instead. -thib -- 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/4be473cc.1040...@stammed.net
Re: Filesystem recommendations
Rob Owens wrote: The resilience is due to the way the journal is written, if I understand correctly. Maybe somebody on this list who understands it better can confirm or deny. There is a journal_data_writeback option for ext3 which will speed up writes to the filesystem, but reduce its resilience to power loss. With this option enabled, I recall reading that the ext3 benchmarks are pretty similar to XFS. Yep. As always, LWN probably has the best word on it [1]. Short answer: ext3 is outdated, ext4 is current and can still be configured to get the same better data resilience without losing all its benefits. XFS should also be able to do so. Criticising ext4 for data resilience problems and praising XFS is a fallacy, both go in the same direction. Now the debate is around the default configuration of modern filesystems (basically performance vs safety). As YMMVVM (very much), one should probably just ignore the debate, take 30m to learn about the issue, and configure his filesystem properly. Well, opinions. ;-) For stable users using ext3, writeback can theoretically offer better throughput, as it doesn't force data to be be pushed on the platters before the metadata has been committed to the journal. It still keeps the filesystem consistent (the only thing a journal is supposed to do), but the risk of corrupting the data is greater. I, personally, don't seek to minimize that risk, I want it to be zero -- no filesystem can help here, and no filesystem will ever do. That's one reason why I don't like to see ext3 recommended for its data resilience: it gives the user the illusion of safety. Of course, it still makes sense to minimize the risk in certain scenarios where it can't be eliminated; but again, modern filesystems can be configured to do so. -thib [1] http://lwn.net/Articles/322823/ -- 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/4bd9d34c.1010...@stammed.net
Re: VM software for personal use?
Hugo Vanwoerkom wrote: Except... what works very nice in VMware is the NAT and Host Only network setups: works out of the box. You share your home dir thru samba. On XP all I had to setup was a netuse * to mount a net fs. Do the others do it that easy? Yes [1]. VBox even has kernel additions which implement shared directories over a specialized interface with a virtual filesystem (vboxfs) [2]. Hugo QEMU and Xen might not be as straightforward for a desktop end-user, but their users certainly won't find it difficult. -thib [1] http://www.virtualbox.org/manual/ch06.html [2] http://www.virtualbox.org/manual/ch04.html#sharedfolders -- 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/4bd5dc07.9060...@stammed.net
Re: Resources for learning Linux
Can't miss the Debian Reference by Osamu Aoki (青木 修): http://www.debian.org/doc/user-manuals#quick-reference It covers a lot of topics and provides up-to-date pointers to other resources. -thib -- 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/4bd5e2a3.5020...@stammed.net
Re: Filesystem recommendations
Boyd Stephen Smith Jr. wrote: [snip] I recommend moving to ext3 (NOT ext4) [snip] Here we go again? :-) -thib -- 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/4bd5e416.7050...@stammed.net
Re: [Quel bordel !] Compiler avec des lib rairies antérieurs au système hôte
steve wrote: Une idée ? apt-get build-dep? -t -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4bced194.3000...@stammed.net
Re: [Quel bordel !] Compiler avec des lib rairies antérieurs au système hôte
Ton patch devrait fonctionner même sur la version de Lenny, non? $ apt-get source tangogps [patch] # apt-get build-dep tangogps Tu devrais pouvoir compiler sans problème après. -thib -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4bc632f4.5090...@stammed.net
Re: C programming question [OT]
Ron Johnson wrote: [snip] http://www1.us.ioccc.org/main.html I guess they got bored looking at normal production C code... Sometimes, I find the code there even more impressive: http://underhanded.xcott.com/ It's even more restricted, and not so pointless. Hiding in plain sight, beautiful. There was also an Obfuscated Perl Contest, but that only ran for 5 years due to the Perl and obfuscation being redundant. I laughed. [snip] -- 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/4bc62afe.7070...@stammed.net
Re: Temporary deconnection from the Internet when too much pages are loaded
If it happens even after the pages have all finished loading, then you have a problem (probably with your browser). If not, well.. you either have to give your connection a rest (streaming video is heavy stuff) or ask network gurus to narrow down the problem. Is it happening only with your browser? What about other things requiring many parallel connections (try a P2P application)? -thib PS Greetings from Liège. -- 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/4bc64f33.4010...@stammed.net
Re: Boot / LVM best practices
Ron Johnson wrote: On 2010-04-13 05:23, Jon Dowland wrote: Stan Hoeppner wrote: If you're going to buy two drives, you'd be stupid to not use mirroring for fault tolerance and a little added read performance here and there (depends on application). I disagree. Mirroring only protects you against drive failures and not human error. And I disagree with that. Mirroring *definitely* makes both reads and writes go faster, due to parallelism. Hmm. Don't ^ these. Backups are always necessary, mirroring is optional but speeds up recovery from hardware failure *only*. Sometimes, you can't backup (it doesn't make sense, it's too big, ..) and thus, yes, you also *need* mirroring (not just to speed up things). But it will not help you in case of human error, as Stan said. -thib -- 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/4bc4981b.6010...@stammed.net
Re: Choix d'un proxy/cache APT [OT]
Pascal Hambourg wrote: On ne s'est pas bien compris, je crois. rsync ne télécharge que les fichiers modifiés, d'accord. Mais ma question portait sur les fichiers modifiés : rsync essaie de ne télécharger que les parties qui diffèrent, en tenant compte d'éventuels décalages. Pour du texte voire de l'exécutable ça peut être efficace, mais l'est-ce aussi pour une archive compressée comme un .deb ? Sinon je ne vois pas trop l'intérêt de rsync si c'est juste pour détecter les paquets qui ont changé, les méta-données d'APT suffisent. Certains algorithmes de compression sont assez tweakables. Je pense que debdelta[1] est le projet le plus à jour sur ce front. -thib [1] http://debdelta.debian.net/ -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4bc3e374.7090...@stammed.net
Re: Choix d'un proxy/cache APT
Pascal Hambourg wrote: Salut, Envisageant de mettre en place un proxy/cache APT pour les machines d'un réseau local, j'apprécierais des avis, retours d'expérience et recommandations sur les différentes options disponibles. En fouillant dans la liste des paquetages, j'en ai trouvé 4 : - apt-proxy (ne semble pas en bon état, donc a priori exclu) En effet, il a été retiré de squeeze vendredi dernier. - apt-cacher - apt-cacher-ng - approx Le choix semble en effet se limiter à ces deux là. Certaines personnes préfèrent aussi une solution plus générique, comme un proxy HTTP. Pour les grandes lignes, voir la référence Debian[1] et cet article sur LWN[2]. Pour se décider, je pense qu'il faut plonger dans quelques threads[3] et simplement tester. [snip] [1] http://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_proxy_server_for_apt [2] http://lwn.net/Articles/318658/ [3] http://www.google.com/search?q=apt-cacher%20approx -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4bc3e770.1010...@stammed.net
Re: Choix d'un proxy/cache APT
David Prévot wrote: La version d'apt-cacher-ng dans Lenny date un peu, et je suis passé vers la version de Squeeze pour utiliser je ne sais plus quelle fonctionnalité ou profiter d'une correction de bogue. Un point peut-être négatif du coup, c'est que cette version dépend maintenant d'une version récente de libc6 (= 2.10). Ça ne m'empêche pas de faire tourner ce serveur globalement sous Lenny, mais il commence à être de plus en plus teinté de la future stable... C'est un problème adressé dans la référence[1]: When Debian reorganizes its archive structure, these specialized proxy tools tend to require code rewrites by the package maintainer and may not be functional for a while. On the other hand, generic web (http) proxy servers are more robust and easier to cope with such changes. Mais évidemment, les proxies spécialisés (à jour) offrent plus de flexibilité. On pourrait dire qu'une règle radicale serait de se limiter à un proxy HTTP pour un serveur stable, et s'offrir le luxe pour un serveur de test ou instable. D'un autre côté, ils ne doivent pas être extrêmement compliqués à backport (ça m'étonnerait qu'il soit nécessaire de bump libc, par exemple), et l'infrastructure de l'archive change très rarement. Au pire, on peut toujours soumettre ces packages à l'archive volatile. -thib [1] http://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_proxy_server_for_apt -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4bc3ea18.5090...@stammed.net
Re: Boot / LVM best practices
I think the main question you should ask yourself is: Do I want redundancy? * Yes? Now you know the drives should have equal size, reflecting your needs. It's also a good idea to get identical drives. You'll then probably create a big volume group over the entire RAID. * No? Then you're free to get whatever you need in addition to your existing drive (why throw it away? well, okay.) You'll just have to create some new logical volumes on the new drive, and assign them to your existing volume group, effectively expanding it. That's where LVM really shines, by the way. As others have said, there's no reason for the boot drive to be as small as possible. Also, GRUB2 supports RAID and LVM [1], so you can even put the /boot partition on a logical volume. Some people will probably say that makes recovery harder; which is true only if you have inappropriate recovery tools. I really see no problem with that, and it makes more sense to integrate it with everything else, IMO -- not doing that looks like a hack. I still agree with the others about your filesystems layout, but maybe you want to just ask yourself the same question I asked myself some weeks ago: Up to where is it worth the trouble? [2]. -thib PS Do your backup and start incrementals every hour now :-) [1] http://grub.enbug.org/LVMandRAID [2] http://lists.debian.org/debian-user/2010/02/msg01945.html -- 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/4bc22516.4050...@stammed.net
Re: Migrate OS to smaller drive?
Others suggested using filesystem-level tools, which is really fine. Alternatively, you can shrink the filesystem and move the entire block at once. Each method probably has its pros and cons. -thib -- 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/4bc22782.8060...@stammed.net
Re: Migrate OS to smaller drive?
Clive McBarton wrote: Ron Johnson wrote: Never destroy the original until you know the copy works! In my earlier days I would have avoided mv for exactly that reason. But when copying (including rsync), you cannot easily see that it worked from the emptyness of the original file system. And comparing large filesystem trees (not just 4GB as in this case) is trickier than most people realize. At least a simple diff -r will be far from doing it. Maybe you have some good way of comparing FS trees? [snip] Including rsync? I'd say that's the exact purpose of rsync. Anyway, there are many filesystem comparison tools if one wants to do it manually, like dirdiff. For file contents, just hash and re-hash. -thib -- 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/4bc23ba5.7030...@stammed.net
Re: Migrate OS to smaller drive?
Sjoerd Hardeman wrote: I thought symlinks keep point via a file location memo, like look at /usr/share/the/file/you/want, which is the old location just after copying, but the new location when you boot from your new device and that becomes root. A tool that tries to be too smart could try to relocate it. Not sure how it would work out though; you'd probably have to be inside the new system, copying files from the old one, and not the other way around. -thib -- 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/4bc23c70.60...@stammed.net
Re: Migrate OS to smaller drive?
Ron Johnson wrote: Yes, wire is slang for network cables, but SATA cables are actual wires too and orders of magnitude slower than CPU/RAM transfer. This is true, but isn't relevant to what you suggested. Think about it some more. ... Oh yes. We'll never talk about this again, I promise. -thib PS I'll tell you something embarrassing about me if you find a SATA controller that can inflate. -- 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/4bc26019.4080...@stammed.net
Re: Migrate OS to smaller drive?
vr wrote: [snip] I'd hoped there was a block by block way to do it so I didn't have to set up the partitions filesystems ahead of time but I suppose that part won't be too painful. Well, as I said in another branch of the thread, you can shrink most filesystems, including all extfs (I think the only bad boy here is XFS), look at resize2fs(8) from e2fsprogs for these. Again, the solution is not necessarily better nor simpler, just different. The system is relatively idle during these types of surgeries because I boot from a live CD so the data on disk isn't churning. That's good, and I'd say that's even necessary if you don't have snapshotting tools (LVM2 is good at it). [snip] -thib -- 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/4bc29707.8050...@stammed.net
Re: automate updates in Lenny
Merciadri Luca wrote: Osamu Aoki wrote: On Sat, Apr 10, 2010 at 01:09:58PM +0300, Andrei Popescu wrote: I guess this was the big headach http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411123 _was_ or _is still_? Was. The only thing to keep in mind is that aptitude keeps an internal state; a sort of staging state that you work on while using the ncurses UI. It only clears it on demand or when you commit your changes, thus you can close and re-open a session without losing your work (yeah, sometimes package management is still work). People simply wonder when they modify some package status with apt-get in the middle of an aptitude session - but everything seems taken care of the best it can; I'm pretty sure there's no (known) bug, the user is almost always the problem. Note that using aptitude CLI only isn't messing with people's head. I also think the fuzz comes from #411123, which is fixed. I've never heard of anything else. Disclaimer -- just my understanding (I'm sometimes surprised.) -thib -- 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/4bc06641.5030...@stammed.net
Re: automate updates in Lenny
Chris Hiestand wrote: On Apr 7, 2010, at 12:27 PM, Ron Johnson wrote: On 2010-04-07 13:52, Jozsi Vadkan wrote: [snip] That's a foolish thing to do, since blind acceptance can lead to a broken system. Maybe so, but I've been using automatic upgrades for the last 2-3 years on many stable systems without a problem. The nice thing about staying within the stable distribution is that typically the only updates are security updates which are generally very small changes. When you get to the scale of managing tens or hundreds of debian systems it's easier to automatically upgrade and fix any problems in the off-chance they happen. If you wanted to be more careful, one solution is to setup your systems in such a way that a small group of computers get updated before the rest, as an early warning system. The major package changes happen between inter-distribution (eg etch - lenny), which always need a human supervisor. This is acceptable on a larger scale because that only happens every 1.5 - 2 years. Also if you have other management software (eg cfengine, puppet) in place, it helps mitigate problems when upgrading debian packages or distributions - decreasing the cost of a package upgrade mishap across many systems. As nicely put in the reference (2.7.5): If the risk of breaking an existing stable system by the automatic upgrade is smaller than that of the system broken by the intruder using its security hole which has been closed by the security update, you should consider using [the] automatic upgrade [...] In other words, use automatic security upgrades if you can't maintain the system actively and have enemies. -thib -- 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/4bbfcf53.4050...@stammed.net
Re: regexp a package with apt?
Jozsi Vadkan wrote: Is there a regexp for the: gstreamer0.10-plugins-bad package? I mean like: apt-get install gstreamer*-plugins-bad so that later, when it will get a new version number, it would still be downloadable by a script written e.g.: now. Sure, gstreamer.*-plugins-bad$ Just don't forget the quotes to prevent shell expansion, to search for package names only, and if it's a batch job, whatever is necessary to be non-interactive. I would suggest aptitude # aptitude --assume-yes install '?name(gstreamer.*-plugins-bad$)' until someone can clear what exactly the different apt-* tools are using: # apt-get --assume-yes install 'gstreamer.*-plugins-bad$' [...] Note, selecting gstreamer0.10-plugins-bad for regex 'gstreamer.*-plugins-bad$' $ apt-cache --names-only search 'gstreamer.*-plugins-bad$' gstreamer0.10-plugins-bad - GStreamer plugins from the bad set gstreamer0.10-plugins-really-bad - GStreamer plugins from the bad set apt-get seems fine, but I find the inconsitency weird. I'll try to blame my regex-fu before apt-cache, although I just can't think of a way it got to match the *really-bad package. Manpage says it's supposed to be POSIX RE. $ apt-show-versions -R '^apt(itude)?$' apt/lenny uptodate 0.7.20.2+lenny1 aptitude/lenny uptodate 0.4.11.11-1~lenny1 -thib -- 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/4bbdd7a2.1020...@stammed.net
Re: automate updates in Lenny
Yet another solution: http://packages.debian.org/lenny/unattended-upgrades -thib -- 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/4bbcf698.5080...@stammed.net
Re: question about fstab in squeeze and uuid
rely on either their path/location (port), serial number* (not always provided, also depends on the interface) or contents (partition(s) or a unique filesystem). *not the same thing as vendor/model ID, which is not unique. Since we currently can't identify partitions either, we can only rely on their order (partition number) or contents (filesystem). Filesystems can be identified by their location (partition/device), UUID, label or contents. debate Note that identifying by contents here means file analysis - yeah. Labels are useful but not always reliable in certain cases: * Considering you only rely on the filesystem label to determine your root or boot filesystem, what happens if you boot with a removable device plugged in containing a filesystem with a label conflicting with another filesystem label on the device you actually want to boot from? Possible pwnage, I guess.) UUIDs for filesystems were introduced partly to answer this problem. This is the only three-nines reliable way. Labels are just there for convenience (and they are very useful at that), and as the hardware layer is beeing more and more abstracted, identifying by path or basically any underlying layer is less and less feasible. That's just a fact: filesystems can be completely detached from the devices. In the future, we should be able to reliably specify on which unique device/partition/LV the filesystem is supposed to be, for extra fun (and more). In fact, the future could be now, I'm just talking about general trends; GPTs can be setup very cleanly even on non-EFI hardware - except on Windows* and for no apparent reason, of course (sigh). OT *since GPTs are backward compatible, it's possible to setup a hybrid configuration and thus still be able to dual-boot it. It's kludgy. /OT /debate - The problem: ? Sorry for the many off-topic blocks, I felt like it could clarify my words, putting them in some context. Hopefully it's informative for someone. Please correct me if you don't like my understanding of these things; but really I see no problem. -thib -- 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/4b9c2fbd.6070...@stammed.net
Re: [OT] Linux should not be booting
Tom H wrote: You're welcome. I hope that you have an actual Windows CD/DVD to use the above commands given that most manufacturers ship recovery CDs only that may or may not allow you to use these commands. :( Maybe the mbr package is what we're looking for here. http://packages.debian.org/lenny/mbr From the manpage, the behavior of this loader is to chainload to the default partition (the one that has the boot flag, I guess) after one sec (configurable), or display a very basic prompt if a keypress occurs before (or if it fails). In other words, it does the job -- the old-school way, but it works. -thib -- 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/4b9c3e5b.8080...@stammed.net
Re: mpg123 does not play
Ron Johnson wrote: This is odd-looking. $ apt-file search output_alsa.la mpg123: /usr/lib/mpg123/output_alsa.la Wow, yup. If someone has the time to investigate, I'm quite sure the file to look at is mpg123-1.4.3/libltdl/ltdl.c. The lib defines the heuristics to find and load the modules; should lead to some understanding. It's quite old code from libtool. Maybe that[1] will be more helpful. 'Hope I got that right. In the meantime, a very ugly hack that could probably work would be to create a link to /usr/lib/mpg132/output_alsa.la from /lib/output_alsa.la. -thib [1] http://www.gnu.org/software/libtool/manual/html_node/Using-libltdl.html -- 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/4b9ad8f5.3060...@stammed.net
Re: question about fstab in squeeze and uuid
Stephen Powell wrote: I believe a UUID is generated when the partition is formatted, either with mkfs or mkswap. I confirm - just tried shrinking and growing back an extfs. UUID is left untouched (as expected); that Mint article is BS or just obsolete. -thib -- 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/4b9ae392.6000...@stammed.net
Re: du avec des répertoires comportant des e spaces
moi-meme wrote: Le Thu, 11 Mar 2010 10:20:03 +0100, Julien Demange a écrit : Ce qui ne résoudra pas réellement ton problème de shell. tant pis : j'ai résolu le problème par un script. Quel script? Je confirme que bash traite les espaces correctement; on peut le tester facilement pour se convaincre: cay:~/tmp$ touch x y 'x y' cay:~/tmp$ rm x* rm: remove regular empty file `x'? y rm: remove regular empty file `x y'? y cay:~/tmp$ bash --version GNU bash, version 3.2.39(1)-release (i486-pc-linux-gnu) Copyright (C) 2007 Free Software Foundation, Inc. Le fichier 'y' n'est pas supprimé: 'x y' s'est donc bien expanded, et est bien escaped correctement. Enfin, tant que ça marche. -thib -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4b98dec7.4080...@stammed.net
Re: du avec des répertoires comportant des e spaces
Julien Demange wrote: Je me demande si ce n'est pas un peu plus que les espace qui lui pose des soucis. Peut êtres l'association d'espace + - + autre chose... Ca m'étonnerait.. Je vote pour un encodage hasardeux, si c'est sur un vieux ntfs. -thib -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4b98e1ac.80...@stammed.net
Re: /boot partition changes when it should not
Clive McBarton wrote: Ron Johnson wrote: Note that Last write time: might not mean what you think it does. I say that because on my system /dev/sda2 is / and I've written a whole bunch of data to it in the past 25.5 days, yet the LWT still matches the LMT. Very interesting. I wasn't surprised that they match for me, since I mount it read-only, so as soon as my kernel is up enough to read and care about /etc/fstab, it will not modify it anymore anyway. It's interesting to know that even people with read-write partitions see similar behavior. As I mentioned in my previous post analyzing the code, the last write time specifies the last *superblock* write time. Since the kernel does everything it can not to touch anything if read-only, it has to be mount(8), when it updates the last mount time (which explains why they always match). I'd really look at the boot loader now. -thib -- 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/4b98cf5d.9000...@stammed.net
Re: /boot partition changes when it should not
Clive McBarton wrote: There may be software out there but I don't know of any, particularly such that can check partitions, just software that merely checks files. Well I would prefer that software to be aware of the filesystem, actually, it doesn't add much more complexity and removes superblock issues for any filesystem, as we discussed earlier. But hey, opinions. I'm pretty sure now that the last mont time and last modify time are what I see changing. Hence this is no longer an ext3 issue that I could discuss on an extfs list. On the contrary, if there is an fs that does not change on boot, I'd use it. Maybe your beloved xfs, thib? Actually, I've never even tried xfs, I was just beeing rational (but I guess it has the potential to hook me up if I take the time to study it, some other day). That beeing said, I can't help much there, but I would suspect it also has a last-mounted field to make mount(8) happy, so it's not a real solution. Even if it was, it'd merely be a workaround, IMHO (same thought: I think that the problem logically lies at the file-level, not really the block-level). I'll let the discussion on the actual solutions go on on the other branch. -thib -- 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/4b98d1b5.8080...@stammed.net
Re: Linux should not be booting
Carlos Davila wrote: Yet linux still boots. I am using Lenny and grub. Where is the kernel actually stored then? Ha. What I can think of: * You were using block-lists to reference the second stage file of grub1 from the first stage in the boot sector, and you didn't store filesystem drivers (stage1_5 files) in /boot/grub. I don't even know if that's possible, but if it's smart enough, it may then have referenced the kernel and initrd files with block-lists too. This way, assuming you didn't wiped the volume, the files are still there, just unlinked. (That's a very long shot.) * If grub is really smart, it may store block-lists automatically as a fallback for this very case when the filesystem won't provide the file (I'm not sure I'd really want it to do that if it does). * You messed up at some point by failing to mount the /boot filesystem, assuming it's on a separate volume. An upgrade may have repopulated the /boot directory on the main filesystem (mounted on /). Now you have two copies of the directory, depending on if you re-updated grub stage1 to load the second stage on the separate filesystem or not, you may have deleted the unused copy of the files. (Still, quite a long shot.) -thib -- 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/4b98f404.5080...@stammed.net
Re: /boot partition changes when it should not
thib wrote: I'd really look at the boot loader now. Which I did. It's not it. Grub doesn't touch anything. For the record, I fired up a VM and tried, on *squeeze*: ext2 / grub2 ext2 / grub1 ext3 / grub1 Mount time never changed, checksums were always identical. The filesystem was mounted ro everytime, of course; specified in the fstab. Adding the journal was silly, actually, since grub1 doesn't really support ext3 (or does it? I mean journaling and all). The first grub2 test isn't relevant to this thread since we're talking about lenny but it was free. Hope I didn't miss anything. So, what's below? fsck? -thib -- 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/4b991ac0.5020...@stammed.net
Re: /boot partition changes when it should not
Clive McBarton wrote: Very interesting point. Indeed running fsck when the shutdown was clean seems pointless. Agreed, I don't think there's anything else to it. And clearly whoever started fsck had no idea that it would take longer and longer as drives got newer. We should probably note the substantial improvements allowed by the extents in this regard - but yep, that's still a long process. Back on; I digged a thread[1] from the grub development list archive which is a subset of this one. Considering the OP there seemed happy to discover that the source of his problem was unrelated, I assume he solved it completely. Since I wasn't able to reproduce it either (see the post on the other branch), the problem might be more specific to your particular setup. I can't think of anything right now; a quick overview of your init scripts might help, I don't know. [1] http://lists.gnu.org/archive/html/grub-devel/2008-03/msg00091.html -thib -- 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/4b99591d.3070...@stammed.net
Re: Linux should not be booting
Carlos E. Davila wrote: [...] but this evidently does not overwrite the boot sector, does grub-install do this? Yes. I have yet to run grub-install. Of course, this would not explain why my system still boots after deleting the vmlinuz files. Did you evaluate our little theories? I imagine your first partition is your /boot (the second beeing your volume group, right?). If the filesystem on this first partition disappeared from your fstab for some reason, it could explain everything. # mount /dev/disk/by-id/$DISK-part1 /mnt # tree /mnt The files in my /boot/ directory (before I deleted them...actually moved them to my home directory for safe keeping) were: default device.map menu.lst menu.lst~ menu.lst_backup That would be /boot/grub. Should the grub image files be here as well? Yep. Anyway, I see you have lilo installed in your boot sector, were you chainloading or is it recent? -thib -- 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/4b995ffe.3040...@stammed.net
Re: encodage en serie
daniel Coadou wrote: Bonjour à tous, j'ai une serie de fichiers avcchd que je dois transformer en avi avec mencoder. la ligne de commande que j'ai adaptee me convient tres bien mais mais je dois la relancer en changeant le n° du fichier (000xx.mts et 000xx.avi) à chaque fois ce qui est fastidieux et je souhaiterai que tous les fichiers soient traités les un apres les autres dans une seule ligne de commande ou un script (là je suis ignare) auriez vous une idée? Utiliser seq(1) pour générer une séquence de nombres. for i in `seq -f $FORMAT $FIRST $LAST` do $CMD ... $i ... done -thib -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4b97a3b5.7080...@stammed.net
Re: encodage en serie
steve wrote:
Créer un script bash (dans $HOME/bin/ par exemple):
#!/bin/bash
REP=/media/Elements/stream-03-11-2009
MENCODER=/usr/bin/mencoder
OPTIONS=-oac copy -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=2500 -fps 60 -vf
scale=1280:720
cd $REP
for i in *.mts
do
$MENCODER $i -o $i.avi $OPTIONS
done
(rem: cela va donner des fichier *.mst.avi, ce qui n'est pas grave en
soi, mais on peut très bien virer le mst, mais là je ne me rappelle plus
comment faire)
Oh, évidemment, cette solution est bien meilleure que la mienne.
Pour supprimer l'extension, utiliser ${i%.mst}.avi pour l'output.
-thib
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists
Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: http://lists.debian.org/4b97a5d0.1090...@stammed.net
Re: encodage en serie
daniel Coadou wrote: Peut être pourriez vous me dire s'il existe un ouvrage simple pour débutant permettant d'aborder la réalisation de scripts ou dois-je me plonger dans bash pour apprendre ? thegeekstuff.com commence justement une série d'articles sur bash pour débutants[1]. Comme la plupart de leurs articles, ils montrent quelques examples et les expliquent simplement, sans trainer. Je pense que c'est un bon moyen de se faire une idée et de commencer à jouer un peu, sans aller trop vite, sans aller trop loin. Cette liste[2] indexe un bon paquet d'autres tutoriaux, anciens ou modernes, bons ou mauvais. Je recommande les deux guides du LDP[3] (Linux Documentation Project) pour apprendre de manière un peu plus structurée, ou le HOWTO d'introduction s'il faut apprendre les grandes lignes rapidement. Des documents comme ceux-ci ne remplaceront jamais le manuel de référence, cela dit. Tout développeur d'un projet un minimum sérieux devrait sans doute le lire - tout est dispo sur la homepage @GNU[4]. La manpage de l'interpreteur est également très utile. Côté ressources, bash-hackers.org est un très bon endroit pour découvrir et discuter de bash en général - le wiki est très, très complet. *Note pas nécessairement intéressante: bash étend POSIX et propose des features utiles et non-standard. Quand la performance est plus importante, on utilise souvent des interpreteurs bourne-shell plus légers - il est donc parfois intéressant de faire un poil attention aux normes pour être lu par d'autres interpreteurs, quand c'est possible et facile. Si on parle de scripting en général, bash est loin d'être seul, mais il a la particularité d'exploiter le système au niveau d'abstraction maximum pour autant de flexibilité. Pour un autre style de scripting qui se base plutôt sur des librairies portables, les grands joueurs sont Perl, Python, Ruby, et bien d'autres. Ils offrent encore plus de flexibilité au niveau du langage (pas nécessairement au niveau fonctionnalité), et se placent à un niveau d'abstraction un poil inférieur. -thib [1] http://www.thegeekstuff.com/2010/03/introduction-to-bash-scripting/ [2] http://www.bashcookbook.com/bashinfo/ [3] http://tldp.org/ [4] http://www.gnu.org/software/bash/ -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4b97c27a.6010...@stammed.net
Re: du avec des répertoires comportant des e spaces
moi-meme wrote: je sèche sur un petit problème : la commande du marche bien. J'ai des répertoires récupérés de windows avec des espaces (c'est pas bien je sais mais c'est pas de moi). Pour trouver la taille totale (du -h) OK. Pour la taille de chaque répertoire (du -h *) c'est une bordée d'injures. Pas de doute c'est les espaces qui f... le b... Bien sûr le man ne parle pas du cas (je le comprends) Je ne veux par renommer. Je peux faire avec un script. Cela serait tellement plus beau avec une astuce au niveau de la commande. d'avance merci. CH Les noms de fichiers expanded par des wildcards sont automatiquement escaped s'ils contiennent des espaces, du moins sous bash et j'imagine tous les bourne-shell (ce n'est donc pas ça le problème). Quelle est la particularité exacte de l'output de `du -h *`? Peut-être que la commande réellement désirée dans ce cas est celle-ci: $ du -h --max-depth=1 2/dev/null -thib -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4b982206.7030...@stammed.net
Re: Getting no reply from this mailing list
Celejar wrote: What do you mean manually? Probably via an archive. The lists servers are fine. You should check your mail filters. -thib -- 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/4b979e35.9070...@stammed.net
Re: /boot partition changes when it should not
Clive McBarton wrote: The online to offline comparison has value, just the offline to online comparison does not. More precisely: You never know if any checksums taken on a running system are reported correctly. But: If you take an online system (powered up), take checksums of important files or partitions, and they are the same after the system later becomes offline (powered down), then they were reported correctly to begin with. Whereas if they were correct before running it and are then are reported correct while the system is running, it does not tell you anything. Oh yep, I stand corrected. Would you care to share your solution, Clive? Currently I take checksums of the partition regularly during operation and while the system is turned off. The online to offline comparison works fine, whereas the offline to online does not always work, hence this thread. Just curious actually; do you use a simple live CD, a USB device, bootstrap via a secure network (PXE?), or..? Do you know of/use some targetted software/efforts to do that or did you hack something together? To get back on the original topic, do you plan to forward the discussion to an extfs specific list (or somewhere else)? I think d-user@ is stuck at this point. I'm asking because I'm interested, too. -thib -- 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/4b980cda.9080...@stammed.net
Re: /boot partition changes when it should not
Stephen Powell wrote: Actually, that could be an important clue. Perhaps the last mount date is what is being updated. And since both mounts were on the same day, the date did not change. But if you reboot tomorrow ... I don't know if that's it, of course. It's just a theory at this point. The trouble with diagnosing something like that is that you can only run one test per day (unless you mess with the system clock). You can find the ext3_super_block data structure in linux/ext3_fs.h[1], line 444 in current mainline 2.6. I noted: ... __le32 s_mtime;/* Mount time */ /*30*/ __le32 s_wtime;/* Write time */ __le16 s_mnt_count;/* Mount count */ ... __le16 s_state;/* File system state */ ... /*40*/ __le32 s_lastcheck;/* time of last check */ ... /*88*/ chars_last_mounted[64]; /* directory where last mounted */ ... __le64 s_mmp_block;/* Block for multi-mount protection */ ... * The mount time is set by cpu_to_le32(get_seconds()) in fs/ext3/super.c l1326, so it stores a timestamp in seconds (sorry Stephen). cpu_to_le32() just byte swaps to little-endian if necessary, in case you're wondering. * The write time is actually the time the superblock itself was last written. Explanation in fs/ext3/super.c l2366: /* * If the file system is mounted read-only, don't update the * superblock write time. This avoids updating the superblock * write time when we are mounting the root file system * read/only but we need to replay the journal; at that point, * for people who are east of GMT and who make their clock * tick in localtime for Windows bug-for-bug compatibility, * the clock is set in the future, and this will cause e2fsck * to complain and force a full file system check. */ if (!(sb-s_flags MS_RDONLY)) es-s_wtime = cpu_to_le32(get_seconds()); * The state is a quite vague term, at least at first glance. Possible values seem to be: #define EXT3_VALID_FS 0x0001 /* Unmounted cleanly */ #define EXT3_ERROR_FS 0x0002 /* Errors detected */ #define EXT3_ORPHAN_FS 0x0004 /* Orphans being recovered */ It should then not change during normal operation. * Apparently, the time of last check and the last mounted directory are never touched by the kernel. Might want to investigate userspace mount(8). BTW, 64 bytes max for the entire path? Really? :/ If you ever try to mount a filesystem in a deep hierarchy, you might want to remember this if something goes haywire. * I don't know what the block for multi-mount protection is, I just mentioned it in case it's some kind of lock to prevent multiple mounts, in which case it would updated at each mount (but why store that on-disk?) Never touched by the kernel itself either. - Maybe I missed something relevant. [1] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob_plain;f=include/linux/ext3_fs.h;hb=HEAD -- 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/4b981d6c.8040...@stammed.net
Re: /boot partition changes when it should not
Ron Johnson wrote: On 2010-03-10 16:30, thib wrote: Maybe I missed something relevant. # dumpe2fs -h /dev/sda2 | grep time dumpe2fs 1.41.10 (10-Feb-2009) Last mount time: Sat Feb 13 08:39:01 2010 Last write time: Sat Feb 13 08:39:01 2010 I will not comment on this. .. Of course, I knew about this utility. Maybe. Damn. :-) -thib -- 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/4b9829bb.4060...@stammed.net
Re: where is angband?
Martin wrote: I downloaded 5 DVD Lenny 5.0.4. As I was browsing packages with aptitude I noticed that there is angband-doc but angband is (UNAVAILABLE). Martin In non-free[1]. [1] http://packages.debian.org/lenny/angband -thib -- 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/4b982a3c.2050...@stammed.net
Re: clamav sur lenny
François Cerbelle wrote: Il faut utiliser le dépot volatile, il est la précisément pour ce cas là. De là, il y a encore un choix à faire: utiliser le package -data (qui est un snapshot régulier de la base de donnée) pour récupérer les signatures via APT, soit continuer à utiliser -freshclam, ce qui est sans doute le mieux à faire, du moins de mon point de vue. -thib -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.org/fr/FrenchLists Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe vers debian-user-french-requ...@lists.debian.org En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org Archive: http://lists.debian.org/4b96dd89.2020...@stammed.net
Re: /boot partition changes when it should not
Ron Johnson wrote: I'd hash each of the files in /boot (storing the results in a thumb drive if you are paranoid) just before you reboot and then just after. How would you do it after with an offline system? That would require to systematically run the machine in a virtualized environment (and other things); not sure that's worth it. -thib -- 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/4b960db9.4070...@stammed.net
Re: /boot partition changes when it should not
Ron Johnson wrote: On 2010-03-09 02:58, thib wrote: Ron Johnson wrote: I'd hash each of the files in /boot (storing the results in a thumb drive if you are paranoid) just before you reboot and then just after. How would you do it after with an offline system? That would require to systematically run the machine in a virtualized environment (and other things); not sure that's worth it. Put your hashing script/program on the thumb drive then boot from a Live CD. Sorry, I meant, how would you run the hashing program before the reboot? I think it has little value if it's ran by the live system beeing checked. Sames goes for a check after the actual boot - only a hypervising or external system should do it. The only moment I can think of when it would actually be useful is right before the boot phase, and yes, any live CD/thumb drive would do. I guess it's kinda overkill though, a boot loader module would maybe be more appropriate, it's really not a complex task. Well as long as it doesn't have to do sig analysis anyway - which it probably shouldn't; I suppose it shouldn't do anything else than raise a red flag, further in-depth analysis can be done manually after that. Would you care to share your solution, Clive? -thib -- 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/4b969873.4030...@stammed.net
Re: /boot partition changes when it should not
Bob McGowan wrote: On further consideration, there are other places where things could be happening, before the system is fully started, meaning before the 'mount' options you're using would have any effect. These don't necessarily do anything (in the write sense ;), but are places to consider checking: BIOS, grub/lilo/other boot loader, kernel and kernel options for startup, initrd. The BIOS should be completely fs-agnostic, but yes, actually, the first stage of the boot loader most certainly doesn't care about the fstab, and if it's a good boy, then it *might* increment the count. After that, the fstab should be taken into account, but maybe the mount count still isn't covered by the ro option. Wild guess: if it's not the mount command, then.. fsck? Better start digging some facts. These days, you need to know udev and udev rules files format (which I don't), to figure out where and how to set this up. Perhaps someone else on the list would have some ideas for you on how to do this? http://reactivated.net/writing_udev_rules.html This is a good reference, although maybe a bit outdated considered the recent developments. Shouldn't be anything significant if at all, and definitely enough for that. -thib -- 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/4b969b58.4010...@stammed.net
Re: /boot partition changes when it should not
Stephen Powell wrote: You might try switching to lilo as your boot loader and see if that solves your problem. I use lilo as my boot loader and have for a long time. I may be able to assist you if you have difficulty. For the record, grub can also load a kernel and an initrd by just providing a block list, as you described for lilo. Since the filesystem is made read-only, this shouldn't be too ugly and certainly worth trying. -thib -- 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/4b96d789.4060...@stammed.net
Re: device name problem after update
Ron Johnson wrote: On 2010-03-09 14:57, Angelin Lalev wrote: After almost each update of my debian lenny kernel I have my IDE disk name changed. Once it's hda1 then is hdc1 and keeps flip-flopping. Is it a known problem? That's udev. Does your fstab use /dev/hdX, labels or uuids? Whatever it currently uses, you *should* use labels in fstab; and when not possible (fancy fs, whatever), UUIDs. To reference the block device anywhere else, use /dev/disk/by-label/... When not possible or not such a good idea (removable drives,..), there are also subdirectories to reference by disk ID (generated with the model/serial numbers,..), path (physical) or UUID. If you don't want to use these paths, you can generate your own symlinks via custom udev rules. I would *not* recommend renaming the drives with fixed kernel names ([sh]d[a-z]) in order to reorder them. I had some issues trying to do that in the past, and in the end I realized it would only add useless confusion. So, it's not a bug, you should just not rely on these names. -thib -- 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/4b96da56.20...@stammed.net
Re: /boot partition changes when it should not
Clive McBarton wrote: For the record, grub can also load a kernel and an initrd by just providing a block list, as you described for lilo. Since the filesystem is made read-only, this shouldn't be too ugly and certainly worth trying. Really? Great. How exactly? I looked at the man and info page and didn't see this option. Actually, I haven't studied grub2 yet, but I see no reason they would have gone backwards regarding this feature. In grub1, you need to get dirty with the install command, from the grub shell. Basically, you wouldn't specify a stage 1.5 (which loads the fs driver), and instead load stage2 directly. It's all documented in the manual[1]. [off-topic] Does anyone know if there's a grub2 reference draft available somewhere? Or any documentation apart from the wiki? [1] http://www.gnu.org/software/grub/manual/html_node/install.html#install -- 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/4b96df25.50...@stammed.net
Re: /boot partition changes when it should not
Clive McBarton wrote: Up to now, I never heard of any advantage whatsoever of ext2 over ext3. ext3 now differs from ext2, aside from the journal. We can run ext3 without one, so there's no real reason to continue to use ext2. One could say the same thing about ext3 and ext4, actually, but that's a widely misunderstood subject, and I wouldn't want to start some flames. That's a highly interesting point. It doesn't? I thought everything in the boot process mounts everything it finds read-only until when the kernel is running. Even the kernel at some point during boot says it now remounts the / filesystem read-write, hence even that must have been read-only until then. Technically it doesn't (because it doesn't have to, and because it has to remain OS-agnostic), but you're right, it should probably not mount anything rw anyway, and maybe it doesn't. That question would probably better be asked in the grub list directly, we're only speculating. And it may be maintaining that field when it reads the kernel image or the initial RAM disk image. As I said, nothing in the filesystem metadata got updated. Well it has to be metadata. One solution would be to get the offset(s) of the diff(s), and see how it compares to the on-disk structure. Or ask this on the extfs list. -thib -- 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/4b96e1ca.4090...@stammed.net
Re: /boot partition changes when it should not
Clive McBarton wrote: I'm not saying grub cannot do it, but I do see a reason: grub has its config in a *file*. By default anyway. Something called menu.lst which controls how the grub display looks like and so on. When grub loads, it loads this file first. There are also other files, like device.map. This file is part of the second stage. We're now talking about grub1 exclusively. Another reason: I read somewhere that grub is too fat to fit in the boot sector. So only half sits in it and loads the other half, which is a *file* on a file system. Yep. In grub1, Only the stage1 fits in the boot sector. If you want, you can either: * Go on to stage2 by hardcoding some block offsets list in stage1. This can of course be automated by the grub shell install command, which is *different* from the grub-install(8) utility. * If the stage2 is on a filesystem which can possibly physically move the file or parts of it (fragmentation, rewrite, whatever) - which is usually the case - you can put a filesystem driver somewhere else, and use it to read the stage2 at a higher level. Usually, the entire first cylinder of a disk drive (someone correct me if I'm wrong) formatted with a PC BIOS style partition table/label is left untouched for historical reasons. This space is large enough to hold any fs driver and will most likely not interfere with any PC BIOS partition table editor. [little bit off topic] Note that in reality, it's a mess, Microsoft uses it for its LDM (Logical Disk Manager) - their *really* crappy equivalent of lvm/mdraid - and it causes bad conflicts. There are solutions to this, but this is off-topic. Let's drop GPT in the discussion, as the ultimate solution (sadly, no support on non-efi machines on Microsoft's side yet, for no apparent reason). -thib -- 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/4b96e6b4.80...@stammed.net
Re: Installing to Flash Drive
http://www.pendrivelinux.com/ -thib -- 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/4b96e7bd.1000...@stammed.net
Re: qemu or qemu-kvm for kvm in squeeze
Martin Kraus wrote: My question is, why there are two apparently identical qemu packages. Which one should I use with kvm. ** I didn't take the time to check that out, so I may be wrong ** The kvm userspace utility is in fact a modified qemu which takes advantage of hardware tech via the kvm kernel subsystem - and nothing more. You can see the command-line resemblance, and the fact that the kvm package is just a virtual package provided by qemu-kvm. To answer your question, I'd say you just can't use kvm without the modified qemu utility (named kvm, provided by qemu-kvm). And if you can, well, you should still use it, since it has to be developed for some reason (supposedly optimization). -thib -- 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/4b94fc4c.6070...@stammed.net
Re: Two Lenny problems
Ron Johnson wrote: On 2010-03-07 03:55, Cecil Knutson wrote: [snip] Is it right to see LVM as software to combine several HD's? Does it have any use with respect to a single 1.5TB HD? Yes. At some point, if you run out of space on that device, simple add another disk to your existing single-disk LV (logical volume) and presto, more space!! Also, you can resize volumes dynamically very easily, thanks to the extra abstraction layer provided by physical and logical extents. I'd recommend only doing that on /home, /data, ... so that if something goes wrong, you can still boot up and log in as root. Traditionally, you would only put /boot out of the volume group, but now that grub2 has fine support for LVM, I don't see any reason to exclude any volume from the group. -thib -- 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/4b9539d5.2020...@stammed.net
Re: Overwrite existing partition with zeros without hurting partition table? (Debian Lenny)
Stan Hoeppner wrote: I'm constantly Googling trying to find new ones. Apparently (and unfortunately), thoughtful, thorough, and fair comparative Linux filesytem benchmarking is a very rare hobby. :( Best thing to do would be to lurk on Phoronix until they release a new one. You can already search the website for more recent benchmarks, there are plenty. -thib -- 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/4b958400.2020...@stammed.net
Re: qemu or qemu-kvm for kvm in squeeze
Martin Kraus wrote: This seems pretty specific to me. I have asked what is the difference between qemu and qemu-kvm for kvm virtualization. Both support kvm and both are based on qemu 0.11.1 so I wanted to know what is the difference. I'm not really sure that virtualbox is the right thing for a server. I'm not much sure about kvm+qemu either, but xen just keeps crashing so there isn't much I can do about it. KVM is a solution, and a good one. Rather than using its own hypervisor software and a special guest to manage the domain, it uses the Linux kernel itself. The latter already provides a hell lot of subsystems relevant to hypervisor technology, which makes KVM really simpler in terms of complexity, thus arguably less prone to problems. Provided you're comfortable with Linux and that you trust its stability, KVM is probably your best solution. If not, then Xen is more independent and has its advantages too; their architectures are just different and inherently offer different things. More info relative to my last post: if you want to use KVM, you do *need* the modified qemu software provided by the kvm package (which really points to qemu-kvm). These changes are currently pushed upstream [1]. I hope it clears any ambiguity. I agree about VirtualBox, it clearly targets workstations (and it's good at it). I can only recommend Tim Jones' articles on IBM's DeveloperWorks site, they provide really good overviews on this subject (and others). Nothing to do with IBM, BTW, I just found they were quality stuff. [1] http://www.linux-kvm.org/page/Main_Page -thib -- 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/4b958935.70...@stammed.net
Re: /boot partition changes when it should not
Aioanei Rares wrote: How do you check this checksum of the partition ? I'm guessing OP literally checksums the volume from the block device. If I'm right, it could be anything, really, lots of filesystem metadata moving around without actually touching any file contents (access times, for example). So, Clive, what filesystem are you using? Would you, by any chance, be asking this because your boot loader doesn't understand this fs and you thus need to be sure the kernel and initrd don't move because you had to reference them by block address? If that's the case, I wouldn't worry, the read-only option should be enough, as long as you don't do any maintenance operations on it (defragmentation, stuff like that). -thib -- 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/4b958d30.9000...@stammed.net
Re: Installing Debian
Aioanei Rares wrote: 2. external HDD's wear out faster [...] Really? No misunderstanding with SSD drives here? (Just wondering.) Anyway, I agree, USB might make it look painful to use, but if you don't have a spare internal drive around, it's still better than a LiveCD. As Aioanei Rares said, Windows won't bother in this case, just boot from a different drive by modifying the boot order in your BIOS setup or use the special boot menu at boot-time if your BIOS provides one (F8 to access it here). If you don't have this menu, it might be cumbersome to reconfigure the BIOS setup every time, so you might want to consider replacing NTLDR's (the NT =5 boot LoaDeR) first stage with a more flexible boot loader (such as grub) to provide you with such a menu. Note that I heard Windows may start crying if it's not installed on the first drive - I don't know if and when it has been fixed, I never tried on XP, but keep that in mind in case something breaks. Grub can help again in this case (by virtually reordering the drives). If you decide to go with the external drive, it shouldn't be a problem. Welcome to the community. -thib -- 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/4b9592ee.5090...@stammed.net
Re: /boot partition changes when it should not
Clive McBarton wrote: Good point, that is probably important. ext3. Well then I would suggest going through the tune2fs(8) manpage and find out what could be.. tuned. You know what? I think your first suggestion is a good one - look at the mount count configuration for a starter. If nothing works for you, you'll have to study the filesystem in depth. The question is, then, as usual; why is it important? (Sorry to ask again, maybe you don't think it is relevant.) -thib -- 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/4b959785.7020...@stammed.net
Re: /boot partition changes when it should not
Aioanei Rares wrote: xfs as a /boot partition? shivers Why not? [This is so going off topic.] -thib -- 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/4b9597be.80...@stammed.net
Re: /boot partition changes when it should not
Clive McBarton wrote: OK, I studied the tune2fs manpage. I found that it controls what happens when a certain mount count or mount interval is reached. Which requires mount count and time to be already stored in the filesystem. What I need is not to prevent the reaction to this data (count and time). What I need is to prevent this data to be updated in the first place during mount while booting. Yep, I just read that :/. I'm not sure why it's absolutely needed, maybe it would be acceptable to ask for a new little switch. The question is, then, as usual; why is it important? It detects malicious tampering with the boot system. It? You mean a rootkit detection tool or something? Is it some kind of offline system you plug-in to boot the system after doing some basic checks? Anyway, you should use a smarter tool, I guess, one that can understand the filesystem and checksum the files inside, not the entire volume. Or hack ext3. -thib -- 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/4b95a7db.4020...@stammed.net
Re: /boot fs (was Re: /boot partition changes when it should not)
Ron Johnson wrote: grub (and maybe lilo) never used to be able to boot from an xfs partition. Grub is doing fine, although it's true it had some issues in the past (just read about them, actually). Can't talk about lilo. As for the shiver, I also am confused. A 64MB partition, though, really doesn't need a high-performance fs. ext2 is more than adequate. Maybe someone simply has reasons not to put /boot on a separate volume. Now I sure agree that it isn't needed in virtually every other cases, but would it really hurt? -thib -- 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/4b95a973.1050...@stammed.net
Re: what is this thing?
Ron Johnson wrote: On 2010-03-08 19:25, tom arnall wrote: I did a download via a torrent file, with results I don't understand. Rtorrent created a directory and put some files in it, all in a seemingly normal manner. But the stuff turned out to be a fake, so I tried to remove it. The result was that the non-hidden files went away, but two hidden files remained. When I tried to remove them, nothing happened except the names of the files changed. How does this happen? Need an example. Yeah. I can guess the first part: bash doesn't expand the wildcard to dotfiles implicitely by default, but the second part? I don't know. $ rm -f dir/.* renames them? If that's the case, I would look for the unlikely. What does happen if you issue a $ rm -rf dir then? Would you, by any chance, using a fancy filesystem without unicode support? (Wild guess.) -thib -- 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/4b95aaf8.60...@stammed.net
Re: /boot fs (was Re: /boot partition changes when it should not)
Clive McBarton wrote: thib wrote: Maybe someone simply has reasons not to put /boot on a separate volume. Now I sure agree that it isn't needed in virtually every other cases, but would it really hurt? We are already discussing this in your thread Single root filesystem evilness decreasing in 2010? (on workstations), so no need to bring it into mine ;) Hehe, don't worry, actually I was just wondering about XFS [hurting as boot filesystem?]. -thib -- 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/4b95b0a4.7090...@stammed.net
Re: /boot partition changes when it should not
Clive McBarton wrote: thib wrote: maybe it would be acceptable to ask for a new little switch. Or hack ext3. Ask who? The maintainers of tune2fs? The maintainers of ext3? Both will say what I already know, that manually mounting and unmounting an ext3 partition read-only does not modify it in any way whatsoever, so the problem lies with whatever modifies my partition (boot process). I would have thought the filesystem itself would increment its mount count but now I don't know how I could be so sure. Well, ask the developers of whatever is touching it. If noboby knows, that will require some code digging. Storing many checksums (one for each file) takes a storage mechanism to write them to. Storing just one can be done in your head. How about storing a hash of all the hashes? -thib -- 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/4b95b221.8060...@stammed.net
Re: qemu or qemu-kvm for kvm in squeeze
Mark Allums wrote: Sorry, there is some (more) confusion. I was referring to the original post, which seemed to me to be about a completely different topic. Are we reading the same original post? Hi. I have been wondering what is the difference between qemu and qemu-kvm packages for kvm virtualization. Manual page in qemu packages shows, that it should be able to work with kvm. Uncle google is silent about this. I thought it was pretty clear. [...] In short, there are lots of choices for Debian beside QEMU. Consider them. qemu/kvm/qemu-kvm: I don't think there is a significant difference between the two packages anymore; you can choose which to use based on convenience rather than performance. Gee, don't add some more confusion :-) kvm is qemu-kvm Soon, qemu will include qemu-kvm code. So, in the end, qemu = qemu-kvm = kvm. Talking about Debian userspace utilities packages only, of course - using qemu without the kvm kernel subsystem will be different than using qemu alone. -thib -- 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/4b95b3a9.2050...@stammed.net
Re: qemu or qemu-kvm for kvm in squeeze
Mark Allums wrote: However, I myself am now failng to understand the difference between the two. Are you saying that one package is simply a meta- or virtual package pointing to the other, and that installing one installs the other? Exactly. In squeeze, kvm is still a virtual package provided by qemu-kvm [1]. In sid, it's already a dummy transitional package [2]. I guess the qemu and qemu-kvm package will eventually merge when the kvm specific code will be imported by qemu upstream (if it ever is, I actually haven't followed any discussion about that, just the note on the kvm project frontpage [3]). Again, this package only provides userspace utilities; the actual kvm subsystem code is in the mainstream kernel and thus should be included in any stock kernel. Well, that's my understanding of the situation anyway, I'm in no way involved with the development of these projects. -thib [1] http://packages.debian.org/squeeze/kvm [2] http://packages.debian.org/sid/kvm [3] http://www.linux-kvm.org/ -- 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/4b95b749.4000...@stammed.net
