GRUB installation

Where in GRUB (this is - understand - the Legacy GRUB coming with SUSE 12.1) can I edit the boot partitions identifiers and then install GRUB on an external HDD that shall eventually become the main bootable HDD.

Background:
I am in a process of system upgrading, but because of rather complex SUSE/WinXP combination I want by all means to preserve the structure that is working well now.

Using dd I copied the 7 partitions I was using to a new, much larger HDD, and they are well visible when attached by USB. No surprise that the new HDD wont boot, since the dd copied old GRUB entries while the IDs/names of the partitions on the new HDD are different. I may try to rename new partitions to the old names, but I am afraid to do this, coz there will be moment when two sets of bootable partitions operate simultaneously on my system. Therefore I want to do what should be done: install the GRUB on the new HDD with the new partition references.

I read quite a lot about the process, and all the config files in /boot/grub/ mentioned on the WEB, suspected on keeping these references, are not editable. The only way to edit them is to use the BootLoader Settings tool, but it seems ready to setup ONLY the data on the disk it was loaded from (the old HDD) while I want to setup the data on the external HDD.
I can do it with boot-install but dont know from where the installer will retrieve the data.

Cloning is a routine procedure here, something done more often than
“installing” distros. I normally find it easier to upgrade a clone to a next
release than to do a fresh installation of a new release from scratch. I
upgrade a clone instead of installing new at a roughly 3:1 or 4:1 ratio.
Upgrading to a bigger HD is done here less often, but it’s still a common
occurrence with the relatively large number of machines that come to me with
only 20GB or 40GB HDs.

When I clone a HD I usually create new partitions first, then reboot, so that
the kernel will have appropriate references to starting points and sizes, but
with no content otherwise. I then do the cloning, which leaves the new
partitions with the old sizes, UUIDs and labels. Next I use tune2fs to set
new UUIDs and LABELs on the cloned partitions, followed by resizing them (if
and as necessary) with resize2fs, then mounting them and editing the
/etc/fstab(s), /etc/grub.conf(s), /boot/grub/device.map(s) and
/boot/grub/menu.lst(s) of the clones, all to work as a primary HD. Last
things are to open the Grub shell and run setup on whichever partition(s)
need it done to be able to boot, ensure whichever primary partition needs to
be set active has its flag set, and write generic boot code to the clone
disk’s MBR (if it doesn’t already live there).

“The wise are known for their understanding, and pleasant
words are persuasive.” Proverbs 16:21 (New Living Translation)

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

Cloning is a routine procedure here, something done more often than
“installing” distros. I normally find it easier to upgrade a clone to a next
release than to do a fresh installation of a new release from scratch. I
upgrade a clone instead of installing new at a roughly 3:1 or 4:1 ratio.
Upgrading to a bigger HD is done here less often, but it’s still a common
occurrence with the relatively large number of machines that come to me with
only 20GB or 40GB HDs.

When I clone a HD I usually create new partitions first, then reboot, so that
the kernel will have appropriate references to starting points and sizes, but
with no content otherwise. I then do the cloning, which leaves the new
partitions with the old sizes, UUIDs and labels. Next I use tune2fs to set
new UUIDs and LABELs on the cloned partitions, followed by resizing them (if
and as necessary) with resize2fs, then mounting them and editing the
/etc/fstab(s), /etc/grub.conf(s), /boot/grub/device.map(s) and
/boot/grub/menu.lst(s) of the clones, all to work as a primary HD. Last
things are to open the Grub shell and run setup on whichever partition(s)
need it done to be able to boot, ensure whichever primary partition needs to
be set active has its flag set, and write generic boot code to the clone
disk’s MBR (if it doesn’t already live there).

The wise are known for their understanding, and pleasant
words are persuasive.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

On 2014-08-10 13:16, ssemczuk wrote:
>
> Where in GRUB (this is - understand - the Legacy GRUB coming with SUSE
> 12.1) can I edit the boot partitions identifiers and then install GRUB
> on an external HDD that shall eventually become the main bootable HDD.

AFAIK grub 1 does not use “names”, but disk references by something
related to bios numbers. So hd0 is the first disk in the bios order.

Finding the right disk number is not trivial. You run the command
“grub”, and then use a command like “find” to locate the disk and
partition notation.

You have to edit :

/boot/grub/menu.lst
/boot/grub/device.map
/etc/grub.conf
/etc/fstab

And then reinstall grub. The command is actually stored in “/etc/grub.conf”.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

On 2014-08-10 14:13 (GMT) Carlos E. R. composed:

> On 2014-08-10 13:16, ssemczuk wrote:

> Finding the right disk number is not trivial. You run the command
> “grub”, and then use a command like “find” to locate the disk and
> partition notation.

How is that not trivial compared to the alternative…

> You have to edit :

> /boot/grub/menu.lst
> /boot/grub/device.map
> /etc/grub.conf
> /etc/fstab

> And then reinstall grub. The command is actually stored in “/etc/grub.conf”.

You forgot the necessity of having the target mounted, via chroot if necessary.

To recover functional Grub after a clone operation, where as the OP has done, keeping the number and relative position of partitions the same, “have to” do all 5 (sic) things is incorrect.

#1-/etc/grub.conf is an openSUSE exclusive. Whether it’s used by perl-Bootloader or yast2-bootloader I don’t remember, but it isn’t a prerequisite to making Grub work.

#2-/etc/boot/device.map would only need to be changed if it doesn’t already contain a generic reference to the target disk (e.g. sda), as opposed to a by-id reference (e.g. /dev/disk/by-id/yadayadayada…)

#3/etc/grub/menu.lst would only need to be changed if the root= parameter needs changing. IOW, if e.g. root=/dev/sda1 or root=LABEL=<preservedPartitionLabel> or root=/dev/disk/by-label/<preservedPartitionLabel> then no change would be required, as opposed to a UUID or device ID as a root=.

#4-/etc/fstab parallels menu.lst.

#5-Whether chrooting is simple or not is a matter of opinion. It does require several steps to initiate before any scripts or yast can be run.

#6-“reinstall Grub” is a term with multiple meanings. It could include resintalling the rpm providing it, or it could mean grub-install, or it could mean simply using Grub’s ‘setup’ command.

When there is no necessity to edit config files, that leaves as the only necessity that the Grub ‘setup’ command be run. Doing so requires no chroot, not even any partition mounting. Generally it can be as simple as as follows:

grub # open Grub’s shell

> find /boot/grub/stage1 # list partitions containing Grub’s files
> root (hdD,P) # e.g. (hd0,2), which tells shell the files it needs are on 1st disk on 3rd partition
> setup (hdD,P) # e.g. (hd0,2), “installs” Grub to target partition (makes partition bootable)
> quit

Above is the short and simple procedure I use to “install” Grub after a clone operation. It’s what I consider “trivial”. The only prerequisite is first booting something that provides the ability to run the Grub Legacy shell.

OTOH, getting all the way into chroot only to execute a script that does no more than perform Grub Legacy setup is more than trivial, while editing of any of the config files that do need changing, which grub-install and other alternatives to simply running setup in a Grub shell do not do, simply requires appropriate partition(s) be mounted with write permission.

The wise are known for their understanding, and pleasant
words are persuasive.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

On 2014-08-10 18:21, Felix Miata wrote:
> On 2014-08-10 14:13 (GMT) Carlos E. R. composed:

> How is that not trivial compared to the alternative…

I did not say that any alternative is trivial.

> You forgot the necessity of having the target mounted, via chroot if necessary.

Probably.

> To recover functional Grub after a clone operation, where as the OP has done, keeping the number and relative position of partitions the same, “have to” do all 5 (sic) things is incorrect.

Well, no, you can recover grub without doing some of that. But you have
to do all of that, regardless, for other reasons. Ah, and you also
probably need to rerun mkinitrd, with the appropriate chroot, of course.

>
> #1-/etc/grub.conf is an openSUSE exclusive.

But we are at an openSUSE forum :slight_smile:

> #2-/etc/boot/device.map would only need to be changed if it doesn’t already contain a generic reference to the target disk (e.g. sda), as opposed to a by-id reference (e.g. /dev/disk/by-id/yadayadayada…)

/boot/grub/device.map, not /etc/boot/device.map

You have to edit the file and change if necessary. Maybe it is not. And,
it is not used for actual booting.

> #3/etc/grub/menu.lst would only need to be changed if the root= parameter needs changing. IOW, if e.g. root=/dev/sda1 or root=LABEL=<preservedPartitionLabel> or root=/dev/disk/by-label/<preservedPartitionLabel> then no change would be required, as opposed to a UUID or device ID as a root=.

I did not say “change” :slight_smile:

> #4-/etc/fstab parallels menu.lst.

Huh? No, the files are different, and for different purposes.

> #5-Whether chrooting is simple or not is a matter of opinion. It does require several steps to initiate before any scripts or yast can be run.
>
> #6-“reinstall Grub” is a term with multiple meanings. It could include resintalling the rpm providing it, or it could mean grub-install, or it could mean simply using Grub’s ‘setup’ command.

Well, yes. :slight_smile:

> When there is no necessity to edit config files, that leaves as the only necessity that the Grub ‘setup’ command be run. Doing so requires no chroot, not even any partition mounting. Generally it can be as simple as as follows:
>
> # grub # open Grub’s shell
>> find /boot/grub/stage1 # list partitions containing Grub’s files
>> root (hdD,P) # e.g. (hd0,2), which tells shell the files it needs are on 1st disk on 3rd partition
>> setup (hdD,P) # e.g. (hd0,2), “installs” Grub to target partition (makes partition bootable)
>> quit
> #
>
> Above is the short and simple procedure I use to “install” Grub after a clone operation. It’s what I consider “trivial”. The only prerequisite is first booting something that provides the ability to run the Grub Legacy shell.

Well, yes, it is simple :slight_smile:

But nevertheless, the files have to be edited. Not necessarily /changed/.


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

On 2014-08-10 18:03 (GMT) Carlos E. R. composed:

>> To recover functional Grub after a clone operation, where as the OP has done, keeping the number and relative position of partitions the same, “have to” do all 5 (sic) things is incorrect.

> Well, no, you can recover grub without doing some of that. But you have
> to do all of that, regardless, for other reasons.

No, you do not “have to” You may have to, and then not necessarily “all”.

> Ah, and you also
> probably need to rerun mkinitrd, with the appropriate chroot, of course.

Doubtful “probably”. I can’t remember ever needing an initrd rebuilt because
of needing to repair Grub.

After cloning, the only times I found any new initrds necessary were when
initrds had been limited to including only drivers specific to the particular
hardware combination, and the HD was going into a different one, such as
moving from Intel CPU and HD controller to AMD, or vice versa. I suppose need
to rebuild initrd could apply also to people using proprietary video drivers,
which I never do on any machines I own.

>> #1-/etc/grub.conf is an openSUSE exclusive.

> But we are at an openSUSE forum :slight_smile:

Which Google will return results from even when the searcher isn’t
necessarily looking for more than generic info. Typing Linux is easier than
typing openSUSE too, and dispenses with the need ever to figure out how it
should be spelled when it needs to begin a sentence.

> /boot/grub/device.map

> You have to edit the file and change if necessary. Maybe it is not. And,
> it is not used for actual booting.

Exactly, “if”. That means only for the Grub shell to run properly, or a when
a script depending on the Grub shell is run.

>> #4-/etc/fstab parallels menu.lst.

> Huh? No, the files are different, and for different purposes.

Then you didn’t understand that what I wrote simply meant ditto #3,
substituting /etc/fstab for /boot/grub/menu.lst, and subsituting for Grub’s
root= references the first column entries in fstab.

> But nevertheless, the files have to be edited. Not necessarily /changed/.

They don’t need editing (“have to be edited”) if they don’t need changing.
Viewing to determine if editing is warranted can be done with any available
text viewer, including cat and less. Normally here that means F3, and maybe
nav keys. :slight_smile: And if one knows nothing needs doing except to run Grub’s
setup, going even to the trouble of mounting isn’t even required.

The wise are known for their understanding, and pleasant
words are persuasive.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

Correct.

> #1-/etc/grub.conf is an openSUSE exclusive.

But we are at an openSUSE forum :slight_smile:

… gee, that is what I thought, too. :wink:

> #2-/etc/boot/device.map would only need to be changed if it doesn’t already contain a generic reference to the target disk (e.g. sda), as opposed to a by-id reference (e.g. /dev/disk/by-id/yadayadayada…)

/boot/grub/device.map, not /etc/boot/device.map

You have to edit the file and change if necessary. Maybe it is not. And,
it is not used for actual booting.

… again, Carlos is correct.

> #4-/etc/fstab parallels menu.lst.

Huh? No, the files are different, and for different purposes.

And this is especially true. Do not get these two mixed up.

> #5-Whether chrooting is simple or not is a matter of opinion.

It is simple, in my opinion, and several failsafe guides to doing so have been fully spelled out in multiple threads on this forum, some of them by myself.

On 2014-08-13 02:16 (GMT) Fraser Bell composed:

> Carlos Wrote:

>> Felix Miata wrote:

>>> To recover functional Grub after a clone operation, where as the OP
>>> has done, keeping the number and relative position of partitions the
>>> same, “have to” do all 5 (sic) things is incorrect.

>> Well, no, you can recover grub without doing some of that. But you have
>> to do all of that, regardless, for other reasons. Ah, and you also
>> probably need to rerun mkinitrd, with the appropriate chroot, of course.

> Correct.

Apparently you and Carlos just haven’t exposed yourselves to as many or as
big a variety of cloning instances as others. I’ve been able to do less than
all six steps on a cloned disk too many times to count. It has been
relatively routine on a large collection of older machines here, retiring
disks of under 80GB in order to add more OS installations whilst eliminating
none, often moving older installations to end of disk to keep newer
installations closer to the typically faster front of disk.

Keep trying and maybe eventually you’ll understand what I previously wrote,
that all may be necessary, in many cases, possibly most, but very
definitely not all six steps are required in every case, and particularly
not in the case where the logical order of a partition by partition clone to
a bigger disk, as the OP did, is not changed. IOW, how many of the six would
be required in any particular case varies. Done in correct sequence, OP’s
particular scenario might require as little as one step from among the six,
that of running setup (“installing” Grub to a partition) from a Grub shell.

Editing of /etc/grub.conf is definitely not prerequisite to initial success
(booting the clone’s openSUSE installation at least once), though it possibly
might be necessary prior to allowing any of the scripts that depend on it
to run. IIRC, I’ve never seen an /etc/grub.conf that referred to a partition
via by-id, by-path or by-uuid, only ever by Grub disk number and partition
number, and so on any of my own installations, editing of grub.conf would
never be prerequisite to total success under the OP’s cloning scenario.

The wise are known for their understanding, and pleasant
words are persuasive.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

On 2014-08-13 05:38, Felix Miata wrote:
> On 2014-08-13 02:16 (GMT) Fraser Bell composed:
>
>> Carlos Wrote:

> Editing of /etc/grub.conf is definitely not prerequisite to initial
> success (booting the clone’s openSUSE installation at least once),
> though it possibly might be necessary prior to allowing any of the
> scripts that depend on it to run.

Exactly, which is why I said that it has to be edited. I did not specify
that it was necessary for “initial success” :slight_smile:

> any of my own installations, editing of grub.conf would never be
> prerequisite to total success under the OP’s cloning scenario.

In my parlance, “editing” doesn’t necessarily mean “change”. An editor
is just a convenient way to look at the contents, and then decide if a
change is needed or not :slight_smile:


Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

On 2014-08-13 09:33 (GMT) Carlos E. R. composed:

> Felix Miata wrote:

>> Editing of /etc/grub.conf is definitely not prerequisite to initial
>> success (booting the clone’s openSUSE installation at least once),
>> though it possibly might be necessary prior to allowing any of the
>> scripts that depend on it to run.

> Exactly, which is why I said that it has to be edited. I did not specify
> that it was necessary for “initial success” :slight_smile:

Again, “might”, same as possibly, same as possibly not, same as maybe, same
as maybe not, unlike here, where on:

>> any of my own installations, editing of grub.conf would never be
>> prerequisite to total success under the OP’s cloning scenario.

> In my parlance, “editing” doesn’t necessarily mean “change”. An editor
> is just a convenient way to look at the contents, and then decide if a
> change is needed or not :slight_smile:

In my native English parlance, edit means exactly what #3 @
http://dictionary.reference.com/browse/editing?s=t above says it means, same
as what my 1973 Webster’s catalogs as 1(c). You’re still responding as though
you don’t get that. To edit implies change, a necessary component of the
process. Examining a file is not equivalent to changing a file. One might use
an editor to do the examining, but that does not make the examination process
“editing”.

The wise are known for their understanding, and pleasant
words are persuasive.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata *** http://fm.no-ip.com/

Tee-hee-hee …rotfl!