Strange font / frame size problem makes emacs unusable.

Strange font / frame size problem makes emacs unusable.

[Gaute Amundsen]

Not entirely sure if this an Emacs bug, an Ubuntu bug, normal expected
behavior, or what, but hopefully somebody here will be able to point me
in the right direction.
An hour of googling did me no good. One of those things it's hard to
pinpoint the right terms for..

Basically I moved a partition containing Ubuntu Karmic to another
laptop, and booted right up.
http://ubuntuforums.org/showthread.php?p=9168599

The only hard problem I have encountered so far is with Emacs.

"GNU Emacs 23.1.1 (i486-pc-linux-gnu, GTK+ Version 2.18.3) of 2010-03-26
on palmer, modified by Debian"

I get "GLib-WARNING **: g_set_prgname() called multiple times", but I
suspect that's unrelated.

Easiest way to explain is some screenshots:

Just after startup, maximized. 
http://www.div.org/emacs/Screenshot-emacs@totiki.png

"Restored"
http://www.div.org/emacs/Screenshot-emacs@totiki-1.png

Default font saved as anything other than what it was.
http://www.div.org/emacs/Screenshot-emacs@totiki-2.png

Starting without .emacs makes no difference.

I have a gut-feeling this must somehow be related to X, but I really
have no clue.

Any ideas are appreciated.

Gaute 

Re: Strange font / frame size problem makes emacs unusable.

[Peter Dyballa]

Am 24.04.2010 um 22:53 schrieb Gaute Amundsen:

> Any ideas are appreciated.


Font switching happens. Possible cause: GNU Emacs has an internal  
default, X11 has a different X resource, GTK has its own settings. In  
this sequence, presumingly, one overrides the elder. GTK makes, IMO,  
things complicated since it customises compound ideas, comprised of  
simple elements.

Check documentation, and check whether you have forgotten to migrate  
~/.Xdefaults and ~/.emacs.d/gtkrc or ~/.gtkrc, whichever gets used...

--
Greetings

   Pete
               <\
                 \__     O                       __O
                 | O\   _\\/\-%                _`\<,
                 '()-'-(_)--(_)               (_)/(_)

Re: Strange font / frame size problem makes emacs unusable.

[Gaute Amundsen]

On Sun, 2010-04-25 at 10:28 +0200, Peter Dyballa wrote:
> Am 24.04.2010 um 22:53 schrieb Gaute Amundsen:
> 
> > Any ideas are appreciated.
> 
> 
> Font switching happens. Possible cause: GNU Emacs has an internal  
> default, X11 has a different X resource, GTK has its own settings. In  
> this sequence, presumingly, one overrides the elder. GTK makes, IMO,  
> things complicated since it customises compound ideas, comprised of  
> simple elements.

Well, it's not just fonts, is it? The buffer starts one line high, even
when the fonts are tiny, and that last screenshot where two lines fills
the screen is supposedly 11pt. fonts.
Come to think of it I should also mention that it looks like that last
shot, briefly during startup. 

I also notice now, that startup seems slower than it ought to be.
Takes around 12 seconds, while -nw is ~1 sec.
Cpu maxes out for some seconds there as well.


Hm.. not my specialty, but playing around with strace...
# strace -c emacs

(emacs:25774): GLib-WARNING **: g_set_prgname() called multiple times
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 42.18    0.004471           1      3660           poll
 39.57    0.004195           1      4724      2022 read
 11.28    0.001196           2       532           getdents64
...

# strace -c emacs -nw
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 66.73    0.000379           2       172           close
 13.56    0.000077           0       946       864 stat64
  6.87    0.000039           0       151           read
...

I figure a lot of those read errors must be from blocks like this.


--- SIGIO (I/O possible) @ 0 (0) ---
sigreturn()                             = ? (mask now [])
read(3, "\1<\377\2L\0\0\0\0\0N\0N\0|\0 \0\341\1\1\0\22\0\0\0N\0N\0|
\0"..., 4096) = 396
read(3, 0x9f10018, 4096)                = -1 EAGAIN (Resource
temporarily unavailable)
read(3, 0x9f10018, 4096)                = -1 EAGAIN (Resource
temporarily unavailable)
poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3,
revents=POLLOUT}])
writev(3, [{"2\30\21\0\1\0<\0", 8},
{"-misc-fixed-medium-r-normal--161"..., 60}, {"", 0}], 3) = 68
poll([{fd=3, events=POLLIN}], 1, -1)    = 1 ([{fd=3, revents=POLLIN}])
--- SIGIO (I/O possible) @ 0 (0) ---


Something about fonts..., but I have to work on that..

> Check documentation, and check whether you have forgotten to migrate  
> ~/.Xdefaults and ~/.emacs.d/gtkrc or ~/.gtkrc, whichever gets used...

I have none of the those anywhere on the system.
You don't think I should try to narrow down where the cause might be a
bit more before I start reading docs? Seems to me I could read docs for
a week to cover the possible territory at this point.. :)

tried emacs -QD but no change.

emacs -fn lucidasans-24 looks more sensible during startup, but then
just the same behavior. Hm.. lucida is not an option in the "default
font" dialog, but is one of the hits in xlsfonts | grep -i sans.


Well, some new angles to work on anyway.

Thanks :)

Gaute

Re: Strange font / frame size problem makes emacs unusable.

[Peter Dyballa]

Am 25.04.2010 um 21:43 schrieb Gaute Amundsen:

> read(3, 0x9f10018, 4096)                = -1 EAGAIN (Resource
> temporarily unavailable)
> read(3, 0x9f10018, 4096)                = -1 EAGAIN (Resource
> temporarily unavailable)

What is there "temporarily unavailable?" And why at all?

> poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3,
> revents=POLLOUT}])
> writev(3, [{"2\30\21\0\1\0<\0", 8},
> {"-misc-fixed-medium-r-normal--161"..., 60}, {"", 0}], 3) = 68


This a rather large font: 161 points... Since Ubuntu is Debian based  
there are certainly some system init files. They're either missing  
(because you did not install the packages) or they're for a different  
version of GNU Emacs? Find and check them! Some trace variant is able  
to record files being opened.

--
Greetings

   Pete

Upgraded, adj.:
	Didn't work the first time.

Re: Strange font / frame size problem makes emacs unusable.

[tomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Apr 25, 2010 at 11:49:20PM +0200, Peter Dyballa wrote:
>
> Am 25.04.2010 um 21:43 schrieb Gaute Amundsen:
>
>> read(3, 0x9f10018, 4096)                = -1 EAGAIN (Resource
>> temporarily unavailable)
>> read(3, 0x9f10018, 4096)                = -1 EAGAIN (Resource
>> temporarily unavailable)
>
> What is there "temporarily unavailable?" And why at all?
>
>> poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3,
>> revents=POLLOUT}])
>> writev(3, [{"2\30\21\0\1\0<\0", 8},
>> {"-misc-fixed-medium-r-normal--161"..., 60}, {"", 0}], 3) = 68
>
>
> [...] Find and check them! Some trace variant is able to record files 
> being opened.

As Peter says, try to find what fd=3 is (somewhere higher in the trace
there should be a call to open/connect returning 3).

Linux makes it difficult to find the "other end" of a Unix domain
socket; nevertheless, if you say "ls -l /proc/fd/<pid of your Emacs>,
you'll see where fd3 is going to; with "lsof" or "netstat -axp" you'll
"see" the connection, but not which process is at the other end...

So your best bet is to search for connect/open/whatever other calls
might be returning an fd of 3 up your trace.

Regards
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFL1SSYBcgs9XrR2kYRAj87AJ9UzzO5F3MiXZS3V1EdmpFsXi+RHwCfdudj
chTp7MY0i9LdHamg5s8x98k=
=XkSW
-----END PGP SIGNATURE-----

Re: Strange font / frame size problem makes emacs unusable.

[Gaute Amundsen]

On Mon, 2010-04-26 at 07:28 +0200, tomas@tuxteam.de wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Sun, Apr 25, 2010 at 11:49:20PM +0200, Peter Dyballa wrote:
> >
> > Am 25.04.2010 um 21:43 schrieb Gaute Amundsen:
> >
> >> read(3, 0x9f10018, 4096)                = -1 EAGAIN (Resource
> >> temporarily unavailable)
> >> read(3, 0x9f10018, 4096)                = -1 EAGAIN (Resource
> >> temporarily unavailable)
> >
> > What is there "temporarily unavailable?" And why at all?
> >
> >> poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3,
> >> revents=POLLOUT}])
> >> writev(3, [{"2\30\21\0\1\0<\0", 8},
> >> {"-misc-fixed-medium-r-normal--161"..., 60}, {"", 0}], 3) = 68
> >
> >
> > [...] Find and check them! Some trace variant is able to record files 
> > being opened.
> 
> As Peter says, try to find what fd=3 is (somewhere higher in the trace
> there should be a call to open/connect returning 3).

Searching backwards for ' = 3$' in less gets me this bit:

socket(PF_FILE, SOCK_STREAM, 0)         = 3
connect(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, 20) = 0
getpeername(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0i\1"}, [20])
= 0

To me that looks like a socket to the current X server.

> Linux makes it difficult to find the "other end" of a Unix domain
> socket; nevertheless, if you say "ls -l /proc/fd/<pid of your Emacs>,

ls -l /proc/<pid>/fd/ gives me "3 -> socket:[1218659]"
the first socket emacs opened.

> you'll see where fd3 is going to; with "lsof" or "netstat -axp" you'll
> "see" the connection, but not which process is at the other end...

Both say about the same yes.

emacs   11410 gaute    3u  unix 0xdd478000      0t0 1218659 socket

unix  3      [ ]         STREAM     CONNECTED     1218757  11410/emacs


> So your best bet is to search for connect/open/whatever other calls
> might be returning an fd of 3 up your trace.

Precisely :) 

So emacs is waiting a lot on X..
Particularly while doing something related to one enormous font.

But I can't say I've noticed any particular slowness otherwise..

And what related to X could have been disturbed by my moving of the
system.. 
The xorg.conf is default and as simple as can be.

My first intuition was that X somehow has saved, or relies on an
external "pointer", to a "video device" that is no longer there, and
emacs relies on some info about screen size that is now wrong or
missing.

Guess I could try to reproduce the problem in some other program that
relies on X... but what?

or I could try to start emacs with a remote X server in different ways.
Perhaps I could sidestep gnome somehow, and see if that's related.

But I ramble :)

Gaute

Re: Strange font / frame size problem makes emacs unusable.

[Gaute Amundsen]

On Sun, 2010-04-25 at 23:49 +0200, Peter Dyballa wrote:
> Am 25.04.2010 um 21:43 schrieb Gaute Amundsen:
> 
> > read(3, 0x9f10018, 4096)                = -1 EAGAIN (Resource
> > temporarily unavailable)
> > read(3, 0x9f10018, 4096)                = -1 EAGAIN (Resource
> > temporarily unavailable)
> 
> What is there "temporarily unavailable?" And why at all?

The socket to X it seems, yes..

> > poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3,
> > revents=POLLOUT}])
> > writev(3, [{"2\30\21\0\1\0<\0", 8},
> > {"-misc-fixed-medium-r-normal--161"..., 60}, {"", 0}], 3) = 68
> 
> This a rather large font: 161 points...  

It is.. and it's not one among many as I presumed.

and it's not in 
xlsfonts | grep misc-fixed-medium-r-normal--

> Since Ubuntu is Debian based  
> there are certainly some system init files. They're either missing  
> (because you did not install the packages) or they're for a different  
> version of GNU Emacs? Find and check them! 

None that I can spot.
Can you suggest a string to grep /etc/ for?

> Some trace variant is able  
> to record files being opened.

neither strace and lsof show anything resembling those names.

Gaute

Re: Strange font / frame size problem makes emacs unusable.

[Peter Dyballa]

Am 26.04.2010 um 09:18 schrieb Gaute Amundsen:

> xlsfonts | grep misc-fixed-medium-r-normal--

*Don't* use the '--' when grep'ing for a font name! And it's so much  
easier to

	xlsfonts -fn '-misc-fixed-medium-r-normal-*'

>
>> Since Ubuntu is Debian based
>> there are certainly some system init files. They're either missing
>> (because you did not install the packages) or they're for a different
>> version of GNU Emacs? Find and check them!
>
> None that I can spot.
> Can you suggest a string to grep /etc/ for?

No, I am not using a Debian based Linux. Other suggestions: locate .el  
| egrep '^/etc', launch GNU Emacs as

	emacs [...] -eval '(defadvice load (before debug-log activate)  
(message "(Tipp von Kai G) Lade jetzt: %s" (ad-get-arg 0)))'

>
>> Some trace variant is able
>> to record files being opened.
>
> neither strace and lsof show anything resembling those names.


Lsof certainly is the wrong choice: it can only list files kept open  
by some process at this moment, not those once temporarily opened and  
now closed. And I am more familiar with DTrace in Solaris or Mac OS X...

--
Greetings

   Pete
                       ~  o
                        ~_\\_/\
                       ~  O   O

Re: Strange font / frame size problem makes emacs unusable.

[Peter Dyballa]

Am 26.04.2010 um 08:59 schrieb Gaute Amundsen:

> Searching backwards for ' = 3$' in less gets me this bit:
>
> socket(PF_FILE, SOCK_STREAM, 0)         = 3
> connect(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, 20) = 0
> getpeername(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0i\1"},  
> [20])
> = 0


This could stop GNU Emacs from contacting the X server to ask for a  
list of available fonts (which could also be supplied by  
libfontconfig, i.e., from the client side). Or, as you already  
supposed, stop from asking for the screen's geometry. And when no  
dimensions are received, defaults (like largest unsigned 16-bit  
integer) are used... (could such a screen fit into my apartment?!  
Electronic paper, rolled in when I got to bed?)

Maybe there is some versions mismatch in the software you try to use.

--
Greetings
                                  <]
   Pete       o        __o         |__    o           recumbo
     ___o    /I       -\<,         |o \  -\),-%       ergo sum!
___/\ /\___./ \___...O/ O____.....`-O-'-()--o_________________

Re: Strange font / frame size problem makes emacs unusable.

[Gaute Amundsen]

On Mon, 2010-04-26 at 11:36 +0200, Peter Dyballa wrote:
> Am 26.04.2010 um 09:18 schrieb Gaute Amundsen:
> 
> > xlsfonts | grep misc-fixed-medium-r-normal--
> 
> *Don't* use the '--' when grep'ing for a font name! And it's so much  
> easier to
> 
> 	xlsfonts -fn '-misc-fixed-medium-r-normal-*'

Don't seem to make much of a difference to he results.
Seems grep is smart enough to know it's part of the string..

> >
> >> Since Ubuntu is Debian based
> >> there are certainly some system init files. They're either missing
> >> (because you did not install the packages) or they're for a different
> >> version of GNU Emacs? Find and check them!
> >
> > None that I can spot.
> > Can you suggest a string to grep /etc/ for?
> 
> No, I am not using a Debian based Linux. Other suggestions: locate .el  
> | egrep '^/etc', 

Only hits are /etc/emacs/site-start* and 
/etc/emacs23/site-start.d/00debian-vars.elc

piping into "xargs -n 1 grep -i font" gives no hits.

> launch GNU Emacs as
> 
> 	emacs [...] -eval '(defadvice load (before debug-log activate)  
> (message "(Tipp von Kai G) Lade jetzt: %s" (ad-get-arg 0)))'

Should the message show up in *Messages* ? Nothing there.
Tried emacs --debug-init as well with no obvious sign of anything
happening.

> >
> >> Some trace variant is able
> >> to record files being opened.
> >
> > neither strace and lsof show anything resembling those names.
> 
> 
> Lsof certainly is the wrong choice: it can only list files kept open  
> by some process at this moment, not those once temporarily opened and  
> now closed. And I am more familiar with DTrace in Solaris or Mac OS X...

Right.

ok. Thanks.

Gaute

Re: Strange font / frame size problem makes emacs unusable.

[Gaute Amundsen]

On Mon, 2010-04-26 at 11:44 +0200, Peter Dyballa wrote:
> Am 26.04.2010 um 08:59 schrieb Gaute Amundsen:
> 
> > Searching backwards for ' = 3$' in less gets me this bit:
> >
> > socket(PF_FILE, SOCK_STREAM, 0)         = 3
> > connect(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"}, 20) = 0
> > getpeername(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0i\1"},  
> > [20])
> > = 0
> 
> 
> This could stop GNU Emacs from contacting the X server to ask for a  
> list of available fonts (which could also be supplied by  
> libfontconfig, i.e., from the client side). Or, as you already  
> supposed, stop from asking for the screen's geometry. And when no  
> dimensions are received, defaults (like largest unsigned 16-bit  
> integer) are used... (could such a screen fit into my apartment?!  
> Electronic paper, rolled in when I got to bed?)
> 
> Maybe there is some versions mismatch in the software you try to use.

You think that sounds plausible.. good.
I will pursue that angle some more then :)

Hard to imagine a version missmatch appearing as a result
copying /dev/sda5 to /dev/sda2 on other hardware, and booting.
That's basically the only change I made...

Gaute

Re: Strange font / frame size problem makes emacs unusable.

[Peter Dyballa]

Am 26.04.2010 um 11:58 schrieb Gaute Amundsen:

>>> xlsfonts | grep misc-fixed-medium-r-normal--
>>
>> *Don't* use the '--' when grep'ing for a font name! And it's so much
>> easier to
>>
>> 	xlsfonts -fn '-misc-fixed-medium-r-normal-*'
>
> Don't seem to make much of a difference to he results.
> Seems grep is smart enough to know it's part of the string..

The final "--" does not hurt grep, xlsfonts does not necessarily  
output that abbreviation.

>
>>>
>>>> Since Ubuntu is Debian based
>>>> there are certainly some system init files. They're either missing
>>>> (because you did not install the packages) or they're for a  
>>>> different
>>>> version of GNU Emacs? Find and check them!
>>>
>>> None that I can spot.
>>> Can you suggest a string to grep /etc/ for?
>>
>> No, I am not using a Debian based Linux. Other suggestions:  
>> locate .el
>> | egrep '^/etc',
>
> Only hits are /etc/emacs/site-start* and
> /etc/emacs23/site-start.d/00debian-vars.elc
>
> piping into "xargs -n 1 grep -i font" gives no hits.

Of course! An ELC file is a compiled Emacs Lisp/ELisp or EL file. Get  
the uncompiled version! In a GPL'ed OS it has to exist. Could be /etc/ 
emacs23/site-start.d has the EL files as well... (GNU Emacs prefers to  
load the byte-compiled variants: they're faster to load.)

>
>> launch GNU Emacs as
>>
>> 	emacs [...] -eval '(defadvice load (before debug-log activate)
>> (message "(Tipp von Kai G) Lade jetzt: %s" (ad-get-arg 0)))'
>
> Should the message show up in *Messages* ? Nothing there.

Yes. You should see a few lines..., but, yes, some Emacsen (I tried  
"Carbon Emacs" in Mac OS X) hide loading these "init" files.

> Tried emacs --debug-init as well with no obvious sign of anything
> happening.

Starts "debugging" (with a 'Backtrace* buffer) *after* an error has  
happened.

--
Greetings

   Pete

There's no place like 127.0.0.1
			– origin unknown

Re: Strange font / frame size problem makes emacs unusable.

[Peter Dyballa]

Am 26.04.2010 um 12:05 schrieb Gaute Amundsen:

> Hard to imagine a version missmatch appearing as a result
> copying /dev/sda5 to /dev/sda2 on other hardware, and booting.
> That's basically the only change I made...


Originally you wrote that you "moved" some partition from here to  
there. You did not mention that it was the contents of the boot and OS  
partition. It could have been *some* data. What you could do is to  
check ownership and permissions. What about SELinux extensions? Are  
ACLs still correct? Which system role had the data "mover?"

--
Greetings

   Pete

Who the fsck is "General Failure," and why is he reading my disk?

Re: Strange font / frame size problem makes emacs unusable.

[Gaute Amundsen]

On Mon, 2010-04-26 at 17:46 +0200, Peter Dyballa wrote:
> Am 26.04.2010 um 11:58 schrieb Gaute Amundsen:
> 
> >>> xlsfonts | grep misc-fixed-medium-r-normal--
<snip>
> 
> >
> >>>
> >>>> Since Ubuntu is Debian based
> >>>> there are certainly some system init files. They're either missing
> >>>> (because you did not install the packages) or they're for a  
> >>>> different
> >>>> version of GNU Emacs? Find and check them!
> >>>
> >>> None that I can spot.
> >>> Can you suggest a string to grep /etc/ for?
> >>
> >> No, I am not using a Debian based Linux. Other suggestions:  
> >> locate .el
> >> | egrep '^/etc',
> >
> > Only hits are /etc/emacs/site-start* and
> > /etc/emacs23/site-start.d/00debian-vars.elc
> >
> > piping into "xargs -n 1 grep -i font" gives no hits.
> 
> Of course! An ELC file is a compiled Emacs Lisp/ELisp or EL file. Get  
> the uncompiled version! In a GPL'ed OS it has to exist. Could be /etc/ 
> emacs23/site-start.d has the EL files as well... (GNU Emacs prefers to  
> load the byte-compiled variants: they're faster to load.)

Yes, that's in /etc/emacs/site-start.d/ 
None of those are elc.
Only mentioned the elc for completeness.

Tried greping for a number of terms related to fonts, devices X, and so
on. no hits.
None of the names suggest anything related to fonts or X either :(

but just moving the whole dir out of the way, does actually make a
difference. Now I get screenshot 3 straight away. :-/

> >
> >> launch GNU Emacs as
> >>
> >> 	emacs [...] -eval '(defadvice load (before debug-log activate)
> >> (message "(Tipp von Kai G) Lade jetzt: %s" (ad-get-arg 0)))'
> >
> > Should the message show up in *Messages* ? Nothing there.
> 
> Yes. You should see a few lines..., but, yes, some Emacsen (I tried  
> "Carbon Emacs" in Mac OS X) hide loading these "init" files.
> 
> > Tried emacs --debug-init as well with no obvious sign of anything
> > happening.
> 
> Starts "debugging" (with a 'Backtrace* buffer) *after* an error has  
> happened.
And as there are no error as such, no trace.

Gaute

Re: Strange font / frame size problem makes emacs unusable.

[Gaute Amundsen]

On Mon, 2010-04-26 at 17:52 +0200, Peter Dyballa wrote:
> Am 26.04.2010 um 12:05 schrieb Gaute Amundsen:
> 
> > Hard to imagine a version missmatch appearing as a result
> > copying /dev/sda5 to /dev/sda2 on other hardware, and booting.
> > That's basically the only change I made...
> 
> Originally you wrote that you "moved" some partition from here to  
> there. You did not mention that it was the contents of the boot and OS  
> partition. It could have been *some* data. What you could do is to  
> check ownership and permissions. What about SELinux extensions? Are  
> ACLs still correct? Which system role had the data "mover?"

I wrote:
> Basically I moved a partition containing Ubuntu Karmic to another
> laptop, and booted right up.

Just trying to be succinct, but perhaps I should have spelled it out
more.

There is only one partition, and I moved it using gparted, ie. dd.
I other words, there should not be any changes except what I had to do
to get it to boot. 

Snip from my post on ubuntuforums
http://ubuntuforums.org/showthread.php?p=9173502
"Old partition boots fine on new pc. What should have broken?"

Synopsis of steps:
Boot old laptop from cd. Connect new laptop disk using usb. 
Partition in gparted, make new swap, then copy paste Karmic partition in
free space.
Fix grub using chroot, grub-install, update-grub
Put disk back. Boot. :)
Freeze up swapping a few times. Fix uuid for swap in fstab.
Fix swap uuid in /etc/initramfs-tools/conf.d/resume just in case.

Does this shed any new light on the issue?  *Hopefull* :)

Gaute