Re: Frustration over Debian naming (was: Re: Meltdown fix for wheezy-backports)
On Fri, 2018-01-12 at 13:54 +, Holger Levsen wrote: > On Fri, Jan 12, 2018 at 08:49:05AM -0500, rhkra...@gmail.com wrote: > > But the various names and use of those names gets very frustrating > > for me, and > > I suspect I am not the only one. The numbered versions, the Toy > > Story names, > > and then the testing, stable, old stable, old old stable is just > > frustrating. > > > https://en.wikipedia.org/wiki/Debian_version_history explains this > nicely and is linked from https://en.wikipedia.org/wiki/Debian I took their point to be that if one needs a wiki page to follow the versioning scheme then perhaps the versioning scheme has an issue. IIRC teams like the Press Team have a policy of always leading with the numerical version rather than the code names, presumably for this very reason, but that doesn't carry over into "casual" conversation like the parent thread or the repo urls etc. Ian.
Re: Bug report - ext4: Unknown symbol __getblk_gfp (err 0)
On Thu, 2016-02-18 at 13:18 +0100, Miroslav Svoboda wrote: > [...] > Linux 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01) x86_64 GNU/Linux > > [...] > Any idea what is the problem? Your local vmlinux and initrd binaries are out of sync with the kernel modules in the mirror network, due to the kernel update in the latest point release. i.e. you need to update the binaries on your PXE server to deb8u2. The current Jessie kernel is now 3.16.7-ckt20-1+deb8u2. Ian.
Re: [Pkg-xen-devel] Recent hypervisor update on Debian Wheezy breaks domU networking
On Mon, 2013-02-18 at 12:04 +0200, Gavin wrote: Firstly I apologise for the cross-post, I've added xen-users since you also bounced this there. however I don't expect to get as quick a response from the package maintainers as I do from the Debian community, and this issue affects a service that I've got scheduled to go live at midnight this evening. :( A recent update from xen-hypervisor-4.1-amd64 version 4.1.3-7, to version 4.1.3-8 on Debian Wheezy has caused all vm's on this host to not receive their arp replies anymore and as such they cannot reach their gateways and are now isolated from the network. There was a more recent update as well (4.1.4-2) which I have now since applied however this particular issue persists. Networking level stuff is all done by the dom0 (or driver domain) kernel rather than the hypervisor so it is far more likely that a kernel level change rather than a hypervisor change would be responsible. What kernel version are you running? Did it also change? The arp replies are received by the host and passed all the way up to the bridge (br200) being used by Xen, however they are not seen on the vif (vif2.0) created for the particular vm. Do you have any firewall or ebfilter entries which might have either been discarded or reintroduced by the reboot? (i.e. a manual settings modification which wasn't propagated to the startup scripts). Or perhaps sysctl tweaks? 1) Please let me know if I should roll-back this particular xen update, kernel and all, and what those steps may be, or if this is a known issue with a particular workaround that I can apply. I'd certainly be tempted to try the older kernel, assuming that was also upgraded. It may even still be installed and in your grub menu already. 2) Would moving to openvswitch be another possible workaround? Without knowing what the underlying issue is it is hard to predict whether it will also affect ovs. My config:- Looks correct to me. Ian. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1361184601.31407.144.ca...@zakaz.uk.xensource.com
Re: [Xen-users] [Pkg-xen-devel] Recent hypervisor update on Debian Wheezy breaks domU networking
On Mon, 2013-02-18 at 13:51 +, Gavin wrote: I managed to get iDRAC console access and on further inspection it appears that grub first boots xen-4.1-amd64.gz and then the Linux kernel. Correct. When I updated the Xen Hypervisor does it not also upgrade the xen-4.1-amd64.gz file ?? Yes. Unless the version number changes in which case you get a new file in addition to the older version, but that doesn't apply here. Are there any better ways to trace where this arp reply is being lost apart from just tcpdump ? tcpdump is what I would use. stumped! / If the kenrel hasn't changed and you are 100% sure the network configuration before and after the reboot is the same then so am I. All I can suggest is to reinstall the previous version of Xen. Ian. -- Ian Campbell Current Noise: Karma To Burn - Thirty Five America, how can I write a holy litany in your silly mood? -- Allen Ginsberg -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1361197937.32047.13.ca...@zakaz.uk.xensource.com
RE: sshd reverse resolving - takes too long to login
I think it sshd -u0 -Original Message- From: Mike Tone [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 29, 2002 10:39 PM To: [EMAIL PROTECTED] Subject: sshd reverse resolving - takes too long to login is there a way to stop sshd from attempting to reverse resolve the connecting client? i can see no doco on openssh.org sshd is woody current (3.4p1 from deb) - NEW to mBox, receive faxes to any email address! Find out more http://www.mbox.com.au/fax -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
