ok, so I had some extra time... 8-)
Common.pm does a swapon -s to get a list of the swap devices and then looks them up in fstab. The problem on my rhel4 system is that swapon -s yields
Filename Type Size Used Priority
/dev/sda3 partition 2048276 0 -1
and Common.pm uses to build a hash, keeping track of each filename, but fstab contains
# This file is edited by fstab-sync - see 'man fstab-sync' for details
LABEL=/ / ext3 defaults 1 1
LABEL=/boot1 /boot ext3 defaults 1 2
none /dev/pts devpts gid=5,mode=620 0 0
none /dev/shm tmpfs defaults 0 0
none /proc proc defaults 0 0
none /sys sysfs defaults 0 0
LABEL=SWAP-sda3 swap swap defaults 0 0
/dev/hda /media/cdrom auto pamconsole,exec,noauto,managed 0 0
/dev/fd0 /media/floppy auto pamconsole,exec,noauto,managed 0 0
and effectively tries to do a join on the filename on column 1, only there isn't an entry in column 1 for /dev/sda3 and therefore it produces the 'uninitialized variable' error. Clearly what needs to be done is find a way to match /dev/sda3 with the fstab entry for 'LABEL=SWAP-sda3' and I just don't know enough to say how to handle this in the most general way. It also turns out that the variable $mounted is getting set to true, but for the wrong reasons so the fact that this works are all seems to be pure luck so while a bug this is not the problem. So, I guess I need to dig deeper to track down my problems...
dig...dig...dig...
I found it!!!
turns out when I did the installation, the default was to use lvm for all the partitions. To make a long story short, the SystemImager kernel I was using didn't support lvm so I simply reinstalled RHEL4 without lvm. Since lvm is the default, I had to manually delete and recreate the partitions. Are you with me so far?
Well guess what, here's what parted shows:
(parted) print Disk geometry for /dev/sda: 0.000-34732.421 megabytes Disk label type: msdos Minor Start End Type Filesystem Flags 2 0.031 101.975 primary ext3 boot 3 101.975 2102.255 primary linux-swap 1 2102.256 34726.442 primary ext3
that what I wanted, boot first, then swap and then root. BUT if you look closer you'll see the 'minor' numbers are out of order. No big deal, right? Wrong! These are the numbers that control the order of things in autoinstallscript.conf. In fact, in this particular case, Common.pm uses sfdisk and not parted to order things and here's what sfdisk shows:
Disk /dev/sda: 4427 cylinders, 255 heads, 63 sectors/track Units = mebibytes of 1048576 bytes, blocks of 1024 bytes, counting from 0
Device Boot Start End MiB #blocks Id System /dev/sda1 2102+ 34726- 32625- 33407167+ 83 Linux /dev/sda2 * 0+ 101- 102- 104391 83 Linux /dev/sda3 101+ 2102- 2001- 2048287+ 82 Linux swap /dev/sda4 0 - 0 0 0 Empty
and here you can see the root has been assigned to sda1, even though it is at the highest sectors on the disk. If Common.pm assigned the right ending sector number to this instead of "*" it would have probably worked, but then it'd also loose a lot of flexibility in being able to install on different siized disks.
My guess is if I were to now go back and carefully recreate the partitions in the right order, the right things would happen, but do people also believe in the Easter Bunny and Santa Clause? Clearly this is a problem and will be a real pain to fix but it's also a problem that's just waiting to bite a lot of people too, especially with rhel4 when they turn off lvm.
sheesh... that was exhausting....
-mark
Mark Seger wrote:
I'm not entirely sure what's going on here my by installation script if blowing up when trying to partition my scsi disk. My source system has a disk that has 3 partitions: 100M boot, 2G swap and the rest data. However, when the autoinstall script tries to create them it's trying to make the first partition 0 thru 34732 and the second one 34732 thru 34888 and blows up because it's saying some other partitioning tool created things incorrectly. That's just not true. In fact, I immediately removed all the partitions while in BusyBox and tried to reimage. Same thing.
In any event, the installation preceeds for a couple of more lines and tries to create a third partition from 34833 to 36834 and blows up because the partition is outside the disk.
As it turns out, when I ran prepareclient I got an error
Use of uninitialized value in hash element at /usr/lib/systemimager/perl/SystemImager/Common.pm line 926, <FH_IN> line 8.
and no idea if this had anything to do with my problems or not. However, when I look at my autoinstallscript.conf file that got created on the golden image, it looks like this:
<disk dev="/dev/sda" label_type="msdos" unit_of_measurement="MB">
<!--
This disk's output was brought to you by the partition tool "sfdisk",
and by the numbers 4 and 5 and the letter Q.
-->
<part num="1" size="*" p_type="primary" p_name="-" flags="-" />
<part num="2" size="101" p_type="primary" p_name="-" flags="boot" />
<part num="3" size="2001" p_type="primary" p_name="-" flags="-" />
</disk>
which is clearly wrong because partition one can't have a size of "*". So I reordered things, making the first entry last, fixed up the now incorrect references in the fstab section and I'm imaging away. However, the question is what's broken.
is there any more data I can provide to help get to the bottom of this short of me diving into the Common.pm code?
-mark
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ Sisuite-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sisuite-users
