Re: [gentoo-user] Anyone succeeded with kmail2?
On Thu, 3 Jan 2013 18:24:13 +, Kevin Chadwick wrote: I love claws but perhaps you should ask on the claws mailing list I thought it was too mouse heavy too but when I actually look it's very few tabs, arrows, enter and ctrl-R to reply etc. and the configurability of claws may help too, though I can't see if you can assign shortcuts to custom commands/actions. You assign shortcuts to actions in the same way as any other menu entry, highlight the menu option and then press the shortcut you want to use. You have to enable customisable keyboard shortcuts in the misc section of preferences. signature.asc Description: PGP signature
Re: [gentoo-user] Anyone succeeded with kmail2?
On Mon, Jan 7, 2013 at 9:29 AM, Neil Bothwick n...@digimed.co.uk wrote: WHAT?! No tagline? J.A.
Re: [gentoo-user] Install from USB stick; here's how
On Sun, Jan 06, 2013 at 10:05:08PM -0500, Walter Dnes wrote: For those of you who don't want to do the tap-dance listed at... http://www.gentoo.org/doc/en/liveusb.xml * My netbook's harddrive is normally /dev/sda, except when I boot from a USB stick. The stick will become /dev/sda and the harddrive becomes /dev/sdb Tired of the old dog-and-pony show? http://www.sysresccd.org/Download gives you a much more complete environment, including wifi support (with firmware), and won't conflabulate and change the devices like that one metioned above, and has a very simple install script. Here's blkid on the laptop normally: /dev/sda1: LABEL=system UUID=d91e2ce9-d1b0-4619-abc3-3886142d58da TYPE=xfs /dev/sda2: LABEL=swap UUID=f303a606-2bd6-47b1-8761-3d5f212725fd TYPE=swap and after booting with SystemRescueCd: /dev/loop0: TYPE=squashfs /dev/sda1: LABEL=system UUID=d91e2ce9-d1b0-4619-abc3-3886142d58da TYPE=xfs /dev/sda2: LABEL=swap UUID=f303a606-2bd6-47b1-8761-3d5f212725fd TYPE=swap /dev/sdb1: LABEL=SYSRESC UUID=52DC-EE33 TYPE=vfat Since it's tools are better, it has x86 or x86_64 kernels, more options, and it's based on Gentoo ... it's a great replacement for those old Gentoo minimals. -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
[gentoo-user] Re: 4 machines - no /dev/cdrom or /dev/dvd anymore
On 2013-01-07, Dale rdalek1...@gmail.com wrote: I'm not sure that is a bug. As I posted earlier, this was changed a good while back. There was a reason for it but I can't recall what it was. The new devices for CD/DVDs is /dev/sr*. It's been something like 6-8 years hasn't it? I don't have, and have not had, /dev/cdrom or dvd on this rig for a good while and it works. I think this happened about the same time as the hard drive devices were changed from hd* to sd* even for old IDE drives. IIRC, the IDE CDROM devices moved over to the SCSI subsystem some time before IDE hard drives did -- but it's been a while... Since it was changed on purpose, I don't believe this is a bug. Yes, it was an intentional change. I haven't seen a /dev/hd* device for years and years. -- Grant Edwards grant.b.edwardsYow! I joined scientology at at a garage sale!! gmail.com
Re: [gentoo-user] Re: 4 machines - no /dev/cdrom or /dev/dvd anymore
On Mon, Jan 7, 2013 at 7:18 AM, Grant Edwards grant.b.edwa...@gmail.com wrote:
On 2013-01-07, Dale rdalek1...@gmail.com wrote:
I'm not sure that is a bug. As I posted earlier, this was changed a
good while back. There was a reason for it but I can't recall what it
was. The new devices for CD/DVDs is /dev/sr*.
It's been something like 6-8 years hasn't it?
IIRC the SATA interface has always labeled them as /dev/sdX /dev/srX.
Everything I've built using new hardware in the last 5 years has been
SATA based and I've not had a new machine with /dev/hdX in longer than
I can remember.
However, best I can tell, that has _nothing_ to do with why /dev/cdrom
/dev/dvd disappeared in the last couple of months. Remember, my
machines have all had /dev/srX.
Going back to my post with one of many solutions to this issue:
First - the old way that udev was recognizing the cdrw/dvd drive on my
system was via an ID_PATH value for the pci device:
#SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_PATH}==pci-:00:1f.2-scsi-0:0:0:0, SYMLINK+=cdrom,
ENV{GENERATED}=1
However you will note that ID_PATH (the key used by udev) doesn't exist any more
c2stable ~ # udevadm info --query=all --name=/dev/sr0 | grep ID_PATH
c2stable ~ #
Best guess I have is that ID_PATH may have been changed to DEVPATH
c2stable ~ # udevadm info --query=all --name=/dev/sr0 | grep DEVPATH
E:
DEVPATH=/devices/pci:00/:00:1f.2/ata11/host10/target10:0:0/10:0:0:0/block/sr0
c2stable ~ #
What I did was ask udev to identify by the drive's model number using ID_MODEL:
New way:
SUBSYSTEM==block, ENV{ID_CDROM}==?*,
ENV{ID_MODEL}==Optiarc_DVD_RW_AD-7241S, SYMLINK+=cdrom,
ENV{GENERATED}=1
A little playing around suggest you can use anything unique to the device.
Now, my point is that change to /dev/srX was the root cause is FUD. It
isn't the root cause of this change because it didn't change on my
systems. All I know is that ID_PATH (from the old file) used to work
and no longer does. Whatever is responsible for creating that, likely
some portion of the kernel, changed the value and created a need to
modify how udev looks at the system. Is it a bug? I don't know. It's
just the way it is.
Just my views,
Mark
[gentoo-user] OT: Fighting bit rot
Hi list! I have a use case where I am seriously concerned about bit rot [1] and I thought it might be a good idea to start looking for it in my own private stuff, too. Solving the problem is easy enough: - Record checksums and timestamps for each file - Check and update records via cronjob - If checksum changed but timestamp didn't, notify user - Let user restore from backup However, I haven't found any application in portage for this task. Now, the implementation is easy enough but I'm wondering why it hasn't been done. Or do I just look for the wrong thing? The only suitable thing seems to be app-admin/tripwire but that application also looks like overkill. [1] http://en.wikipedia.org/wiki/Bit_rot Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] OT: Fighting bit rot
On Mon, Jan 7, 2013 at 2:11 PM, Florian Philipp li...@binarywings.net wrote: Hi list! I have a use case where I am seriously concerned about bit rot [1] and I thought it might be a good idea to start looking for it in my own private stuff, too. Solving the problem is easy enough: - Record checksums and timestamps for each file - Check and update records via cronjob - If checksum changed but timestamp didn't, notify user - Let user restore from backup However, I haven't found any application in portage for this task. Now, the implementation is easy enough but I'm wondering why it hasn't been done. Or do I just look for the wrong thing? The only suitable thing seems to be app-admin/tripwire but that application also looks like overkill. Not really what you are asking for, but I think btrfs and zfs have checksumming built-in to the filesystem. I'm not sure what userspace tools are like to monitor this, or if it's just an fsck away.
Re: [gentoo-user] OT: Fighting bit rot
On Mon, Jan 7, 2013 at 3:11 PM, Florian Philipp li...@binarywings.net wrote: Hi list! I have a use case where I am seriously concerned about bit rot [1] and I thought it might be a good idea to start looking for it in my own private stuff, too. Solving the problem is easy enough: - Record checksums and timestamps for each file - Check and update records via cronjob - If checksum changed but timestamp didn't, notify user - Let user restore from backup However, I haven't found any application in portage for this task. Now, the implementation is easy enough but I'm wondering why it hasn't been done. Or do I just look for the wrong thing? The only suitable thing seems to be app-admin/tripwire but that application also looks like overkill. [1] http://en.wikipedia.org/wiki/Bit_rot Regards, Florian Philipp Have you looked at Tripwire to see if it'll do what you need? -- :wq
Re: [gentoo-user] OT: Fighting bit rot
Am 07.01.2013 22:07, schrieb Paul Hartman: On Mon, Jan 7, 2013 at 2:11 PM, Florian Philipp li...@binarywings.net wrote: Hi list! I have a use case where I am seriously concerned about bit rot [1] and I thought it might be a good idea to start looking for it in my own private stuff, too. Solving the problem is easy enough: - Record checksums and timestamps for each file - Check and update records via cronjob - If checksum changed but timestamp didn't, notify user - Let user restore from backup However, I haven't found any application in portage for this task. Now, the implementation is easy enough but I'm wondering why it hasn't been done. Or do I just look for the wrong thing? The only suitable thing seems to be app-admin/tripwire but that application also looks like overkill. Not really what you are asking for, but I think btrfs and zfs have checksumming built-in to the filesystem. I'm not sure what userspace tools are like to monitor this, or if it's just an fsck away. Yes, that's a start. `btrfs scrub start` might give something meaningful. But I'm not really trusting btrfs with valuable data, yet. And CRC32 isn't much, either. Thanks anyway, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] OT: Fighting bit rot
Am 07.01.2013 22:33, schrieb Michael Mol: On Mon, Jan 7, 2013 at 3:11 PM, Florian Philipp li...@binarywings.net wrote: Hi list! I have a use case where I am seriously concerned about bit rot [1] and I thought it might be a good idea to start looking for it in my own private stuff, too. [...] The only suitable thing seems to be app-admin/tripwire but that application also looks like overkill. [...] Have you looked at Tripwire to see if it'll do what you need? Not in detail. I guess you can get it to do that but one look at the configuration and I told myself, Screw this, I will have coded it in perl before I understood tripwire. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Anyone succeeded with kmail2?
On Mon, 7 Jan 2013 11:33:18 +, Jorge Almeida wrote: On Mon, Jan 7, 2013 at 9:29 AM, Neil Bothwick n...@digimed.co.uk wrote: WHAT?! No tagline? I was experimenting with Enlightenment... clearly it isn't :) -- Neil Bothwick Unsupported service (adj): Broken (see Demon) signature.asc Description: PGP signature
Re: [gentoo-user] Re: 4 machines - no /dev/cdrom or /dev/dvd anymore
On Monday 07 Jan 2013 07:35:32 Dale wrote: I think you misunderstand or I didn't make myself clear. I'm not saying it was udev that did this. I am pretty sure it was the kernel. All this happened when people with older IDE drives, myself included on my old machine, had to switch to the new drivers and devices. Before the change, old IDE drives and CD/DVD drives were given hd* devices and udev made a link to that with /dev/cdrom or dvd or whatever for optical devices which is what you seem to expect now. The reason udev did that was for it to be consistent which I have no problem with . When the kernel folks changed this, they also changed it from /dev/cdrom and /dev/dvd to /dev/sr0. From my understanding, all optical devices such as CD and DVD readers/burners are supposed to be sr0. I know k3b updated theirs too. I seem to recall I had to run a unstable version for a bit because the older version didn't have the code to see sr* devices. I never said anything was broke, just that it was changed. There was several things that was changed at about the same time that were related and this was just one of them. Another was the change from /dev/hdXX to /dev/sdXX for ALL hard drives. This change happened even if you was using the old IDE drives. As I understand it, /dev/hdxx is no longer supported on current kernels. All hard drives are /dev/sdxx and optical drives are /dev/sr0(1,2,3,4 etc). Also, I didn't remove anything. It was changed by the kernel which also lead to udev changing what it did. Again, as much as I dislike what udev is planning, I never said udev did this one. I'm pretty sure this was all started with the kernel devs. The udev folks just followed along. The biggest thing I recall is everyone with IDE drives having to update the kernel config, edit fstab and grub or lilo before rebooting. This was discussed on this list and I don't recall much fuss except for having to change it and update everything. It was sort of a one time thing and had a long term goal. All hard drives are sdxx and optical devices are srx. All this happened when I was on my old rig which was at least a few years ago. Does that make more sense now? Dale :-) :-) I think that you are conflating two issues which are separate in terms of chronology at least. Years ago we moved to libata and hdX changed to sdX. The udev confguration was updated at the time to link /dev/cd* and /dev/dvd* to srX. More recently, the udev rules nomenclature changed. The udev persistent-cd rules however was not changed. I moved it, remerged stable udev and the file was not recreated. So something in udev has changed and it no longer generates the persistent-cd rules. BTW, pressing the touch sensitive button on the laptop to eject the CD won't work, neither will typing eject in a terminal: $ eject eject: tried to use `/mnt/cdrom' as device name but it is no block device eject: unable to find or open device for: `cdrom' So, eject is still looking for cdrom ... Either all commands and legacy apps should update themselves, or I better follow Mark's suggestion? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] OT: Fighting bit rot
On Mon, 07 Jan 2013 21:11:35 +0100 Florian Philipp li...@binarywings.net wrote: Hi list! I have a use case where I am seriously concerned about bit rot [1] and I thought it might be a good idea to start looking for it in my own private stuff, too. Solving the problem is easy enough: - Record checksums and timestamps for each file - Check and update records via cronjob - If checksum changed but timestamp didn't, notify user - Let user restore from backup However, I haven't found any application in portage for this task. Now, the implementation is easy enough but I'm wondering why it hasn't been done. Or do I just look for the wrong thing? The only suitable thing seems to be app-admin/tripwire but that application also looks like overkill. [1] http://en.wikipedia.org/wiki/Bit_rot Regards, Florian Philipp You are using a very peculiar definition of bitrot. bits do not rot, they are not apples in a barrel. Bitrot usually refers to code that goes unmaintained and no longer works in the system it was installed. What definition are you using? If you mean crummy code that goes unmaintained, then keep systems up to date and report bugs. If you mean disk file corruption, then doing it file by file is a colossal waste of time IMNSHO. You likely have 1,000,000 files. Are you really going to md5sum each one daily? Really? This is a filesystem task, not a cronjab task. Use a filesystem that does proper checksumming. ZFS does it, but that is of course somewhat problematic on Linux. Check out the others, it will be something modern you need, like ext4 maybe or btrfs -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: 4 machines - no /dev/cdrom or /dev/dvd anymore
On Mon, 7 Jan 2013 09:37:05 -0800 Mark Knecht markkne...@gmail.com wrote: Now, my point is that change to /dev/srX was the root cause is FUD. It isn't the root cause of this change because it didn't change on my systems. All I know is that ID_PATH (from the old file) used to work and no longer does. Whatever is responsible for creating that, likely some portion of the kernel, changed the value and created a need to modify how udev looks at the system. Is it a bug? I don't know. It's just the way it is. It's not a bug as /dev/dvd is a mere convenience for the user - a nickname if you will. You are highly unlikely to find a standards doc of any kind stating the symlink should be there. Which means if it's not there, you get to make your own convenient nicknames. /dev/harddrive has never existed, right? Same with /dev/dvd and friends. make them if you want, but you can't expect them to be there and their absence is not a bug. Obviously someone left them out of the rules files. Maybe they had a reason, maybe they got lazy. Either way you get to add your own rules to get the names YOU want. It really is as simple as that, don't overthink this one. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] OT: Fighting bit rot
On 08/01/13 04:11, Florian Philipp wrote: Hi list! I have a use case where I am seriously concerned about bit rot [1] and I thought it might be a good idea to start looking for it in my own private stuff, too. Solving the problem is easy enough: - Record checksums and timestamps for each file - Check and update records via cronjob - If checksum changed but timestamp didn't, notify user - Let user restore from backup However, I haven't found any application in portage for this task. Now, the implementation is easy enough but I'm wondering why it hasn't been done. Or do I just look for the wrong thing? The only suitable thing seems to be app-admin/tripwire but that application also looks like overkill. [1] http://en.wikipedia.org/wiki/Bit_rot Regards, Florian Philipp equery check pkg for the OS and tripwire for private data. BillK
Re: [gentoo-user] Anyone succeeded with kmail2?
On Mon, 7 Jan 2013 22:23:29 + Neil Bothwick n...@digimed.co.uk wrote: On Mon, 7 Jan 2013 11:33:18 +, Jorge Almeida wrote: On Mon, Jan 7, 2013 at 9:29 AM, Neil Bothwick n...@digimed.co.uk wrote: WHAT?! No tagline? I was experimenting with Enlightenment... clearly it isn't :) Raster is screwing with your head. He does that :-) E17 is all about choice. Like these: You get to chose if you want to chase through 17 dialogs to find the one that sets the thing you want to change. Then you get to choose to change it or not. You choose to notice your tagline going missing and you still can chose if you want to fix it or not. Then go to the first example. You even get to chose to become enlightened or remain un-enlightened (for varying definitions of enlightened) and you get to chose your next next. All with the obligatory search through 17 different config dialogs at each step of them process. See? E17 is all about choice. All the choices all the time. Even the ones you have absolutely no idea at all what they are. :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Anyone succeeded with kmail2?
On Tue, 8 Jan 2013 01:32:29 +0200, Alan McKinnon wrote: I was experimenting with Enlightenment... clearly it isn't :) Raster is screwing with your head. He does that :-) E17 is all about choice. Like these: [snippage] See? E17 is all about choice. All the choices all the time. Even the ones you have absolutely no idea at all what they are. For the time being, I chose to go back to KDE :) -- Neil Bothwick Suborbital Ballistic-Propulsion Engineer Not Exactly A Rocket Scientist signature.asc Description: PGP signature
Re: [gentoo-user] Re: 4 machines - no /dev/cdrom or /dev/dvd anymore
On Mon, Jan 7, 2013 at 3:25 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On Mon, 7 Jan 2013 09:37:05 -0800 Mark Knecht markkne...@gmail.com wrote: Now, my point is that change to /dev/srX was the root cause is FUD. It isn't the root cause of this change because it didn't change on my systems. All I know is that ID_PATH (from the old file) used to work and no longer does. Whatever is responsible for creating that, likely some portion of the kernel, changed the value and created a need to modify how udev looks at the system. Is it a bug? I don't know. It's just the way it is. It's not a bug as /dev/dvd is a mere convenience for the user - a nickname if you will. You are highly unlikely to find a standards doc of any kind stating the symlink should be there. Which means if it's not there, you get to make your own convenient nicknames. /dev/harddrive has never existed, right? Same with /dev/dvd and friends. make them if you want, but you can't expect them to be there and their absence is not a bug. Obviously someone left them out of the rules files. Maybe they had a reason, maybe they got lazy. Either way you get to add your own rules to get the names YOU want. It really is as simple as that, don't overthink this one. -- Alan McKinnon alan.mckin...@gmail.com Alan, While I don't completely disagree with your POV, let's at least agree that it is nothing other than your POV. I have a different one, but as it's mine it's clearly of little interest or value. I really don't see why I'm the one getting banged on here but that's life sometimes. I saw a problem for a couple of months. It frustrated me but not enough to do anything about it. Solving it finally bubbled up high enough on my list that I finally asked if others were having the same problem. (which they were, and which they also considered a problem) Before anyone had actually answered me I had posted one way that folks who cared could fix it. I thought I was doing the community a small service by getting a little bit of technically positive info out there. I guess not in this case. Sorry for wasting bandwidth. I suspect it's time for me to unsubscribe and just read gentoo-user in a list somewhere. Sad, but flotsam jetsam I suppose... Over an out, Mark
Re: [gentoo-user] Re: 4 machines - no /dev/cdrom or /dev/dvd anymore
On Jan 7, 2013 8:08 PM, Mark Knecht markkne...@gmail.com wrote: On Mon, Jan 7, 2013 at 3:25 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On Mon, 7 Jan 2013 09:37:05 -0800 Mark Knecht markkne...@gmail.com wrote: Now, my point is that change to /dev/srX was the root cause is FUD. It isn't the root cause of this change because it didn't change on my systems. All I know is that ID_PATH (from the old file) used to work and no longer does. Whatever is responsible for creating that, likely some portion of the kernel, changed the value and created a need to modify how udev looks at the system. Is it a bug? I don't know. It's just the way it is. It's not a bug as /dev/dvd is a mere convenience for the user - a nickname if you will. You are highly unlikely to find a standards doc of any kind stating the symlink should be there. Which means if it's not there, you get to make your own convenient nicknames. /dev/harddrive has never existed, right? Same with /dev/dvd and friends. make them if you want, but you can't expect them to be there and their absence is not a bug. Obviously someone left them out of the rules files. Maybe they had a reason, maybe they got lazy. Either way you get to add your own rules to get the names YOU want. It really is as simple as that, don't overthink this one. -- Alan McKinnon alan.mckin...@gmail.com Alan, While I don't completely disagree with your POV, let's at least agree that it is nothing other than your POV. I have a different one, but as it's mine it's clearly of little interest or value. I really don't see why I'm the one getting banged on here but that's life sometimes. I saw a problem for a couple of months. It frustrated me but not enough to do anything about it. Solving it finally bubbled up high enough on my list that I finally asked if others were having the same problem. (which they were, and which they also considered a problem) Before anyone had actually answered me I had posted one way that folks who cared could fix it. I thought I was doing the community a small service by getting a little bit of technically positive info out there. I guess not in this case. Sorry for wasting bandwidth. I suspect it's time for me to unsubscribe and just read gentoo-user in a list somewhere. Sad, but flotsam jetsam I suppose... Over an out, Mark Eh. Please stick around. Udev is a polarizing issue wherever it pops up.
Re: [gentoo-user] Processes hang - system dies
On Sun, Jan 6, 2013 at 1:05 AM, Robin Atwood robin.atw...@attglobal.netwrote: ** I have a very severe problem after a recent disk replacement. After a few days running, all new processes just hang. The kernel reports: My guess is disk failing or kernel bug. Install smartmontools and see if smartctl -H devicename returns anything interesting. What kernel are you using? Try 3.7.1 if you're not already using that.
Re: [gentoo-user] Re: Ethernet Machination
On Sat, Jan 5, 2013 at 11:45 AM, Mark Knecht markkne...@gmail.com wrote: On Sat, Jan 5, 2013 at 8:03 AM, Kerin Millar kerfra...@fastmail.co.uk wrote: james wrote: After deleting the 70-persistent-net.rule file udev does not re-create it. All is now fine with rc-status only showing net.eth0 which is set up how I like it per /etc/conf.d/net. All services are fine Beware. SNIP This doesn't appear to be common knowledge, so it struck me as worth mentioning. Cheers, --Kerin Very interesting info. Thanks! Cheers, Mark I think the proper explanation is here: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames Regards. -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
Re: [gentoo-user] Re: 4 machines - no /dev/cdrom or /dev/dvd anymore
On Tuesday 08 Jan 2013 01:15:10 Michael Mol wrote: On Jan 7, 2013 8:08 PM, Mark Knecht markkne...@gmail.com wrote: Sorry for wasting bandwidth. I suspect it's time for me to unsubscribe and just read gentoo-user in a list somewhere. Sad, but flotsam jetsam I suppose... Over an out, Mark Eh. Please stick around. Udev is a polarizing issue wherever it pops up. Mark, I don't think anyone is having a go at you and FWIW you're not wasting *my* bandwidth. I found your suggestion useful for solving this problem. Meanwhile, this bug has been kicking around recognising that there is indeed a problem, which it seems will be solved with udev-196-r1: https://bugs.gentoo.org/show_bug.cgi?id=444604 I haven't upgraded yet to see if it works. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Re: 4 machines - no /dev/cdrom or /dev/dvd anymore
On Mon, 7 Jan 2013 22:53:19 + Mick michaelkintz...@gmail.com wrote: On Monday 07 Jan 2013 07:35:32 Dale wrote: BTW, pressing the touch sensitive button on the laptop to eject the CD won't work, neither will typing eject in a terminal: $ eject eject: tried to use `/mnt/cdrom' as device name but it is no block device eject: unable to find or open device for: `cdrom' So, eject is still looking for cdrom ... Either all commands and legacy apps should update themselves, or I better follow Mark's suggestion? Mick, You can tell eject which device to eject by adding the device-name to the command, eg: # eject /dev/sr0 This also works with USB-drives/sticks :) -- Joost
Re: [gentoo-user] OT: Fighting bit rot
Am 08.01.2013 00:20, schrieb Alan McKinnon: On Mon, 07 Jan 2013 21:11:35 +0100 Florian Philipp li...@binarywings.net wrote: Hi list! I have a use case where I am seriously concerned about bit rot [1] and I thought it might be a good idea to start looking for it in my own private stuff, too. [...] [1] http://en.wikipedia.org/wiki/Bit_rot Regards, Florian Philipp You are using a very peculiar definition of bitrot. bits do not rot, they are not apples in a barrel. Bitrot usually refers to code that goes unmaintained and no longer works in the system it was installed. What definition are you using? That's why I referred to wikipedia, not the jargon file ;-) The definition that I thought about was decay of storage media, especially hard disks. I'm not aware of another commonly used name for that effect. Disk rot seems to apply only to optical media. If you mean crummy code that goes unmaintained, then keep systems up to date and report bugs. If you mean disk file corruption, then doing it file by file is a colossal waste of time IMNSHO. You likely have 1,000,000 files. Are you really going to md5sum each one daily? Really? Well, not daily but often enough that I likely still have a valid copy as a backup. This is a filesystem task, not a cronjab task. Use a filesystem that does proper checksumming. ZFS does it, but that is of course somewhat problematic on Linux. Check out the others, it will be something modern you need, like ext4 maybe or btrfs AFAIK, ext4 only has checksums for its metadata. Even if the file system would support appropriate checksums out-of-the-box, I'd still need a tool to regularly read files and report on errors. As I said above, the point is that I need to detect the error as long as I still have a valid backup. Professional archive solutions do this on their own but I'm looking for something suitable for desktop usage. Regards, Florian Philipp signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] OT: Fighting bit rot
On Tue, 08 Jan 2013 08:27:51 +0100 Florian Philipp li...@binarywings.net wrote: This is a filesystem task, not a cronjab task. Use a filesystem that does proper checksumming. ZFS does it, but that is of course somewhat problematic on Linux. Check out the others, it will be something modern you need, like ext4 maybe or btrfs AFAIK, ext4 only has checksums for its metadata. Even if the file system would support appropriate checksums out-of-the-box, I'd still need a tool to regularly read files and report on errors. As I said above, the point is that I need to detect the error as long as I still have a valid backup. Professional archive solutions do this on their own but I'm looking for something suitable for desktop usage. rsync might be able to give you something close to what you want easily Use the -n switch for an rsync between your originals and the last backup copy, and mail the output to yourself. Parse it looking for and symbols and investigate why the file changed. This strikes me as being a very easy solution that you could use reliably with a suitable combination of options. -- Alan McKinnon alan.mckin...@gmail.com
