|
Bugzilla – Full Text Bug Listing |
| Summary: | Yast2 partitioner deletes partition table on firewire disk | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 10.3 | Reporter: | Torsten Duwe <duwe> |
| Component: | YaST2 | Assignee: | Hannes Reinecke <hare> |
| Status: | RESOLVED FIXED | QA Contact: | Jiri Srain <jsrain> |
| Severity: | Critical | ||
| Priority: | P5 - None | CC: | snwint, wolfgang.engel |
| Version: | Final | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE 10.3 | ||
| Whiteboard: | |||
| Found By: | Development | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
yast 2 logfile from calling yast2, launching and quitting the partitioner.
backup MBR broken MBR |
||
Note that that parted command Yast claims to execute worked as expected, printing the current table and doing nothing else. Providing a few more files... Created attachment 189029 [details]
backup MBR
The backup MBR I started to use during initial investigation. This should match the one used in the log.
Created attachment 189030 [details]
broken MBR
That's what the first block on the disk looks like afterwards
Strange, from the log I could only see calls "/usr/sbin/parted -s /dev/sdb unit cyl print" and "/sbin/fdisk -l /dev/sdb". Both should not change anything regarding content of disk sdb. Need access to the system to investigate this further. Just reproduced on my office workstation, a freshly updated 10.3. Details via PM. I found that calling hwinfo --disk is enough to make the partitition table data temporarily go away. I could always get back to a sane state by calling: echo 1 > /sys/block/sdc/device/delete; rmmod sbp2; modprobe sbp2 The code executed by hwinfo --disk is also executed when yast2 is probing for harddisks. Steffen needs to have a look at this. It's requesting the scsi serial number page that triggers it; e.g.: scsiinfo -s /dev/sdc Looks like a kernel bug. scsiinfo -s or scsiinfo -i both kill the first block on amd64. This also happens with a freshly compiled vanilla 2.6.23.12. Either this is a bug in the mainline kernel or the scsi utilities are not 64-bit-clean. Please, do not use scsiinfo. It's grossly out of date and not maintained anymore. Please use 'sg_inq' instead. This is providing the same information but is maintained. And I don't seem to be able to write to the drive anyway. Writing partition table works, but calling fdisk again doesn't return a valid table. Buggy interface chip. Any call to 'INQUIRY' has to be followed by a 'READ CAPACITY' command, otherwise a READ command will precede the payload by 36 empty bytes. Speak about crappy implementations ... For the record: the FireWire interface chip is a Prolific PL-3507, Dated Week 23, Year 2006, revision 4C. A firmware update to http://www.prolific.com.tw/support/files/\IDE Storage\PL-3507\Firmware\fw_pl3507B_d042006.zip resolved the issue. |
Created attachment 189028 [details] yast 2 logfile from calling yast2, launching and quitting the partitioner. It proved sufficient to attach a firewire disk with a DOS/BIOS partition table to a 10.3 system and simply call the partitioner, acknowledge the expert warning and then immediately quit the partitioner, to erase the partition table (!) Independently of whether the disk contained partitions or not, yast2 partitioner, even when quit immediately, makes sure there are none, by writing junk into the first block.