Bug 441463

Summary: boot loader entry four times after update
Product: [openSUSE] openSUSE 11.1 Reporter: Ludwig Nussel <lnussel>
Component: Update ProblemsAssignee: Josef Reidinger <jreidinger>
Status: RESOLVED DUPLICATE QA Contact: Jiri Srain <jsrain>
Severity: Normal    
Priority: P5 - None    
Version: Beta 4   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: Development Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Ludwig Nussel 2008-11-04 13:03:17 UTC
After an update 10.3 -> 11.1beta4 the 11.1 Bootloader entry and it's failsafe entry are listed four times in menu.lst.
Comment 4 Josef Reidinger 2008-11-05 07:31:08 UTC
Hmm, thats look quite bad, especially initrd in chainloader section.
Comment 5 Josef Reidinger 2008-11-05 07:46:17 UTC
I found why it added that section four time, it is because it cannot find initrd, but due to poor loging in this area, I cannot find what is that reason...Can you post as much details about your configuration as possible? I try reproduce it. 
Comment 6 Josef Reidinger 2008-11-05 08:04:21 UTC
Problematic initrd keys in chainloader section is not filtered in perl-Bootloader (next release), but yast should not send it to me.
Comment 7 Ludwig Nussel 2008-11-05 08:05:18 UTC
what kind of information? I've attached the yast2 logs that should contain pretty much everything yast found out about the system?
Comment 8 Josef Reidinger 2008-11-05 08:24:56 UTC
(In reply to comment #7 from Ludwig Nussel)
> what kind of information? I've attached the yast2 logs that should contain
> pretty much everything yast found out about the system?
> 

I mean if you do something special during upgrade...if you upgrade via dvd or zypper dup....also can you please post ls -l /boot ? It's look like some problem with initrd file.
Comment 9 Ludwig Nussel 2008-11-05 09:08:05 UTC
I used a network installation source to upgrade. ie the regular way, no upgrade in the running system.

yukon:~ # l /boot/
insgesamt 13728
drwxr-xr-x  6 root root    4096  5. Nov 09:50 ./
drwxr-xr-x 26 root root    4096  5. Nov 10:31 ../
-rw-------  1 root root     512  5. Okt 2007  backup_mbr
lrwxrwxrwx  1 root root       1  4. Nov 13:39 boot -> ./
-rw-r--r--  1 root root   95091 29. Okt 01:59 config-2.6.27.4-2-default
drwxr-xr-x  2 root root    4096  5. Nov 09:50 grub/
lrwxrwxrwx  1 root root      25  4. Nov 14:27 initrd -> initrd-2.6.27.4-2-default
-rw-r--r--  1 root root 6024837  4. Nov 14:27 initrd-2.6.27.4-2-default
drwx------  2 root root    4096 27. Mai 14:29 install_dist_openSUSE-11.0-Build0120-KY4322/
drwx------  2 root root    4096  4. Nov 11:31 install_dist_openSUSE-11.1-Beta4-np5090/
drwx------  2 root root    4096 18. Apr 2008  loader-Za4946/
-rw-r--r--  1 root root  424960  5. Nov 09:50 message
-rw-r--r--  1 root root  124582 29. Okt 02:08 symsets-2.6.27.4-2-default.tar.gz
-rw-r--r--  1 root root  400891 29. Okt 02:07 symtypes-2.6.27.4-2-default.gz
-rw-r--r--  1 root root  119362 29. Okt 02:00 symvers-2.6.27.4-2-default.gz
-rw-r--r--  1 root root 1086633 29. Okt 01:44 System.map-2.6.27.4-2-default
-rw-r--r--  1 root root 3207165 29. Okt 01:59 vmlinux-2.6.27.4-2-default.gz
lrwxrwxrwx  1 root root      26  4. Nov 13:57 vmlinuz -> vmlinuz-2.6.27.4-2-default
-rw-r--r--  1 root root 2485680 29. Okt 01:44 vmlinuz-2.6.27.4-2-default
Comment 10 Josef Reidinger 2008-11-05 10:54:18 UTC
Thanks...so no I found where is problem, new section is added with grub root hd0,0 ,but correct is hd0,1 (same as old 10.3) , am I right?
Comment 11 Josef Reidinger 2008-11-05 10:56:06 UTC
(In reply to comment #10 from Josef Reidinger)
> Thanks...so no I found where is problem, new section is added with grub root
> hd0,0 ,but correct is hd0,1 (same as old 10.3) , am I right?
> 

like I nothing say, I overlook number :)
Comment 12 Josef Reidinger 2008-11-05 10:58:20 UTC
No it is right, hd0,0 is problem, but your menu.lst is at end correct. So it needs more investigating....sorry for confussing I have open two almost same logs, one from my test where everything is ok and second is yours.
Comment 13 Josef Reidinger 2008-11-05 11:09:52 UTC
OK, to diagnostic I need find some info which is not enough logged ( I add logging for future).

I need output of this command to reproduce problematic part (one possibility is bad udev translation):
cat /sys/block/sda/range
ls /sys/block/sda
cat /sys/block/sda/sda[1-number of partitions]

if doesn't exist /sys/block/sda then please output of /sys/block
Thanks
Comment 14 Ludwig Nussel 2008-11-05 15:45:39 UTC
The system now uses hda for some reason.
# cat /sys/block/hda/range 
64
# ls /sys/block/hda
bdi         device  hda3  hda6     queue      ro      stat
capability  hda1    hda4  holders  range      size    subsystem
dev         hda2    hda5  power    removable  slaves  uevent

/sys/block/hda/hda* are directories, can't cat them.
Maybe this one is useful instead:
# fdisk -l

Disk /dev/hda: 40.0 GB, 40007761920 bytes
16 heads, 63 sectors/track, 77520 cylinders
Units = cylinders of 1008 * 512 = 516096 bytes
Disk identifier: 0x000dc97d

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1               1       12218     6157840+   7  HPFS/NTFS
/dev/hda2   *       12219       30912     9421776   83  Linux
/dev/hda3           30913       38663     3906504   83  Linux
/dev/hda4           38664       77520    19583928    5  Extended
/dev/hda5           38664       39827      586624+  82  Linux swap / Solaris
/dev/hda6           39828       77520    18997240+  83  Linux
Comment 15 Josef Reidinger 2008-11-06 07:48:27 UTC
Interesting, using hda could be source of problems. I look why p-BL try use sda.
Comment 16 Josef Reidinger 2008-11-10 08:23:26 UTC
thanks for report, I found that problem is in kernel and close this bug as duplicate of that kernel bug (sda changed to hda, which is not expected scenario).

*** This bug has been marked as a duplicate of bug 440986 ***