Hi, I had a problem with the GLI that i guess is a bug. The destination partition was inside an extended partition and the other ones also present inside the ext where screwed up by the install, altough i've not touched them in the partitioning of the GLI. You can see in the installer.log that it actually deleted the whole extended partition. The installer is a bit modified to suit my needs of it to put in on my pentoo livecd (http://www.pentoo.ch) but i did not touch the partitioning part. Attached are the config files and the install log.
Created attachment 79357 [details] clientconfiguration.xml
Created attachment 79358 [details] installer.log
Created attachment 79359 [details] installprofile.xml
Yes, it's supposed to delete the extended partition (along with every other partition). That's how it works. What are you complaining about? It looks to me like your install was successful. Please attempt to actually understand what's happening before filing a bug, especially when there isn't even a problem/error. Also, we don't support any modifications made to the installer by someone not on the installer team. If the installer breaks in any way after being modified and can't be reproduced with the "vanilla" installer, we don't care. Also, we will not support anyone using the installer from your CD, modified or not. We only support the installer running on official Gentoo release media.
Since in the installprofile.xml it's stated : <partition format="False" ... for the partitions also in the extended one i thought it would not touch nor delete them. I just started python less than a week ago so i don't have the skill to understand all your code. NP, i'll warn user to not complain about breakage and that's all. Thanks anyway.
(In reply to comment #4) > Yes, it's supposed to delete the extended partition (along with every other > partition). That's how it works. What are you complaining about? It looks to me > like your install was successful. Please attempt to actually understand what's > happening before filing a bug, especially when there isn't even a > problem/error. Erm? Could you please clarify this? Disregarding modified/unmodified/supported/unsupported stuff here, you are actually confirming that the *default* (and perhaps only) way that GLI uses to install Gentoo is to wipe someone's drive clean and that it's not an error but rather by design??? If this is indeed what you are suggesting, I say such design is completely insane and inacceptable.
He never said that it wipes a drive clean, you assumed that. He said that it recreates the partition. It is safe to remove and recreate the partition so long as it has the same starting and ending sector. Please try to understand what is going on before reopening other people's bugs.
Yes, the installer removes all of the partitions, and recreates them in disk order. This is the only way to preserve disk order for the partition numbers. The data itself is never touched. Jakub, if this is so insane and unacceptable, don't use the installer. This method has been tested over and over again, and works quite well. Michael, you said that the logical partitions were screwed up by the install. Do you mean that they can't be accessed properly anymore, or did you just freak out when you saw the extended partition was being removed? The installer remembers the start/end sector of each partition that is supposed to be preserved and recreates it in the same place. There shouldn't ever be any data corruption.
The partitions are corrupt and unreadable.
I recommend booting from an official installer livecd, removing all the partitions with parted, and using parted's 'rescue' command to recreate the partitions in the "proper" spots. Then run the official installer in verbose mode and try to reproduce it. If you can reproduce it there, then it's a bug I need to fix. The only reason I'm skeptical is that we haven't had anyone else complain about the installer corrupting their exist partitions, other than because of other failures where the installer died in the middle of recreating all the partitions.
(In reply to comment #7) > He never said that it wipes a drive clean, you assumed that. He said that it > recreates the partition. It is safe to remove and recreate the partition so > long as it has the same starting and ending sector. Please try to understand > what is going on before reopening other people's bugs. Uhm, he didn't say anything about re-creating the partitions, that's why I asked for clarification. Also, this bug report somewhat suggests that it's really not so safe (and I still fail to see why is this *necessary* first of all). And BTW - there's a thread on a Czech linux forum, where a user complains that using (unmodified in this case) GLI resulted in total loss of extended/logical partitions when GLI failed for some reason (http://www.root.cz/diskuse/797/ - Czech only, sorry, I can translate it for you if you are interested) So again - why is it needed to wipe and then recreate all the partitions?
I'm gonna try to reproduce it. Thanks for your time
(In reply to comment #11) > And BTW - there's a thread on a Czech linux forum, where a user complains that > using (unmodified in this case) GLI resulted in total loss of extended/logical > partitions when GLI failed for some reason (http://www.root.cz/diskuse/797/ - > Czech only, sorry, I can translate it for you if you are interested) Please translate it. My Czech is a bit rusty :P
(In reply to comment #13) > Please translate it. My Czech is a bit rusty :P OK, so... The user had Ubuntu already installed on a primary partition. He decided to install Gentoo to logical partition (/dev/hda8). He also had another logical partition with data (/dev/hda6). He used GLI to install Gentoo to a logical partition (/dev/hda8) - (allegedly) some issues occured when selecting packages for GRP install. He decided to ignore that part because he didn't need them immediately, so he can install them later on, when Gentoo install itself is finished. The installer failed while formatting the install partition. After rebooting, grub couldn't boot Gentoo and the extended partition (and of course all the logical ones) were gone. This is the resulting disk layout: Disk /dev/hda: 60.0 GB, 60060155904 bytes 255 heads, 63 sectors/track, 7301 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes # fdisk -l /dev/hda Device Boot Start End Blocks Id System /dev/hda1 1 547 4393746 83 Linux /dev/hda2 * 548 1094 4393777+ 83 Linux He managed to rescue all logical partitions later on with testdisk (which unfortunately damaged his primary partition with Ubuntu install), additionally only SUSE 10.0 is able to read the data from those partitions. Install logs are unfortunately not available due to the above issues. So - that's all I was able to work out from the thread. I can ask him for additional info on that thread, but I'm really not sure if he'll be willing to try GLI again (and he's also busy with data rescue ATM :P).
That is a completely different issue. That person's issue was likely caused by one of the few partitioning bugs that were present in version 0.1 (and one in 0.2) of the installer that caused the installer to die while recreating the partition table, which causes not all partitions to be recreated. All of the known bugs like this have been fixed. Most were NTFS and FAT32 related (I have neither type of partition/filesystem), so that code got very little testing. Michael's issue is completely different. The installer acted like it created everything properly and the install was successful (apparently). The end result was corrupted data. BTW, when was that post made to that Czech forum? I can't see anything resembling a date :P
(In reply to comment #15) > BTW, when was that post made to that Czech forum? I can't see anything > resembling a date :P 8. 2. 18:17, so that's yesterday...
Ok, i've reproduced the issue and i'm attaching several files with diff between before and after the installation. The installation failed but the partition table is totally screwed up so in a sense it is a success. I've also reproduced the issue pointed out by Jakub by running the installer present by default with the livecd so it don't count. After rebooting, reseting all partitions with fdisk, updating the installer to latest snapshot available, i can reproduce my issue. I used disktype that i compiled from an other machine to see all partition before and after and created a diff. Also fdisk is showing weird things. I started the gtkfe with --debug but that seems pointless. Maybe it's a parted bug.
Created attachment 79389 [details] clientconfiguration.xml With official livecd and ran updategtkfe
Created attachment 79390 [details] installer.log.failed With official livecd and ran updategtkfe
Created attachment 79391 [details] installprofile.xml With official livecd and ran updategtkfe
Created attachment 79392 [details] Disktype before install
Created attachment 79393 [details] Disktype after install
Created attachment 79394 [details] disktype.diff
Created attachment 79395 [details] Fdisk -l before
Created attachment 79396 [details] Fdisk -l after
Created attachment 79397 [details] fdisk.diff
This is definitely something that libparted is doing. libparted tends to "massage" the start/end sector values that you give to it. While I'm giving it the values I've saved, it's throwing a little extra onto the end for some reason. I'll take a look at the code and try to figure out a way to prevent this.
I know what's causing that partitioning problem, but not *why*. the size in MB of those partitions are being calculated differently between when gtkfe is first started and when the install starts. if tmppart_old['mb'] == tmppart_new['mb']: that's my check to see if the partition is being resized. in your case, a partition is being seen as 94MB the first time and 95MB the 2nd time, so the partitioning code thinks that it's being resized and doesn't preserve the old end point, so the beginning of each partition after it is being offset because a new endpoint is being calculated from the size in MB. I've added a new flag to the partitioning information called 'resized'. If a partition is resized in the partition editor, that flag is set. When the partitioning code is running during the install, it checks that flag instead of the detected size of the partition. If that flag is not set, it preserves both the start and end points of the partition. If you would, rescue your partition table again, and give the latest cvs a try (run /opt/installer/misc/updategtkfe). Grab that disktype information again before and after the install for comparison purposes. If my theory is right, this should "fix" the problem.
(In reply to comment #28) > If you would, rescue your partition table again, and give the latest cvs a try > (run /opt/installer/misc/updategtkfe). Grab that disktype information again > before and after the install for comparison purposes. If my theory is right, > this should "fix" the problem. I'm away from home until sunday evening. I'll test it asap when back. Just a question, i can see there are two lines commented (1213,1214) that compares the starting and ending sectors. Why is it commented out? IMHO it will be totally error-proof if comparing between sectors than actually comparing between MB.
I was completely wrong about the cause of this problem. It turns out that while I was recording the ending sector for partitions that weren't being touched, I wasn't using what I recorded when I recreated it. The end sector was being calculated from the recorded start sector and the size of the partition in MB. The latest CVS snapshot should actually fix this problem. Please test and let me know what happens.
I still have the same problem with the latest snapshot on an installer CD using the vanilla installer. Version is 20060211. Attached are the diffs with fdisk and disktype.
Created attachment 79603 [details] disktype.diff
Created attachment 79604 [details] fdisk.diff
What is this disktype program you're using?
Okay, please try the latest snapshot. I added a bunch of debugging code to the partitioning code. It will now long the recorded start/end sectors and which start/end sectors it is using when it recreates the partitions. This will tell me if it's my code or something that libparted/pyparted is doing.
Oh, I will need your installer.log from after the installer run.
I'm using disktype-8. I'll test that again but i'll provide a fake stage3 to the installer so it will stop just after partitionning occur, cause i don't mind to go through the whole install again on my old pentium3 800 inside a virtual machine... Do i need to pass the --debug to it or it will throw debug info in the log file anyway?
Meh, the --debug option is deprecated. Debug mode is now activated in the installer by choose the Verbose option on the Misc. tab of the Pre-install config screen. Anyway, this output should show in the log regardless of that setting. BTW, I want to thank you for your help in tracking down this problem.
(In reply to comment #38) > BTW, I want to thank you for your help in tracking down this problem. > NP, i also need it to work so it's in my interest of helping you to fix it, regardless of what have been said at the beginning.
Created attachment 79612 [details] installer.log.failed There's an error in the x86ArchitectureTemplate.py file. I couldn't find how to fix it...
Okay, I think I've finally got it. I just ran a test install myself and the partitions that I didn't want touched were recreated in the exact same start and end sectors. I created a disk layout similar to what you have. Give it one more try to see if it works for you as well.
Created attachment 79618 [details] installer.log.failed Sorry but it still fails to go further, error in x86ArchitectureTemplate.py, line 216. It has not deleted any partitions though, and they are all still readable. I've selected the partition 7 for the install.
I can't say that I have ever seen a failure there. I put in some error checking code there, so that it won't die if that happens. Give it another try.
Ok, it worked nice this time and all my partitions are still available. I'll attach anyway the installer.log file as there are some message stating : Retrieved start sector is not the same as the calculated next start sector Thanks for your quick fixes. If the logs looks ok to you you can close the bug. Thanks again, Michael
Created attachment 79630 [details] installer.log.failed The fails come from my empty stage3 tarball file so it's ok.
Good! That message about the start sector not being the same can be ignored. That's the way the partitions were on the disk previously. This bug was not present in 0.2. It came about due to a code cleanup I did in GLIStorageDevice.py. I'm glad this came up *before* the 0.3 release instead of after. Thanks again.
Moving to Release Media/Installer.
