On 08/05/2011 08:17 AM, Felix Miata wrote:

device.map got me last week too: http://lists.opensuse.org/opensuse-factory/2011-07/msg00422.html

Especially important when handling dmraid arrays.... eg: 08:34 archangel:~> cat /boot/grub/device.map (hd0) /dev/mapper/nvidia_fdaacfde (hd1) /dev/mapper/nvidia_baaccaja Any changes to dmraid arrays will require updates of the dmraid ID in device.map. You can also control which drive, or array, is seen by grub as (hd0) and (hd1) by adjusting the device.map designations. -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On 8/5/2011 11:52 AM, Constant Brouerius van Nidek wrote:

On Friday, August 05, 2011 09:17:42 AM Felix Miata wrote:

...

On 2011/08/05 18:31 (GMT+0700) Constant Brouerius van Nidek composed:

...

After the exchange of my hd0 hard-disk I had to remove manually the existence of the old drive. I remember that I used midnight commander to find all places that mentioned the old drive.

Do you use a separate /boot that was not mounted at the time? In any event, you missed one.

...

The new drive is working properly but at boot or in case I install the latest kernel I get the message:

Perl-Bootloader: 2011-08-05 17:38:09 ERROR: GRUB::GrubDev2UnixDev: did not find a match for hd0 in the device map

Is there an automatic method to get rid of this message?

The tools aren't set up to fix things like this that result from HD cloning.

...

I reckoned that the

system would do a self-repair after partitioning and such.

device.map got me last week too: http://lists.opensuse.org/opensuse-factory/2011-07/msg00422.html

Thanks, I was there just now and the repair is done. Not reading the factory list so I missed it. Thought originally that if the hardware information from Yast which shows the correct hard disk would do automatically a update. Well manual work is also fun ;).

It's hard for stuff like that to be both automatic and safe. There are several ways to set up grub and no one way is best. The same scheme that would be safest and be the most successfully automatic for one user, will be instant death for another user. So it's pretty expected that the tools should be very shy about making automated changes to critical boot files. Not even with prompts that ask "I'm about to make this change, is this ok?" because too many users would have no idea if the proposed change is correct or not. Not saying it's not theoretically possible at least in most cases, but it's just "hard". There are situations where the OS sees the hardware completely differently than the bootloader does, and before that the bios sees the hardware differently from either the bootloader or the OS. They sometimes require very arcane setups that no automated tool running in the OS, and therefore only seeing the hardware as the OS sees it, and having absolutely no even theoretical way to guess or deduce how the bios and bootloader will see things, if it made any change based on what it can see, it would only break the install and the next boot will fail. Some human has to figure out what is required and the tools have to just say "ok, this doesn't make any sense to me, but I'll just blindly do what you say, hope you know what you're doing". That's why they generally don't change existing configs, in case they had been manually set by the user. Also, there are more than one way to possibly do things automatically, resulting in different outcomes, which are each correct, but for different people in different situations with different wishes. You can't have all possible types of automatic, you have to choose one or another since they exactly oppose each other in some cases. What I mean is, in one case, you may say "I want these hard drives to work no matter where they are plugged in and no matter which order the bios/bootloader/kernel discovers them. So the safest way to do that is use uuid referencing. The kernel looks at all devices without caring what kind of controller they're plugged in to or which port they are in, and finds the one with the uuid it wants. If you have a motherboard die and move all your drives to another one, this makes it very likely that it will automatically work on the new motherboard. If the drive in question is say a usb thumb drive that moves around, same thing. volume label also works for this, but, volume label is also a little unsafe. Say the drive is used for booting and you set the label to "boot", it's too easy for someone to plug in another drive labeled boot. But, as what happened to you, if it's all set up using uuid, but the drive failed instead of the motherboard, blam, new drive has it's own uuid which is by definition [u]nique. So you can have both situations work sometimes by using the older device name approach, /dev/sda instead of uuid or label, but then that isn't actually very reliable in either case whether it's the drive or the controller that changes. Either one may cause the device name to change, or not, depending on your particular hardware and your particular use of it. It's just not a simple situation and parts of it are worse than merely not simple, they're plain impossible to predict with certainty, programatically. Probably there are things that could be done that will make the tools a lot better and at least come pretty close, become more automatic and more likely to be right, it just can't probably ever be 100% at least with todays hardware and mish mash of standards behaviors of different hardware. Definitely suse yast bootloader screens could be _way_ _way_ better in terms of: * Help that explains exactly what each and every choice and checkmark and input box will do. With links to upstream on-line docs that go into full detail for those things that need a lot of explaining. It's practically unusable right now. I happen to be pretty good with grub and am pretty aware of all the unsuspected hardware and firmware/bios gotcha's. I know how to configured grub completely by hand. And yet, _I_ couldn't tell you what some of the fields in the yast bootloader screens will actually do. It's not a matter of knowing the topic. I know the topic. The tool just doesn't document itself and so it's impossible to know the _tool_ other than by trial & error or reading it's code. * More predictable and expected behavior. There are menu choices that let you edit the config files directly, but then the tool will go and overwrite your manual edits without either telling you that it's going to, or giving you any way to avoid it. Same goes for some of the regular input fields like the "message file" field, which happens to mean "what gfxboot file do you want to load to present the graphical bootloader screen?" For me the only correct answer for that one is "NONE! I'm on a SERIAL CONSOLE. Invoking the vga graphics AT ALL will BREAK MY CONSOLE REDIRECTION." But if you try to blank out the field, or enter ##'s to try and nullify the line so it's not empty but treated as a comment at boot time, the cursed tool just writes gfxboot in there anyway. This happens even if you have manually deselected and taboo'd all the gfxboot and splash and branding packages so that there is physically no gfxboot message file even being installed. You just have to not use the tool, or at least not load certain screens, I haven't mapped out the full behavior, I just avoid using the tool. (Which is a pretty big failure for any tool) * In the installer, the install summary screen just before you say "ok, do it" the bootloader part always (for me, because I'm usually specifying a special boot arrangement booting from a usb thumb drive which the bootloader tool in the installer just refuses to believe is really going to be the boot device at boot time) it always prompts something along the lines of "boot loader location is no longer on /dev/sda, set default location?" What the heck does THAT mean? I never know how to answer it. Does it mean "take the settings you manually provided, and treat them as the new default" or does it mean "throw away the settings you probably set by mistake and use the programs default" ? Absolute perfect example of what's wrong with so many bits of software users are forced to use. There IS NO correct answer to that prompt, but, you MUST answer it one way or the other, and it's even possible that NEITHER options will do what you really want which is "don't touch anything just use the settings I entered" ,given the above point about ignoring or re-writing things you entered in some places. Yes there's a lot of room for improvement but it's still reasonable to leave a change like you had up to you to adjust instead of trying to do it automatically. -- bkw -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

Felix Miata wrote:

Unfortunately, discussing now in context of all the resources being gobbled up by Factory init system overhaul, and looming conversion to Grub 2, probably means little or no developer interest matched to available time for what's left of 12.1's development period. Anyone who thinks perl-Bootloader and yast2-bootloader are bad now is probably in for a fatal shock when the hopelessly under-documented mini operating system called Grub 2 usurps Legacy Grub's default bootloader status. Think about this: Buntu has used Grub 2 for something like 4 releases, yet, the nearly as popular bleeding edge distro Fedora _still_ uses Legacy Grub.

In my experience, ubuntu's grub2 installation is way more reliable than opensuse's grub1 installation has been. I don't use fedora. JMHO. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org

On Friday, August 05, 2011 02:14:25 PM Brian K. White wrote:

On 8/5/2011 11:52 AM, Constant Brouerius van Nidek wrote:

...

On Friday, August 05, 2011 09:17:42 AM Felix Miata wrote:

...

On 2011/08/05 18:31 (GMT+0700) Constant Brouerius van Nidek composed:

...

After the exchange of my hd0 hard-disk I had to remove manually the existence of the old drive. I remember that I used midnight commander to find all places that mentioned the old drive.

Do you use a separate /boot that was not mounted at the time? In any event, you missed one.

...

The new drive is working properly but at boot or in case I install the latest kernel I get the message:

Perl-Bootloader: 2011-08-05 17:38:09 ERROR: GRUB::GrubDev2UnixDev: did not find a match for hd0 in the device map

Is there an automatic method to get rid of this message?

The tools aren't set up to fix things like this that result from HD cloning.>>

...

I reckoned that the

system would do a self-repair after partitioning and such.

device.map got me last week too: http://lists.opensuse.org/opensuse-factory/2011-07/msg00422.html

Thanks, I was there just now and the repair is done. Not reading the factory list so I missed it. Thought originally that if the hardware information from Yast which shows the correct hard disk would do automatically a update. Well manual work is also fun ;).

It's hard for stuff like that to be both automatic and safe. There are several ways to set up grub and no one way is best. The same scheme that would be safest and be the most successfully automatic for one user, will be instant death for another user.

ignoring or re-writing things you entered in some places.

Yes there's a lot of room for improvement but it's still reasonable to leave a change like you had up to you to adjust instead of trying to do it automatically.

Thanks for the input. Learned a lot of it. -- Linux User 183145 using LXDE and KDE4 on a Pentium IV , powered by openSUSE 11.4 (i586) Kernel: 3.0.0-7-desktop LXDE WM & KDE Development Platform: 4.7.00 (4.7.0) 09:52am up 11:26, 3 users, load average: 1.23, 1.12, 1.22 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org