On Sat, 2012-09-15 at 09:27 +0300, cornel panceac wrote: > You need to say what layout you had on the disk(s) previously, > and what options you chose during install. It's impossible to > know what happened. > > well the layout was something like this: > > p1 ->10gb -> scientific linux > p2 -> 0.5 gb -> boot > p3 -> 1gb -> swap > > p5 -> 140 gb -> /home -- that's the partition anaconda complained > about and errored out. also that's the partition i care more about :) > > p6 -> 10 gb -> f18 > p7 -> 70 gb -> / -- this is no longer present > > the size are aproximated. the partitions that apparently are still > there, can not be mounted Thanks, but you still didn't say what options you chose during the run of anaconda. > It's possible you simply hit this: > > https://bugzilla.redhat.com/show_bug.cgi?id=855976 > > looks similar but, i've never seen something like choosing what kind > of partitioning to use (custom, free space, replace linux ). it just > crashed and data was no longer there or accessible. Eh? That report doesn't say there are such things. In newUI, right now, there aren't. There were in oldUI. In 18 Alpha, as it stands, all you get 'use entire disk(s)' or 'custom partitioning'. This will change for Beta, but right now that's the story. > > > Remember, this is an *Alpha*. You shouldn't deploy an Alpha of > anything to any system you can't bear to lose. We do warn > about this, regularly. You're also installing the Alpha before > it's even been announced; I'm aiming to ensure this issue and > other major ones in Alpha are explained in the release > announcement when we release it, but we haven't, yet. > > well, i always fail to mention this: one of the reason i report this > kind of things is because i want you to know about their existence. > another reson is that i want to learn why this happened and how can be > avoided. in this case, i also very much want to recover the lost > data :D That's good and certainly the reason we ship pre-releases for testing, yep. But in that case, we do need details in the report :) > That's a horrible idea... > > Bootloader installation selection is something else which > isn't entirely implemented in newUI yet. But we certainly > don't want to go around automatically squelching whatever's in > the MBR of every single disk on the system. That certainly > would be bad behaviour. And 'lethal'. > > i do not really understand why are you sayng that. i mean, since we > already do not know if we are installing grub to the right drive, > what's worst in doing it two times in a row? (or three, etc) Right now Alpha will at least only install an MBR to (one of) the disk(s) you choose explicitly as install targets. If you just meant to install the MBR to each of the disk(s) the user chooses, that's a less terrible idea, but still not really necessary. I mean, ultimately, you just need to offer a selection of bootloader target disk somehow. We did in oldUI, we no doubt will in newUI. > after all, this can be enabled by user's choice, who should know > better if there's is some special boot loader in mbr somewhere ... sure, but you didn't seem to be suggesting to make it optional :) > otoh, this is the smallest of my problems, now :) > > > -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
