steel bank common lisp hung during install F17

clariceoshea · #1 31st May 2012, 01:50 AM

preupgrade F16->F17

during final install

hung on steel bank common lisp install

I returned to F16 and using yumex I deleted

steel bank common lisp

and restarted installation to hang on

steel bank common lisp install

again

yumex posted prob 400-500 messages
that zoomed by.

kept restarting and the install finally finished

problem is the kernel is still F16

yum update did nothing...guess its back to installing F17 from DVD

However:

[root@lmkiii etc]# cat system-release
Fedora release 17 (Beefy Miracle)
[root@lmkiii etc]#
[root@lmkiii etc]# uname -r
3.3.7-1.fc16.i686.PAE

RupertPupkin · #2 31st May 2012, 03:47 AM

I ran into the same problem upgrading F16 to F17 from the DVD. Sbcl and nfs-utils were two of the packages that caused problems when I tried a "yum update" after the upgrade. I had to remove sbcl then add it back later so yum wouldn't hang.

clariceoshea · #3 31st May 2012, 04:44 AM

thanks! wonder how I got FC16 on the kernel but FC17 on the /etc release....

sbcl has a gaggle of dependencies

HMMM tried to install sbcl:

[root@lmkiii etc]# yum install sbcl
Loaded plugins: langpacks, presto, refresh-packagekit
Resolving Dependencies
--> Running transaction check
---> Package sbcl.i686 0:1.0.51-1.fc16 will be installed
--> Finished Dependency Resolution

Dependencies Resolved

================================================== ================================================== ==============================
Package Arch Version Repository Size
================================================== ================================================== ==============================
Installing:
sbcl i686 1.0.51-1.fc16 fedora 14 M

Transaction Summary
================================================== ================================================== ==============================
Install 1 Package

Total download size: 14 M
Installed size: 14 M
Is this ok [y/N]: y
Downloading Packages:
sbcl-1.0.51-1.fc16.i686.rpm | 14 MB 00:12
Running Transaction Check
Running Transaction Test
Transaction Test Succeeded
Running Transaction
Installing : sbcl-1.0.51-1.fc16.i686 1/1
Verifying : sbcl-1.0.51-1.fc16.i686 1/1

Installed:
sbcl.i686 0:1.0.51-1.fc16

Complete!

rpm -qa|grep -i fc17 outputs many many entries as does fc16

Zotter · #4 31st May 2012, 05:45 AM

Quote:

Originally Posted by clariceoshea

preupgrade F16->F17

during final install

hung on steel bank common lisp install

Had the exact same problem on an HP laptop - nw8440. My "fix": Ctrl+Alt+Fx (forget which, one that gave me a command line), executed shutdown -r now, then reselected the upgrade from the Grub menu. This time, it went right through with no issue and is currently running fine.

matth45 · #5 31st May 2012, 08:06 PM

I ran into the same problem. It seems rebooting and continuing the installation solves it, with one caveat. You will have a bunch of packages that were not cleaned up, namely the ones that were updated before sbcl.

To fix this, run

Code:

package-cleanup --cleandupes

as root.

One other (unrelaed) caveat:

If you are running kernel-3.3.7-1.fc16.x86_64, the preupgrade script will not change your boot options to kernel-3.3.7-1.fc17.x86_64. You have to manually edit /etc/grub*.conf (grub or grub2) so that the system boots the f17 version of the kernel.

Until you do this, you will have stability issues.

---------- Post added at 03:06 PM ---------- Previous post was at 02:52 PM ----------

Also note, there is an ongoing bugzilla report regarding this issue. If you ran into this, you could make some noise over there.

https://bugzilla.redhat.com/show_bug.cgi?id=822008

clariceoshea · #6 1st June 2012, 04:38 AM

Thanks...I'll try that

right now I have an F16 kernel

and a F17 machine

[root@lmkiii etc]# cat system-release
Fedora release 17 (Beefy Miracle)
[root@lmkiii etc]#
[root@lmkiii etc]# uname -r
3.3.7-1.fc16.i686.PAE
____________________________
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Fedora (3.3.7-1.fc16.i686.PAE)' --class fedora --class gnu-linux --class gnu --class os {
savedefault
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd0,gpt2)'
search --no-floppy --fs-uuid --set=root b408347c-264f-4a0a-b1f4-091f05c8699c
echo 'Loading Fedora (3.3.7-1.fc16.i686.PAE)'
linux /vmlinuz-3.3.7-1.fc16.i686.PAE root=/dev/mapper/vg_lmkiii-lv_root ro quiet rhgb SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
echo 'Loading initial ramdisk ...'
initrd /initramfs-3.3.7-1.fc16.i686.PAE.img
}
menuentry 'Fedora (3.3.6-3.fc16.i686.PAE)' --class fedora --class gnu-linux --class gnu --class os {
savedefault
load_video
set gfxpayload=keep
insmod gzio
_____________________________________

I am 64 bit so what do I put in grub

concerning the PAE and x86_64

kernel-3.3.7-1.fc17.x86_64

'Fedora (3.3.7-1.fc16.i686.PAE)'

somewhere is a list of proper kernel names

maybe "PAE" disappeared with F17!!!

---------- Post added at 06:57 PM ---------- Previous post was at 01:33 PM ----------

tried this grub2.cfg and got "file not found"

so I must have used the wrong kernel name

there are many "experts who have advised to edit this file"

maybe I need to run grub2-install

I am out of my league

#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by grub2-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#

### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
load_env
fi
set default="0"
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi

function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}

function load_video {
insmod vbe
insmod vga
insmod video_bochs
insmod video_cirrus
}

set timeout=5
### END /etc/grub.d/00_header ###

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Fedora (3.3.7-1.fc17.x86_64)' --class fedora --class gnu-linux --class gnu --class os {
savedefault
load_video
set gfxpayload=keep
insmod gzio
insmod part_gpt
insmod ext2
set root='(hd0,gpt2)'
search --no-floppy --fs-uuid --set=root b408347c-264f-4a0a-b1f4-091f05c8699c
echo 'Loading Fedora (3.3.7-1.fc17.x86_64)'
linux /vmlinuz-3.3.7-1.fc17.x86_64 root=/dev/mapper/vg_lmkiii-lv_root ro quiet rhgb SYSFONT=latarcyrheb-sun16 LANG=en_US.UTF-8 KEYTABLE=us
echo 'Loading initial ramdisk ...'
initrd /initramfs-3.3.7-1.fc16.i686.PAE.img
}
menuentry 'Fedora (3.3.6-3.fc16.i686.PAE)' --class fedora --class gnu-linux --class gnu --class os {
savedefault
load_video

---------- Post added at 07:38 PM ---------- Previous post was at 06:57 PM ----------

well I did it this time!

I wanted to let grub find the correct spelling of the kernel

since I failed.

grub2-mkconfig /etc/grub2.cfg
grub2-install /dev/sdb

reboot

this time "file not found" and a grub rescue prompt

This doesn't need to be this complicated

now using dual boot XP Professional to write this post

matth45 · #7 1st June 2012, 04:51 AM

You do want to be careful editing those files, as you can put the system in an unbootable state.

First, check which kernel rpms you have installed.

Code:

rpm -qa | grep kernel

You should probably see something like

Code:

kernel-3.3.7-1.fc16.x86_64
kernel-3.3.7-1.fc17.x86_64

PAE is physical address extension, and is used to allow 32 bit kernels to address more than 32 bits of memory (aka more than 4gb). If you don't have 4gb of memory, it doesn't matter if you use PAE or not. It also doesn't apply to 64 bit kernels (which can address a 64 bit memory address space). So if you have a 64 bit kernel, then there will not be any PAE anything.

The grub2 file you posted seems like a strange mix of 32bit and 64bit. I'm not sure if the installer can go from a 32 bit to a 64 bit system, although I suppose its possible. You're probably in for a bit of pain if that's really the case though. So before I suggest anything else, let's see what kernel RPMs you have installed.

---------- Post added at 11:48 PM ---------- Previous post was at 11:44 PM ----------

Wow, I didn't read the second part of your post. Looks like you're already in trouble!

Boot from a rescue CD. Then when you get to a bash prompt, you can do chroot /mnt/sysimage, and try the rpm command I suggested. This will tell us which kernel rpms are really installed. Then you can hopefully fix the grub config files. You should not have to reinstall the bootloader though.

---------- Post added at 11:51 PM ---------- Previous post was at 11:48 PM ----------

And a second thought - at a very minimum, all the files listed in that config file you posted should exist in your /boot partition, and should all be the same type. I.e., vmlinuz-3.3.7-1.fc17.x86_64 kernel image (64 bit) with initramfs-3.3.7-1.fc16.i686.PAE.img filesystem (32 bit) is very very wrong.

clariceoshea · #8 1st June 2012, 05:34 PM

I tried doing a rescue

chroot /mnt/sysimage

message: no such directory or file

Using dual boot to get to F17 (usual way)I get a grub rescue prompt.

Anybody have the commands for this?

I did save the original grub2.cfg

but cannot find it using either rescue.

matth45 · #9 2nd June 2012, 09:46 PM

To know what commands to use at the grub rescue prompt, you will have to know which kernel you have installed, or equivalently, the contents of the /boot partition. I think you gave up too quickly on the rescue CD. You need to mount your filesystem and fix the /boot/grub2/grub.cfg to be consistent with the installed kernel (as I mentioned in my previous post).

The rescue should find your existing fedora partitions, but if it doesn't you can mount them manually. Try to answer these questions:

What disks are attached to your system? They will appear sequentially as /dev/sda, /dev/sdb, etc...

What partitions are on those disks?

(as root)

Code:

parted /dev/sda print
parted /dev/sdb print

and so on...

It should now be clearer which partition corresponds to /boot. Some partitions might be windows (FAT, NTFS), some might be swap, if you have LVM, there will probably be an LVM partition which contains your system. But if you did a standard Fedora install, you should see an ext2 or ext4 partition with a boot flag that is between 100MB and 600MB (depending on which version of Fedora did the installation). This is probably the /boot partition.

Here's what that looks like on my system:

Code:

#parted /dev/sda print
Model: ATA Hitachi HTS54502 (scsi)
Disk /dev/sda: 250GB
Sector size (logical/physical): 512B/512B
Partition Table: msdos
Disk Flags: 

Number  Start   End    Size   Type     File system  Flags
 1      1049kB  525MB  524MB  primary  ext4         boot
 2      525MB   250GB  250GB  primary

So I can see that /dev/sda1 is the /boot partition.

Now you should mount it to fix the grub.cfg file. Make some mount point in the rescue filesystem, such as /mnt/sysimage/boot

Code:

mkdir -p /mnt/sysimage/boot

Then mount the /boot partition

Code:

mount /dev/sda1 /mnt/sysimage/boot

Where the partition and mount point correspond to the values you discover for your system.

Then check what files you have in /mnt/sysimage/boot

Code:

ls /mnt/sysimage/boot

Update your grub.cfg file to match the kernel and initramfs files you see listed there.

Code:

vi /mnt/sysimage/boot/grub2/grub.cfg

(or nano or whatever editor you like)

With any luck, you should be able to boot again. Then you can worry about which kernel exactly should be listed in grub.cfg.

(FYI /etc/grub2.cfg is a symlink to /boot/grub2/grub.cfg in your main filesystem).

---------- Post added at 04:46 PM ---------- Previous post was at 04:44 PM ----------

Also,

Code:

df -h

to see what the rescue system mounted.

Mariusz W · #10 3rd June 2012, 01:34 AM

The same problem here: preupgrade F16 -> F17 hung on steel bank common lisp. This is the first time since that infamous Fedora 8 preupgrade, that I see anaconda hung in the middle of the preupgrade install, and I am wondering what is the safest way to proceed.

Quote:

Originally Posted by matth45

Also note, there is an ongoing bugzilla report regarding this issue. If you ran into this, you could make some noise over there.

https://bugzilla.redhat.com/show_bug.cgi?id=822008

Thank you. This is it. The bug report page has several lucid comments. The problem is due to hung script that, according to Rex Dieter, needs to be killed with something like

Code:

killall -KILL sbcl

so no necessity to shut down, and a probable a lesson for the future is:

if anaconda installer hangs on some package, open Linux console and find (using ps) the script that is waiting infinitely, write down its exact name including flags and arguments for a future reference (e.g., to file a gug, or for interente searches), and kill it).

Another important point I got from those comments is: due to an oversight, anaconda does not refresh the installation screen (!) which means that if you switch to the Linux console, when you switch back to the installation screen, you are greeted with a blank, bright milk-gray screen, and you will not see anything else until anaconda proceeds to install the next package.

Does anybody know how to get information about the progress of installation from the console?