Microsoft is a bunch of crooks and imbeciles, burned my copy of xp

Say Jan,

OK, but don't the "fancier" OS loaders such as GRUB and whatever Vista/Win7 uses occupy a lot more than one sector? So that you can't just, e.g., copy the boot sector and your active partitions from one drive (one-by-one, not a whole drive copy) to another drive and still have the system boot? (Since the boot sector's loader is looking for the "rest" of itself in a fixed position?)

There are. The OP here might want to pick up a copy of Linux User (print magazine), as there's a handful that advertise in there. Most of them are targeting rack-mount servers, but there's still decent pickings for regular desktop and laptop PCs. Dell still sells some of their models with Linux pre-isntalled too.

But also less compatible. :-( Particularly with laptops or netbooks... look at how much effort it takes to get, e.g., an Acer AO751H working with Ubuntu vs. Windows.

That's a lot of good information you've posted; thanks!

---Joel

On a sunny day (Wed, 2 Dec 2009 12:09:39 -0800) it happened "Joel Koltner" wrote in :

Of course I dunno about Vista-win, maybe those write data in secret places. I just gave an example how to edit a disk sector, the boot sector specifically, could be a DVD sector too :-) I have grub installed on hda, on a floppy, and a DVD+RW, so have boot backup options. I know very little about the innards of grub, except in needs 'stage1' 'stage2', and 'menu.lst' and stuff like that. As grub fits on a floppy, it cannot be bigger then that. I have made little 'howto' files for all that stuff for myself, so I do not have to look it up every time.

Well, so far I had no problems, even have a Linux whats it called 'woof?' no oh yes 'Puppy Linux' SDcard for the eeePC as second 'rescue' OS. I have installed and used: SLS Slackware RatHead Suse (several versions) grml puppy and a few more Linuxes, all without problems with installing. This one I am using now, grml, is Debian based, you can install from a live disk. But it is more for servers. More work is getting kernel sources and compiling in drivers. Usually with a new kernel everything stops working. So if it works, do not fix it, upgrade, if you can avoid it. OTOH distributions like Debian do a whole lot of dependencies automatically when upgrading.

Thank you.

Not with a 'word' that spans > 1 page.

Maybe your problem is holding that key down is overflowing some buffer on your machine-- I used cut and paste because I'm lazy and wanted to do it fast.

in it have been read.

bytes in the image file have been read.

This is still far more inefficient and cumbersome than using Norton Ghost. Norton Ghost only copies occupied disk space and can create compressed images taking much less space than a copy of a disk image.

Cut and paste also does it.

To reproduce: I hold the 'd' key until 5.5 lines are full. I hit cursor up two times (up to this point everything is fine) and then press the delete key. Makes Word crash every time. I tried this on several machines with different installs!

The boot sector is 512 bytes and contains a "pointer" to the rest of GRUB, which may be almost anywhere that the OS can reach. The MBR must know where to find the rest of GRUB which includes stages for each of the file system with which it works, as well as a file "menu.1st" which is the boot menu seen on cold boot. This file can contain entries which "point to" other boot sectors, which can then boot other OS's.

Most Linux distros will automagically find other OS's, (including Windows), and set up GRUB to include them on its boot menu. Windows, when installed after Linux, will wipe out the MBR and substitute its own.

Works fine for me. Do you have all of Microsquish's various patches/updates installed? I'm running Word 2003 SP3 + whatever additional security updates MS has issued.

So say I have a copy of my PC's boot section and partition that contains the OS and the "rest of GRUB." I write both to a new hard drive, and let's assume the partition (and hence the rest of GRUB) ends up on different sectors than on the original PC. In that case, (presumably) GRUB's boot sector won't be able to find the rest of itself; is there any super-simple way of fixing the problem?

Thanks for the help,

---Joel

Works fine for me (Dell Vostro laptop).

I can't see any problem with my machines. Perhaps, this could happen because of some 3rd party spell checker or other add-on.

VLV

The method I've used, when in a similar quandry, is to get a simple stand-along GRUB boot image... they can be burned to a CD-R or written to a USB stick. Boot from this, and you'll get a GRUB prompt, as both the initial boot-sector and the later stages of GRUB are loaded from this new medium.

You can then enter the "root" and "kernel" lines to tell GRUB where your kernel image is and what command-line options to use, and then say "boot". Your normal kernel and filesystem environment should then come up. [May take a couple of tries to get all of the options right.]

Once you've brought the system up, log in as root and re-run "grub-install". This will install fresh copies of the later-stage GRUB elements, and write a new boot-sector stage which has the correct load locations for the later-stage elements.

I would get and run "Memtest" that sounds very much like bad memory somewhere.

On a sunny day (Wed, 02 Dec 2009 16:00:13 -0500) it happened Spehro Pefhany wrote in :

I got a funny 'stack overflow' running wine on some application, and a crash. You can have Linux programs crash too that claim too much space on the stack, they wont even start, More memory icould be the solution.

Try running this for different values of the aray size

/* test 38.c */ #include #include

int main(int argc, char**argv) { int a[100000000];

fprintf(stderr, "test38: Hello sizeof(int)=%d\\n", sizeof(int)); }

grml: ~ # gcc -o test38 test38.c grml: ~ # ./test38

Stackspace limitation.

On a sunny day (Wed, 02 Dec 2009 21:05:29 GMT) it happened snipped-for-privacy@puntnl.niks (Nico Coesel) wrote in :

I do not see how cp /dev/hda5 my_image is cumbersome, except if you have a not functioning hand.

You can always run it through gzip, but that makes it slow. Diskspace is not an issue these days, 1TB is now < 100$. Norton is not needed ever. It is only for the clueless.

On a sunny day (Wed, 2 Dec 2009 13:39:25 -0800) it happened "Joel Koltner" wrote in :

If you really copy /dev/hda (without the number) to /dev/hdb, then everything should work (assuming they are the same size). I have done that.

I just came across this tutorial on GRUB:

It's one of the better explanations and seems to answer many questions.

By the time we all get to understand GRUB, GRUB II will be out!

-- Virg Wall

Thanks Dave; that's a reasonably simple approach. One last question: Is /grub part of the "regular old file system" on a given partition (i.e., menu.lst, etc. are stored within your, say, ext2 filesystem just like any other file), or is it a special filesystem that GRUB understands but that actually occupies parts of a partition separate from the rest of your files?

I ask in that it's never been clear to me how, if menu.lst, etc. are all just regular files, GRUB manages to access them since first it would have to be able to find the ext2 or ext3 or reiserfs or jfs or a myriad of other filesystem driver, which seems like a chick-and-egg problem.

---Joel

Thanks, I'll go read up o it!

Maybe they'll come up with a better way to make packages too. I downloaded and begin reading a tutorial on how to make your own .deb (or .rpm) packages, and my eyes quickly rolled into the back of my head. :-) I mean, I realize the problem is rather non-trivial with all the dependencies and whatnot, but in the Windoze world there are at least a dozen readily-available installers that build a setup.exe for you with just a bunch of pointing and clicking -- no dicey editing of manifest files by hand needed.

---Joel

The former.

The only part of GRUB which isn't part of a normal filesystem, is the boot-sector itself - the very first level. The later stages are all stored in a standard filesystem.

When you run "install-grub", the installer asks your filesystem code (e.g. ext2) where the later-stage loading files are (that is, their actual sector offsets within the filesystem partition in which they live). Specifically, it needs to know where "stage1" is, and the "stage1_5" files for any filesystem formats you may need to use to locate your kernel. I'm not sure whether it needs to know where "stage2" is.

It patches these values into the bootloader and/or into stage1.

When you boot up, the boot-sector code now has enough information to locate "stage1" on disk (without having to interpret any filesystem structures) and it loads it. "stage1" has enough information to locate the filesystem interpreter for EXT2, and loads that (and "stage2", I think).

The menu.lst file, and any kernels and initial-RAMdisk images needed, are locate dynamically by (e.g.) "e2fs_stage1_5" - it has enough knowledge of the filesystem structure to be able to navigate directories and load file contents (it's a purely read-only beast). That's why you can navigate through directories dynamically, and boot a kernel which wasn't even on the machine when you installed GRUB.

What this means, is that you need to re-run the grub installer and write a new boot sector any time you move the low-level files around (or update them), but don't need to do this low-level operation when you edit menu.lst, or add a new kernel to your confirmation, or etc.

It's a more sophisticated system than LILO... which requires that you re-run the low-level installer any time you change the kernel. Replace vmlinux, and forget to run LILO again, and at best you'll end up booting your old kernel rather than your new one. At worst, you will sooner or later find that your old vmlinux file's sectors have been re-used for a new file, and the "kernel" you just tried to boot is actually Aunt Mamie's recipe for mango chutney.

Usually doesn't work too well...