Mailinglist Archive: opensuse-bugs (4172 mails)

< Previous Next >
[Bug 513004] New: yast2 bootloader doesn't represent the REAL boot conditions
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Sat, 13 Jun 2009 12:42:27 -0600
  • Message-id: <bug-513004-21960@xxxxxxxxxxxxxxxxxxxxxxxx/>

Summary: yast2 bootloader doesn't represent the REAL boot
Classification: openSUSE
Product: openSUSE 11.1
Version: Final
Platform: x86-64
OS/Version: openSUSE 11.1
Status: NEW
Severity: Major
Priority: P5 - None
Component: YaST2
AssignedTo: bnc-team-screening@xxxxxxxxxxxxxxxxxxxxxx
ReportedBy: suse@xxxxxxxxx
QAContact: jsrain@xxxxxxxxxx
Found By: ---

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:
Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)

I tried to install the xen kernel. It failed due to insufficient room in boot
(though it updated the boot config to boot from the new kernel, resulting in a
failure each boot, that I had to manually intervene in and boot from an
existing kernel until I fixed the problem).

The partition was too small for the number and sizes of the new kernels. I
repurposed another partition on the same disk. I mount my disks by label.
I formatted the new partition as 'Boot'. After copyping the contents
of my existing /boot to the new filesystem, I unmounted and relabeled the old
partition 'Oboot'. I remounted /boot, and it mounted the new partition
by label Boot as expected.

I then went into yast2 and told it to finish installing the xen kernel, which
it did. When I tried to boot, the system still couldn't find the xen kernel.

I edited the /boot/grub/menu and noticed references to the my disk partitions
not using LABELS!! :-( (separate issue/bug). I created alternate/duplicate
entries for each boot entry so I'd have the originals- but added the suffix
'sda2' after each noting the partition they referenced. The others I changed
to reference the new boot partition, sda8 (as I saw no way to specify by label,
:-(!). I specified the 'default' entry to boot from a correct entry.

Rebooted. Nada. Zilch. Same problemo. No xen.gz. Upon returning to the
grub manual intervention screen, I saw the *old* menu.lst. Hrmph!

I continued boot and went back into yast2 bootloader.

yast2 bootloader showed me my NEW menu -- not the menu I actually saw when I

THIS is a the bug.

Yast2, as a system config util, should give the user the *real* representation
of what is happening at boot-time, not some 'mocked' up simulation based on
labeled file system mounts that the *boot loader* doesn't know about.

As long as the boot loader doesn't know about labels and doesn't boot from
labels, yast2, needs to look at the MBR, and see what physical partition is
being booted from and look at the information in that partition.

I even noted in yast2 -- that still had the 'menu.lst' file listed as being
on "hd(0,1)" -- which it was NOT -- the menu.lst file it was displaying was
located on sda8 hd(0,7).

I labeled the new disk 'Boot' and renamed the old partition label 'Oboot'. I
remount /boot, and it mounted the ne

Reproducible: Always

Steps to Reproduce:
1. See above in Details
Actual Results:
Yast2 bootloader doesn't use same info as real boot loader -- it uses correctly
labeled partitions while the bootloader still doesn't understand them -- yast2
should check the real MBR data on disk to provide a admin tool that guarantees
integrity against the actual system.

Severity = major, perhaps even critical since it displays the FALSE

However the 'priority' as moderated by likelihood of occurrence would be more
like a 'Normal' level.

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

< Previous Next >