Bug 591700 - System fails to boot after "zypper dup" (wrong 'root' in menu.lst)
System fails to boot after "zypper dup" (wrong 'root' in menu.lst)
Status: RESOLVED FIXED
: 596833 795838 (view as bug list)
Classification: openSUSE
Product: openSUSE 11.3
Classification: openSUSE
Component: Bootloader
RC 2
Other Other
: P3 - Medium : Major (vote)
: ---
Assigned To: Steffen Winterfeldt
Jiri Srain
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-28 13:41 UTC by Klaus Kämpf
Modified: 2014-08-15 09:30 UTC (History)
7 users (show)

See Also:
Found By: Development
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
/boot/grub/menu.lst (1.92 KB, application/octet-stream)
2010-03-28 13:42 UTC, Klaus Kämpf
Details
Complete /var/log/YaST2 (433.34 KB, application/x-bzip)
2010-03-28 13:44 UTC, Klaus Kämpf
Details
/var/log/YaST2 (488.11 KB, application/x-gzip)
2010-04-16 18:58 UTC, Klaus Kämpf
Details
/var/log/YaST2 (wrong partition) (1.04 MB, application/x-gzip)
2010-04-16 19:23 UTC, Klaus Kämpf
Details
udevadm for dm-0 (1.50 KB, text/plain)
2010-04-19 08:42 UTC, Klaus Kämpf
Details
udevadm for sda2 (2.96 KB, text/plain)
2010-04-19 08:43 UTC, Klaus Kämpf
Details
Fresh files from /var/log/YaST2 (76.50 KB, application/x-bzip)
2010-06-18 14:13 UTC, Klaus Kämpf
Details
zypper.log and zypp/ (616.28 KB, application/x-bzip)
2010-06-18 14:14 UTC, Klaus Kämpf
Details
pbl.log (1.66 MB, text/x-log)
2013-02-02 12:00 UTC, Klaus Kämpf
Details
perl-BL-standalone-log (713.52 KB, application/x-bzip)
2013-02-02 14:40 UTC, Klaus Kämpf
Details
zypp history (551.22 KB, application/x-bzip)
2013-02-02 14:41 UTC, Klaus Kämpf
Details
pbl.log (68.50 KB, application/x-bzip)
2013-02-10 11:54 UTC, Klaus Kämpf
Details
perl-BL-standalone (749.25 KB, application/x-bzip)
2013-02-10 11:55 UTC, Klaus Kämpf
Details
history (683.40 KB, application/x-bzip)
2013-02-10 11:55 UTC, Klaus Kämpf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Klaus Kämpf 2010-03-28 13:41:58 UTC
/boot/grub/menu.lst is wrong after "zypper up" (see attachment)

- It contains multiple entries (2.6.33-5-default, which is not installed)
- The first entries have the wrong disk ( hd(1,0) vs hd(0,0) )
- The second entries have the wrong kernel ( 2.6.33-5 vs 2.6.3-6 )
Comment 1 Klaus Kämpf 2010-03-28 13:42:30 UTC
Created attachment 351026 [details]
/boot/grub/menu.lst
Comment 2 Klaus Kämpf 2010-03-28 13:44:03 UTC
Created attachment 351027 [details]
Complete /var/log/YaST2
Comment 3 Klaus Kämpf 2010-03-29 11:24:04 UTC
Its one of these BIOS-disk-order vs. Kernel-disk-order problems.

The system has SATA and IDE controller, both with a disk attached. The kernel sees the IDE disk first (/dev/sda), SATA second (/dev/sdb).
However, the SATA drive is the boot drive so to grub hd(0,0) is the right value.
Comment 4 Josef Reidinger 2010-03-30 08:01:58 UTC
(In reply to comment #3)
> Its one of these BIOS-disk-order vs. Kernel-disk-order problems.
> 
> The system has SATA and IDE controller, both with a disk attached. The kernel
> sees the IDE disk first (/dev/sda), SATA second (/dev/sdb).
> However, the SATA drive is the boot drive so to grub hd(0,0) is the right
> value.

This should not be problem, as we use udev links. Problem is that in some time hd0,0 is written instead of correct entry. I must dig logs to find where this happen (sometime between 06.03 and 28.3 - first refresh which doesn't change anything read (hd0,0))
Comment 5 Klaus Kämpf 2010-03-30 08:18:56 UTC
(In reply to comment #4)
> 
> This should not be problem, as we use udev links.

Indeed. Linux is using by-id links and doesn't care about disk order.

But grub has huge problems.

> Problem is that in some time
> hd0,0 is written instead of correct entry.

In my case, hd(0,0) is the right entry since hd(0,0) == first disk in BIOS boot order.
The bug is that grubs menu.lst contained hd(1,0) since the 'boot' disk shows up as sdb in Linux

Actually, there are two bugs since menu.lst still contained the boot entries for the previous (Milestone 2) kernel !
Comment 6 Josef Reidinger 2010-03-30 08:46:10 UTC
(In reply to comment #5)
> (In reply to comment #4)
> > 
> > This should not be problem, as we use udev links.
> 
> Indeed. Linux is using by-id links and doesn't care about disk order.
> 
> But grub has huge problems.
> 
> > Problem is that in some time
> > hd0,0 is written instead of correct entry.
> 
> In my case, hd(0,0) is the right entry since hd(0,0) == first disk in BIOS boot
> order.
> The bug is that grubs menu.lst contained hd(1,0) since the 'boot' disk shows up
> as sdb in Linux
> 
> Actually, there are two bugs since menu.lst still contained the boot entries
> for the previous (Milestone 2) kernel !

Boot order is stored in /boot/grub/device.map so if you change boot order in BIOS you must regenerate whole boot configuration. Otherwise yast2-bootloader should store correct order and I use this order.
It is not two bugs just two effects of one bug :)
Comment 7 Klaus Kämpf 2010-03-31 08:06:43 UTC
(In reply to comment #6)
> 
> Boot order is stored in /boot/grub/device.map

Do you need this file for debugging ?

> so if you change boot order in BIOS

I didn't change anything in the BIOS. The system booted fine with M2.

> It is not two bugs just two effects of one bug :)

I see two bugs here
1. Wrong disk choosen (hd(1,0))
2. Invalid boot entry (pointing to old kernel image)
Comment 8 Klaus Kämpf 2010-04-13 20:25:39 UTC
/boot/grub/device.map shows
(hd2)   /dev/disk/by-id/usb-WDC_WD16_00JB-00GVC0-0:0
(hd1)   /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV56153591
(hd3)   /dev/disk/by-id/usb-Ut165_USB2FlashStorage_08032651d04575-0:0
(hd0)   /dev/disk/by-id/ata-SAMSUNG_SP1654N_S0GEJ1FL700392

which is *wrong* since WS10EARS (reported as hd1) was used for booting
Comment 9 Klaus Kämpf 2010-04-13 20:28:09 UTC
After upgrading to 11.3 M5, menu.lst has again (hd1,0) :-(

Interestingly enough, menu.lst also has "gfxmenu (hd0,0)/message", which is correct!
Comment 10 Josef Reidinger 2010-04-14 06:26:35 UTC
Could you attach fresh logs after the latest update? There is something wrong with information about disc which I must discover and maybe it will be easier to find. I add jozo to bug as he is the one who propose device.map. I just use it.
Comment 11 Klaus Kämpf 2010-04-14 12:17:02 UTC
As soon as I get this system to boot again (M5 kernel hangs at "doing fast boot" :-()
Comment 12 Klaus Kämpf 2010-04-16 18:58:08 UTC
Created attachment 355079 [details]
/var/log/YaST2

This is complete /var/log/YaST2
Comment 13 Klaus Kämpf 2010-04-16 19:03:03 UTC
Now I have a second system with similar symptoms. This time the disk # is correct but the partition # is wrong.

This occured with an openSUSE 11.2 -> 11.3 M5 upgrade via 'zypper dup'

Logs follow
Comment 14 Klaus Kämpf 2010-04-16 19:22:33 UTC
The device.map of the second system is not very spectacular ;-)
(hd0)   /dev/disk/by-id/ata-WDC_WD1600BEVS-00UST0_WD-WXEY07S93095
Comment 15 Klaus Kämpf 2010-04-16 19:23:57 UTC
Created attachment 355085 [details]
/var/log/YaST2 (wrong partition)

This is /var/log/YaST2 of the system with wrong partition in the bootloader
Comment 16 Josef Reidinger 2010-04-19 07:08:17 UTC
(In reply to comment #15)
> Created an attachment (id=355085) [details]
> /var/log/YaST2 (wrong partition)
> 
> This is /var/log/YaST2 of the system with wrong partition in the bootloader

Hi, in this case it looks like udev is totally broken after kernel update and it cause problem with partition because it cannot translate partition information.
Please provide output of these script to ensure if problem happen only after kernel update or it is still present:

udevadm info -q all -n /dev/dm-0

udevadm info -q all -n /dev/sda2

thanks

Kay - if you know about similar problem in current factory please add note.
Comment 17 Klaus Kämpf 2010-04-19 08:42:50 UTC
Created attachment 355218 [details]
udevadm for dm-0
Comment 18 Klaus Kämpf 2010-04-19 08:43:50 UTC
Created attachment 355219 [details]
udevadm for sda2

Guys, remember that I did a 'zypper dup' which means that the old (11.2) kernel was still running during the upgrade !
Comment 19 Josef Reidinger 2010-04-19 11:07:38 UTC
Kay - it looks like incosistent between udev return during update (where it doesn't know DM_NAME for dm-0 and also other mapping looks like doesn't exist for block devices. Do you know what could happen in this case?
Comment 20 Kay Sievers 2010-04-19 11:28:17 UTC
A version upgrade of udev might not convert all the information in the udev database. As a result, during the upgrade, some dynamic information will no longer be available when the new udev binaries are installed along with the old database. The values need to be re-evaluated, by rebooting the system, or "udevadm trigger" needs to be run for the devices in question.

I don't know how to solve this from the udev side, running "udevadm trigger" when updating udev is known to cause problems in some cases. It should not in theory, but especially things like device-mapper may break their udev setup, if we emit additional events.

I guess, we need to make sure, that a bootloader update happens before the udev update, if the bootloader depends on non-core/non-kernel properties from the udev database.
Comment 21 Josef Reidinger 2010-04-19 11:32:29 UTC
Michal - please see comment #20 is possible to ensure in packages that update of kernel happen before update of udev?
Comment 22 Klaus Kämpf 2010-04-19 11:35:37 UTC
Sounds like bootloader would need a versioned(!) "Require(post):" to the udev version in the build environment. This should ensure that an updated udev is available at the time the post-install scripts are run.
Comment 23 Michal Marek 2010-04-19 11:39:52 UTC
That would be quite a strict dependency though. Another option would be making udev depend on the kernel (unversioned), which would look a bit silly OTOH.
Comment 24 Josef Reidinger 2010-04-19 11:52:50 UTC
so strict version dependency looks also for me too much, but udev dependency on kernel sounds like simple working solution. 
Kay - could you add dependency on kernel? thanks
Comment 25 Klaus Kämpf 2010-04-19 11:57:51 UTC
How can an unversioned dependency work during "zypper dup" ?
Comment 26 Michal Marek 2010-04-19 12:03:31 UTC
If there are no cycles, the install order is given by the topological sort of the dependency graph. That's what I've been told at least :-), but let's ask the zypp developers before adding any hacks.
Comment 27 Klaus Kämpf 2010-04-19 12:41:13 UTC
That was not my question.

If you're doing an unversioned dependency, a "zypper dup" will fulfill all dependencies based on the _old_ packages.

I don't see how this will fix the reported bug.
Comment 28 Josef Reidinger 2010-04-19 14:10:26 UTC
*** Bug 596833 has been marked as a duplicate of this bug. ***
Comment 29 Klaus Kämpf 2010-04-20 08:00:09 UTC
jfyi, "mkinitrd" shows multiple lines of 
2010-04-20 09:58:45 WARNING: GRUB::GrubDev2UnixDev: No partition found for /dev/sda with 1.
Comment 30 Josef Reidinger 2010-04-20 08:08:29 UTC
(In reply to comment #29)
> jfyi, "mkinitrd" shows multiple lines of 
> 2010-04-20 09:58:45 WARNING: GRUB::GrubDev2UnixDev: No partition found for
> /dev/sda with 1.

Yes, this also prints pbl, it is result of failed consistent name translation.
Comment 31 Klaus Kämpf 2010-05-01 17:45:42 UTC
Still not fixed in M6

Grubs menu.lst contains hd(1,0) while hd(0,0) is boot disk in BIOS disk order

device.map is:
(hd2)   /dev/disk/by-id/usb-WDC_WD16_00JB-00GVC0-0:0
(hd1)   /dev/disk/by-id/ata-WDC_WD10EARS-00Y5B1_WD-WCAV56153591
(hd3)   /dev/disk/by-id/usb-Ut165_USB2FlashStorage_08032651d04575-0:0
(hd0)   /dev/disk/by-id/ata-SAMSUNG_SP1654N_S0GEJ1FL700392

which reflects the *kernel* order not the BIOS order :-/
Comment 32 Josef Reidinger 2010-05-03 05:04:18 UTC
jozo - device.map proposal is your job. please look if you find something strange here.
Comment 33 Klaus Kämpf 2010-06-17 18:58:43 UTC
So it happened again.

Interestingly, "zypper dup" from M6 to M7 went flawless.

However, "zypper dup" from M7 to RC1 rewrote the "root" entry in menu.lst again
Comment 34 Josef Reidinger 2010-06-18 07:18:18 UTC
Yes, it is interesting that it sometime work and sometime not. Please provide fresh logs and I try find what is difference between these two updates.
Comment 35 Klaus Kämpf 2010-06-18 14:13:25 UTC
Created attachment 370107 [details]
Fresh files from /var/log/YaST2
Comment 36 Klaus Kämpf 2010-06-18 14:14:06 UTC
Created attachment 370108 [details]
zypper.log and zypp/
Comment 37 Josef Reidinger 2010-06-21 09:55:48 UTC
Klaus - does zypper dup change device.map? It should not change it. Do you have correct one? I also cannot find any valid menu.lst each one which I see in logs has broken hd(0,0) so is menu.lst fixed before upgrade? (perl-Bootloader during update/upgrade doesn't 'fix' menu, it just try to change in same way as it works before)
Comment 38 Klaus Kämpf 2010-06-21 10:06:38 UTC
(In reply to comment #37)
> Klaus - does zypper dup change device.map?
How should I know ?
> It should not change it. Do you have
> correct one?

There is no 'correct' or 'wrong' device.map
Whats wrong is the detection of which device was used for booting


> I also cannot find any valid menu.lst each one which I see in logs
> has broken hd(0,0) so is menu.lst fixed before upgrade?
I manually fix menu.lst because I cannot boot otherwise.

> (perl-Bootloader during
> update/upgrade doesn't 'fix' menu, it just try to change in same way as it
> works before)

How does perl-Bootloader determine what to use as 'root' device ?
Comment 39 Josef Reidinger 2010-06-21 10:16:26 UTC
(In reply to comment #38)
> (In reply to comment #37)
> > Klaus - does zypper dup change device.map?
> How should I know ?
> > It should not change it. Do you have
> > correct one?
> 
> There is no 'correct' or 'wrong' device.map
> Whats wrong is the detection of which device was used for booting
> 

device.map reflect order of booting for x86 based machines. BIOS code 0x80 is for first device to boot etc...it is important mainly when you write boot code to MBR.

> 
> > I also cannot find any valid menu.lst each one which I see in logs
> > has broken hd(0,0) so is menu.lst fixed before upgrade?
> I manually fix menu.lst because I cannot boot otherwise.

Interesting is that I cannot find correct one logs. Could you specify date when you update ( There is quite a lot of message, so time could help me to better identify it).

> 
> > (perl-Bootloader during
> > update/upgrade doesn't 'fix' menu, it just try to change in same way as it
> > works before)
> 
> How does perl-Bootloader determine what to use as 'root' device ?

When you update the root device is device which is mounted under /boot (or / if /boot is not separated). So it try to find if there is some device which has as root device which is mounted as /boot. If it is not found then add default arguments and add it. Of course if it is broken before update it doesn't remove old entries as It think that it is for another system.
Comment 40 Klaus Kämpf 2010-07-06 09:30:01 UTC
Why does bootloader try to newly guess grubs root() device during upgrade ?
It should just leave it alone !
Comment 41 Klaus Kämpf 2010-07-06 18:28:21 UTC
RC2 still breaks the grub configuration :-/
Comment 42 Josef Reidinger 2010-07-07 07:00:38 UTC
(In reply to comment #40)
> Why does bootloader try to newly guess grubs root() device during upgrade ?
> It should just leave it alone !

Because some users have more then one image section with different roots, so set root to /boot is done always as part of workflow ( it is part of pbl abstraction for another bootloader, you always set root by unix device and for grub it is translated to grub device)
Comment 43 Josef Reidinger 2010-10-12 08:32:22 UTC
OK, I investigate issue with bad partition and it is same issue as in bug #543076
Issue with disc order I still investigating as I still don't find when it switch from working state to non-working one and why.
Comment 44 Felix Miata 2010-10-12 13:58:21 UTC
http://lists.opensuse.org/opensuse/2010-09/msg01405.html is a thread that may indicate a problem unpreventable except possibly via motherboard BIOS update. It seems some BIOS are disposed to change boot priority/BIOS disk order at the slightest provocation that may or may not come from actually entering BIOS setup or changing anything in BIOS setup, but might come from any transient or worse problem with BIOS HD0 during POST, or from HD replacement. Once this happens, /boot/grub/device.map may no longer be correct. It allows by-label, by-uuid, etc. to work for fstab & cmdline, but not necessarily for bootloader and/or initrd issues.
Comment 45 Christian Boltz 2010-10-17 14:37:40 UTC
I had a similar problem after a zypper dup from 11.2 to 11.3 - menu.lst contained hd(0,0) instead of hd(0,1), which (obviously) broke booting. What should I do?
a) report more details here
b) open a new bugreport
c) nothing - if you think it is the same bug as described here
?

BTW: If I get this bugreport right, it affects only zypper dup. This should even be fixable by releasing an update for 11.3 - at least for those people who include the update repo when running zypper dup.
Comment 46 Josef Reidinger 2010-10-18 07:17:54 UTC
(In reply to comment #45)
> I had a similar problem after a zypper dup from 11.2 to 11.3 - menu.lst
> contained hd(0,0) instead of hd(0,1), which (obviously) broke booting. What
> should I do?
> a) report more details here
> b) open a new bugreport
> c) nothing - if you think it is the same bug as described here
> ?
> 
> BTW: If I get this bugreport right, it affects only zypper dup. This should
> even be fixable by releasing an update for 11.3 - at least for those people who
> include the update repo when running zypper dup.

I think that your problem is little different and is affected by change of udev DB format which leads to situation, that if udev is upgraded earlier then kernel, kernel cannot get translation between udev links and kernel device, which leads to bad GRUB device. more in bug #543076
Comment 47 Christian Boltz 2010-10-18 22:44:37 UTC
(In reply to comment #46)
> I think that your problem is little different and is affected by change of udev
> DB format which leads to situation, that if udev is upgraded earlier then
> kernel, kernel cannot get translation between udev links and kernel device,
> which leads to bad GRUB device. more in bug #543076

Yes, that sounds like a valid explanation, and rpm -qi confirms that udev was installed earlier than the kernel.

Maybe I'm thinking too simple, but shouldn't this be solvable be releasing an udev update that requries kernel >= $11.3_original_kernel to give the solver a hint about the installation order? (Precondition is of course that the update repo is added when running zypper dup.)
Comment 48 Josef Reidinger 2010-11-30 18:53:05 UTC
(In reply to comment #47)
> (In reply to comment #46)
> > I think that your problem is little different and is affected by change of udev
> > DB format which leads to situation, that if udev is upgraded earlier then
> > kernel, kernel cannot get translation between udev links and kernel device,
> > which leads to bad GRUB device. more in bug #543076
> 
> Yes, that sounds like a valid explanation, and rpm -qi confirms that udev was
> installed earlier than the kernel.
> 
> Maybe I'm thinking too simple, but shouldn't this be solvable be releasing an
> udev update that requries kernel >= $11.3_original_kernel to give the solver a
> hint about the installation order? (Precondition is of course that the update
> repo is added when running zypper dup.)

Hi, discussion about possible solution please post to mentioned bug, as it is hard to track it in more bug reports. Thanks
Comment 50 Jean-Daniel Dodin 2011-11-11 14:19:44 UTC
seems this problem is still not solved with 12.1 (https://bugzilla.novell.com/show_bug.cgi?id=691060) - the best solution (on my computers) is to simply remove the root=(hdX,Y) line wich is unusefull 

see also https://bugzilla.novell.com/show_bug.cgi?id=728524
Comment 51 Michael Chang 2013-01-08 06:53:19 UTC
*** Bug 795838 has been marked as a duplicate of this bug. ***
Comment 52 Klaus Kämpf 2013-01-28 08:53:37 UTC
Wow, this bug is marked as P1/Critical for months and 12.3 Beta 1 still suffers from it.
Comment 54 Steffen Winterfeldt 2013-01-28 13:51:54 UTC
The issue has been solved in 12.3.

Background: the issue was caused by udevd loosing part of its database after
an update. If the udev update happened before the kernel update, updating the
bootloader config may fail. Several band-aids had been added to perl-Bootloader
to work around this. 12.3 solves this by not using udev in perl-Bootloader
anymore.
Comment 55 Klaus Kämpf 2013-01-28 14:05:30 UTC
Huh ?

A 'zypper dup' from 12.2 (latest updates applied) to 12.3 Beta1 did NOT result in a correct menu.lst
Comment 56 Steffen Winterfeldt 2013-01-28 15:39:24 UTC
Logs?

/var/log/pbl.log
/var/log/YaST2/perl-BL-standalone-log
/var/log/zypp/history
Comment 57 Klaus Kämpf 2013-02-02 12:00:29 UTC
Created attachment 523110 [details]
pbl.log
Comment 58 Klaus Kämpf 2013-02-02 14:40:08 UTC
Created attachment 523112 [details]
perl-BL-standalone-log
Comment 59 Klaus Kämpf 2013-02-02 14:41:11 UTC
Created attachment 523113 [details]
zypp history
Comment 60 Klaus Kämpf 2013-02-10 11:52:39 UTC
'zypper dup' from 12.3-Beta1 to 12.3-RC1 still shows this bug
Comment 61 Klaus Kämpf 2013-02-10 11:54:52 UTC
Created attachment 524046 [details]
pbl.log
Comment 62 Klaus Kämpf 2013-02-10 11:55:30 UTC
Created attachment 524047 [details]
perl-BL-standalone
Comment 63 Klaus Kämpf 2013-02-10 11:55:59 UTC
Created attachment 524048 [details]
history
Comment 64 Klaus Kämpf 2013-03-02 15:46:39 UTC
Still unchanged with openSUSE 12.3 RC2
Comment 65 Duncan Mac-Vicar 2013-03-04 10:30:19 UTC
Fixing Severity and Urgency according to common guidelines.

Severity: moved to Major (major loss of functionality, but no data corruption to be critial)
Importancy: Moved to Medium. There is no reason for this bug to be "Urgent". Reporter can't set urgency unless it is the openSUSE project manager himself.
Comment 66 Steffen Winterfeldt 2013-03-04 10:47:29 UTC
The logs show consistently (hd0,0) in menu.lst. I see nothing wrong with that.
See also comment 37.
Comment 68 Duncan Mac-Vicar 2013-03-05 09:28:24 UTC
Steffen, line 450119 from perl-BL-standalone shows root (hd2,0) for the first and second entry (12.3 and failsafe) but (hd0,0) for the Beta2 entry that comes later.
Comment 69 Steffen Winterfeldt 2013-03-05 14:00:13 UTC
The relevant part of the log starts with

2013-01-26 15:14:14 <1> pbl-2235.1

at this point the bootloader config is already broken ((hd0,0) holding the boot
files is not mounted). pbl comes up with the correct (hd2,0) for the
new entry. The existing 12.2 entry is kept unchanged as it doesn't know what
to make of it.

So everything looks fine to me.
Comment 70 Werner Heisch 2013-03-29 14:57:38 UTC
Installing opensuse 12.3, it still does not work on second hdd !!

( Remarkable: 
first report for this bug was from 28.03.2010, yesterday was the 3 anniversary)

Starting Situation:
Hardware:
Acer Aspire V3-771G
Intel Core I7-3630M (64Bit)   32GB RAM

HDD0 : Crucial Micron RealSSD C400 256GB (MTFDDAK256MAM)
HDD1 : Toshiba MQ01ABD100   (1TB)

On HDD0: a preinstalled Windows 8 on HDD0
on HDD1: formated by Windows 8

This was the original situation.

I tried to install opensuse *12.2* on HDD1 by shortening the Windows-HDD1-partition and creating new EXT4-partitions and a swap partition.

This installation failed. (known situation: see me original bug report 795838)

After deleting Windows 8 and formating the hdds, the installation of suse 12.2
failed again ( same as 12.3, it tried it at this moment).
(Because Installation F3->"Text mode" is not text mode, I can not tell you the reason.)

I tried again with F5->save settings, than Installation on opensuse 12.2 works. 

After having installed opensuse 12.2 on hdd0 and parts of hdd1, I tried to
install opensuse 12.3 on the free parts of hdd1 and got the same results as
for the installation of 12.2.

Conclusions:
- After reading the discussion to this bug, I think, bugzilla  should have an additional Status "annoyed by discussions" because "Resolved" normally means something different. 

- If it is not possible to repair bugs in a boot process in the time over 3 years, normally it would be a good reason to think about the general design.

- Since 1996, I used Suse as 2. operation system behind Windows on different
  PCs. The installation has been easy ( at least since V 4.4.1)
  Today, one needs at least experience or better: insider knowledge to handle 
  this.
  Good for winning new linux users ?

- Maybe, there are reasons to use disk-by-id for fixed hdds, but  until yet,I found none. For industrial use it's a curse.
Comment 71 Steffen Winterfeldt 2013-04-02 07:01:49 UTC
Please don't hijack other bugs. The reported issue _had_ been fixed. This is
not a general 'boot config broken after update' catch-all bug.

That said, please attach logs and we'll see.

/var/log/pbl.log
/var/log/zypp/history
Comment 72 Werner Heisch 2013-04-10 00:59:58 UTC
Hi Steffen,
it was not my intention to hijack the bugs. I reported the bug 795838 and it has been regarded as equal to this one. But coming to the point.

After a lot of different tries to install 12.2 or 12,3 I found, that the problems result from an other problem: parted reports, that it cannot read /dev/sda.
This is the SSD Crucial Micron RealSSD C400 256GB (MTFDDAK256MAM).

In Bios, I've changed to hdd1 ( /dev/sdb ) as the booting device and now I am booting from this hd.

in /boot/grub2/device.map the Toshiba-(classical hd) is regarded as (hd0) while
The SSD is regardes as (hd1).

Again:
It seems to be a parted-problem associated with the micron SSD.

If you still need the requested log files I will send it to you, but I believe, it is not necessary here.
Comment 73 Steffen Winterfeldt 2014-08-15 09:30:35 UTC
please check again with 13.2, we have a different situation using grub2 now