Bug#567590: Reproducable
reassign 567590 partman-partitioning 64 fixed 567590 71 tag 567590 pending thanks On Saturday 30 January 2010, Zachary Palmer wrote: > I witnessed the same confusion myself; in retrospect, I should've > mentioned it. I simply assumed that it was a graphical glitch of some > kind. I was unable to set the "bootable flag" as well and had been > setting the BIOS boot area flag (bios_grub) as well. I'm not clear as > to the semantic of that flag, but that's what I have set at the moment > and it seems to be booting my machine correctly. I'd be glad to provide > more information at request, but I'm not terribly familiar with GPT, so > I'm not sure what's relevant. :) OK. I'm not a gpt expert myself, but it does seem logical to me that a BIOS boot area cannot be used for RAID. AFAIK it's supposed to be a (small) separate partition reserved for use for booting the system. Possibly the bios_grub flag should have been implemented as a "use as" option instead of a toggle. This seems to be confirmed as the changelog for version 71 of the relevant component has: * Convert BIOS GRUB boot area support to a method, thereby making it impossible to accidentally put a filesystem on such a partition as well, and making it simpler to preseed. So it looks to be changed already for Squeeze. So for now I'm going to just fix the display issue and assume that the disappearing RAID flag is as it should be. Thanks for the additional info. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567590: Reproducable
Frans,
I witnessed the same confusion myself; in retrospect, I should've
mentioned it. I simply assumed that it was a graphical glitch of some
kind. I was unable to set the "bootable flag" as well and had been
setting the BIOS boot area flag (bios_grub) as well. I'm not clear as
to the semantic of that flag, but that's what I have set at the moment
and it seems to be booting my machine correctly. I'd be glad to provide
more information at request, but I'm not terribly familiar with GPT, so
I'm not sure what's relevant. :)
Thanks,
Zach
On Saturday 30 January 2010, Frans Pop wrote:
│ Bootable flag:off│
│ off │
Note the extra line with 'off' below the 'Bootable flag' line. That
could be caused by bootable flag, but possibly also a different flag.
OK, that was possibly an unrelated issue. The second line was for the 'BIOS
boot area flag' for which the description is not correctly displayed.
I've committed a fix for that.
Toggling Bootable flag does not work (it remains 'off'), but toggling
the line below changes it from 'off' to 'on'.
Toggling the bootable flag still does not have any effect. It should be
supported: VALID_FLAGS in the partman log has: boot, hidden, raid, lvm,
hp-service, msftres, bios_grub.
I can see the flag is getting set correctly, but when libparted reads the
current flags again, it's not there.
Zacharay: is the problem really with the "bootable flag", or rather with
that 'BIOS boot area' (bios_grub) flag?
It looks as if setting bios_grub may remove the raid flag. Could it be that
a 'BIOS boot area' partition simply cannot be a RAID partition? That seems
quite logical...
To test with that display issue corrected, you need to make the following
change in /lib/partman/active-partition/67toggle_biosgrub/choices before
you run partman:
-description=$(stralign -25 "$RET")
+description="$RET"
if [ $biosgrub = yes ]; then
db_metaget partman-partitioning/text/on description
- printf "nobiosgrub\t%s%s\n" "$description" "${RET}"
+ printf "nobiosgrub\t%s\${!TAB}%s\n" "$description" "${RET}"
else
db_metaget partman-partitioning/text/off description
- printf "biosgrub\t%s%s\n" "$description" "${RET}"
+ printf "biosgrub\t%s\${!TAB}%s\n" "$description" "${RET}"
fi
I'll test a bit more myself too.
Cheers,
FJP
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567590: Reproducable
On Saturday 30 January 2010, Frans Pop wrote: > On Saturday 30 January 2010, Frans Pop wrote: > > Toggling Bootable flag does not work (it remains 'off'), but toggling > > the line below changes it from 'off' to 'on'. > > Toggling the bootable flag still does not have any effect. It should be > supported: VALID_FLAGS in the partman log has: boot, hidden, raid, lvm, > hp-service, msftres, bios_grub. > I can see the flag is getting set correctly, but when libparted reads > the current flags again, it's not there. Just to be clear: toggling the bootable flag does not work, but also does not affect the raid flag. The raid flag remains set correctly. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567590: Reproducable
On Saturday 30 January 2010, Frans Pop wrote:
> │ Bootable flag: off │
> │ off │
>
> Note the extra line with 'off' below the 'Bootable flag' line. That
> could be caused by bootable flag, but possibly also a different flag.
OK, that was possibly an unrelated issue. The second line was for the 'BIOS
boot area flag' for which the description is not correctly displayed.
I've committed a fix for that.
> Toggling Bootable flag does not work (it remains 'off'), but toggling
> the line below changes it from 'off' to 'on'.
Toggling the bootable flag still does not have any effect. It should be
supported: VALID_FLAGS in the partman log has: boot, hidden, raid, lvm,
hp-service, msftres, bios_grub.
I can see the flag is getting set correctly, but when libparted reads the
current flags again, it's not there.
Zacharay: is the problem really with the "bootable flag", or rather with
that 'BIOS boot area' (bios_grub) flag?
It looks as if setting bios_grub may remove the raid flag. Could it be that
a 'BIOS boot area' partition simply cannot be a RAID partition? That seems
quite logical...
To test with that display issue corrected, you need to make the following
change in /lib/partman/active-partition/67toggle_biosgrub/choices before
you run partman:
-description=$(stralign -25 "$RET")
+description="$RET"
if [ $biosgrub = yes ]; then
db_metaget partman-partitioning/text/on description
- printf "nobiosgrub\t%s%s\n" "$description" "${RET}"
+ printf "nobiosgrub\t%s\${!TAB}%s\n" "$description" "${RET}"
else
db_metaget partman-partitioning/text/off description
- printf "biosgrub\t%s%s\n" "$description" "${RET}"
+ printf "biosgrub\t%s\${!TAB}%s\n" "$description" "${RET}"
fi
I'll test a bit more myself too.
Cheers,
FJP
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567590: Reproducable
reassign 567590 partman-base 128lenny1 retitle 567590 Strange bootable flag behavior with gpt disk label; RAID fails thanks On Saturday 30 January 2010, Zachary Palmer wrote: > Here's the interesting bit. I sped through the menus and discovered > that the RAID system was quite happy to create a RAID1 for me. I went > back, deleted the RAID, and started over. The second time, I was able > to reproduce the bug. The only difference between these two runs was > that I remembered to flag both drives as bootable the second time. It > seems that a bootable GPT partition is the problem; the RAID menu system > doesn't seem to see it. It looks as if there's something wrong with the bootable flag code for gpt partitions, even without RAID. When I create a new partition I get: │ Partition settings: │ │ │ │ Name:│ │ Use as: Ext3 journaling file system│ │ │ │ Mount point: / │ │ Mount options:defaults │ │ Label:none │ │ Reserved blocks: 5% │ │ Typical usage:standard │ │ Bootable flag:off│ │ off │ Note the extra line with 'off' below the 'Bootable flag' line. That could be caused by bootable flag, but possibly also a different flag. Toggling Bootable flag does not work (it remains 'off'), but toggling the line below changes it from 'off' to 'on'. I think we should look into this first and see if it also fixes the reported issue with RAID. Reassigning to partman-base for now as this is likely a more general issue than just in partman-md. Cheers, FJP -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#567590: Reproducable
I managed to reproduce the problem on my laptop with a KVM instance and two 8G QEMU drive images. I used the i386 Debian 5.03 net installer CD and started an expert install. I put a GPT on each of the two drives and created a single partition on each. I instructed the installer to use each as a physical device for software RAID. Here's the interesting bit. I sped through the menus and discovered that the RAID system was quite happy to create a RAID1 for me. I went back, deleted the RAID, and started over. The second time, I was able to reproduce the bug. The only difference between these two runs was that I remembered to flag both drives as bootable the second time. It seems that a bootable GPT partition is the problem; the RAID menu system doesn't seem to see it. (Again, mdadm works just fine.) Cheers, Zach -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
