It works with ext3. With the same profile, grub installation hangs when root is an xfs file system, but dosn't when it's ext3. The lsmod command shows that the autoinst kernel has the xfs modules loaded. Thanks, Gary Hans-Joachim Ehlers wrote:

Just a thought, is the xfs driver loaded during network installation ? Saying so i would make a test with ext3 fs.

hth Hajo

...

...

...

Gary Lowell 16/10/2008 02:20 >>>

Hi -

I'm looking for some pointers on how to figure out why grub is hanging during autoyast install.

The profile was created on the target system after installing from the OpenSuSE 11 DVD. Pretty much all options and package selections were the default. I did update to autoyast2-2.16.19-0.1 to generate the profile, as the installed version appeared to go into an infinite loop trying to resolve package dependencies.

After wiping the disk, and starting a network install with that profile, it hangs installing the grub rpm post install scriptlet. If I kill that process and run the grub script by hand it succeeds, and the autoyast apparently proceeds normally. I've tried several variations of this all with the same result.

The command in the script that hangs is: /usr/sbin/grub --batch < /etc/grub.conf >/dev/null 2>&1 and grub.conf is: setup --stage2=/boot/grub/stage2 (hd0) (hd0,1) quit

The only thing at all unusual about the system is that boot/root disk is a hardware raid array managed by an LSISAS1068E chip on the motherboard. There is only one target, and that is correctly labeled as /dev/sda. /dev/sda1 is swap, and /dev/sda2 is root (with XFS filesystem). But this all works normally with a DVD install.

Any pointers on how to track this down would be greatly appreciated.

Thanks, Gary

-- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org

Looks like grub gets in trouble installing the stage 1.5 boot loader. Our profile works ok on OpenSuse 10.x, but hangs on OpenSuse 11. As a work around, we're using an ext3 boot partition. Now I need to figure out why the chroot scripts won't run. It looks like autoyast is plugging in "nil" where "-x" should go when the debug option is set. This is happening regardless of the state of the debug option. Cheers, Gary Hans-Joachim Ehlers wrote:

In that case i would test the following: Supply the xfs driver on the kernel command line for the network boot kernel or supply it via a info file. Also check that the xfs driver is within the initrd . Not that in your case the XFS driver gets loaded during the autoyast installation which i assume as to be to late.

hth Hajo

...

...

...

Gary Lowell 16/10/2008 23:26 >>>

It works with ext3. With the same profile, grub installation hangs when root is an xfs file system, but dosn't when it's ext3. The lsmod command shows that the autoinst kernel has the xfs modules loaded.

Thanks, Gary

Hans-Joachim Ehlers wrote:

...

Just a thought, is the xfs driver loaded during network installation ? Saying so i would make a test with ext3 fs.

hth Hajo

...

...

...

Gary Lowell 16/10/2008 02:20 >>>

Hi -

I'm looking for some pointers on how to figure out why grub is hanging during autoyast install.

The profile was created on the target system after installing from the OpenSuSE 11 DVD. Pretty much all options and package selections were the default. I did update to autoyast2-2.16.19-0.1 to generate the profile, as the installed version appeared to go into an infinite loop trying to resolve package dependencies.

After wiping the disk, and starting a network install with that profile, it hangs installing the grub rpm post install scriptlet. If I kill that process and run the grub script by hand it succeeds, and the autoyast apparently proceeds normally. I've tried several variations of this all with the same result.

The command in the script that hangs is: /usr/sbin/grub --batch < /etc/grub.conf >/dev/null 2>&1 and grub.conf is: setup --stage2=/boot/grub/stage2 (hd0) (hd0,1) quit

The only thing at all unusual about the system is that boot/root disk is a hardware raid array managed by an LSISAS1068E chip on the motherboard. There is only one target, and that is correctly labeled as /dev/sda. /dev/sda1 is swap, and /dev/sda2 is root (with XFS filesystem). But this all works normally with a DVD install.

Any pointers on how to track this down would be greatly appreciated.

Thanks, Gary

-- To unsubscribe, e-mail: opensuse-autoinstall+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-autoinstall+help@opensuse.org