Bug 434455

Before you run anything that re-requests a partition table scan, like fdisk does, at the point you miss the partitions, what does:
  ls -l /sys/class/block
print?

Created attachment 244974 [details]
Output of "ls -l /sys/class/block"

(Used an attachment to avoid line automatic breaks.)

There is no sda1 device known by the kernel at that time, therefore no /dev/sda1, or any link to it. The vbox driver interaction of the emulated disk needs to be fixed, or a manual partition scan needs to be requested. Nothing that could be fixed from udev's side.

Of course. Because there's no sda1 device before I create a partition.

Ah sorry, I see, you miss a specifically named link. Still, looks like a emulated block driver issue to return different results on scsi inquiries, like:
  1ATA_VBOX_HARDDISK_VB49544707-9defca96
  SATA_VBOX_HARDDISK_VB49544707-9defca96

What does:
  /lib/udev/scsi_id --whitelisted -p0x80 -d /dev/sda
and:
  /lib/udev/scsi_id --whitelisted -p0x83 -d /dev/sda
print?

linux:/home/linux # /lib/udev/scsi_id --whitelisted -p0x80 -d /dev/sda
SATA     VBOX HARDDISK  VB3664379b-b804dda6
linux:/home/linux # /lib/udev/scsi_id --whitelisted -p0x83 -d /dev/sda
SATA     VBOX HARDDISK  VB3664379b-b804dda6

Seems, the disk returned a different result in the very first query.

Before you partition it, what does scsi_id print?

Which by-id/ links are created for the disk, before it is partitioned?

(In reply to comment #7 from Kay Sievers)
> Before you partition it, what does scsi_id print?

Comment 6 is before the partitioning.

> Which by-id/ links are created for the disk, before it is partitioned?

That is visible in attachment 244939 [details] (in the initial description).

Ok, the vbox disk emulation logic seems to have a problem. The 1ATA* vendor query result does not happen anytime later, only for the very first query maybe.

FYI, Ubuntu (ubuntu-8.10-beta-desktop-i386.iso) only creates these links:

ata-VBOX_HARDDISK_VB3664379b-b804dda6 -> ../../sda
ata-VBOX_HARDDISK_VB3664379b-b804dda6-part1 -> ../../sda1
scsi-1ATA_VBOX_HARDDISK_VB3664379b-b804dda6 -> ../../sda
scsi-1ATA_VBOX_HARDDISK_VB3664379b-b804dda6-part1 -> ../../sda1

Also, the installed system doesn't have that "1ATA" links.

And the installation DVD works without any problems. So that problem is special to the "installable Live CD". 

It looks like the behavior of the emulated Vbox disk changes, regarding what repeated reading of SCSI mode pages return? Sounds like a bug in the Vbox device emulation.

SUSE is the only distro using by-id/ links in fstab, as far as I know, and all other use the UUID's if the filesystems. So it might be, that this behavior never caused a problem for anybody else.

Did you always recreate the guest before your tests? I wonder, if only the first query after creating the Vbox guest has this problem, because the initrd of the later installed system should also not be able to find it's disk, if they always return different results, like in the installer, for the first query.

(In reply to comment #13 from Kay Sievers)
> It looks like the behavior of the emulated Vbox disk changes, regarding what
> repeated reading of SCSI mode pages return? Sounds like a bug in the Vbox
> device emulation.

But I cannot report that as bug at Sun when I have nothing more than
"that happens only with openSUSE Live CD in Beta 2 i386".

> Did you always recreate the guest before your tests?

No. I always used the same VM, but did reset the disk with parted mklabel
for the fdisk test.

Of course, in Ubuntu, I did not install (which would not cause the problem to happen because of UUIDs), but I started the live CD and did the fdisk test. So the problem would have shown up if it would be there.

Also, I did the fdisk test in the installation DVD (with Ctrl+Alt+X opening a Terminal in YaST). So that would be exactly the same case as with the bootable
Live CD.

Maybe it's the scsi-passthrough for ATA disks, we got a similar bug on real hardware:
  https://bugzilla.novell.com/show_bug.cgi?id=435093

The current speculation is, that we miss /etc/scsi_id.config in the installer/installer initramfs, which could explain the differences in the queries.

(In reply to comment #10 from Bernhard Walle)
> FYI, Ubuntu (ubuntu-8.10-beta-desktop-i386.iso) only creates these links:
> 
> ata-VBOX_HARDDISK_VB3664379b-b804dda6 -> ../../sda
> ata-VBOX_HARDDISK_VB3664379b-b804dda6-part1 -> ../../sda1
> scsi-1ATA_VBOX_HARDDISK_VB3664379b-b804dda6 -> ../../sda
> scsi-1ATA_VBOX_HARDDISK_VB3664379b-b804dda6-part1 -> ../../sda1

I tried that too, and ubuntu does not ship scsi_id.config in the installer/live cd, therefore the results (as expected) of SCSI mode page 0x83.

Looks like a problem in our installation system, but we have currently no idea what's going wrong.

Kay, could this be caused by bug 435093 as well?

(In reply to comment #18 from Christoph Thiel)
> Kay, could this be caused by bug 435093 as well?

If the image is built by kiwi, it's definitely the same bug. I'm pretty confident, that it is caused by a missing scsi_id.config.

It was built using kiwi. So I bet it's a dup. Please give a try, as soon as I have a Build0075 LiveCD ready for testing.

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

I tested openSUSE-11.1-Beta3-Build0075-KDE4-LiveCD-i386.iso and everything is fine.

Quite cool how "problems of [...] vbox disk emulation logic" (comment 9) can be fixed in our LiveCDs. ;-)