|(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix
Prev | Contents | Next
The new chips are the Atom N2600 and N2800, based on the Intel's third-generation Atom architecture, codenamed Cedarview. The Cedar Trail-M platform pairs one of these processors with company's pre-existing NM10 chipset. As with the previous generation Pineview processor, each dual core, four thread chip integrates a GPU. For Cedarwood, the processor is based on a PowerVR design. Cedarview's GPU offers twice the performance of Pineview's. Cedarview adds to this a dedicated media engine for hardware-accelerated decoding of motion video, including support for 1080p H.264.
Cedarview is built on Intel's 32 nm process, compared to the 45 nm process used in Pineview. This allows for reduced power consumption in spite of the faster GPU-5 W for the 1.6 GHz N2600, 8 W for the 1.86 GHz N2800, compared to 10 W for the 1.66 GHz Pineview N570. The new processors also include more aggressive power-saving features than their predecessors. Intel is targeting system runtimes of up to 10 hours, with standby times measured in weeks. The company also claims that systems using the slower N2600 part will draw so little power that they can be passively cooled-no need for fans.
Desktop-oriented Cedarview parts, D2500 and D2700, started shipping in the third quarter of 2011
Disk /dev/dm-0 doesn't contain a valid partition table
This has been very helpful to me. I found this thread by Goggle on dm-0 because I also got the no partition table error message.
Here is what I think:
When the programs fdisk and sfdisk are run with the option -l and no argument, e.g. # /sbin/fdisk -l
they look for all devices that can have cylinders, heads, sectors, etc.
If they find such a device, they output that information to standard output and they output the partition table to standard output. If there is no partition table, they have an error message (also standard output).
One can see this by piping to 'less', e.g.
# /sbin/fdisk -l | less
/dev/dm-0 ... /dev/dm3 on my fedora C5 system seem to be device mappers associated with LVM.
RAID might also require device mappers.
Open a command prompt at any folder
Command prompt fans will welcome this tip. With it, when you're in Windows Explorer, you can open a command prompt to any folder. This tip does exactly what the Windows XP PowerToy "Open Command Window Here" does.
To use it, hold down the Shift key and right-click a folder, then choose "Open command window here" from the context menu that appears. (Note that this tip doesn't work in the Documents folder.)
The User Account Control security produces constant warning messages asking for permission to continue many operations. You can still tweak warning if you consider them overboard:
Here's how to turn UAC on or off, and make it less or more intrusive than the default:
1. Go to the Control Panel --> User Accounts and Family Safety.
2. Click User Accounts, then click Change User Account Control settings.
3. From the screen that appears, use the slider to select the level of protection you want. Here are the four levels and what they mean:
Always notify me. Think of this as UAC Classic. It works like Vista's UAC: When you make changes to your system, when software is installed or when a program tries to make a change to your system, an annoying prompt appears.
Default -- Notify me only when programs try to make changes to my computer. This is, obviously, the default; make a change yourself and UAC leaves you alone. When a program makes a change, a prompt appears and your desktop goes dark, just like it does in Vista. Otherwise, UAC sits there silently.
Notify me only when programs try to make changes to my computer (do not dim my desktop). This setting is identical to the default setting, with one difference: It won't dim your desktop so that you only see the UAC prompt asking you to take action. This presents a slightly elevated security risk over the default setting, because theoretically a program could allow a malicious program to interfere with the UAC prompt.
Never notify me when: In this one, UAC is completely turned off. This is, of course, an insecure option and not recommended for most users.
After you make the selection, click OK. Depending on the selection you made, you may need to restart your system for it to take effect.
If you are not careful you can wipe out your C disk performing a restore of the Windows C partition image to a USB drive, as selection of bootable recovery image somehow redirects recovery to disk C. The warning sign is when Acronis True Image wants to reboot computer to proceed.
If you are brave enough to go past this point, then despite the fact that you explicitly made your target different from bootable drive you need to face unpleasant consequences -- your C partition is now gone.
You can imagine your surprise with the results. I once did that. Thanks God there was no critical data on this wiped C drive. I already migrate it to a new PC. My first reaction was to throw this garbage program where it belongs. But the problem is that other similar programs are not much better and now I am trained not to trust Acronis and probably can do better in future. Another factor is that if you don't use Acronis True Image often you forget about it capabilities (in this case the write decision would be to use cloning of the disk operating, not restoration from the image but the problem was that the disk and image were slightly different and I want the content of the image not the content of the disk.
Still right way would be to do first clone of the disk and then perform restoration of the image to this drive. As I don't use complex operations with Acronis often, I forgot about that and was punished. And believe me you jaw really drops in such cases when you see the results...
Another time, our AIX/370 cluster managed to trash the /etc/passwd file. All 4 machines in the cluster lost their copies within milliseconds. In the next few minutes, I discovered that (a) the nightly script that stashed an archive copy hadn't run the night before and (b) that our backups were pure zorkumblattum as well. (The joys of running very beta-test software).
I finally got saved when I realized the cluster had *5* machines in it - a lone PS/2 had crashed the night before, and failed to reboot. So it had a propogated copy of /etc/passwd as of the previous night.
Go to that PS/2, unplug it's Ethernet.. reboot it. Copy /etc/passwd to floppy, carry to a working (?) PS/2 in the cluster, tar it off, let it propogate to other cluster sites. Go back, hook up the
crashed PS/2s ethernet.. All done.
Only time in my career that having beta-test software crash a machine saved me from bugs in beta-test software. ;)
Once I was in the position of upgrading a Gould PN/9080. I was a good sysadmin, took a backup before I started, since the README said that they had changed the I-node format slightly. I do the upgrade, and it goes with unprecidented (for Gould) smoothness. mkfs all the user partitions, start restoring files. Blam.
I/O error on the tape. All 12 tapes. Both Sets of backups.
However, 'dd' could read the tape just fine.
36 straight hours later, I finally track it down to a bad chip on the tape controller board - the chip was involved in the buffer/convert from a 32-bit backplane to a 8-bit I/O cable. Every 4 bytes, the 5th bit would reverse sense. 20 mins later, I had a program written, and 'dd 3 my_twiddle 3 restore -f -' running.
Moral: Always *verify* the backups - the tape drive didn't report a write error, because what it *received* and what went on the tape were the same....
I'm sure I have other sagas, but those are some of the more memorable ones I've had...
Computer Systems Engineer
From: [email protected] (Bob Arnold)
Organization: Ask Computer Systems Inc., Ingres Division, Alameda CA 94501
Many moons ago, in my first sysadmin job, learning via "on-the-job training", I was in charge of a UNIX box who's user disk developed a bad block. (Maybe you can see it already ...)
The "format" man page seemed to indicate that it could repair bad blocks. (Can you see it now?) I read the man page very carefully. Nowhere did it indicate any kind of destructive behavior.
I was brave and bold, not to mention boneheaded, and formatted the user disk.
The good news:
1) The bad block was gone.
2) I was about to learn a lot real fast :-)
The bad news:
1) The user data was gone too.
2) The users weren't happy, to say the least.
Having recently made a full backup of the disk, I knew I was in for a miserable all day restore. Why all day? It took 8 hours to dump that disk to 40 floppies. And I had incrementals (levels 1, 2, 3, 4, and 5, which were another sign of my novice state) to layer on top of the full.
Only it got worse. The floppy drive had intermittent problems reading some of the floppies. So I had to go back and retry to get the files which were missed on the first attempt.
This was also a port of Version 7 UNIX (like I said, this was many moons ago). It had a program called "restor", primordial ancestor of BSD's "restore". If you used the "x" option to extract selected files (the ones missed on earlier attempts), "restor" would use the *inode number* as the name of the extracted files. You had to move the extracted files to their correct locations yourself (the man page said to write a shellscript to do this :-(). I didn't know much about shell scripts at the time, but I learned a lot more that week.
Yes, it took me a full week, including the weekend, maybe 120 hours or more, to get what I could (probably 95% of the data) off the backups.
And there were a few ownership and permissions problems to be cleaned up after that.
Once burned twice shy. This is the only truly catastrophic mistake I've ever made as a sysadmin, I'm glad to be able to say.
I kept a copy of my memo to the users after I had done what I could. Reading it over now is sobering indeed. I also kept my extensive notes on the restore process - thank goodness I've never had to use them since.
1) The "man" pages don't tell you everything you need to know.
2) Don't do backups to floppies.
3) Test your backups to make sure they are readable.
4) Handle the format program (and anything else that writes directly to disk devices) like nitroglycerine.
5) Strenuously avoid systems with inadequate backup and restore programs wherever possible (thank goodness for "restore" with an "e"!).
6) If you've never done sysadmin work before, take a formal training class.
Well, I haven't thought about that one in a while! I can laugh about it now ....
From: [email protected] (Bob Arnold)
Organization: Ask Computer Systems Inc., Ingres Division, Alameda CA 94501
In article <[email protected]> I wrote:
>I was brave and bold, not to mention boneheaded, and formatted the user disk.
> U rest of story deleted ... Bob ~
> 1) The "man" pages don't tell you everything you need to know.
> 2) Don't do backups to floppies.
> 3) Test your backups to make sure they are readable.
> 4) Handle the format program (and anything else that writes directly
> to disk devices) like nitroglycerine.
> 5) Strenuously avoid systems with inadequate backup and restore
> programs wherever possible (thank goodness for "restore" with
> an "e"!).
> 6) If you've never done sysadmin work before, take a formal
> training class.
Just thought of a few more related morals (managers pay attention now):
7) You get what you pay for.
8) There's no substitute for experience.
9) It's a lot less painful to learn from someone else's experience than your own (that's what this thread is about, I guess :-) )
Part of the story I should tell here. My employer had been looking for a way to cut costs. I was 15% cheaper than their previous sysadmin so they let him go and hired me. It wasn't as nasty as it sounds, since they kept him on as a consultant at 4 hours a week and he ended up with a better job too (so did I). Everyone benefited in the end. I leaned heavily on his consulting, which was great. He was older and wiser, and probably had his own horror stories to tell. After this one, so did I!