1364601783 M * Jb_boin have you used the same config file?
1364601828 M * Jb_boin in case you based your kernel on the beng source package, its config file might not have all the required modules compiled to use X
1364601869 M * Jb_boin at least i had problems with nvidias when i tried to run X on the host using beng vserver kernels but i might have encountered specific issues
1364602017 M * Seattle Yes, used to same config file.  This time, did not use BenG as had trouble there too.  Is there an alternative?  I think in one iteration (maybe trying makeoldconfig) was an endless series of questions about the hardware....
1364602128 M * Jb_boin you can use its source packages and recompile the kernel using your own configuration, its usually simpler/faster than create a package from scratch
1364602241 M * Seattle I.e., something like "apt-get install linux-source-3.2.39" and "apt-get build-dep linux-source-3.2.39"?
1364602260 M * Seattle Or from synaptic?
1364602773 M * Seattle If we do that, is there some procedure to patch updated versions of vserver and util vserver?
1364602811 M * Seattle I.e., to a recompiled kernel from source packages.
1364603277 N * Bertl_zZ Bertl
1364603281 M * Bertl back now ...
1364603343 M * Bertl Seattle: hey, it seems you have been working on this for quite some time now, do you mind if I ask why you are doing this ... i.e. what's the task/goal here and how did you get to work on this?
1364603388 M * Bertl and as usual, I have a bunch of tipps for you :)
1364603545 M * Seattle Hi Bertl - have a couple of goals - a) ran into some errors with encrypted (encfs) not unmounting, and one possiblity for a fix was to upgrade tools and vserver which lead to trying to figure out how to upgrade kernel.  Also, given that it seems we should know how to compile to work with later versions of debian....
1364603597 M * Bertl okay, so you are doing this as a company mostly to stay up-to-date, yes?
1364603645 M * Bertl or is this more a one man project?
1364603657 M * Seattle Yes, especially as think there are probably workarounds to deal with when we log of (x2go sessions) that our encfs mounts don't unmount
1364603672 M * Seattle 1.1 man project
1364603684 M * Bertl okay, understood
1364603688 M * Seattle I.e., have a little help from someone, but not much
1364603700 M * Bertl I presume, serial console is still no option on your hardware?
1364603711 M * Seattle right
1364603730 M * Bertl i.e. it is hosted somewhere, you got a single dedicated server there?
1364603734 M * Seattle and think may be passed that....have managed to compile kernel
1364603745 M * Bertl yeah, I read that
1364603795 M * Seattle dell quad core (am sitting next to it).  Have messed around with cloud server vendors (e.g., Terremark) but think they may be a rip off if try to go beyond a few users
1364603820 M * Bertl hmm, sitting next to it means you have physical access to the machine?
1364603829 M * Seattle Sorry, yes
1364603854 M * Bertl so what keeps you from having a serial console?
1364603880 M * Seattle Sorry, assumed I needed a serial port...
1364603912 M * Bertl well, yes, you need one somewhere, what kind of server is that? do you have a model name?
1364603973 M * Seattle Some sort of inspiron (can get specifics from Dell service code, but don't know it off the top)
1364604012 M * Seattle Could add a serial port, but assumed that was for when I couldn't get passed kernel panics.  Is that wrong?
1364604040 M * Bertl the serial console is a very useful tool for all kind of debugging
1364604062 M * Bertl especially in linux, as you can send so called 'magic sysrq' commands
1364604109 M * Bertl also, you still want to go for a recent kernel, i.e. if you choose 3.2.x then 3.2.42 for example
1364604158 M * Bertl the many questions you were asked with 'make oldconfig' are basically drivers which changed between your config and the kernel you are trying to configure
1364604196 M * Bertl so, if you copy your existing .config to a new kernel source tree, and run 'make oldconfig' the kernel will ask about everything which was added/changed since your config
1364604263 M * Bertl further, it is (in general, not really Linux-VServer related) advised to 'slim' down the kernel to the actual hardware/drivers your system/server has/uses, not just for performance reasons but also to avoid buggy drivers and such
1364604308 M * Bertl now to the tips for your current setup:
1364604454 M * Bertl build a recent kernel without Linux-VServer patches (i.e. just the vanilla sources from kernel.org) based on your current config (which seems to boot at least), see what works with that (again not Linux-VServer related) and what doesn't
1364604488 M * Bertl check the kernel messages (dmesg or serial console) regarding comments, issues, hardware, etc
1364604585 M * Bertl when you keep the source tree (where you build your kernel) around and do not clean it up, rebuilding a modified kernel (i.e. with a few driver added or removed, a few options changed) takes only a few seconds and you can easily test a bunch of variations
1364604674 M * Bertl make sure that everything you want/need on that host (IMHO gnome or kde is not something you want on a server host, but YMMV) works with the new vanilla kernel, if you encounter problems, ask the debian folks for tips
1364604745 M * Bertl once that is done, simply add the Linux-VServer patch to the mix, run 'make oldconfig' and either take the defaults or adjust some options to you liking (you can get a help for each option with '?')
1364604896 M * Seattle Thanks Bertl - Think (hope) I'm with you until the last "add the Linux-Vserver patch to the mix".  I.e., download the patch, link it to ???
1364604924 M * Bertl adding the patch is simple, you do it like described on the wiki
1364604950 M * Bertl basically you have a directory with the kernel sources you built the vanilla/mainline kernel from
1364604964 M * Seattle OK, thanks
1364604968 M * Bertl let's say, it is called linux-3.2.42
1364605006 M * Bertl you copy it to e.g. linux-3.2.42-vs2.3.2.16
1364605033 M * Bertl then you grab the patch from with e.g. wget http://vserver.13thfloor.at/Experimental/patch-3.2.39-vs2.3.2.16.diff
1364605056 M * Bertl then you change into the new copy, with cd linux-3.2.42-vs2.3.2.16
1364605082 M * Bertl then you apply the patch with 'patch -p1 <../patch-3.2.39-vs2.3.2.16.diff'
1364605107 M * Bertl this will succeed except for the Makefile, because the patch is for version 3.2.39 not 42
1364605120 M * Bertl (there will be an updated patch soon, but that is not a problem)
1364605140 M * Bertl you then adjust the one failing patch manually with an editor (it just adds the kernel version)
1364605157 M * Bertl rerun the 'make oldconfig' and answer the questions)
1364605188 M * Bertl and then you are ready to build the Linux-VServer kernel which will act and work like the one without, except for the added Linux-VServer support
1364605248 M * Seattle This is really helpful - Q: can you expand on "you then adjust the one failing patch manually with an editor (it just adds the kernel version)"?
1364605305 M * Bertl --- linux-3.2.39/Makefile       2013-03-02 15:22:30.000000000 +0000
1364605305 M * Bertl +++ linux-3.2.39-vs2.3.2.16/Makefile    2013-03-02 17:57:32.000000000 +0000
1364605305 M * Bertl @@ -1,7 +1,7 @@ VERSION = 3 PATCHLEVEL = 2 SUBLEVEL = 39
1364605305 M * Bertl -EXTRAVERSION =
1364605305 M * Bertl +EXTRAVERSION = -vs2.3.2.16 NAME = Saber-toothed Squirrel
1364605317 M * Bertl this is the 'hunk' which will fail
1364605335 M * Bertl it basically adds -vs2.3.2.16 to EXTRAVERSION
1364605359 M * Bertl it will fail because SUBLEVEL is 39 not 42 (in the patch)
1364605424 M * Bertl you can either adjust the patch before you apply it (with patch) to read 42 instead of 39 as SUBLEVEL or you can adjust the EXTRAVERSION in the Makefile afterwards (to have the -vs2.3.2.16 as EXTRAVERSION)
1364605459 M * Bertl but probably when you get to this point, an updated patch for .42 is alrady available, so I wouldn't worry to much about that
1364605591 M * Seattle OK - thanks (!) - appreciate your help, patience (a lot of this is new, so am fumbling along)...
1364605650 M * Bertl and get me the server model, so that I can check what options regarding serial console you have
1364605714 M * Seattle OK, thanks Bertl - will post back....hopefully with "got it to work"
1364605785 M * Seattle Bye for tonight(!)
1364605795 M * Bertl cya
1364605804 Q * Seattle Quit: ChatZilla 0.9.90 [Iceweasel 3.5.16/20121207230533]
1364621361 M * Bertl off to bed now ... have a good one everyone!
1364621367 N * Bertl Bertl_zZ
1364623942 Q * DLange Quit: irssi update. Not. :)
1364624165 J * DLange ~DLange@dlange.user.oftc.net
1364633462 Q * mcp Remote host closed the connection
1364635145 J * Ghislain ~aqueos@adsl1.aqueos.com
1364635924 J * bonbons ~bonbons@2001:a18:209:3a01:a1ca:2799:e619:4d7a
1364636367 J * mcp ~mcp@wolk-project.de
1364641688 Q * michal Quit: chilling out
1364641755 J * michal ~michal@168.63.70.79
1364641841 Q * ircuser-1 Ping timeout: 480 seconds
1364648833 Q * Aiken Remote host closed the connection
1364650854 N * Bertl_zZ Bertl
1364650859 M * Bertl morning folks!
1364652500 J * ircuser-1 ~ircuser-1@35.222-62-69.ftth.swbr.surewest.net
1364652883 Q * _Shiva_ Remote host closed the connection
1364652885 J * _Shiva_ shiva@whatcha.looking.at
1364656911 J * hijacker_ ~hijacker@cable-84-43-134-121.mnet.bg
1364661149 Q * hijacker_ Quit: Leaving
1364664781 J * _WildPikachu_ ~nkukard@196-215-197-16.dynamic.isadsl.co.za
1364664892 Q * fback Remote host closed the connection
1364664921 Q * nkukard_ Ping timeout: 480 seconds
1364665218 J * fback fback@red.fback.net
1364672730 Q * Ghislain Quit: Leaving.
1364672804 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1364677418 J * hijacker_ ~hijacker@cable-84-43-134-121.mnet.bg
1364681999 Q * hijacker_ Quit: Leaving