[cAos-devel] Cinch partition_scan (was Re: System Imager)

[Martyn]

Greg Kurtzer wrote:

>Dang, I wrote that code eons ago!
>  
>
I know that feeling!

>I think what happened was that I was originally also grabbing the  
>partition type which you can't get from /proc/partitions. Then I  
>removed that logic for something else and didn't rewrite the function  
>to use /proc/partitions.
>  
>
That's not really what it looks like, here's what I think it's doing :

scan_partitions seems to read /proc/partitions, then to check that the 
partition is really accessible you run fdisk on the *partition* and if 
it outputs an error, assume it's a valid partition.  Unfortunately, 
there appear to be a few situations (partition used to be an extended, 
is now a primary is common) where fdisk will output a partition table 
/from inside/ a partition.

  I know I had a hard time getting this info through to Michael on irc 
(too many opportunities for misunderstanding), so I'll repeat and 
rephrase : scan_partitions looks at /proc/partitions and sees for 
example hda1-4, so you run fdisk /dev/hda1 and check for error to see if 
it's a valid partition; rinse and repeat.  If for example hda4 used to 
be an extended partition, there's no error output, so cinch ignores it.  
That seems to be the same for some XP NTFS partitions too as fdisk 
somehow interprets some data at the start of the partition (I'd assume a 
backup of the partition table within the fs, but not certain).

As I say, the workround is to obliterate the start of all the valid 
partitions, then cinch will get an error from them, but I don't think 
that's a "solution" by any means.

Hopefully I've explained well enough, but ask for more clarification and 
I'll try and explain differently.  If you think there's a possibility of 
the kernel not catching up with the partitions or something, I'd suggest 
using dd to verify we can read from the partition instead of fdisk (If 
that's why it's doing it!).

>So if I am understanding correctly you are saying that /proc/ 
>partitions is more accurate then fdisk output? I am pretty sure that  
>fdisk reads /proc/partitions, but maybe in changing how it is  
>represented something gets messed up....?
>
>Greg
>
>On Feb 27, 2007, at 3:46 AM, Martyn wrote:
>
>  
>
>>Michael Jennings wrote:
>>    
>>
>>>I have ISO's which have done successful installs under qemu, but I'm
>>>holding off on calling them "2.3" until I can put the 2.6.20.x kernel
>>>on there.
>>>
>>>      
>>>
>>And let's try and get some clarification on why greg doesn't trust
>>/proc/partitions.
>>
>>Greg: in scan_partitions of cinch, you're using fdisk to clarify if a
>>partition is real by looking for "no valid".... unfortunately if there
>>has been an extended partition at the block where the partition  
>>starts,
>>there is a valid partition table.   Also on some winXP installs, there
>>seems to be a backup of the partition table in the first block of the
>>NTFS partition, so to install on these, I have had to dd if=/dev/zero
>>of=/dev/hda1....
>>
>>That's not really a sensible way to get cinch to see the partitions to
>>install to.  Also, my preference is not to create extended partitions
>>unless they're needed, so for the base 4-partition scheme for  
>>cAos-2, I
>>would prefer to see hda1-4 not hda1-3 and 5!
>>    
>>
>>>I guess I could post them as pre-release ISO's if folks want to test
>>>them, though...
>>>
>>>      
>>>
>>Well, I'm not so desperate, but maybe others are :-)
>>    
>>
>>>Michael
>>>
>>>      
>>>
>>--
>>Martyn (Joran)
>>
>>
>>_______________________________________________
>>cAos-devel mailing list
>>cAos-devel at caoslinux.org
>>http://lists.caosity.org/mailman/listinfo/caos-devel
>>    
>>
>
>--
>Greg Kurtzer
>
>    I believe the world would be a better place if people didn't  
>believe in their beliefs. -- gmk
>
>
>_______________________________________________
>cAos-devel mailing list
>cAos-devel at caoslinux.org
>http://lists.caosity.org/mailman/listinfo/caos-devel
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.caosity.org/pipermail/caos-devel/attachments/20070228/b4956c2d/attachment.html