Re: [D-I] Question about setting up palo/ext2 boot partition
On Saturday 21 April 2007, Helge Deller wrote:
> On Tuesday 17 April 2007, Frans Pop wrote:
> > (No need to CC me, I'm subscribed.)
> >
> > On Tuesday 17 April 2007 16:43, Thibaut VARENE wrote:
> > > Hmm, I have no problem running palo with -U on a mounted partition:
> >
> > Very, very strange because the README for palo says:
> > The update (-U) feature is currently disabled, perhaps permanently.
> > The usual method for maintaining your disk is to edit /etc/palo.conf
> > and rerun palo.
> >
> > And it also seems disabled in the source (palo/palo.c):
> > <snip>
> > else /* update */
> > {
> > unsigned end = f0start + f0length;
> >
> > fprintf(stderr, "palo -U doesn't work yet\n"); exit(2);
> > #if 0
> > <code that should implement -U>
> > #endif
> > </snip>
>
> Hi Frans,
>
> yes, it's not available and this has bothered me as well already.
> If I understand you correctly, you already have fixed the debian-installer to reserve bad-blocks when the palo-partition was formatted.
> All what is missing now, is that "palo -U" installs the bootloader into those reserved blocks, correct ?
>
> Technically IMHO it shouldn't be such a big problem.
> One problem I see though is, that palo should check if the badblocks really were marked as such before just writing in the bootloader... ?
> Maybe that's the reason it's currently disabled ?
I think it works for Thibaut, because he used palo to format his ext3 partition.
In addition palo modified the first harddisk sector and stored the location to where the IPL bootloader is located.
This is missing with your modifications to the debian-partitioner/formatter and is why palo.c can't update.
What you would need is, that palo scans the output of "dumpe2fs":
b160:/mnt# dumpe2fs -h /dev/sda1
dumpe2fs 1.40-WIP (14-Nov-2006)
Filesystem volume name: <none>
Last mounted on: <not available>
Filesystem UUID: 9565ddc5-9366-4a7c-805b-09c8157498c3
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: resize_inode dir_index filetype sparse_super
Filesystem flags: signed directory hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 4160
Block count: 16385
Reserved block count: 829
Free blocks: 15457
Free inodes: 4149
First block: 1
Block size: 1024
Fragment size: 1024
Reserved GDT blocks: 64
Blocks per group: 8192
Fragments per group: 8192
Inodes per group: 2080
Inode blocks per group: 260
Filesystem created: Sat Apr 21 14:45:12 2007
Last mount time: n/a
Last write time: Sat Apr 21 14:45:12 2007
Mount count: 0
Maximum mount count: 27
Last checked: Sat Apr 21 14:45:12 2007
Check interval: 15552000 (6 months)
Next check after: Thu Oct 18 14:45:12 2007
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 128
Default directory hash: tea
Directory Hash Seed: 782c7f45-351e-43d8-ad9d-ac5b3595ac5f
Bad blocks: 225, 226, 227, 228, 229, 230, 231, 232, 233, 234, 235, 236, 237, 238, 239, 240, 241, 242, 243, 244, 245, 246, 247, 248, 249, 250, 251, 252, 253, 254, 255, 256, 257, 258, 259, 260, 261, 262, 263, 264, 265, 266, 267, 268, 269, 270, 271, 272, 273, 274, 275, 276, 277, 278, 279, 280, 281, 282, 283, 284, 285, 286, 287, 288, 289, 290, 291, 292, 293, 294, 295, 296, 297, 298, 299, 300, 301, 302, 303, 304, 305, 306, 307, 308, 309, 310, 311, 312, 313, 314, 315, 316, 317, 318, 319, 320, 321, 322, 323, 324, 325, 326, 327, 328, 329, 330, 331, 332, 333, 334, 335, 336, 337, 338, 339, 340, 341, 342, 343, 344, 345, 346, 347, 348, 349, 350, 351, 352, 353, 354, 355, 356, 357, 358, 359, 360, 361, 362, 363, 364, 365, 366, 367, 368, 369, 370, 371, 372, 373, 374, 375, 376, 377, 378, 379, 380, 381, 382, 383, 384, 385, 386, 387, 388, 389, 390, 391, 392, 393, 394, 395, 396, 397, 398, 399, 400, 401, 402, 403, 404, 405, 406, 407, 408, 409, 410, 411, 412, 413, 414, 415, 416, 417, 418, 419, 420, 421, 422, 423, 424, 425, 426, 427, 428, 429, 430, 431, 432, 433, 434, 435, 436, 437, 438, 439, 440, 441, 442, 443, 444, 445, 446, 447, 448, 449, 450, 451, 452, 453, 454, 455, 456, 457, 458, 459, 460, 461, 462, 463, 464, 465, 466, 467, 468, 469, 470, 471, 472, 473, 474, 475, 476, 477, 478, 479, 480
analyzes the "Block size" (1024 or higher) value and checks if the bad blocks are constantly growing and provides a minimum of EXT2_HOLE bytes.
Then palo would need to convert the numbers and update the f.ipl_addr and f.version and f.flags values (search for "Updating formatted" in palo.c) acordingly.
Does this sound right ?
Helge
Reply to: