[Bug 53443] NEW: SATA renumbering prevents boot

https://qa.mandriva.com/show_bug.cgi?id=53443


           Summary: SATA renumbering prevents boot
    Classification: Mandriva Linux
           Product: Mandriva Linux
           Version: Cooker
          Platform: x86_64
        OS/Version: Linux
            Status: NEW
          Severity: critical
          Priority: normal
         Component: Core Packages
        AssignedTo: triage@...
        ReportedBy: t.blackwell@...
         QAContact: bugs@...


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are
1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of
about 25 Gb, then extended partition containing mostly a large encrypted
partition as well as swap.  The next 1.5Gb HD is all a single encrypted
partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well,
using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the
older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo
still points at sda, which cooker now thinks is the second HD with only the
encrypted data partition on it.  Curiously lilo can still start the 2009
partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs
OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot
without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.


--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://qa.mandriva.com/show_bug.cgi?id=53443

  Summary    : SATA renumbering prevents boot
  Product    : Mandriva Linux
  Component  : Core Packages
  Version    : Cooker
  Status     : NEW
  Severity   : critical
  Priority   : normal
  Assigned To: triage@...
  Reported By: t.blackwell@...





--- Comment #1 from Tony Blackwell <t.blackwell@...>  2009-09-05 03:15:24 CEST ---
typo: hardware: 1st 2 drives 1.5 terabytes each



----------------------------------------------------------------------------
Original Bug Text:


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are 1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of about 25 Gb, then extended partition containing mostly a large encrypted partition as well as swap.  The next 1.5Gb HD is all a single encrypted partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well, using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo still points at sda, which cooker now thinks is the second HD with only the encrypted data partition on it.  Curiously lilo can still start the 2009 partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.



--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://qa.mandriva.com/show_bug.cgi?id=53443

  Summary    : SATA renumbering prevents boot
  Product    : Mandriva Linux
  Component  : Core Packages
  Version    : Cooker
  Keywords   : NEEDINFO
  Status     : NEW
  Severity   : critical
  Priority   : normal
  Assigned To: triage@...
  Reported By: t.blackwell@...


Pacho Ramos <pacho@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |NEEDINFO
                 CC|                            |pacho@...
                   |                            |ovi.es




--- Comment #2 from Pacho Ramos <pacho@...>  2009-09-09 13:55:21 CEST ---
Please attach "dmesg" output and /etc/fstab file
--
Mandriva Triage Team



----------------------------------------------------------------------------
Original Bug Text:


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are 1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of about 25 Gb, then extended partition containing mostly a large encrypted partition as well as swap.  The next 1.5Gb HD is all a single encrypted partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well, using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo still points at sda, which cooker now thinks is the second HD with only the encrypted data partition on it.  Curiously lilo can still start the 2009 partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.



--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://qa.mandriva.com/show_bug.cgi?id=53443

  Summary    : SATA renumbering prevents boot
  Product    : Mandriva Linux
  Component  : Core Packages
  Version    : Cooker
  Keywords   : NEEDINFO
  Status     : NEW
  Severity   : critical
  Priority   : normal
  Assigned To: triage@...
  Reported By: t.blackwell@...





--- Comment #3 from Tony Blackwell <t.blackwell@...>  2009-09-10 14:43:43 CEST ---
As you requested below, _but_ see my following comments at the end.

dmesg output
consists of many shorewall messages of the form
SRC=192.168.0.1 DST=192.168.0.166 LEN=321 TOS=0x00 PREC=0x00 TTL=64 ID=13839
PROTO=UDP SPT=1900 DPT=38483 LEN=301
Shorewall:net2fw:DROP:IN=eth0 OUT=
MAC=00:26:18:54:a0:a9:00:13:46:5e:23:9d:08:00

/etc/fstab:
# Entry for /dev/sda2 :
UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88 / ext3 relatime 1 1
/dev/cdrom /media/cdrom auto umask=0,users,iocharset=utf8,noauto,ro,exec 0 0
# Entry for /dev/sda1 :
UUID=72C26660C2662895 /mnt/windows ntfs-3g defaults,umask=000 0 0
none /proc proc defaults 0 0
# Entry for /dev/sda6 :
UUID=a9e744a8-7c47-46c2-8212-5d23d47ec4e1 swap swap defaults 0 0

Comments: This problem is getting stranger and stranger:

1. I downloaded the latest nvidia driver and ran its install script.
2.  Nothing much seemed to have happened, so after reboot I went I think into
mandrake control center, hardware, X configuration.  It offered choice of
proprietary driver which I accepted, but rather than using what I had just
downloaded from nvidia, it downloaded one with very slightly earlier minor
version number from Mandriva, together with and nvidia-enabled kernel.
3. On reboot, the system panicked, couldn't find disk, just as led to this
problem as first reported.
4. I used the 2010beta1 DVD, rescue, console, used fdisk.  It still incorrectly
was seeing the 2nd 1.5TB drive with only a single data partition as sda, and my
original sda with the real OS was still seen as sdb.  Without changing anything
I chrooted to the 2010 partition and ran lilo, still re-configured to think sdb
was the boot disk.
5. reboot sort-of-worked, but it didn't come up to a full working graphical
screen.
6. From a failsafe login I then ran drakboot.  It told me there was no boot
code installed and offered to create it!  To my complete surprise, drakboot was
now seeing the correct HD with the original OS partitions as sda, and my data
disk as sdb.  This was even though lilo had done the reboot thinking the
bootable disk was sdb. I allowed drakboot to (re)create the boot stuff.
7. Subsequently system reboots seeing the correct disk as sda, and the system
appears to be back as it should be.


Yes, well, how to explain all this?  I suspect something in your most recent
kernel update did the damage, and my switching to the ndvidia driver,
accompanied by the install downloading an nvidia-enabled kernel, reverted to
correct behaviour.

uname -a now shows:
Linux quad.grh.au 2.6.31-desktop-0.rc9.1mnb #1 SMP Mon Sep 7 18:08:53 EDT 2009
x86_64 Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz GNU/Linux

original kernel was
vmlinuz-2.6.31-desktop-0.rc8.1mnb

recent kernels your update had installed include
vmlinuz-2.6.31-desktop-0.rc6.1mnb
vmlinuz-2.6.31-0.rc8.rt9.2mdv

I suspect the last kernel mentioned caused the problem.
You may have a better interpretation.......
Tony



----------------------------------------------------------------------------
Original Bug Text:


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are 1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of about 25 Gb, then extended partition containing mostly a large encrypted partition as well as swap.  The next 1.5Gb HD is all a single encrypted partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well, using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo still points at sda, which cooker now thinks is the second HD with only the encrypted data partition on it.  Curiously lilo can still start the 2009 partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.



--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://qa.mandriva.com/show_bug.cgi?id=53443

  Summary    : SATA renumbering prevents boot
  Product    : Mandriva Linux
  Component  : Core Packages
  Version    : Cooker
  Keywords   : Triaged
  Status     : NEW
  Severity   : critical
  Priority   : release_critical
  Assigned To: kernel@...
  Reported By: t.blackwell@...


Pacho Ramos <pacho@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|NEEDINFO                    |Triaged
           Priority|normal                      |release_critical
                 CC|                            |cfergeau@...
         AssignedTo|triage@...         |kernel@...




--- Comment #4 from Pacho Ramos <pacho@...>  2009-09-10 16:17:54 CEST ---
(In reply to comment #3)
> As you requested below, _but_ see my following comments at the end.
>
> dmesg output
> consists of many shorewall messages of the form
> SRC=192.168.0.1 DST=192.168.0.166 LEN=321 TOS=0x00 PREC=0x00 TTL=64 ID=13839
> PROTO=UDP SPT=1900 DPT=38483 LEN=301
> Shorewall:net2fw:DROP:IN=eth0 OUT=
> MAC=00:26:18:54:a0:a9:00:13:46:5e:23:9d:08:00
>

I know shorewall floods it, but there should be more messages (specially just
after booting)

>
> 1. I downloaded the latest nvidia driver and ran its install script.
> 2.  Nothing much seemed to have happened, so after reboot I went I think into
> mandrake control center, hardware, X configuration.  It offered choice of
> proprietary driver which I accepted, but rather than using what I had just
> downloaded from nvidia, it downloaded one with very slightly earlier minor
> version number from Mandriva, together with and nvidia-enabled kernel.

It's not related with this problem, anyway, it's the normal behavior, as MCC
only supports official packages from non-free repos (that are the only
supported drivers and the only supported method for installing them)


> Yes, well, how to explain all this?  I suspect something in your most recent
> kernel update did the damage, and my switching to the ndvidia driver,
> accompanied by the install downloading an nvidia-enabled kernel, reverted to
> correct behaviour.
>

Maybe because of module compilation :-/

Please also provide lilo.conf

Assigning for now to kernel team as this needs to be checked soon, also adding
drakboot maintainer to CC list



----------------------------------------------------------------------------
Original Bug Text:


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are 1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of about 25 Gb, then extended partition containing mostly a large encrypted partition as well as swap.  The next 1.5Gb HD is all a single encrypted partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well, using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo still points at sda, which cooker now thinks is the second HD with only the encrypted data partition on it.  Curiously lilo can still start the 2009 partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.



--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://qa.mandriva.com/show_bug.cgi?id=53443

  Summary    : SATA renumbering prevents boot
  Product    : Mandriva Linux
  Component  : Core Packages
  Version    : Cooker
  Keywords   : Triaged
  Status     : NEW
  Severity   : critical
  Priority   : release_critical
  Assigned To: kernel@...
  Reported By: t.blackwell@...





--- Comment #5 from Tony Blackwell <t.blackwell@...>  2009-09-10 21:50:38 CEST ---
For comparison, the following is the output of dmesg on the same hardware but
_from 2009 x86_64_.  I'll put in the 2010 dmesg in a subsequent post.

2009 dmesg (down to the point where shorewall starts flooding)

sd 3:0:0:0: Attached scsi generic sg5 type 0
sd 4:0:0:0: Attached scsi generic sg6 type 0
scsi 6:0:1:0: Attached scsi generic sg7 type 5
input: PC Speaker as /class/input/input3
Driver 'sr' needs updating - please use bus_type methods
sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 6:0:1:0: Attached scsi CD-ROM sr0
ACPI: SSDT BF6980C0, 0403 (r1 DpgPmm  P001Ist       11 INTL 20060113)
processor ACPI0007:00: registered as cooling_device0
ACPI: SSDT BF6984D0, 0403 (r1 DpgPmm  P002Ist       12 INTL 20060113)
processor ACPI0007:01: registered as cooling_device1
ACPI: SSDT BF6988E0, 0403 (r1 DpgPmm  P003Ist       12 INTL 20060113)
processor ACPI0007:02: registered as cooling_device2
ACPI: SSDT BF698CF0, 0403 (r1 DpgPmm  P004Ist       12 INTL 20060113)
processor ACPI0007:03: registered as cooling_device3
ACPI: SSDT BF699100, 0403 (r1 DpgPmm  P005Ist       12 INTL 20060113)
processor ACPI0007:04: registered as cooling_device4
ACPI: SSDT BF699510, 0403 (r1 DpgPmm  P006Ist       12 INTL 20060113)
processor ACPI0007:05: registered as cooling_device5
ACPI: SSDT BF699920, 0403 (r1 DpgPmm  P007Ist       12 INTL 20060113)
processor ACPI0007:06: registered as cooling_device6
ACPI: SSDT BF699D30, 0403 (r1 DpgPmm  P008Ist       12 INTL 20060113)
processor ACPI0007:07: registered as cooling_device7
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:06:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
r8169 0000:06:00.0: setting latency timer to 64
r8169 0000:06:00.0: no MSI. Back to INTx.
eth0: RTL8168c/8111c at 0xffffc20000c52000, 00:26:18:54:a0:a9, XID 3c4000c0 IRQ
18
udev: renamed network interface eth0 to eth1
ACPI: WMI: Mapper loaded
input: Power Button (FF) as /class/input/input4
ACPI: Power Button (FF) [PWRF]
input: Power Button (CM) as /class/input/input5
rtc_cmos 00:03: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one month, y3k, hpet irqs
HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
HDA Intel 0000:00:1b.0: setting latency timer to 64
hda_codec: Unknown model for ALC883, trying auto-probe from BIOS...
ACPI: Power Button (CM) [PWRB]
i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
ACPI: I/O resource 0000:00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG
[0x400-0x40f]
ACPI: Device needs an ACPI driver
Linux video capture interface: v2.00
cx2388x alsa driver version 0.0.6 loaded
cx88_audio 0000:08:01.1: PCI INT A -> GSI 17 (level, low) -> IRQ 17
cx88[0]: subsystem: 18ac:db40, board: DViCO FusionHDTV DVB-T Hybrid
[card=46,autodetected]
cx88[0]: TV tuner type 72, Radio tuner type -1
cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded
cx88/0: cx2388x v4l2 driver version 0.0.6 loaded
tuner' 1-0061: chip found @ 0xc2 (cx88[0])
tuner-simple 1-0061: creating new instance
tuner-simple 1-0061: type set to 72 (Thomson FE6600)
cx88[0]/1: CX88x/0: ALSA support for cx2388x boards
cx8800 0000:08:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
cx88[0]/0: found at 0000:08:01.0, rev: 5, irq: 17, latency: 64, mmio:
0xf8000000
cx88[0]/0: registered device video0 [v4l2]
cx88[0]/0: registered device vbi0
cx88[0]/2: cx2388x 8802 Driver Manager
cx88-mpeg driver manager 0000:08:01.2: PCI INT A -> GSI 17 (level, low) -> IRQ
17
cx88[0]/2: found at 0000:08:01.2, rev: 5, irq: 17, latency: 64, mmio:
0xfa000000
cx88/2: cx2388x dvb driver version 0.0.6 loaded
cx88/2: registering cx8802 driver, type: dvb access: shared
cx88[0]/2: subsystem: 18ac:db40, board: DViCO FusionHDTV DVB-T Hybrid [card=46]
cx88[0]/2: cx2388x based DVB/ATSC card
tuner-simple 1-0061: attaching existing instance
tuner-simple 1-0061: type set to 72 (Thomson FE6600)
DVB: registering new adapter (cx88[0])
DVB: registering frontend 0 (Zarlink ZL10353 DVB-T)...
device-mapper: uevent: version 1.0.3
device-mapper: ioctl: 4.14.0-ioctl (2008-04-23) initialised:
dm-devel@...
EXT3 FS on sda3, internal journal
scsi 8:0:0:0: Direct-Access     Multi    Flash Reader     1.00 PQ: 0 ANSI: 0
sd 8:0:0:0: [sdh] Attached SCSI removable disk
sd 8:0:0:0: Attached scsi generic sg8 type 0
usb-storage: device scan complete
scsi 9:0:0:0: Direct-Access     Generic  Flash HS-CF      4.44 PQ: 0 ANSI: 0
sd 9:0:0:0: [sdi] Attached SCSI removable disk
sd 9:0:0:0: Attached scsi generic sg9 type 0
scsi 9:0:0:1: Direct-Access     Generic  Flash HS-COMBO   4.44 PQ: 0 ANSI: 0
sd 9:0:0:1: [sdj] Attached SCSI removable disk
sd 9:0:0:1: Attached scsi generic sg10 type 0
usb-storage: device scan complete
loop: module loaded
Adding 6843648k swap on /dev/sda6.  Priority:-1 extents:1 across:6843648k
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Plase use
nf_conntrack.acct=1 kernel paramater, acct=1 nf_conntrack module option or
sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
ctnetlink v0.93: registering with nfnetlink.
ClusterIP Version 0.8 loaded successfully
netfilter PSD loaded - (c) astaro AG
IFWLOG: register target
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
Bluetooth: Core ver 2.13
NET: Registered protocol family 31
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP ver 2.11
Bluetooth: L2CAP socket layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.10
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bridge firewalling registered
r8169: eth1: link up
r8169: eth1: link up
NET: Registered protocol family 17
/dev/vmmon[5749]: Module vmmon: registered with major=10 minor=165
/dev/vmmon[5749]: Initial HV check: anyNotCapable=0 anyUnlocked=0 anyEnabled=1
anyDisabled=0
/dev/vmmon[5749]: HV check: anyNotCapable=0 anyUnlocked=0 anyEnabled=1
anyDisabled=0
/dev/vmmon[5749]: Module vmmon: initialized
/dev/vmci[5812]: VMCI: Driver initialized.
/dev/vmci[5812]: Module vmci: registered with major=10 minor=58
/dev/vmci[5812]: Module vmci: initialized
ppdev: user-space parallel port driver
eth1: no IPv6 routers present
Shorewall:net2fw:DROP:IN=eth1 OUT=
MAC=00:26:18:54:a0:a9:00:13:46:5e:23:9d:08:00 SRC=192.168.0.1 DST=192.168.0.166
LEN=257 TOS=0x00 PREC=0x00 TTL=64 ID=29 PROTO=UDP SPT=1900 DPT=51056 LEN=237



----------------------------------------------------------------------------
Original Bug Text:


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are 1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of about 25 Gb, then extended partition containing mostly a large encrypted partition as well as swap.  The next 1.5Gb HD is all a single encrypted partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well, using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo still points at sda, which cooker now thinks is the second HD with only the encrypted data partition on it.  Curiously lilo can still start the 2009 partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.



--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://qa.mandriva.com/show_bug.cgi?id=53443

  Summary    : SATA renumbering prevents boot
  Product    : Mandriva Linux
  Component  : Core Packages
  Version    : Cooker
  Keywords   : Triaged
  Status     : NEW
  Severity   : critical
  Priority   : release_critical
  Assigned To: kernel@...
  Reported By: t.blackwell@...





--- Comment #6 from Tony Blackwell <t.blackwell@...>  2009-09-10 22:11:05 CEST ---
2010beta1
dmesg (down to shorewall flooding)


usb usb5: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb5: Product: EHCI Host Controller
usb usb5: Manufacturer: Linux 2.6.31-desktop-0.rc9.1mnb ehci_hcd
usb usb5: SerialNumber: 0000:00:1d.7
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 6 ports detected
uhci_hcd 0000:00:1d.0: PCI INT A -> GSI 23 (level, low) -> IRQ 23
uhci_hcd 0000:00:1d.0: setting latency timer to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 6
uhci_hcd 0000:00:1d.0: irq 23, io base 0x00009080
usb usb6: New USB device found, idVendor=1d6b, idProduct=0001
usb usb6: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb6: Product: UHCI Host Controller
usb usb6: Manufacturer: Linux 2.6.31-desktop-0.rc9.1mnb uhci_hcd
usb usb6: SerialNumber: 0000:00:1d.0
usb usb6: configuration #1 chosen from 1 choice
hub 6-0:1.0: USB hub found
hub 6-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
uhci_hcd 0000:00:1d.1: setting latency timer to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 7
uhci_hcd 0000:00:1d.1: irq 19, io base 0x00009400
usb usb7: New USB device found, idVendor=1d6b, idProduct=0001
usb usb7: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb7: Product: UHCI Host Controller
usb usb7: Manufacturer: Linux 2.6.31-desktop-0.rc9.1mnb uhci_hcd
usb usb7: SerialNumber: 0000:00:1d.1
usb usb7: configuration #1 chosen from 1 choice
hub 7-0:1.0: USB hub found
hub 7-0:1.0: 2 ports detected
uhci_hcd 0000:00:1d.2: PCI INT C -> GSI 18 (level, low) -> IRQ 18
uhci_hcd 0000:00:1d.2: setting latency timer to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 8
uhci_hcd 0000:00:1d.2: irq 18, io base 0x00009480
usb usb8: New USB device found, idVendor=1d6b, idProduct=0001
usb usb8: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb8: Product: UHCI Host Controller
usb usb8: Manufacturer: Linux 2.6.31-desktop-0.rc9.1mnb uhci_hcd
usb usb8: SerialNumber: 0000:00:1d.2
usb usb8: configuration #1 chosen from 1 choice
hub 8-0:1.0: USB hub found
hub 8-0:1.0: 2 ports detected
EXT3 FS on sda2, internal journal
Linux video capture interface: v2.00
fuse init (API version 7.12)
cx88/0: cx2388x v4l2 driver version 0.0.7 loaded
cx8800 0000:08:01.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
cx88[0]: Your board has no valid PCI Subsystem ID and thus can't
cx88[0]: be autodetected.  Please pass card=<n> insmod option to
cx88[0]: workaround that.  Redirect complaints to the vendor of
cx88[0]: the TV card.  Best regards,
cx88[0]:         -- tux
cx88[0]: Here is a list of valid choices for the card=<n> insmod option:
cx88[0]:    card=0 -> UNKNOWN/GENERIC
cx88[0]:    card=1 -> Hauppauge WinTV 34xxx models
cx88[0]:    card=2 -> GDI Black Gold
cx88[0]:    card=3 -> PixelView
cx88[0]:    card=4 -> ATI TV Wonder Pro
cx88[0]:    card=5 -> Leadtek Winfast 2000XP Expert
cx88[0]:    card=6 -> AverTV Studio 303 (M126)
cx88[0]:    card=7 -> MSI TV-@nywhere Master
cx88[0]:    card=8 -> Leadtek Winfast DV2000
cx88[0]:    card=9 -> Leadtek PVR 2000
cx88[0]:    card=10 -> IODATA GV-VCP3/PCI
cx88[0]:    card=11 -> Prolink PlayTV PVR
cx88[0]:    card=12 -> ASUS PVR-416
cx88[0]:    card=13 -> MSI TV-@nywhere
cx88[0]:    card=14 -> KWorld/VStream XPert DVB-T
cx88[0]:    card=15 -> DViCO FusionHDTV DVB-T1
cx88[0]:    card=16 -> KWorld LTV883RF
cx88[0]:    card=17 -> DViCO FusionHDTV 3 Gold-Q
cx88[0]:    card=18 -> Hauppauge Nova-T DVB-T
cx88[0]:    card=19 -> Conexant DVB-T reference design
cx88[0]:    card=20 -> Provideo PV259
cx88[0]:    card=21 -> DViCO FusionHDTV DVB-T Plus
cx88[0]:    card=22 -> pcHDTV HD3000 HDTV
cx88[0]:    card=23 -> digitalnow DNTV Live! DVB-T
cx88[0]:    card=24 -> Hauppauge WinTV 28xxx (Roslyn) models
cx88[0]:    card=25 -> Digital-Logic MICROSPACE Entertainment Center (MEC)
cx88[0]:    card=26 -> IODATA GV/BCTV7E
cx88[0]:    card=27 -> PixelView PlayTV Ultra Pro (Stereo)
cx88[0]:    card=28 -> DViCO FusionHDTV 3 Gold-T
cx88[0]:    card=29 -> ADS Tech Instant TV DVB-T PCI
cx88[0]:    card=30 -> TerraTec Cinergy 1400 DVB-T
cx88[0]:    card=31 -> DViCO FusionHDTV 5 Gold
cx88[0]:    card=32 -> AverMedia UltraTV Media Center PCI 550
cx88[0]:    card=33 -> Kworld V-Stream Xpert DVD
cx88[0]:    card=34 -> ATI HDTV Wonder
cx88[0]:    card=35 -> WinFast DTV1000-T
cx88[0]:    card=36 -> AVerTV 303 (M126)
cx88[0]:    card=37 -> Hauppauge Nova-S-Plus DVB-S
cx88[0]:    card=38 -> Hauppauge Nova-SE2 DVB-S
cx88[0]:    card=39 -> KWorld DVB-S 100
cx88[0]:    card=40 -> Hauppauge WinTV-HVR1100 DVB-T/Hybrid
cx88[0]:    card=41 -> Hauppauge WinTV-HVR1100 DVB-T/Hybrid (Low Profile)
cx88[0]:    card=42 -> digitalnow DNTV Live! DVB-T Pro
cx88[0]:    card=43 -> KWorld/VStream XPert DVB-T with cx22702
cx88[0]:    card=44 -> DViCO FusionHDTV DVB-T Dual Digital
cx88[0]:    card=45 -> KWorld HardwareMpegTV XPert
cx88[0]:    card=46 -> DViCO FusionHDTV DVB-T Hybrid
cx88[0]:    card=47 -> pcHDTV HD5500 HDTV
cx88[0]:    card=48 -> Kworld MCE 200 Deluxe
cx88[0]:    card=49 -> PixelView PlayTV P7000
cx88[0]:    card=50 -> NPG Tech Real TV FM Top 10
cx88[0]:    card=51 -> WinFast DTV2000 H
cx88[0]:    card=52 -> Geniatech DVB-S
cx88[0]:    card=53 -> Hauppauge WinTV-HVR3000 TriMode Analog/DVB-S/DVB-T
cx88[0]:    card=54 -> Norwood Micro TV Tuner
cx88[0]:    card=55 -> Shenzhen Tungsten Ages Tech TE-DTV-250 / Swann OEM
cx88[0]:    card=56 -> Hauppauge WinTV-HVR1300 DVB-T/Hybrid MPEG Encoder
cx88[0]:    card=57 -> ADS Tech Instant Video PCI
cx88[0]:    card=58 -> Pinnacle PCTV HD 800i
cx88[0]:    card=59 -> DViCO FusionHDTV 5 PCI nano
cx88[0]:    card=60 -> Pinnacle Hybrid PCTV
cx88[0]:    card=61 -> Leadtek TV2000 XP Global
cx88[0]:    card=62 -> PowerColor RA330
cx88[0]:    card=63 -> Geniatech X8000-MT DVBT
cx88[0]:    card=64 -> DViCO FusionHDTV DVB-T PRO
cx88[0]:    card=65 -> DViCO FusionHDTV 7 Gold
cx88[0]:    card=66 -> Prolink Pixelview MPEG 8000GT
cx88[0]:    card=67 -> Kworld PlusTV HD PCI 120 (ATSC 120)
cx88[0]:    card=68 -> Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid
cx88[0]:    card=69 -> Hauppauge WinTV-HVR4000(Lite) DVB-S/S2
cx88[0]:    card=70 -> TeVii S460 DVB-S/S2
cx88[0]:    card=71 -> Omicom SS4 DVB-S/S2 PCI
cx88[0]:    card=72 -> TBS 8920 DVB-S/S2
cx88[0]:    card=73 -> TeVii S420 DVB-S
cx88[0]:    card=74 -> Prolink Pixelview Global Extreme
cx88[0]:    card=75 -> PROF 7300 DVB-S/S2
cx88[0]:    card=76 -> SATTRADE ST4200 DVB-S/S2
cx88[0]:    card=77 -> TBS 8910 DVB-S
cx88[0]:    card=78 -> Prof 6200 DVB-S
cx88[0]:    card=79 -> Terratec Cinergy HT PCI MKII
cx88[0]:    card=80 -> Hauppauge WinTV-IR Only
cx88[0]:    card=81 -> Leadtek WinFast DTV1800 Hybrid
cx88[0]: subsystem: 0000:0000, board: UNKNOWN/GENERIC [card=0,autodetected],
frontend(s): 0
cx88[0]: TV tuner type -1, Radio tuner type -1
usb 3-6: new high speed USB device using ehci_hcd and address 2
usb 3-6: New USB device found, idVendor=0409, idProduct=005a
usb 3-6: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 3-6: configuration #1 chosen from 1 choice
hub 3-6:1.0: USB hub found
hub 3-6:1.0: 4 ports detected
Manufacturer ID= 0x00, Chip ID = 0000. It is not a TEA5761
usb 5-2: new high speed USB device using ehci_hcd and address 2
tuner 0-0042: chip found @ 0x84 (cx88[0])
tda9887 0-0042: creating new instance
tda9887 0-0042: tda988[5/6/7] found
cx88[0]/0: found at 0000:08:01.0, rev: 5, irq: 17, latency: 64, mmio:
0xfa000000
IRQ 17/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs
cx88[0]/0: registered device video0 [v4l2]
cx88[0]/0: registered device vbi0
usb 5-2: New USB device found, idVendor=0424, idProduct=2502
usb 5-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 5-2: configuration #1 chosen from 1 choice
hub 5-2:1.0: USB hub found
hub 5-2:1.0: 2 ports detected
usb 7-1: new full speed USB device using uhci_hcd and address 2
usb 7-1: New USB device found, idVendor=05e3, idProduct=0604
usb 7-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 7-1: Product: USB Hub
usb 7-1: configuration #1 chosen from 1 choice
hub 7-1:1.0: USB hub found
hub 7-1:1.0: 4 ports detected
usb 3-6.4: new high speed USB device using ehci_hcd and address 3
Adding 6843648k swap on /dev/sda6.  Priority:-1 extents:1 across:6843648k
usb 3-6.4: New USB device found, idVendor=058f, idProduct=6366
usb 3-6.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 3-6.4: Product: Mass Storage Device
usb 3-6.4: Manufacturer: Generic
usb 3-6.4: SerialNumber: 058F0O1111B1
usb 3-6.4: configuration #1 chosen from 1 choice
Initializing USB Mass Storage driver...
scsi8 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb 5-2.1: new high speed USB device using ehci_hcd and address 4
usb 5-2.1: New USB device found, idVendor=0424, idProduct=2602
usb 5-2.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 5-2.1: configuration #1 chosen from 1 choice
hub 5-2.1:1.0: USB hub found
hub 5-2.1:1.0: 4 ports detected
usb 5-2.1.1: new high speed USB device using ehci_hcd and address 5
usb 5-2.1.1: New USB device found, idVendor=0424, idProduct=2228
usb 5-2.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
usb 5-2.1.1: Product: Flash Card Reader
usb 5-2.1.1: Manufacturer: Generic
usb 5-2.1.1: SerialNumber: 26020128B005
usb 5-2.1.1: configuration #1 chosen from 1 choice
scsi9 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 5
usb-storage: waiting for device to settle before scanning
input: PC Speaker as /devices/platform/pcspkr/input/input5
i801_smbus 0000:00:1f.3: PCI INT C -> GSI 18 (level, low) -> IRQ 18
ACPI: I/O resource 0000:00:1f.3 [0x400-0x41f] conflicts with ACPI region SMRG
[0x400-0x40f]
ACPI: Device needs an ACPI driver
i801_smbus: probe of 0000:00:1f.3 failed with error -16
iTCO_vendor_support: vendor-support=0
sd 0:0:0:0: Attached scsi generic sg0 type 0
sd 0:0:1:0: Attached scsi generic sg1 type 0
sd 1:0:0:0: Attached scsi generic sg2 type 0
sd 1:0:1:0: Attached scsi generic sg3 type 0
sd 2:0:0:0: Attached scsi generic sg4 type 0
sd 3:0:0:0: Attached scsi generic sg5 type 0
sd 4:0:0:0: Attached scsi generic sg6 type 0
sr 6:0:1:0: Attached scsi generic sg7 type 5
sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 6:0:1:0: Attached scsi CD-ROM sr0
nvidia: module license 'NVIDIA' taints kernel.
Disabling lock debugging due to kernel taint
sky2 driver version 1.23
sky2 0000:03:00.0: PCI INT A -> GSI 30 (level, low) -> IRQ 30
sky2 0000:03:00.0: setting latency timer to 64
sky2 0000:03:00.0: Yukon-2 EC chip revision 2
sky2 0000:03:00.0: irq 55 for MSI/MSI-X
sky2 eth0: addr 00:21:91:19:9e:f6
iTCO_wdt: Intel TCO WatchDog Timer Driver v1.05
iTCO_wdt: Found a ICH10R TCO device (Version=2, TCOBASE=0x0860)
iTCO_wdt: initialized. heartbeat=30 sec (nowayout=1)
udev: renamed network interface eth0 to eth1
nvidia 0000:02:00.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24
nvidia 0000:02:00.0: setting latency timer to 64
NVRM: loading NVIDIA UNIX x86_64 Kernel Module  185.18.36  Fri Aug 14 17:35:21
PDT 2009
r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
r8169 0000:06:00.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
r8169 0000:06:00.0: setting latency timer to 64
r8169 0000:06:00.0: irq 56 for MSI/MSI-X
eth0: RTL8168c/8111c at 0xffffc90000c72000, 00:26:18:54:a0:a9, XID 3c4000c0 IRQ
56
HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
HDA Intel 0000:00:1b.0: setting latency timer to 64
hda_codec: Unknown model for ALC1200, trying auto-probe from BIOS...
autoconfig: line_outs=4 (0x14/0x15/0x16/0x17/0x0)
   speaker_outs=0 (0x0/0x0/0x0/0x0/0x0)
   hp_outs=1 (0x1b/0x0/0x0/0x0/0x0)
   mono: mono_out=0x0
   dig-out=0x11/0x1e
   inputs: mic=0x18, fmic=0x19, line=0x1a, fline=0x0, cd=0x0, aux=0x0
realtek: No valid SSID, checking pincfg 0x4015e601 for NID 0x1d
realtek: Enabling init ASM_ID=0xe601 CODEC_ID=10ec0888
input: HDA Digital PCBeep as /devices/pci0000:00/0000:00:1b.0/input/input6
scsi 8:0:0:0: Direct-Access     Multi    Flash Reader     1.00 PQ: 0 ANSI: 0
sd 8:0:0:0: Attached scsi generic sg8 type 0
sd 8:0:0:0: [sdh] Attached SCSI removable disk
usb-storage: device scan complete
scsi 9:0:0:0: Direct-Access     Generic  Flash HS-CF      4.44 PQ: 0 ANSI: 0
sd 9:0:0:0: Attached scsi generic sg9 type 0
scsi 9:0:0:1: Direct-Access     Generic  Flash HS-COMBO   4.44 PQ: 0 ANSI: 0
sd 9:0:0:1: Attached scsi generic sg10 type 0
sd 9:0:0:1: [sdj] Attached SCSI removable disk
sd 9:0:0:0: [sdi] Attached SCSI removable disk
usb-storage: device scan complete
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
r8169: eth0: link up
r8169: eth0: link up
sky2 eth1: enabling interface
ADDRCONF(NETDEV_UP): eth1: link is not ready
NET: Registered protocol family 17
martian source 255.255.255.255 from 192.168.0.1, on dev eth0
ll header: ff:ff:ff:ff:ff:ff:00:13:46:5e:23:9d:08:00
sky2 eth1: Link is up at 1000 Mbps, full duplex, flow control both
ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
eth0: no IPv6 routers present
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
Slow work thread pool: Starting up
Slow work thread pool: Ready
FS-Cache: Loaded
FS-Cache: Netfs 'nfs' registered for caching
Installing knfsd (copyright (C) 1996 okir@...).
NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
NFSD: starting 90-second grace period
ip_tables: (C) 2000-2006 Netfilter Core Team
Netfilter messages via NETLINK v0.30.
nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
CONFIG_NF_CT_ACCT is deprecated and will be removed soon. Please use
nf_conntrack.acct=1 kernel parameter, acct=1 nf_conntrack module option or
sysctl net.netfilter.nf_conntrack_acct=1 to enable it.
ctnetlink v0.93: registering with nfnetlink.
ClusterIP Version 0.8 loaded successfully
xt_time: kernel timezone is +1000
eth1: no IPv6 routers present
netfilter PSD loaded - (c) astaro AG
IFWLOG: register target
Shorewall:net2fw:DROP:IN=eth0 OUT=
MAC=00:26:18:54:a0:a9:00:13:46:5e:23:9d:08:00 SRC=192.168.0.1 DST=192.168.0.166
LEN=257 TOS=0x00 PREC=0x00 TTL=64 ID=351 PROTO=UDP SPT=1900 DPT=47614 LEN=237









This is lilo.conf, as it was after I edited it following the first boot failure
reported here, changing everything to sdb.  It was from booting with this that
drakboot curiously still saw the 'proper' sda as sda, even though lilo treated
it as sdb.

/etc/lilo.conf:
# File generated by DrakX/drakboot
# WARNING: do not forget to run lilo after modifying this file

default="linux"
boot=/dev/sdb
map=/boot/map
install=menu
menu-scheme=wb:bw:wb:bw
compact
prompt
nowarn
large-memory
timeout=50
message=/boot/message
image=/boot/vmlinuz
    label="linux"
    root="UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88"
    initrd=/boot/initrd.img
    append="resume=UUID=a9e744a8-7c47-46c2-8212-5d23d47ec4e1 splash=silent"
    vga=788
image=/boot/vmlinuz
    label="linux-nonfb"
    root="UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88"
    initrd=/boot/initrd.img
    append="resume=UUID=a9e744a8-7c47-46c2-8212-5d23d47ec4e1"
image=/boot/vmlinuz
    label="failsafe"
    root="UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88"
    initrd=/boot/initrd.img
    append="failsafe"
other=/dev/sdb1
    label="windows"
    table=/dev/sdb
other=/dev/sdb3
    label="2009_pwp"
image=/boot/vmlinuz-2.6.31-desktop-0.rc6.1mnb
    label="2.6.31-desktoprc6-1mnb"
    root="UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88"
    initrd=/boot/initrd-2.6.31-desktop-0.rc6.1mnb.img
    append="resume=UUID=a9e744a8-7c47-46c2-8212-5d23d47ec4e1 splash=silent"
    vga=788
image=/boot/vmlinuz-2.6.31-desktop-0.rc8.1mnb
    label="2.6.31-desktoprc8-1mnb"
    root="UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88"
    initrd=/boot/initrd-2.6.31-desktop-0.rc8.1mnb.img
    append="resume=UUID=a9e744a8-7c47-46c2-8212-5d23d47ec4e1 splash=silent"
    vga=788






[root@quad ~]# cat /etc/lilo.conf
# File generated by DrakX/drakboot
# WARNING: do not forget to run lilo after modifying this file

default="linux"
boot=/dev/sda
map=/boot/map
install=menu
keytable=/boot/us.klt
menu-scheme=wb:bw:wb:bw
compact
prompt
nowarn
large-memory
timeout=50
message=/boot/message
image=/boot/vmlinuz
    label="linux"
    root="UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88"
    initrd=/boot/initrd.img
    append=" resume=UUID=a9e744a8-7c47-46c2-8212-5d23d47ec4e1"
image=/boot/vmlinuz-2.6.31-desktop-0.rc8.1mnb
    label="2.6.31-desktoprc8-1mnb"
    root="UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88"
    initrd=/boot/initrd-2.6.31-desktop-0.rc8.1mnb.img
    append=" resume=UUID=a9e744a8-7c47-46c2-8212-5d23d47ec4e1"
image=/boot/vmlinuz-2.6.31-desktop-0.rc6.1mnb
    label="2.6.31-desktoprc6-1mnb"
    root="UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88"
    initrd=/boot/initrd-2.6.31-desktop-0.rc6.1mnb.img
    append=" resume=UUID=a9e744a8-7c47-46c2-8212-5d23d47ec4e1"
image=/boot/vmlinuz-2.6.31-0.rc8.rt9.2mdv
    label="2.6.31rc8-rt9.2"
    root="UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88"
    initrd=/boot/initrd-2.6.31-0.rc8.rt9.2mdv.img
    append=" resume=UUID=a9e744a8-7c47-46c2-8212-5d23d47ec4e1"
image=/boot/vmlinuz
    label="failsafe"
    root="UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88"
    initrd=/boot/initrd.img
    append=" failsafe"
other=/dev/sda1
    label="windows"
    table=/dev/sda
other=/dev/sda3
    label="2009_pwp"






 /etc/lilo.conf, as most recently written by drakconf, which reverted to the
correct disk for sda (I manually added the last 2 lines):

[root@quad ~]# cat /etc/lilo.conf
# File generated by DrakX/drakboot
# WARNING: do not forget to run lilo after modifying this file

default="linux"
boot=/dev/sda
map=/boot/map
install=menu
keytable=/boot/us.klt
menu-scheme=wb:bw:wb:bw
compact
prompt
nowarn
large-memory
timeout=50
message=/boot/message
image=/boot/vmlinuz
    label="linux"
    root="UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88"
    initrd=/boot/initrd.img
    append=" resume=UUID=a9e744a8-7c47-46c2-8212-5d23d47ec4e1"
image=/boot/vmlinuz-2.6.31-desktop-0.rc8.1mnb
    label="2.6.31-desktoprc8-1mnb"
    root="UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88"
    initrd=/boot/initrd-2.6.31-desktop-0.rc8.1mnb.img
    append=" resume=UUID=a9e744a8-7c47-46c2-8212-5d23d47ec4e1"
image=/boot/vmlinuz-2.6.31-desktop-0.rc6.1mnb
    label="2.6.31-desktoprc6-1mnb"
    root="UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88"
    initrd=/boot/initrd-2.6.31-desktop-0.rc6.1mnb.img
    append=" resume=UUID=a9e744a8-7c47-46c2-8212-5d23d47ec4e1"
image=/boot/vmlinuz-2.6.31-0.rc8.rt9.2mdv
    label="2.6.31rc8-rt9.2"
    root="UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88"
    initrd=/boot/initrd-2.6.31-0.rc8.rt9.2mdv.img
    append=" resume=UUID=a9e744a8-7c47-46c2-8212-5d23d47ec4e1"
image=/boot/vmlinuz
    label="failsafe"
    root="UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88"
    initrd=/boot/initrd.img
    append=" failsafe"
other=/dev/sda1
    label="windows"
    table=/dev/sda
other=/dev/sda3
    label="2009_pwp"



----------------------------------------------------------------------------
Original Bug Text:


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are 1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of about 25 Gb, then extended partition containing mostly a large encrypted partition as well as swap.  The next 1.5Gb HD is all a single encrypted partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well, using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo still points at sda, which cooker now thinks is the second HD with only the encrypted data partition on it.  Curiously lilo can still start the 2009 partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.



--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://qa.mandriva.com/show_bug.cgi?id=53443

  Summary    : SATA renumbering prevents boot
  Product    : Mandriva Linux
  Component  : Core Packages
  Version    : Cooker
  Keywords   : Triaged
  Status     : RESOLVED
  Severity   : critical
  Priority   : release_critical
  Assigned To: kernel@...
  Reported By: t.blackwell@...


Herton Ronaldo Krzesinski <herton@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |herton@...
         Resolution|                            |OLD




--- Comment #7 from Herton Ronaldo Krzesinski <herton@...>  2009-10-07 19:49:13 CEST ---
Judging by the last comments, then issue has gone away. The kernel could be at
fault if it included a new driver which sees new controller, or could be that
you had a pen drive/usb disk enclosure attached while booting when the problems
happened?

Also, it's possible that mkinitrd or bootloader-config could have a bug too.
I'm closing as OLD, please reopen if you still see the issue.



----------------------------------------------------------------------------
Original Bug Text:


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are 1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of about 25 Gb, then extended partition containing mostly a large encrypted partition as well as swap.  The next 1.5Gb HD is all a single encrypted partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well, using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo still points at sda, which cooker now thinks is the second HD with only the encrypted data partition on it.  Curiously lilo can still start the 2009 partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.



--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://qa.mandriva.com/show_bug.cgi?id=53443

  Summary    : SATA renumbering prevents boot
  Product    : Mandriva Linux
  Component  : Core Packages
  Version    : Cooker
  Keywords   : Triaged
  Status     : RESOLVED
  Severity   : critical
  Priority   : release_critical
  Assigned To: kernel@...
  Reported By: t.blackwell@...





--- Comment #8 from Tony Blackwell <t.blackwell@...>  2009-10-08 11:19:10 CEST ---
This is still an issue with 2010 x86_64 RC1.

The install process sees the disks differently than the system it is installing
then sees them.  Install thinks the "first" disk is sdb, I install to it as
sdb, but on reboot it thinks it is on sda.  All sorts of stuff is not right as
a consequence.

If, immediately on reboot after install, I attempt to run lilo, it fails:
(I suspect the device-mapper error is unrelated?)

# lilo
/proc/misc: No entry for device-mapper found
Is device-mapper driver missing from kernel?
Failure to communicate with kernel device-mapper driver.
Added linux *
Added linux-nonfb
Added failsafe
Warning: First sector of /dev/sdb1 doesn't have a valid boot signature
Added windows
2 warnings were suppressed.
#


# df
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda2              25G  4.7G   19G  20% /
/dev/sda1              36G   21G   15G  59% /mnt/windows
/dev/sda3              26G   16G  8.3G  66% /media/disk
#


# cat /etc/lilo.conf
# File generated by DrakX/drakboot
# WARNING: do not forget to run lilo after modifying this file

default="linux"
boot=/dev/sdb
map=/boot/map
install=menu
menu-scheme=wb:bw:wb:bw
compact
prompt
nowarn
large-memory
timeout=50
message=/boot/message
disk=/dev/sdb bios=0x80
image=/boot/vmlinuz
    label="linux"
    root="UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88"
    initrd=/boot/initrd.img
    append=" resume=UUID=a9e744a8-7c47-46c2-8212-5d23d47ec4e1 splash=silent"
    vga=788
image=/boot/vmlinuz
    label="linux-nonfb"
    root="UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88"
    initrd=/boot/initrd.img
    append=" resume=UUID=a9e744a8-7c47-46c2-8212-5d23d47ec4e1"
image=/boot/vmlinuz
    label="failsafe"
    root="UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88"
    initrd=/boot/initrd.img
    append=" failsafe"
other=/dev/sdb1
    label="windows"
    table=/dev/sdb
[root@quad ~]#


Edited /etc/lilo.conf, changed all sdb to sda, added an entry for the 2009
partition, then ran lilo:

# lilo
/proc/misc: No entry for device-mapper found
Is device-mapper driver missing from kernel?
Failure to communicate with kernel device-mapper driver.
Added linux *
Added linux-nonfb
Added failsafe
Added windows
Added 2009_pwp
One warning was suppressed.
[root@quad ~]#

# more /etc/fstab
# Entry for /dev/sdb2 :
UUID=fa886aed-5dc7-4904-a5b3-8e8d57f72f88 / ext3 relatime 1 1
/dev/cdrom /media/cdrom auto umask=0,users,iocharset=utf8,noauto,ro,exec 0 0
# Entry for /dev/sdb1 :
UUID=72C26660C2662895 /mnt/windows ntfs-3g defaults,umask=000 0 0
none /proc proc defaults 0 0
# Entry for /dev/sdb6 :
UUID=a9e744a8-7c47-46c2-8212-5d23d47ec4e1 swap swap defaults 0 0
[root@quad ~]#



----------------------------------------------------------------------------
Original Bug Text:


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are 1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of about 25 Gb, then extended partition containing mostly a large encrypted partition as well as swap.  The next 1.5Gb HD is all a single encrypted partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well, using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo still points at sda, which cooker now thinks is the second HD with only the encrypted data partition on it.  Curiously lilo can still start the 2009 partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.



--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://qa.mandriva.com/show_bug.cgi?id=53443

  Summary    : SATA renumbering prevents boot
  Product    : Mandriva Linux
  Component  : Core Packages
  Version    : Cooker
  Keywords   : Triaged
  Status     : REOPENED
  Severity   : critical
  Priority   : release_critical
  Assigned To: kernel@...
  Reported By: t.blackwell@...


Tony Blackwell <t.blackwell@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|OLD                         |




--- Comment #9 from Tony Blackwell <t.blackwell@...>  2009-10-08 11:20:35 CEST ---
Re-opened, as above



----------------------------------------------------------------------------
Original Bug Text:


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are 1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of about 25 Gb, then extended partition containing mostly a large encrypted partition as well as swap.  The next 1.5Gb HD is all a single encrypted partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well, using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo still points at sda, which cooker now thinks is the second HD with only the encrypted data partition on it.  Curiously lilo can still start the 2009 partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.



--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://qa.mandriva.com/show_bug.cgi?id=53443

  Summary    : SATA renumbering prevents boot
  Product    : Mandriva Linux
  Component  : Core Packages
  Version    : Cooker
  Keywords   : Triaged
  Status     : REOPENED
  Severity   : critical
  Priority   : release_critical
  Assigned To: kernel@...
  Reported By: t.blackwell@...


Pascal Terjan <pterjan@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pterjan@...




--- Comment #10 from Pascal Terjan <pterjan@...>  2009-10-08 11:41:56 CEST ---
Yes you can no longer run lilo because it lists the disk, but the bug is titled
"prevents boot" which is wrong as you could boot



----------------------------------------------------------------------------
Original Bug Text:


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are 1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of about 25 Gb, then extended partition containing mostly a large encrypted partition as well as swap.  The next 1.5Gb HD is all a single encrypted partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well, using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo still points at sda, which cooker now thinks is the second HD with only the encrypted data partition on it.  Curiously lilo can still start the 2009 partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.



--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://qa.mandriva.com/show_bug.cgi?id=53443

  Summary    : SATA renumbering prevents boot
  Product    : Mandriva Linux
  Component  : Core Packages
  Version    : Cooker
  Keywords   : NEEDINFO, Triaged
  Status     : REOPENED
  Severity   : critical
  Priority   : release_critical
  Assigned To: kernel@...
  Reported By: t.blackwell@...


Herton Ronaldo Krzesinski <herton@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |NEEDINFO




--- Comment #11 from Herton Ronaldo Krzesinski <herton@...>  2009-10-08 16:12:10 CEST ---
Ok, happening with install vs. installed system, can you attach to this bug the
following?:

- the dmesg of 2010.0 booted system (disable shorewall or do dmesg right after
system boot, to avoid system log flood truncating the kernel log, the dmesg you
posted are truncated, missing the first part).
- attach the contents of /root/drakx/report.bug.gz of the installed 2010.0
system here.



----------------------------------------------------------------------------
Original Bug Text:


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are 1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of about 25 Gb, then extended partition containing mostly a large encrypted partition as well as swap.  The next 1.5Gb HD is all a single encrypted partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well, using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo still points at sda, which cooker now thinks is the second HD with only the encrypted data partition on it.  Curiously lilo can still start the 2009 partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.



--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://qa.mandriva.com/show_bug.cgi?id=53443

  Summary    : SATA renumbering prevents boot
  Product    : Mandriva Linux
  Component  : Core Packages
  Version    : Cooker
  Keywords   : NEEDINFO, Triaged
  Status     : REOPENED
  Severity   : critical
  Priority   : release_critical
  Assigned To: kernel@...
  Reported By: t.blackwell@...





--- Comment #12 from Pascal Terjan <pterjan@...>  2009-10-15 18:36:04 CEST ---
Are both drives on the same controller (can't know as first part of dmesg is
missing) ?



----------------------------------------------------------------------------
Original Bug Text:


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are 1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of about 25 Gb, then extended partition containing mostly a large encrypted partition as well as swap.  The next 1.5Gb HD is all a single encrypted partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well, using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo still points at sda, which cooker now thinks is the second HD with only the encrypted data partition on it.  Curiously lilo can still start the 2009 partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.



--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://qa.mandriva.com/show_bug.cgi?id=53443

  Summary    : SATA renumbering prevents boot
  Product    : Mandriva Linux
  Component  : Core Packages
  Version    : Cooker
  Keywords   : NEEDINFO, Triaged
  Status     : REOPENED
  Severity   : normal
  Priority   : normal
  Assigned To: kernel@...
  Reported By: t.blackwell@...


Oden Eriksson <oeriksson@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|release_critical            |normal
                 CC|                            |oeriksson@...
           Severity|critical                    |normal




--- Comment #13 from Oden Eriksson <oeriksson@...>  2009-10-21 21:28:23 CEST ---
lowering this issue as it's not release critical.



----------------------------------------------------------------------------
Original Bug Text:


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are 1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of about 25 Gb, then extended partition containing mostly a large encrypted partition as well as swap.  The next 1.5Gb HD is all a single encrypted partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well, using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo still points at sda, which cooker now thinks is the second HD with only the encrypted data partition on it.  Curiously lilo can still start the 2009 partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.



--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://qa.mandriva.com/show_bug.cgi?id=53443

  Summary    : SATA renumbering prevents boot
  Product    : Mandriva Linux
  Component  : Core Packages
  Version    : Cooker
  Keywords   : NEEDINFO, Triaged
  Status     : REOPENED
  Severity   : normal
  Priority   : release_critical
  Assigned To: kernel@...
  Reported By: t.blackwell@...


Frederic Crozat <fcrozat@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|normal                      |release_critical






----------------------------------------------------------------------------
Original Bug Text:


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are 1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of about 25 Gb, then extended partition containing mostly a large encrypted partition as well as swap.  The next 1.5Gb HD is all a single encrypted partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well, using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo still points at sda, which cooker now thinks is the second HD with only the encrypted data partition on it.  Curiously lilo can still start the 2009 partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.



--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://qa.mandriva.com/show_bug.cgi?id=53443

  Summary    : SATA renumbering prevents boot
  Product    : Mandriva Linux
  Component  : Core Packages
  Version    : Cooker
  Keywords   : NEEDINFO, Triaged
  Status     : REOPENED
  Severity   : normal
  Priority   : release_critical
  Assigned To: kernel@...
  Reported By: t.blackwell@...


Wanderlei Antonio Cavassin <cavassin@...> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |cavassin@...




--- Comment #14 from Wanderlei Antonio Cavassin <cavassin@...>  2009-10-28 16:39:34 CEST ---
Hi Tony, are you able to attach the information asked in previous posts?

you can also attach /var/log/dmesg which contains the first kernel messages
during the boot process.



----------------------------------------------------------------------------
Original Bug Text:


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are 1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of about 25 Gb, then extended partition containing mostly a large encrypted partition as well as swap.  The next 1.5Gb HD is all a single encrypted partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well, using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo still points at sda, which cooker now thinks is the second HD with only the encrypted data partition on it.  Curiously lilo can still start the 2009 partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.



--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://qa.mandriva.com/show_bug.cgi?id=53443

  Summary    : SATA renumbering prevents boot
  Product    : Mandriva Linux
  Component  : Core Packages
  Version    : Cooker
  Keywords   : NEEDINFO, Triaged
  Status     : REOPENED
  Severity   : normal
  Priority   : release_critical
  Assigned To: kernel@...
  Reported By: t.blackwell@...





--- Comment #15 from Tony Blackwell <t.blackwell@...>  2009-11-02 06:03:19 CEST ---
Created an attachment (id=15679)
 --> (https://qa.mandriva.com/attachment.cgi?id=15679)
dmesg booting failsafe



----------------------------------------------------------------------------
Original Bug Text:


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are 1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of about 25 Gb, then extended partition containing mostly a large encrypted partition as well as swap.  The next 1.5Gb HD is all a single encrypted partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well, using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo still points at sda, which cooker now thinks is the second HD with only the encrypted data partition on it.  Curiously lilo can still start the 2009 partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.



--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://qa.mandriva.com/show_bug.cgi?id=53443

  Summary    : SATA renumbering prevents boot
  Product    : Mandriva Linux
  Component  : Core Packages
  Version    : Cooker
  Keywords   : NEEDINFO, Triaged
  Status     : REOPENED
  Severity   : normal
  Priority   : release_critical
  Assigned To: kernel@...
  Reported By: t.blackwell@...





--- Comment #16 from Tony Blackwell <t.blackwell@...>  2009-11-02 06:04:39 CEST ---
Created an attachment (id=15680)
 --> (https://qa.mandriva.com/attachment.cgi?id=15680)
dmesg booting run level 5



----------------------------------------------------------------------------
Original Bug Text:


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are 1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of about 25 Gb, then extended partition containing mostly a large encrypted partition as well as swap.  The next 1.5Gb HD is all a single encrypted partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well, using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo still points at sda, which cooker now thinks is the second HD with only the encrypted data partition on it.  Curiously lilo can still start the 2009 partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.



--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://qa.mandriva.com/show_bug.cgi?id=53443

  Summary    : SATA renumbering prevents boot
  Product    : Mandriva Linux
  Component  : Core Packages
  Version    : Cooker
  Keywords   : NEEDINFO, Triaged
  Status     : REOPENED
  Severity   : normal
  Priority   : release_critical
  Assigned To: kernel@...
  Reported By: t.blackwell@...





--- Comment #17 from Tony Blackwell <t.blackwell@...>  2009-11-02 06:07:04 CEST ---
Created an attachment (id=15681)
 --> (https://qa.mandriva.com/attachment.cgi?id=15681)
attached /root/drakx/report.bug.gz



----------------------------------------------------------------------------
Original Bug Text:


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are 1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of about 25 Gb, then extended partition containing mostly a large encrypted partition as well as swap.  The next 1.5Gb HD is all a single encrypted partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well, using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo still points at sda, which cooker now thinks is the second HD with only the encrypted data partition on it.  Curiously lilo can still start the 2009 partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.



--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

https://qa.mandriva.com/show_bug.cgi?id=53443

  Summary    : SATA renumbering prevents boot
  Product    : Mandriva Linux
  Component  : Core Packages
  Version    : Cooker
  Keywords   : NEEDINFO, Triaged
  Status     : REOPENED
  Severity   : normal
  Priority   : release_critical
  Assigned To: kernel@...
  Reported By: t.blackwell@...





--- Comment #18 from Tony Blackwell <t.blackwell@...>  2009-11-02 06:08:58 CEST ---
Created an attachment (id=15682)
 --> (https://qa.mandriva.com/attachment.cgi?id=15682)
attached /var/log/dmesg



----------------------------------------------------------------------------
Original Bug Text:


Description of problem:
hardware:
ASUS P6T motherboard, i7 920 CPU, several SATA drives of which first 2 are 1.5Gb each.  1st SATA drive has a 35gb windows partition then 2 ext3 each of about 25 Gb, then extended partition containing mostly a large encrypted partition as well as swap.  The next 1.5Gb HD is all a single encrypted partition.
windows on sda1, cooker on sda2, 2009 on sda3.  All has been working well, using lilo from the 2020beta1 on root of sda to boot cooker on sda2 or the older 2009 on sda3.

Last night loaded all the updates offered - around 500 files.

Today boot failed.  Eventually found that now cooker thinks it is on sdb.  Lilo still points at sda, which cooker now thinks is the second HD with only the encrypted data partition on it.  Curiously lilo can still start the 2009 partition on sda3, which still corectly knows it is on sda and works fine.

Work-Around:
Edited lilo.conf, changed everyting to sdb, ran lilo and cooker boots and runs OK now.


Summary:
Last night's updates have somehow changed SATA enumeration to prevent boot without manually fixing lilo.


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.



--
Configure bugmail: https://qa.mandriva.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.