While using fdisk, even that one broken from anaconda, an "unused" partition 'c' which covers the whole disk is created. Quite rightly so if the disk in question can be seen also by another OS like Tru64. At the very end of an installation process an error mesage from "bootconfig:" flashes on screen. It is hard to catch up because a machine is immediately rebooting and the error is not, unfortunately, recorded in any log files. As far as I can tell it is complaining that a bootblock will overlap with some partitions (the said 'c') and fails to write one on a disk with a fresh installation. It looks to me that '-f3' flag to 'swriteboot' was forgotten. In case when 'c' does not include an initial disk sector no harm will be done. But although booting from such disk is not a very big deal to me it can be quite frustrating to a newbie. Additional idea. It would be quite nice to have in /etc/aboot.conf on a distribution CD extra entries of this kind: 2:kernels/vmlinux.gz root=/dev/hda1 ro Say four for hda partitions for sda. There is a pretty good chance that a newbie with a missing bootblock could use one of these for the first boot. In case none would fit s/he would have at least some sample boot lines to be displayed by 'l' in aboot. Michal michal
Switch arch to alpha - this doesn't sound like a problem on the i386.
Yes, this is bug on Alpha. It is quite possible that I forgot to switch an architecture from a default; or this is an example of bugzilla getting confused. I know why I immediately filed up a bug report against bugzilla when it was introduced. Unfortunately it was totally ignored.
hi Michal, does your "whole disk" partition start @ cylinder 1 and end at the last cylinder ...? If so, perhaps creating the partition starting from cylinder 2 and going to the last cylinder may workaround this ...? Our partition tables do not use cylinder 1 (as boot info is stored there). such as the sample partition table below: [root@Alpha3 /root]# fdisk -l /dev/hda Disk /dev/hda: 16 heads, 63 sectors, 39770 cylinders Units = cylinders of 1008 * 512 bytes 8 partitions: # start end size fstype [fsize bsize cpg] a: 2 1042 1041 ext2 b: 1043 1563 521 swap c: 1564 2604 1041 ext2 d: 2605 10927 8323 ext2 e: 10928 19250 8323 ext2 f: 19251 27573 8323 ext2 g: 27574 35896 8323 ext2 h: 35897 39770 3874 ext2 [root@Alpha3 /root]#
my suggestion above probably is wrong: :( (from the SRM Howto see http://www.alphalinux.org/faq/srm.html) --------------------------------- Sharing a Disk With DEC Unix Unfortunately, DEC Unix doesn't know anything about Linux, so sharing a single disk between the two OSes is not entirely trivial. However, it is not a difficult task if you heed the tips in this section. The section assumes you are using aboot version 0.5 or newer. Partitioning the disk First and foremost: never use any of the Linux partitioning programs (minlabel or fdisk) on a disk that is also used by DEC Unix. The Linux minlabel program uses the same partition table format as DEC Unix disklabel, but there are some incompatibilities in the data that minlabel fills in, so DEC Unix will simply refuse to accept a partition table generated by minlabel. To setup a Linux ext2 partition under DEC Unix, you'll have to change the disktab entry for your disk.
Yes, my suggestion above is wrong ... (apologies, Michal!) (from the SRM Howto see http://www.alphalinux.org/faq/srm.html) "DEC Unix insists that partition a starts at offset 0 and that partition c spans the entire disk."
I will mark this as an enhancement request (probably will be deferred until the next release), and change the Summary info ... Here is an excerpt from an email from Michal that summarizes the issue well (thanks!): Date: Thu, 19 Oct 2000 09:22:32 -0600 From: michal To: borgan Subject: Re: [Bug 19019] Changed - errors in an installation of a boot block ... <snip> ... BSD partitioning explicitely allows for overlapping partitions, and fdisk follows that specification, although this is not a good idea for partitions on which you are storing your data. :-) This is _different_ than with partition tables of "FAT type" as used on x86. 'fdisk' actually does that right and maybe a bug report against DiskDruid should be filed if this is one is messing things up? "Tru64 compatible partitioning" should be at least an option. With a "compatible" partition table present an installer indeed screws up and fails to write a boot block while on obstacle is really present. Still 'swritedisk' is on a cautious side and wants a confirmation that you do know what you are doing. ... <snip>