Hi everyone,
I have decided to venture down what I hope is a well trodden path by now;
upgrading my VPS from Debian Lenny to Squeeze.
I have scoured the list archives and tried to make the most of
http://www.debian.org/releases/squeeze/i386/release-notes/ch-upgrading.en.h…
however I'm not ashamed to admit that I'm no expert in this regard and
very much still learning so would appreciate a critique of my plan of
action:
- Ask Support kindly to perform a temporary disk snapshot
- Login via Xen console
- Verify no pending actions required for currently installed packages:
aptitude (Then hit 'g' once in 'visual mode')
- Verify that all packages are in an upgradable state:
dpkg --audit
- Show currently installed kernel(s):
dpkg -l | grep linux-image
Mine currently shows:
ii linux-image-2.6-xen-686 2.6.26+17+lenny1 Linux 2.6 image on
i686, oldstyle Xen suppor
ii linux-image-2.6.26-1-xen-686 2.6.26-13lenny2 Linux 2.6.26
image on i686, oldstyle Xen sup
ii linux-image-2.6.26-2-xen-686 2.6.26-26lenny2 Linux 2.6.26
image on i686, oldstyle Xen sup
- Confirm non-usage of grub2:
dpkg -l | grep grub
Mine currently shows:
ii grub 0.97-47lenny2 GRand Unified Bootloader (Legacy version)
ii grub-common 1.96+20080724-16 GRand Unified Bootloader, version
2 (common
- Updates apt sources lists from lenny to squeeze:
sed -i s/lenny/squeeze/g /etc/apt/sources.list
- Manually edit /etc/apt/source.list to confirm success of the above step
and comment out any other repositories (non-Debian, backports etc) ?
- Upgrade the kernel: (*** Am I aiming for the right one here? ***)
aptitude install linux-image-2.6-686-bigmem
- Update grub configuration:
update-grub
- Remove clocksource=jiffies from kopt directive in /boot/grub/menu.lst
and confirm correct kernel will be loaded (i.e. default # matches new
kernel position)
- Upgrade udev (to minimise the risk of running the old udev with the new
kernel):
apt-get install udev
- Reboot
- Record a transcript of the upgrade session:
script -t 2>~/upgrade-squeeze.time -a ~/upgrade-squeeze.script
(This can be reviewed at a later date with scriptreplay
~/upgrade-squeeze.time ~/upgrade-squeeze.script)
- Update the package list:
apt-get update
- Perform a minimal upgrade (i.e. upgrade those packages that don't
require installation/removal of any other package(s)):
apt-get upgrade
- Complete the rest of the upgrade:
apt-get dist-upgrade
- Remove old/obsolete packages no longer required:
apt-get autoremove
- (Hopefully:) After the dust settles, advise Support that the snapshot of
the old system can be removed
Hope does that all look? Please don't hold back...
Regards,
Mathew
Hi,
I was hoping to only mention this much closer to the time when it
could actually happen, but a few people have been asking about this
so I thought it was only fair to give an update.
TL;DR version:
We're planning to soon double the amount of RAM offered for the
current price. You'll be contacted individually when this can
happen; hopefully it just happens, but if you're unlucky then you
might need to be migrated or keep the same amount of RAM for a lower
price instead. Do not panic. You can stop reading now. :)
Longer version:
For a while now it has been clear to us that BitFolk has fallen
behind its competitors in how much RAM we offer for a given price
point, and I wanted to reassure you that I have been taking steps to
remedy this. These have included:
- 56GiB of RAM installed across several machines at the recent
maintenance at the end of February.
- Ongoing migration of all customers off of dunkel.bitfolk.com so
that some non-urgent hardware maintenance and a RAM upgrade can be
done.
- New server with 48GiB RAM being prepared for colo now.
We are hoping to double the RAM allocation for the same price, i.e.
the smallest VPS will come with 480MiB RAM and additional RAM may be
purchased 240MiB at a time.
We could of course just offer this right now to new customers, but I
really dislike it when existing customers are not offered the same
deal as new, even if it does make some business sense to chase the
new. So, I'm holding back from doing that until I know it will be
possible to apply the upgrade to the majority of existing customers.
I can't give any firm timescale for this right now; it's going to
happen as soon as possible.
For many customers this is all going to be very simple; you'll
receive an email that says "congrats, shut down and boot again to
enjoy twice as much RAM". That's it. Unfortunately for some of you
it's not going to be possible to "just do it".
Some of you will be on hosts that cannot be economically upgraded.
8GiB DDR2 DIMMs are stupidly expensive; it's cheaper to buy new
machines with 8GiB DDR3. Here's how it's going to work:
Customers with 240 or 360MiB RAM will be upgraded first. That's
because 240 and 360MiB plans won't be available to new customers
afterwards. If we can't upgrade you because the host is out of
RAM then you will be offered migration[1] to a host that does have
enough RAM. If there's no host available with enough RAM then you
will remain with the same amount of RAM and your future renewals
will be cheaper, however we will upgrade you to at least 480MiB RAM
as soon as we can and you will have no choice in this.[2]
Next, customers with 480MiB or more RAM will be upgraded. If we
can't upgrade you then you'll stay with the RAM you have, at the
lower cost.[3]
As soon as we start upgrading people, the new plans will be
available to new customers, although we may run out of capacity
quickly due to upgrading existing customers. Once this happens,
please don't try to cancel your monthly contract and sign up again
to get the extra RAM quicker; I would hope to have upgraded everyone
that I can within a couple of days of starting. :)
As usual if anyone wants to downgrade then they will be free to do
so from their next contract renewal.
However, if:
- you currently have 480MiB or more of RAM *and*;
- you know you don't need twice as much as you have now *and*;
- you're definitely going to ask to be downgraded back towards what
you started with;
then it would be helpful if you could email support(a)bitfolk.com with
your VPS account name and the amount of RAM you'd like to end up
with. We *may* be able to both downgrade you (and give you some
service credit back) and use that RAM to give to someone else. No
promises though; you may have to wait until your next renewal as
normal.
If you have any questions about all this then please just hit reply
to direct them to the users list, or send an email to
support(a)bitfolk.com if you'd rather discuss off-list.
Cheers,
Andy
[1] Migrating your VPS between hosts will require us to shut it down
and then boot it up again, with something like 5-10 minutes of
downtime in between. If a migration is necessary then we'll
contact you individually to co-ordinate the work.
[2] While you may be satisfied that 240 or 360MiB RAM is adequate
for you, I don't want to keep lots of custom plans going and I
don't want to bill below £8.99/mo if possible.
[3] e.g. If you're on 480MiB RAM, 10GiB disk, 100GB/mo data transfer
then that currently costs £13.99/mo. If we couldn't upgrade you
to 960MiB RAM then you will remain on 480MiB but the plan will
only cost you £8.99/mo from your next renewal.
--
http://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
> From: Martin Meredith <mez(a)ubuntu.com>
> Sky broadband DO actively block VoIP. I bought this up with them and
> they faffed around the issue until I went away.
>
I am visiting the UK at the moment and am a guest at house with Sky
broadband and have had no problems at all with Skype - well apart from
all the usual ones :) If Sky do actively block Skype they don't seem
to be very successful.
Steve
Hi All,
I ran a port scan on my own server out of curiosity and noticed
something quite out of place...
Not shown: 996 closed ports
PORT STATE SERVICE
22/tcp open ssh
53/tcp open domain
80/tcp open http
1720/tcp filtered H.323/Q.931
22,53 and 80 are the ones which should be open, so what on earth is
1720? I have tried to locate the process behind it..."lsof -Pni :1720"
brings nothing back and "netstat -tulpn" is also not bringing anything
up, there is also nothing in iptables (I haven't got round to setting
it up yet). Is it something in the Bitfolk network? Just want to know
what it is really..
Daniel
Hello,
We had a support ticket earlier where a customer with 480MiB RAM is
only seeing 464MiB of it as reported by "free -m".
Now, I suspect this is not a new thing, and has only been noticed by
them because the ongoing RAM upgrades made them take an interest in
how much RAM they actually have.
I've had a look at many of my own (Debian) VMs and they all see
exactly as much RAM as they have been assigned.
I've mentioned this on IRC and a few other people also see slightly
less RAM than they have been assigned. Most so far appear to be
using Ubuntu, though there are some with Debian who are missing a
few MiB of RAM too.
It's not a big deal and I'm not asking you to let me know if you do
or don't see it too (there's currently nothing I can do about it). I
was just wondering if anyone knows where it goes? Perhaps some
kernel feature that eats up to 20MiB RAM, which I don't have
enabled?
My own kernels are 32bit PAE, so I don't think it's a PAE thing.
Cheers,
Andy
I guess it would help if I send the email to the entire list not just
one person :P
Original message:
> On Mon, 2011-06-20 at 12:40 +0200, Ole-Morten Duesund wrote:
> *snip*
> > My debian (sqeeze) says :
> > $ uname -a
> > Linux for 2.6.32-5-686-bigmem #1 SMP Tue Mar 8 22:14:55 UTC 2011 i686
> > GNU/Linux
> *snip*
>
> On my CentOS VM (a 2.6.18 kernel), free -m shows the correct amount of
> RAM. On the other hand, my desktop running Fedora 15 (2.6.38) shows that
> I'm missing 40MB:
>
> [moggers@delta6thc ~]$ free -m
> total used free shared buffers cached
> Mem: 2008 1299 709 0 84 594
> -/+ buffers/cache: 621 1387
> Swap: 3839 0 3839
>
> I'm just wondering if we've always had this "lost" RAM, but only recent
> kernels show it.
>
> M
>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi
Since pretty much everybody with a VPS which runs Lenny has asked about
the upgrade to Squeeze, I have added my own upgrade notes to the Bitfolk
wiki:
https://tools.bitfolk.com/wiki/Upgrading_your_Debian_VPS_from_Lenny_to_Sque…
I'm not sure how many people are left still to perform the upgrade, but
those of you who have already done so, please give it the once over and
add your own notes or clarify any details you feel I may have missed.
Regards,
Adam Sweet
- --
http://blog.adamsweet.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk37OIAACgkQRi1ZcmvD37dKBwCfZpEW/izGYsEBiKjdWCRnEynu
oScAoLppv0px2Lo7jGwPVAUgdbniLzSb
=V5qR
-----END PGP SIGNATURE-----
On 15 June 2011 15:03, Michael Stevens <mstevens(a)etla.org> wrote:
> On Wed, Jun 15, 2011 at 01:55:50PM +0000, Isabell Long wrote:
>> Hi,
>>
>> On Wed, Jun 15, 2011 at 02:02:42PM +0100, Michael Stevens wrote:
>> > Feature request/idea/whatever:
>>
>> You can submit a feature request at https://tools.bitfolk.com/redmine,
>> for future reference. But thanks all the same - here on the mailing list
>> may well generate more discussion. :-)
>
> Customer documentation at
> http://www.bitfolk.com/customer_information.html informs me:
>
> "If you have any feature requests we'd love to hear about them, either
> directly to support or discussed on the users mailing list."
>
> I vaguely remembered redmine existed from a previous mention, but a
> quick hunt didn't find it, and *did* find encouragement to post here.
>
> So here we are!
I wasn't complaining, but simply informing. :-)
Isabell.
Hi,
On Wed, Jun 15, 2011 at 02:02:42PM +0100, Michael Stevens wrote:
> Feature request/idea/whatever:
You can submit a feature request at https://tools.bitfolk.com/redmine,
for future reference. But thanks all the same - here on the mailing list
may well generate more discussion. :-)
> It'd be nice if we could see the progress of our tickets online. Since
> it like it's RT, I guess I'm suggesting we should have access to the RT
> web UI?
In my experience[1], tickets are dealt with promptly and communication
is strong, possibly negating the need for a "ticket tracking" system. I
can, however, see a benefit to tracking your support ticket: for
reorganisation of VPSes, or progress of orders, for example.
[1] To avoid problems, I should note here that my response is based on tickets I
have submitted, not ones I have responded to in my role as support
assistant.
Regards,
Isabell.
I've updated the debian OS on my VM from Lenny to Squeeze, unfortunately
I've run into an issue with grub:
# update-grub
Searching for GRUB installation directory ... found: /boot/grub
warning: grub-probe can't find drive for /dev/xvda1.
grub-probe: error: cannot find a GRUB drive for /dev/xvda1. Check your
device.map.
# cat /boot/grub/device.map
(hd0) /dev/xvda
# ls -l /dev/xvda*
brw-rw---- 1 root disk 202, 0 Jun 11 19:02 /dev/xvda
brw-rw---- 1 root disk 202, 1 Jun 11 19:02 /dev/xvda1
My O/S is basically upgraded; I started by updating the kernel and libc
and bits, and was able to reboot into that. So, hopefully, my VM would
still reboot at this point. But, for some reason, once I had done the
full dist-upgrade the grub-update stopped working.
Has anyone seen anything like this? Is there something else I should be
checking? I went through the previous list mail on the squeeze update
and I don't see anything that was missed.
Thanks
Alex.
--
This message was scanned by Better Hosted and is believed to be clean.
http://www.betterhosted.com
