Re: gpart on macbook air
On 30.09.2012 23:06, Raoul MEGELAS wrote: When you are deleting a partition, the kernel completely overwrites the partition table and PMBR area. You can compare first 34 blocks before deletion and after to see what is going on. I can understand that, but i would have thought that the deletion of the concerned partition was written preserving others??? something like: - read the gpt table - find the offset - zeroes the partition entry - rewrites the table? is not that logic? if it is not so, i does not understand this behaviour. Hi, Raoul, The kernel has a copy of the partition table in the memory. When you are deleting some partition, it removes the partition entry from the memory, constructs updated GPT header and table, calculates checksums and writes this data into corresponding places. Any way, this should correctly work. My guess is that Apple's boot loader detects some changes and just doesn't want to work. If you think that gpart incorrectly works, please make a copy of first 34 blocks before and after deletion and send them to me. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gpart on macbook air
On Mon, 01 Oct 2012 12:29:02 +0400 From: Andrey V. Elsukov a...@freebsd.org wrote: On 30.09.2012 23:06, Raoul MEGELAS wrote: When you are deleting a partition, the kernel completely overwrites the partition table and PMBR area. You can compare first 34 blocks before deletion and after to see what is going on. I can understand that, but i would have thought that the deletion of the concerned partition was written preserving others??? something like: - read the gpt table - find the offset - zeroes the partition entry - rewrites the table? is not that logic? if it is not so, i does not understand this behaviour. Hi, Raoul, The kernel has a copy of the partition table in the memory. When you are deleting some partition, it removes the partition entry from the memory, constructs updated GPT header and table, calculates checksums and writes this data into corresponding places. Any way, this should correctly work. My guess is that Apple's boot loader detects some changes and just doesn't want to work. If you think that gpart incorrectly works, please make a copy of first 34 blocks before and after deletion and send them to me. Hi Andrey, thanks for your clear explaination; that make sense. in all case i will backup my 18g freebsd partition and and delete it. as soon as possible will send privately the two copy of the first 34 blocks of the disk, before and after deletion. Thanks again. Raoul rm...@free.fr ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gpart on macbook air
on Mon, 01 Oct 2012 12:29:02 +0400 Andrey V. Elsukov a...@freebsd.org wrote: On 30.09.2012 23:06, Raoul MEGELAS wrote: When you are deleting a partition, the kernel completely overwrites the partition table and PMBR area. You can compare first 34 blocks before deletion and after to see what is going on. I can understand that, but i would have thought that the deletion of the concerned partition was written preserving others??? something like: - read the gpt table - find the offset - zeroes the partition entry - rewrites the table? is not that logic? if it is not so, i does not understand this behaviour. Hi, Raoul, The kernel has a copy of the partition table in the memory. When you are deleting some partition, it removes the partition entry from the memory, constructs updated GPT header and table, calculates checksums and writes this data into corresponding places. Any way, this should correctly work. My guess is that Apple's boot loader detects some changes and just doesn't want to work. If you think that gpart incorrectly works, please make a copy of first 34 blocks before and after deletion and send them to me. Hi Andrey, You helped me to find the point: Apple maps the starting point of the first partition in the MBR like this: 01be 00 fe ff ff ee fe ff ff 01 when gpart maps: 01be: 80 00 02 00 ee ff ff ff 01 it is a 251G drive. a solution would be to inspect the gpt table and if an osx-boot is present to leave the starting point unchanged? i tested it on osx 10.8. Please note than geom mark active the partition when osx zeroes the 1be byte. but with this byte set or unset, osx starts (perhaps non checked at all). Regards Raoul rm...@free.fr ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gpart on macbook air
On 30.09.2012 20:37, Raoul MEGELAS wrote: i installed CURRENT on a macbook air (internal ssd as you know): i noticed the following: 1. on freebsd, deleting a partition with gpart: say gpart delete -i 4 ada0 dammage the osx boot. of cours, booting with a backup disk and repairing the disk make it functional again. any light woukd be appreciated on this topic. Hi, When you are deleting a partition, the kernel completely overwrites the partition table and PMBR area. You can compare first 34 blocks before deletion and after to see what is going on. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gpart on macbook air
On Sun, 30 Sep 2012 21:43:50 +0400 Andrey V. Elsukov a...@freebsd.org wrote: On 30.09.2012 20:37, Raoul MEGELAS wrote: i installed CURRENT on a macbook air (internal ssd as you know): i noticed the following: 1. on freebsd, deleting a partition with gpart: say gpart delete -i 4 ada0 dammage the osx boot. of cours, booting with a backup disk and repairing the disk make it functional again. any light woukd be appreciated on this topic. Hi, When you are deleting a partition, the kernel completely overwrites the partition table and PMBR area. You can compare first 34 blocks before deletion and after to see what is going on. -- WBR, Andrey V. Elsukov Hi Andrey, I can understand that, but i would have thought that the deletion of the concerned partition was written preserving others??? something like: - read the gpt table - find the offset - zeroes the partition entry - rewrites the table? is not that logic? if it is not so, i does not understand this behaviour. Thanks. raoul rm...@free.fr ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
