nstalling GRUB on a disk that is going to be actually installed on a different comput

[reedhedges]

Hello,

I hope I'm wording this issue clearly.

I'd like to plug a disk (IDE or SATA) into an adapter that lets me plug it into my workstation via USB. (E.g. N82E16817153071 at newegg)

It will show up as /dev/sdX where X is some arbitrary letter depending on what other disks the system happens to have.

I'd like to have a script then partition, format and copy files onto it. Then we need to install GRUB on it.

Then I will remove the disk and install it permanently into a different computer, here it will either be /dev/hda (if IDE) or /dev/sda (if SATA).

However, it seems that in general when you install GRUB on a disk, it assumes it is going to be the same disk that boots??

I am first trying an IDE disk so it will be /dev/hda.

I get a "GRUB Hard Disk Error" when booting it as /dev/hda rather than whetever it was on the USB adapter. I used this to install grub:

grub-install --root-directory /mnt/removable/ /dev/sdX

Where X was the appropriate letter based on the USB adapter. Then I fixed /mnt/removable/boot/grub/device.map to use /dev/hda../dev/hdc instead of sda..sdc.

I haven't found much about this specific scenario I have so far on the web.

I am guessing that stage1 is either attempting to find files based on what the original workstations primary disk geometry was, or it's assuming that the disk is the same location as it was when it was a "removable" one (i.e. /dev/sdX or (hd5) or whatever, when it should just be looking at (hd0).

The goal is to do this kind of installation easily and quickly, and not have to do it individually on each final computer via install CDROM or whatever, or reboot the workstation each time in order to attach the disk as the same location there, etc. (This is a manufacturing setting).

Thanks for any ideas you have!

Reed

[coopstah13]

most recent distros, anything from past 2 years anyway, don't refer to IDE disk as hdX, they still are referred to as sdX

that being said, I think the problem is more along the lines of what you are saying that it is using the information about how it is currently recognized

maybe you should look into something like clonezilla, since running a disk imaging process will be much faster than running file copies, you could set up a workstation how you want it, then use clonezilla to make the image, then you can image any disk you want

[reedhedges]

I have looked at clonezilla, and the one part of it that I would want to use is not exactly what I want and not documented at all (not much of clonezilla is really documented except the general user interface) or easy to use on its own. (Clonezilla is good at network booting and installing on that computer.... I do use it for some things that need that but this is different). Imaging a whole disk block by block is actually pretty slow, and I want to be able to use the exact same procedure and file set for different kinds of storage devices of different sizes, maybe with different partitioning schemes, and want to make it really easy and foolproof to maintain the files that go on the disk (I.e. change the file and commit to revision control, that's it).

Thanks for the tip about the naming in /dev. I wan't really aware of that, since I've always only used SATA devices on newer systems with newer kernels I may need to use this procedure to make systems that run a pretty old kernel, but can deal with the /dev naming later if needed.

One additional question -- is devices.map neccesary to boot? Or is it just used when installing grub on a disk?

[yancek]

One additional question -- is devices.map neccesary to boot? Or is it just used when installing grub on a disk?

This link might help:

Device map - GNU GRUB Manual 1.98

[coopstah13]

clonezilla only clones the data that is there on the partitions, it isn't a byte by byte clone of a disk as long as it is a supported FS, I set up systems with 120gb disks and the installs on them only had 5-10gb, takes like 5 minutes to write it to a new disk

you can run clonezilla from the command line onto any target device with no interaction by you after you enter the command, the longest task is setting up the base image to clone from, once you create the clone you can run clonezilla from anywhere standalone pretty easily

[reedhedges]

clonezilla only clones the data that is there on the partitions, it isn't a byte by byte clone of a disk as long as it is a supported FS, I set up systems with 120gb disks and the installs on them only had 5-10gb, takes like 5 minutes to write it to a new disk

you can run clonezilla from the command line onto any target device with no interaction by you after you enter the command, the longest task is setting up the base image to clone from, once you create the clone you can run clonezilla from anywhere standalone pretty easily

What is the command? Do you know where that is documented?

[coopstah13]

when you do it with the wizard manually, it puts the command in a text file for running it next time, this is how I figured it out

there is stuff on the site under related documents too