Created attachment 580773 [details] screenshot overwritten external USB disk layout Description of problem: after successfull tested F17 in parallel install, I installed F17 as my main OS. I backuped my files to an external USB disk and forgot to power off it afterwards. It was still powered on during Installation, what I didn't realized in that deep. Well I even wondered why the USB stick I installed from is in the unchangeable right box of the install target... During install I selected the right (!) disk to install to - it the first entry - and the installation went good, all without bugs. After firstboot stuff I went on to copy my files back from that external USB disk and I was shocked ! The disk didn't carry a one-partition layout anymore (see screenshot) Version-Release number of selected component (if applicable): How reproducible: plug an external USB disk in your box, power it on, and install F17 to an internal disk. review the layout of the external USB disk. Steps to Reproduce: 1. see above 2. 3. Actual results: layout of the external USB Disk has changed/is damaged Expected results: choosing the internal disk as the install target should leave ALL other's untouched !!! Additional info: I raised the "Severity" to "High", cause dataloss is hard ! iso was: Fedora-17.TC1-x86_64-Live-Desktop.iso; dd'ed to an USB Stick I ddrescued the disc and with foremost I scratched 116.000 files from it... a "cat /dev/sdb | grep <something>" shows some/most of the files with complete pathes are still on the disc !!! This makes me think: maybe there is an easy way to unchange/recover the org. disk layout (1 partition whole disk, ext4) and files. But I don't know how to do that; I won't treat this disk further. any Help ?????
I'm seeing the same thing on F17 Beta. I only selected a single disk to install to, but all the other disks in the system were re-labeled with GPT disk labels.
(In reply to comment #1) > I'm seeing the same thing on F17 Beta. I only selected a single disk to > install to, but all the other disks in the system were re-labeled with GPT disk > labels. Please provide logs showing this behavior. From the installer, you can get to a shell on tty2 by pressing ctrl+alt+f2, then get the following logs: /tmp/anaconda.log /tmp/storage.log /tmp/program.log /tmp/syslog (non-live only) /var/log/messages (live only) If you've already rebooted into the newly installed system the logs are: /var/log/anaconda/anaconda.log /var/log/anaconda/anaconda.storage.log /var/log/anaconda/anaconda.program.log /var/log/anaconda/anaconda.syslog Please don't make a tarball/archive -- attach the files individually and ensure they get type text/plain. Thanks.
please also test with TC4 rather than Beta - we changed back from GPT labelling to MS-DOS by default... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Charles, were you also installing from one USB stick, with another USB stick connected? What partitioning method did you choose - Custom, Use All Space, or what? I've been trying to reproduce this in a VM for the last half hour and not getting anywhere.
Tried this with a usb install + usb harddrive and it worked fine. usb drive was left alone.
Until we at least have some kind of reproduction info for this, I'm -1 blocker, I cannot figure out any way to hit it so it seems like a corner case. But it's possible there's something we're missing. Reporters, we _really_ need detailed reproduction steps and/or logs (preferably both). We need to know all disks you had connected, exactly what steps you picked in the installer, and exactly what happened. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I originally encountered this with F17 Beta and a server with 3 SATA disks. The target disk sda is a 250GB, while the other two sdb and sdc are 2TB and contained a mirrored FreeBSD ZFS volume. ZFS volumes are apparently using some form of GPT partition labels. The USB memory stick is also a self-booting FreeBSD (FreeNAS) installation. F17 Beta anaconda prompted about the unknown 2TB volumes asking to format or keep data, and I selected keep data. It then tried to read the GPT-like ZFS volumes, and hung in an infinite loop with errors scrolling by on program.log about trying to read those ZFS volumes (sorry I don't have the exact errors saved). I then zeroed out the first 10meg of the 2TB drives to clear the ZFS volumes, and rebooted F17 Beta. Again, anaconda prompted about the unknown 2TB (and 256MB USB memory stick) volumes asking to format or keep data, and again I selected keep data. This time, anaconda insisted on trying to install a GPT disklabel on the 2TB disks, even though they were not selected as target disks, and were left selected as data-only disks. At the verify partition screen, the 2TB disks (sdb and sdc) were shown as "Free". Clicking Next gave the "these filesystems will be formatted" screen, listing sda (target 250GB), sdb (2TB), sdc (2TB), and sdd (256MB USB) to be formatted with GPT disklabels. At one point I removed sdd USB, and let it proceed to format the 2TB sdb and sdc. So far, I've been unable to reproduce this with F17 TC4. I re-zeroed the first 10meg of the 2TB disks. F17 TC4 anaconda prompted about the unknown 2TB SATA and 256MB USB volumes, but did not try to format/label them after I said "keep data". Likewise, after I rebooted into the FreeNAS USB memory stick and recreated the ZFS pool on the 2TB drives (mirrored the two drives, created one ZFS pool on top), F17 TC4 anaconda prompted about the unknown 2TB SATA and 256MB USB volumes, but did not try to format/label them after I said "keep data". Also, it didn't exhibit the loop in program.log trying to read the ZFS devices. So either this bug was fixed in TC4, or avoided due to the reversion back to MBR disklabels by default. Is there a way to force anaconda to use GPT so I can try to reproduce this in that scenario? Also, gdisk didn't like the ZFS volumes very much. It complained that the 2TB disks had no MBR and a corrupted GPT disklabel.
Steps to try to reproduce: 1. Boot anaconda via PXE repo=http://... 2. Select Basic Storage. 3. Select Keep Data on all the unknown disk formats anaconda finds. 4. Select only one disk as Target for installation and bootloader, leaving the other disks on the left as data disks to be mounted. 4. Select Fresh Installation. 5. Select Use All Space. You obviously need disks with existing data on them, and the data disks might need to be formatted with FreeBSD GPT-like disklabels and/or ZFS volumes.
sorry David Lehman and Adam Williamson I currently can't provide only small data to my case, cause I'm on vacation up to 17.05.2012. So I can't test since then. It had been best, that the needed reports were asked at the time round 27.04.2012. your mail @Adam Williamson on the test-list was recognized be me a little bit "dry", so I went on to get an working evironment ! for the record: =============== box is an Intel DH55HC with an USB3 PCI-E addon-controller and an 320 backup disk in an IcyBox USB3 case connected to. This case was powered on - during installation - blind blind sixpack13 ! - Disk was 1 partition ext4. Target disk was an Seagate 250 GB disk, GPT layout with 5 partitions on: 1 MB ~ to do the GPT trick ~, 10 GB /(F16), 4GB swap, ~220 GB /home and one ~ 10 GB / (F17) , all ext4. USB2 Stick connected to an USB2 Port. F17(TC2) was dd'ed on it. all disks were in the right panel in installer window, were you are ask which disks are potential target. I was not able to move some disks to left panel, cause buttons were in-active. I marked the Seagate disk as *THE TARGET* [Mr Adam Williamson] I kicked the 5th partition (F17), so /home got all the remaining space. I believe, at this step I went back 1 or 2 steps with the "back button" to look at the old layout/partition sizes, but not so far were you get the 2 panels with "inactive move left/right buttons". so target disk wasn't changed. So I choosed the above 4 partition layout (again), formated as ext4, all went well, but the USB3 backup disk was gone ! (see screenshot, it looks like: the installer copied the USB2 stick twice, once on the target disk AND once on the backup disk !) !!! To me it's important that *NO ONE* else hit my disaster, that's ALL !!! cause > 100.000 files from disks {scratch,sort,rename}ing is a fxxking job ! maybe more next week...,if asked for (again) (but dump handled on mailing list, and bug report filling is a fxxking job too [it seems])
sed '/be/by/g' third sentence
(In reply to comment #9) > all disks were in the right panel in installer window, were you are ask which > disks are potential target. > I was not able to move some disks to left panel, cause buttons were in-active. > > I marked the Seagate disk as *THE TARGET* [Mr Adam Williamson] I think this is the cause of your problem. If you leave the disks on the right hand "target" panel, they could be touched or formatted by the installer. I think you are confusing the "target" panel with the "bootloader" checkbox. When you went ahead, did it pop up with a warning "these partitions will be formatted"? What showed up there? In my case, I left all disks on the left hand "data disk" panel, and only moved one disk to the right hand "target" panel.
NO, NO, NO !!! It was F17 TC2(!) live CD dd'ed to an USB stick. I even was UNABLE to move the disks between the panels, the buttons with arrows right/left WERE IN(!)ACTIVE. ALL connected disks were automatically in the RIGHT panel WITHOUT possibility to change that ! My blindness was that I didn't realized that my backup disks was among them. I'm also not very much confused with $something-checkboxes, etc, I look at them since Redhat 6.2. Even when I had been so superblind to partioned my *USB3 backup disk* AND put grub on it, it had *never* booted an F17 ! Cause it's connected to an ADDON-USB3-Controller which I'm unable to boot from. without driver loaded I even don't see the disk behind/connected to it ...,okay ? And what had been booted than that? my old F16 !!! NO, it booted F17 from the only bootable disk in the box, the internal disk with my partition layout, with my chosen place for boot code, /dev/sda ! And BTW the disk layout of the external USB disk had been *slightly* different than that in the screenshot, if really be superblind. How does it look now ? it had been /dev/sdb1 only ! does it have now: 200 MB /boot 10 GB / 4 GB swap ~220 GB /home No ! would it look like the above after the installer would have finished it's internal magic starting with the layout in my screenshot ? 'don't know !, but difficult to image. IMHO the *real* cause of the problem is, that under some conditions the contents of the install CD or install USB key gets copied more than once to "some"[1] disks in the right panel , maybe caused by me as I went back in the "partioning panel", maybe ...! My screenshot shows that the layout of the damaged USB disk looks equal to the the contents of an install USB Key or live CD , doesn't it ? If so, IMHO the bug lays between the points "partitioning" and "resizing" partitions after copying/dd'ing the install CD contents to the choosen disk, if I get that right. [1] "some", cause my USB stick, I installed FROM, was in the right panel too <exclamation mark> BTW. I'm tired to tell the same stuff again and again. it's up to you to fix that obvious bug. obvious, cause my screenshot and that the install on the internal disks was errorfree tells IMHO enought, to say the installer went horrible wrong in my case. hopefully only in my case ! that this won't happen to more people esp. from 22 may 2012 on *should* be your task P.S. don't put me in "Super-User"-Boots with your checkbox-shit, Okay ? so long close this bug !!!!
Without logs there really isn't anything else we can do.
Charles: you can't move anything to the left on the 'disk filter' screen if you choose 'custom partitioning'. The disk filter screen actually never used to appear if you chose custom partitioning: we only made it pop up, starting in F16, to allow you to pick the bootloader target disk (because you can't do it from the later dialog any more). It intentionally doesn't allow you to 'de-select' any disks, for custom partitioning. But if you don't assign any Fedora partitions to a drive or check the 'format' box at the actual partitioning screen, it still shouldn't be formatted. Unfortunately, crash here happened in the binary-only flash player for which we don't have any source code, so unfortunately we cannot help you with it. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Discussed at 2012-05-11 blocker review meeting: http://meetbot.fedoraproject.org/fedora-bugzappers/2012-05-11/f17-final-blocker-review-meeting-5.2012-05-11-17.04.html . This was rejected as blocker and as NTH; the reports are somewhat unclear and at least one seems to involve very unusual steps (messing around with ZFS volumes), and is apparently not reproducible in Final TC4. Frankly, the available information isn't enough even to be sure there is a bug in here anywhere. QA and anaconda teams both tried to reproduce any undesired formatting of second/third disks in various controlled conditions and were unable to. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
"Unfortunately, crash here happened in the binary-only flash player for which we don't have any source code, so unfortunately we cannot help you with it." text above was obviously a mispaste, please ignore it. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers