1334105131 J * ichavero_ ~ichavero@189.231.30.236
1334105191 J * Mr_Smoke ~smokey@layla.lecoyote.org
1334105325 Q * Mr_Smoke_ Read error: Connection reset by peer
1334106569 Q * ichavero_ Quit: This computer has gone to sleep
1334119976 Q * clopez Ping timeout: 480 seconds
1334120633 J * ghislain ~AQUEOS@adsl1.aqueos.com
1334124266 Q * vspas Ping timeout: 480 seconds
1334125726 J * ichavero_ ~ichavero@189.231.30.236
1334125827 Q * ichavero_ 
1334127692 J * Alex[fob] ~alex@2001:638:80a:109::152:0
1334127933 J * vspas ~vspas@87.213.36.165
1334129189 M * ghislain hello, 
1334129197 M * ghislain ever seen a (root)> df -h
1334129197 M * ghislain df: no file systems processed
1334129197 M * ghislain  ? :)
1334129272 M * daniel_hozac what's in your /etc/mtab?
1334129289 M * ghislain ohhh i think nothing ^^
1334129317 M * ghislain just none /proc proc defaults 0 0
1334129317 M * ghislain none /dev/pts devpts gid=5,mode=620 0 0
1334129354 M * daniel_hozac right
1334129387 M * ghislain should i have one entry for the rootfs ?
1334129432 M * daniel_hozac yeah, typically.
1334129442 M * ghislain in /proc/mount i have two entry for it a "rootfs" and a /dev/root
1334129515 M * ghislain the rootfs is the good one i guess as /dev/root do not exist
1334129561 M * daniel_hozac does rootfs exist?
1334129571 M * daniel_hozac they're both just dummies.
1334129578 M * ghislain yes
1334129591 M * ghislain rootfs is a dummy one too
1334129611 M * ghislain /dev/root / ext3 rw,tag,relatime,errors=continue,barrier=1,data=writeback 0 0 or rootfs / rootfs rw 0 0
1334132358 N * Bertl_zZ Bertl
1334132363 M * Bertl morning folks!
1334132707 J * ghislain1 ~AQUEOS@adsl2.aqueos.com
1334132823 Q * geb Ping timeout: 480 seconds
1334132881 J * Bl4ckB1rD 4d6f0224@ircip4.mibbit.com
1334132919 M * Bl4ckB1rD any idea why would this happen: http://shrani.si/f/2j/Ac/LiJT8Ma/kernel-panic.png
1334132947 M * Bl4ckB1rD got kernel panic yesterday while there was hard load on server
1334132955 M * Bl4ckB1rD seems like kernel oops
1334132993 Q * ghislain Ping timeout: 480 seconds
1334132994 M * Bl4ckB1rD daniel_hozac's kernel, but i dont think this is vserver related ?
1334132999 M * Bl4ckB1rD correct me if i'm wrong
1334133007 M * Bertl well, it looks incomplete at least
1334133023 M * Bertl do you have a more complete trace somewhere?
1334133033 M * Bl4ckB1rD this is all the trace i got
1334133048 M * Bl4ckB1rD u mean there is more of it ?
1334133053 M * Bl4ckB1rD in bottom ?
1334133096 M * Bertl well, normally kernel traces are surrounded by cutmarks
1334133125 M * Bl4ckB1rD umm how do they look like ? some special character or something ?
1334133182 M * Bertl it looks like the kernel oopsed before that one
1334133196 M * Bl4ckB1rD oh i see
1334133289 M * Bl4ckB1rD i'd have to change some parameters in kernel to see it i guess, cause i didn't get anything besides this "oops" maybe echo 2 > /proc/sys/kernel/hung_task_timeout_secs
1334133291 M * Bl4ckB1rD or something
1334133300 Q * guerby Ping timeout: 480 seconds
1334134315 J * kir ~kir@swsoft-msk-nat.sw.ru
1334134463 M * Bertl Bl4ckB1rD: make sure to have a proper console if you can repeat the issue
1334134477 M * Bertl i.e. a serial console or a tested/working network console
1334135166 M * Bertl off for now .. bbl
1334135170 N * Bertl Bertl_oO
1334135516 M * Bl4ckB1rD ty
1334135518 M * Bl4ckB1rD will do
1334136940 J * guerby ~guerby@nc10d.tetaneutral.net
1334136999 J * petzsch ~markus@dslb-092-078-228-089.pools.arcor-ip.net
1334137459 Q * guerby Ping timeout: 480 seconds
1334137493 J * guerby ~guerby@nc10d.tetaneutral.net
1334138993 J * geb ~geb@mars.gebura.eu.org
1334139622 J * clopez ~clopez@82.25.60.213.dynamic.mundo-r.com
1334140195 N * ensc Guest1555
1334140205 J * ensc ~irc-ensc@p54ADEF01.dip.t-dialin.net
1334140664 Q * Guest1555 Ping timeout: 480 seconds
1334144340 Q * Aiken Quit: Leaving
1334146684 Q * clopez Ping timeout: 480 seconds
1334147004 Q * jeroen__ Quit: Ex-Chat
1334154492 J * clopez ~clopez@fanzine.igalia.com
1334155605 J * dowdle ~dowdle@scott.coe.montana.edu
1334157841 Q * vspas Ping timeout: 480 seconds
1334158468 J * waldi ~waldi@bblank.thinkmo.de
1334158470 M * waldi h
1334158516 M * waldi is there a way to possitively identify a vserver kernel from within a system within?
1334158546 M * daniel_hozac from inside a guest?
1334158566 M * Bl4ckB1rD uname shows kernel from host... 
1334158584 M * waldi daniel_hozac: yes
1334158586 M * Bl4ckB1rD you can't have own kernel on guest... 
1334158607 M * waldi Bl4ckB1rD: answer to a different question
1334158633 M * Bl4ckB1rD mkay... 
1334158659 M * daniel_hozac there's no guaranteed way, no.
1334158714 M * daniel_hozac if the host admin is nice (or lazy), you can see the presence of VxID and NxID in /proc/self/status
1334158751 M * daniel_hozac (and /proc/self/vinfo)
1334158851 M * waldi yes, it seems to list the XID in /proc/*/status
1334158993 M * waldi and it is > 49k, which AFAIK means that it is automatically assigned
1334159003 Q * Bl4ckB1rD Quit: http://www.mibbit.com ajax IRC Client
1334159065 M * daniel_hozac must be an ancient kernel, no recent kernels even support dynamic assignments anymore.
1334159086 M * waldi yep. it is a 2.6.18, not sure which vserver version
1334159113 M * waldi built in 2010. i don't want to imagine the amount of exploits in it
1334159215 M * Bertl_oO sure it isn't 2.4.18? :)
1334159293 M * waldi Bertl_oO: almost eight years late
1334160200 P * waldi 
1334160687 J * bonbons ~bonbons@2001:960:7ab:0:bd14:8110:6956:8e5a
1334163080 Q * ensc|w Remote host closed the connection
1334163089 J * ensc|w ~ensc@www.sigma-chemnitz.de
1334169473 M * _Shiva_ could someone please (re-)enlighten me about what "~single_ip" in nflags does..? ;-)
1334170203 Q * kir Remote host closed the connection
1334170233 J * kir ~kir@swsoft-msk-nat.sw.ru
1334172475 M * Bertl_oO _Shiva_: it disable the single ip special casing in case your kernel config automatically enabled it (AUTO_SINGLE_IP)
1334172483 M * Bertl_oO *disables
1334172607 M * _Shiva_ ok thanks - that's what it says in the description.. what DOES it actually DO? :-)
1334172720 M * Bertl_oO exactly that, i.e. there is a flag, called single_ip
1334172736 M * Bertl_oO this network context flag controls special casing for single ip guests
1334172767 M * Bertl_oO i.e. * (0.0.0.0) gets mapped to the single ip assigned to the guest (at bind time)
1334172807 M * _Shiva_ see: i have a guest that has two IPs on two interfaces - like the host... but my guest originating packets carry the wrong IP..
1334172845 M * _Shiva_ i'm able to work around that in the host - using a SNAT iptables
1334172851 M * Bertl_oO with two or more guest IPs the single_ip special casing isn't enabledat all
1334172866 M * Bertl_oO the solution to a multi homed guest is in proper routing tables
1334172889 M * Bertl_oO i.e. normal linux setup for multihomed systems (with source based routing)
1334172923 M * _Shiva_ like: iptables -t nat -I POSTROUTING -o vpn -s wrong <wrong ip> -j SNAT --to-source <correct ip>
1334172955 M * _Shiva_ you see - routing table on the host *is* correct - but the guest picks the wrong source ip
1334172979 M * _Shiva_ it's the one from the other interface - facing the other "way out"..
1334172979 M * Bertl_oO that is no routing table, that is an SNAT entry
1334173009 M * _Shiva_ no - i mean it already goes out via the vpn dev
1334173015 M * Bertl_oO routing tables can be seen with 'ip route ls'
1334173028 M * _Shiva_ that's why "-o vpn" matches the packets
1334173069 M * Bertl_oO the setup you have doesn't provide a route for the guest IP you want it to use (inside the guest)
1334173090 M * Bertl_oO otherwise it would already use that source IP
1334173125 M * _Shiva_ it (the guest) does have a correct route for the network via tha correct interface- 
1334173141 M * _Shiva_ as the host has..
1334173148 M * Bertl_oO okay, show me the 'ip route ls' from inside the guest
1334173165 M * Bertl_oO as well as the 'ip a l' to see what interfaces/ips are used
1334173193 M * _Shiva_ from the guest that is?
1334173199 M * Bertl_oO yup
1334173351 M * _Shiva_ http://paste.linux-vserver.org/20793
1334173357 J * Aiken ~Aiken@2001:44b8:2168:1000:21f:d0ff:fed6:d63f
1334173361 M * _Shiva_ and i want to reach 192.168.1.40
1334173403 M * daniel_hozac set a correct network mask and it should work fine.
1334173443 M * Bertl_oO well, yes, the network masks are obbviously wrong
1334173459 M * Bertl_oO but I wonder what IP you expect it to use for 192.168.1.40?
1334173506 M * Bertl_oO the guest has no IP in the 192.168.1 network, and the route doesn't suggest any either
1334173541 M * Bertl_oO the default route suggests indirectly the 78.46.99.2 source IP, which isn't assigned to the guest, so no option
1334173549 M * _Shiva_ Bertl_oO: the route says: 192.16.1.0/24 dev mesh
1334173559 M * Bertl_oO if everything works as expected, the first IP assigned to the guest will be used
1334173568 M * _Shiva_ so imho it shoud pick mesh's address
1334173654 M * _Shiva_ and that's what I've said: the packet already pich the right routing turn while going out on dev "mesh"
1334173676 M * _Shiva_ but with the official IP of eth0 as source
1334173689 M * _Shiva_ s/pich/picks/
1334173691 M * Bertl_oO yes, but no guest IP is available in the given networks
1334173754 M * Bertl_oO the guest has two networks consisting of a single IP, none of them are involved in the routing tables actually used
1334173770 M * _Shiva_ correct - but i do not have an IP of that net - that net is reachable via routing...
1334173818 M * _Shiva_ setting the iptabls-SNAT rule above - everything is ok
1334173831 M * _Shiva_ so routing actualy *does* work
1334173840 M * Bertl_oO yes, but the guest can only select from guest IPs
1334173850 M * Bertl_oO (for the source IP)
1334173859 M * daniel_hozac most likely everything would just work if you just fixed your network masks.
1334173880 M * daniel_hozac at least if the host picks an address in the desired range when you use that.
1334173889 Q * ensc|w Ping timeout: 480 seconds
1334173897 M * _Shiva_ than again, why does'nt it take the first address of the dev it's going to take the route out..?
1334173934 M * Bertl_oO because the design says, in case of doubt, use the first IP
1334174009 M * daniel_hozac and interfaces are never really considered
1334174020 M * daniel_hozac in Linux.
1334174100 M * _Shiva_ daniel_hozac: the host also has an IP in that /24 range - that's why i picked a /32 prefix for the guest
1334174122 M * Bertl_oO which was a bad decision
1334174212 M * _Shiva_ correct - i've just changed it into /24 - and it works w/o the SNAT rule... doh!
1334174287 M * _Shiva_ thanks
1334174294 M * Bertl_oO np
1334174310 M * _Shiva_ (i wonder what will brake now..) ;-)
1334174329 J * ensc|w ~ensc@www.sigma-chemnitz.de
1334176102 Q * petzsch Quit: Leaving.
1334176826 Q * clopez Ping timeout: 480 seconds
1334178241 M * Bertl_oO off to bed now ... have a good one everyone!
1334178246 N * Bertl_oO Bertl_zZ
1334178654 Q * nicholi Quit: leaving
1334178709 J * hparker_lappie ~hparker@2001:470:1f0f:32c:beae:c5ff:fe01:b647
1334178712 Q * hparker_lappie Read error: Connection reset by peer
1334179128 J * clopez ~clopez@82.25.60.213.dynamic.mundo-r.com
1334180174 Q * bonbons Quit: Leaving
1334181438 Q * ghislain1 Quit: Leaving.
1334185186 Q * dowdle