Upgrade path from 0.6 to 0.9?

I'll be burning a ISO image over the weekend, but I was curious. Is there the equivalent of "apt-get dist-update" or a simple way to do this w/ out a complete reload?

On a somewhat related note, the 712 I've been playing on has the 0.6 bits loaded & I've been doing some apt-get's, but right now I can't get anywhere. I've tried "apt-get -f install" to try to "clean things up", but keep getting this:

============================================================

dpenguin:~# apt-get -f install
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
  libc6 
1 packages upgraded, 0 newly installed, 0 to remove and 51  not
upgraded.
1 packages not fully installed or removed.
Need to get 0B/4106kB of archives. After unpacking 254kB will be used.
Do you want to continue? [Y/n] 
debconf: skipping preconfiguration (apt-utils is not installed)
(Reading database ... 16349 files and directories currently installed.)
Preparing to replace libc6 2.2.1-1 (using
.../libc6_2.2.3-2.0.0.2_hppa.deb) ...
Unpacking replacement libc6 ...
dpkg: error processing
/var/cache/apt/archives/libc6_2.2.3-2.0.0.2_hppa.deb (--unpack):
 dpkg: warning - old post-removal script killed by signal (Segmentation
fault)

dpkg: error while cleaning up:
dpkg: warning - pre-installation script killed by signal (Segmentation
fault)

Errors were encountered while processing:
/var/cache/apt/archives/libc6_2.2.3-2.0.0.2_hppa.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

============================================================

And in dmesg:

============================================================

do_page_fault() pid=244 command='libc6.postrm' type=15 address=0x000003a4

YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001111

r0-3     00000000 00098058 00047573 000a40d0
r4-7     000003a4 000003a4 bff0021b 0000000c
r8-11    0000003d bff002d8 00000028 00000001
r12-15   00000081 00000029 00098058 00098058
r16-19   00000000 bff01708 0004fe90 00000000
r20-23   000a48d1 00000000 ffffc8bf 000a0858
r24-27   ffffffff 000a40d0 000003a4 00098058
r28-31   000a48d0 00000000 bff007c0 401cc057
sr0-3    0000002c 0000002c 00000000 0000002c
sr4-7    0000002c 0000002c 0000002c 0000002c

IASQ: 0000002c 0000002c IAOQ: 0004751b 0004751f
IIR: 0f401014 ISR: 0000002c IOR: 000003a4
ORIG_R28: 40235ef4

do_page_fault() pid=245 command='libc6.preinst' type=15 address=0x000003a4

YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001111

r0-3     00000000 00098058 00047573 000a40d0
r4-7     000003a4 000003a4 bff00224 0000000c
r8-11    0000003d bff002d8 00000028 00000001
r12-15   00000081 00000029 00098058 00098058
r16-19   00000000 bff01708 0004fe90 00000000
r20-23   000a48d1 00000000 ffffc8bf 000a0858
r24-27   ffffffff 000a40d0 000003a4 00098058
r28-31   000a48d0 00000000 bff007c0 401cc057
sr0-3    0000002f 0000002f 00000000 0000002f
sr4-7    0000002f 0000002f 0000002f 0000002f

IASQ: 0000002f 0000002f IAOQ: 0004751b 0004751f
IIR: 0f401014 ISR: 0000002f IOR: 000003a4
ORIG_R28: 40235ef4

============================================================

I'm thinking I need to update the kernel, but I'd like to not have to reload this from scratch. I can pull the kernel from the 0.9 ISO, but PALO didn't seem to be too intuitive.

Any suggestions?

-chuck

You do have to update your kernel in order to run glibc 2.2.3, due to the changes in how stacks are managed for threads. I don't think palo is too unintuitive...

Revolutions do not require corporate support.

RTFM, I know. I updated the kernel from the ISO image (mounted via loopback on a RH 7.0 system) and I was able to fix the problem I was having. I added the ISO image to "sources.list" & have "apt-get upgrade" running so far without a hitch.

Wahoo!

-chuck

P.S. The confustion I had about PALO, was wether or not it needed to be run (like LILO) after changing /boot/vmlinux. The answer, BTW, is "no".

Greetings all,

I've noticed a problem that I believe is might be related to the kernel not being able to use swap space. I've never seen swap utilization > 0 and suspect that something might be seriously wrong. Here's an example of the kernel error:

do_page_fault() pid=8730 command='Xvfb' type=6 address=0x00000003

YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
PSW: 00000000000001001111111100001111

r0-3     00000000 0049a1f8 00000000 00000013
r4-7     723cff78 00000000 00000000 00000000
r8-11    00000500 00000400 00000000 00000020
r12-15   00000000 00000000 00000000 00000400
r16-19   00000500 0058fd70 00000000 000057e4
r20-23   00000000 00000014 00000040 004c61f8
r24-27   faf00d58 faf00cd8 0000000e 004471f8
r28-31   0002bf20 00000000 faf00e48 00054f83
sr0-3    00000000 00000100 00000000 00000100
sr4-7    00000100 00000100 00000100 00000100

IASQ: 00000100 00000100 IAOQ: 00000003 00000007
IIR: e85e02a1 ISR: 00000100 IOR: 005dc000
ORIG_R28: 00000003

My system is a 712/60 with 128MB RAM.

Does anyone have a good example of test to force the system to use swap?

-chuck

Hmm... none of my systems are using swap either; I had noticed this before, but never really thought much of it. This has to be a moderately recent breakage because I know jsm has tested swapping.

Sure. malloc 256MB, then dirty each page.

Revolutions do not require corporate support.

I noticed similar behavior w/ the kernel from the 0.6 ISO, but it's been behaving much better since upgrading to the 0.9 bits.