I was too busy to upgrade one of my VPS to Buster the other week. Also the
email from Andy reminded me that I have not converted that one to 64 bit.
So I decided to kill 2 birds with one stone.
First, into Xen shell and type in arch x86_64
That went nice and easy and Xen now tells me that I am operating in 64 bit
mode and that the bootloader can only boot x86_64 guests
Great. Prepare for upgrade to Buster, the press the go button. Chugging
through the upgrade process I see that it is all 32 bit packages being
installed. I thought Xen by some internal magic changed what I could
download. Well Kernel wise really
When all finished and a reboot done (a totally problem free upgrade by the
way) I ran lscpu
~# lscpu
Architecture: i686
CPU op-mode(s): 32-bit
Byte Order: Little Endian
OK I should have done some step earlier on in the process which I didn't -
maybe install a 64 bit kernel and rebooted, or something.
Showing my ignorance here I know, but I seem to remember when doing it on
my other VPS it was as simple as do the arch command on xen then just
update/upgrade
What have I missed, please?
Hi all, sorry it's me with a problem. Last night I did a complete reinstall
of the OS. I am running Stretch 64 bit.
I had some troubles with Bind not updating slaves, It said it was not
authoritative. Googled for remedies, tried them all out (will list what I
did in a minute.
No luck so purged and reinstalled Bind, then manually entered a single
zone, restarted Bind. The logs showed this:-
zone keiths-place.co.uk/IN: sending notifies (serial 2019072335)
zone 31.172.in-addr.arpa/IN: sending notifies (serial 1)
zone 127.in-addr.arpa/IN: sending notifies (serial 2)
zone 27.172.in-addr.arpa/IN: sending notifies (serial 1)
zone 255.in-addr.arpa/IN: sending notifies (serial 1)
zone 0.in-addr.arpa/IN: sending notifies (serial 1)
client 85.119.84.35#35865 (keiths-place.co.uk): bad zone transfer request:
'keiths-place.co.uk/IN': non-authoritative zone (NOTAUTH)
client 85.119.80.222#59271 (keiths-place.co.uk): bad zone transfer
request: 'keiths-place.co.uk/IN': non-authoritative zone (NOTAUTH)
client 85.119.80.198#10938 (keiths-place.co.uk): query '
keiths-place.co.uk/SOA/IN' denied
client 85.119.80.198#49851 (keiths-place.co.uk): bad zone transfer
request: 'keiths-place.co.uk/IN': non-authoritative zone (NOTAUTH)
So you will need to see the conf files
/etc/bind/named.conf.local
// Consider adding the 1918 zones here, if they are not used in your
// organization
include "/etc/bind/zones.rfc1918";
zone "keiths-place.co.uk" {
type master;
file "/var/lib/bind/keiths-place.co.uk.hosts";
allow-query {
85.119.84.35;
85.119.80.222;
2001:ba8:1f1:f085::53;
2600:3c01:e000:259::53;
45.33.107.124;
172.104.29.216;
2600:3c03::31:2153;
2001:ba8:1f1:f309::2;
127.0.0.1;
};
check-names warn;
notify yes;
};
in frustration I added all the possible slaves and localhost to allow-query
Named.conf
acl slaves {
85.119.84.35; 2001:ba8:1f1:f309::2;
};
// This is the primary configuration file for the BIND DNS server named.
//
// Please read /usr/share/doc/bind9/README.Debian.gz for information on the
// structure of BIND configuration files in Debian, *BEFORE* you customize
// this configuration file.
//
// If you are just adding zones, please do that in
/etc/bind/named.conf.local
include "/etc/bind/named.conf.options";
include "/etc/bind/named.conf.local";
include "/etc/bind/named.conf.default-zones";
and finally named.conf.options
options {
directory "/var/cache/bind";
// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk. See http://www.kb.cert.org/vuls/id/800113
// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.
forwarders {
8.8.8.8;
};
//========================================================================
// If BIND logs error messages about the root key being expired,
// you will need to update your keys. See
https://www.isc.org/bind-keys
//========================================================================
dnssec-validation auto;
auth-nxdomain yes; # conform to RFC1035
listen-on-v6 { any; };
check-names master warn;
check-names slave warn;
allow-query {
85.119.84.35; 2001:ba8:1f1:f309::2;
};
also-notify {
85.119.84.35; 2001:ba8:1f1:f309::2;
};
notify yes;
forward first;
};
And just for good measure the zone file
$ttl 38400
keiths-place.co.uk. IN SOA ns3.keiths-place.co.uk.
keithwilliamsnp.gmail.com. (
2019072335
10800
3600
604800
38400 )
keiths-place.co.uk. IN A 85.119.82.237
www.keiths-place.co.uk. IN A 85.119.82.237
ns3.keiths-place.co.uk. IN A 85.119.82.237
mail.keiths-place.co.uk. IN A 85.119.84.35
ns1.keiths-place.co.uk. IN A 85.119.84.35
ns2.keiths-place.co.uk. IN A 85.119.82.237
webmail.keiths-place.co.uk. IN A 85.119.82.237
keiths-place.co.uk. IN MX 10 keynesmail.com.
keiths-place.co.uk. IN TXT "v=spf1 mx redirect=keynesmail.com"
keiths-place.co.uk. IN AAAA 2001:ba8:1f1:f29d::2
mail.keiths-place.co.uk. IN AAAA 2001:ba8:1f1:f309::2
ns1.keiths-place.co.uk. IN AAAA 2001:ba8:1f1:f309::2
ns2.keiths-place.co.uk. IN AAAA 2001:ba8:1f1:f309::2
webmail.keiths-place.co.uk. IN AAAA 2001:ba8:1f1:f309::2
ns3.keiths-place.co.uk. IN AAAA 2001:ba8:1f1:f29d::2
www.keiths-place.co.uk. IN AAAA 2001:ba8:1f1:f29d::2
keiths-place.co.uk. IN NS a.authns.bitfolk.com.
keiths-place.co.uk. IN NS b.authns.bitfolk.com.
keiths-place.co.uk. IN NS c.authns.bitfolk.com.
keiths-place.co.uk. IN NS ns3.keiths-place.co.uk.
Following "solutions" on Google, I checked all permissions, checked
apparmor (no file for bind there) added all possible slaves to allow-query,
checked firewalls. And read all I could find on Bind. Though I have been
running the 2 bind servers for years and they always just seemed to work.
Sorry, should have said, running Bind 9.11
Keith
Hi All,
I have just done a "sudo apt-get update" and "sudo apt-get upgrade" and
got the following messages on the screen.
update-initramfs: Generating /boot/initrd.img-4.15.0-54-generic
update-initramfs: Generating /boot/initrd.img-4.15.0-52-generic
depmod: WARNING: could not open
/var/tmp/mkinitramfs_hecyM2/lib/modules/4.15.0-5
2-generic/modules.order: No such file or directory
depmod: WARNING: could not open
/var/tmp/mkinitramfs_hecyM2/lib/modules/4.15.0-5
2-generic/modules.builtin: No such file or directory
update-initramfs: Generating /boot/initrd.img-4.15.0-50-generic
update-initramfs: Generating /boot/initrd.img-4.15.0-48-generic
depmod: WARNING: could not open
/var/tmp/mkinitramfs_1XbniU/lib/modules/4.15.0-4
8-generic/modules.order: No such file or directory
depmod: WARNING: could not open
/var/tmp/mkinitramfs_1XbniU/lib/modules/4.15.0-4
8-generic/modules.builtin: No such file or directory
update-initramfs: Generating /boot/initrd.img-4.15.0-47-generic
update-initramfs: Generating /boot/initrd.img-4.15.0-46-generic
depmod: WARNING: could not open
/var/tmp/mkinitramfs_acPqsQ/lib/modules/4.15.0-4
6-generic/modules.order: No such file or directory
depmod: WARNING: could not open
/var/tmp/mkinitramfs_acPqsQ/lib/modules/4.15.0-4
6-generic/modules.builtin: No such file or directory
update-initramfs: Generating /boot/initrd.img-4.15.0-45-generic
depmod: WARNING: could not open
/var/tmp/mkinitramfs_bPQxlw/lib/modules/4.15.0-4
5-generic/modules.order: No such file or directory
depmod: WARNING: could not open
/var/tmp/mkinitramfs_bPQxlw/lib/modules/4.15.0-4
5-generic/modules.builtin: No such file or directory
update-initramfs: Generating /boot/initrd.img-4.4.0-116-generic
WARNING: missing /lib/modules/4.4.0-116-generic
Ensure all necessary drivers are built into the linux image!
depmod: ERROR: could not open directory /lib/modules/4.4.0-116-generic:
No such file or directory
depmod: FATAL: could not search modules: No such file or directory
depmod: WARNING: could not open
/var/tmp/mkinitramfs_B46ktb/lib/modules/4.4.0-11
6-generic/modules.order: No such file or directory
depmod: WARNING: could not open
/var/tmp/mkinitramfs_B46ktb/lib/modules/4.4.0-11
6-generic/modules.builtin: No such file or directory
update-initramfs: Generating /boot/initrd.img-4.4.0-112-generic
WARNING: missing /lib/modules/4.4.0-112-generic
Ensure all necessary drivers are built into the linux image!
depmod: ERROR: could not open directory /lib/modules/4.4.0-112-generic:
No such file or directory
depmod: FATAL: could not search modules: No such file or directory
depmod: WARNING: could not open
/var/tmp/mkinitramfs_gDoz9s/lib/modules/4.4.0-11
2-generic/modules.order: No such file or directory
depmod: WARNING: could not open
/var/tmp/mkinitramfs_gDoz9s/lib/modules/4.4.0-11
2-generic/modules.builtin: No such file or directory
Setting up apache2 (2.4.29-1ubuntu4.8) ...
Processing triggers for initramfs-tools (0.130ubuntu3.8) ...
update-initramfs: Generating /boot/initrd.img-4.15.0-54-generic
ian@hobsoni:~$
I am using the standard Ubunutu 18.04 LTS kernel and software.
What do these warnings and errors mean? Can I safely ignore them? And if
not, how can I fix?
Regards
Ian
--
Ian Hobson
Tel (+351) 910 418 473
[Redirected back to the list with permission.]
Hi David,
I should stress again that crossgrading between 32- and 64-bit is
not officially support by Debian/Ubuntu nor BitFolk. It does however
work, multiarch is supported by these distros, I've done it a bunch
of times and so have other customers.
The worst thing that happened to me was that one time I accidentally
let it remove /bin/rm, and I had to scp in a /bin/rm from another
host before dpkg would work again (it requires a working rm
command!). Removing coreutils is not a good plan, for future
reference. :-)
The basic procedure is described here:
https://wiki.debian.org/CrossGrading
The only BitFolk-specific issue is the architecture of the
bootloader that we use to boot your VM. You have to tell us whether
it should be 32-bit or 64-bit. You do that by using the "arch"
command in the Xen Shell.
Going by that page, you would use the Xen Shell "arch" command
after you install the 64-bit (amd64) kernel but before you reboot.
This is step 2 ("Install a kernel that supports both architectures
in userland") in that article.
Assuming your VM then boots 64-bit into the amd64 kernel, you could
stop there. You would be running a 64-bit operating system and
kernel but all your apps would still be 32-bit and anything new you
install would be 32-bit as well.
I think it's unlikely that anything too weird would happen if you
carried on like this.
You could take it a step further, which is step 4 ("Crossgrade
`dpkg` `tar` and `apt`"). That involves downloading the .deb files
for the 64-bit versions of those packages and installing them
forcibly with dpkg. After you've done that your default architecture
would be amd64 so everything new you install would be amd64, while
all your existing stuff that is i386 still works.
Leaving things in this state I've seen some confusion happen at
later package upgrades. Things being upgraded or installed in future
sometimes need to pull in amd64 versions of things already
installed, and apt wants to ask you if you are really sure about
that. So expect some ongoing work.
If you are brave you could go the whole way of listing everything
installed and replacing it with its amd64 counterpart. This is the
really tricky thing to do, as apt won't like you trying to remove
essential things (even though you are only doing it to immediately
replace them) and it will come up with some very odd suggestions
that also involve removing most of your system.
Most times I have tried this involved repeatedly issuing commands
like:
# apt remove blah:i386 blah:amd64+ coreutils:amd64+
and seeing what it suggests, before letting it or hitting 'n' and
trying again.
Note the '+' on the end of some of the package names. This is apt
syntax for "Please remove package blah but also install amd64
architecture of package blah and also keep coreutils installed too".
You do this when apt wants to remove something that you really don't
want it to remove, to tell it to try again with a different plan.
If this sounded scary, or you aren't familiar with doing this sort
of thing, you probably should not try this. Just reinstall. Or keep
going with a 64-bit kernel and 32-bit userland.
The other thing I would say is, make sure you are familiar with how
to use the Xen Shell to start, stop, destroy (power yank) your VPS
and access its console. It is totally mad^W^Wextremely unwise to
consider trying to change the architecture of your running VPS
without having offline access to its console, yet I have had to
rescue a few people who gave it a go and then were flummoxed when
their only problem was that grub was waiting for them to choose
which kernel to boot.
Of course, if you don't fancy doing any of that, the offer of a free
VPS for 2 weeks to migrate into is always there.
https://tools.bitfolk.com/wiki/Migrating_to_a_new_VPS
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hi,
Those running 32-bit VMs who haven't thought about
upgrading/reinstalling them to 64-bit yet, please have a read of:
“There are no current plans to remove support for 32bit PV
guests from Xen, but it is very much in the category of "you
shouldn't be using this mode any more".”
https://lists.xenproject.org/archives/html/xen-devel/2019-07/msg00827.html
When Juergen asked for feedback on removing 32-bit guest support a
year or two ago I told him that (at the time) more than 60% of
BitFolk's user base was 32-bit and they'd need time to transition.
Now that there is a stable grub release which supports PVH¹ booting
Juergen is pushing this again and it will eventually go through to
the Linux kernel.
When Xen does remove 32-bit PV mode we can still continue to support
32-bit guests in PVH mode or HVM mode, so I will still make sure it
works without customers having to do anything. But you should be
clear that just because it will work doesn't mean it is a good idea!
I have a round of updates to do and then I will start moving
customers over to PVH mode where possible (requires 4.11+ kernel in
guest).
Cheers,
Andy
¹ PVH mode guests run all the normal code paths of a kernel not
under virtualisation except for their IO drivers like networking
and block devices which are still paravirtualised for performance
reasons. This results in a kernel that has a smaller attack
surface as there is much less xen-specific code being used, it's
faster and simpler. It also still doesn't require use of qemu on
BitFolk's side. See:
https://wiki.xen.org/wiki/Understanding_the_Virtualization_Spectrum
for more information.
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hello,
I wrote a thing about the different options for handling boot-time
entropy on distributions that may be affected such as Debian 10
(buster).
TL;DR: By default the CPU's RDRAND instruction is used so you won't
notice anything and don't need to care unless you believe that Intel
is a pawn of the US government, in which case maybe you want to
disable it.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
Hello Folks,
I hope this question is OK to ask here. Before doing some research and digging elsewhere, I thought I might tap thoughts here.
I currently work for a small software company based in Poplar, London (Poplar Business Park) but will be leaving in a month for new pastures. We only have a few software engineers and support people now - about 5. With me leaving, there is no Linux experience left in the company and there are a few servers and services that may need watcing and support. So, considering options, I am thinking of seeing if an external third-party could do the occasional Linux server support, on call, email support, visit if required etc. I don't think the workload will require any full-time position.
Does anyone here have any recommendations on a Linux Support service - company or person? If so, feel free to contact me off-list if preferred.
This is a small office, with small requirements and no rocket science is used..
Servers : ~3 Debian 9 VM's and 1 Debian 9 file server (HP micro,RAID5).
Services : main server is Apache/Mysql/Mercurial repo/ Samba SMB. Others for intranet DNS (dnsmasq), Samba workgroup.
I can share more details later obviously. Most of the stuff just needs to stay available as-is, so we need to cope with a VM or host crash, RAID failure etc.
Any recommendations would be gratefully received.
Cheers,
--
Alastair Sherringham
http://www.sherringham.net
Hi,
Debian 10.0 (buster) was released on Sunday. You can now use the
self-installer to install it. From the Xen Shell type:
xen shell> install debian_buster
If this is not your first install you may wish to check that your
architecture is set to x86_64 (64-bit). If it's 32-bit then you can
change it with:
xen shell> arch x86_64
I recommend that you do switch to 64-bit if you haven't already.
The new Debian testing (bullseye) is also present but is still a
work in progress. We'd still be interested in hearing about any
problems with it.
More info:
https://tools.bitfolk.com/wiki/Using_the_self-serve_net_installerhttps://tools.bitfolk.com/wiki/Xen_Shell
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
Hello,
Debian 10 (buster) is supposed to be released later today. Those who
wish to upgrade to it in the usual Debian way should be able to do
so after reading the release notes for any gotchas:
https://www.debian.org/releases/testing/amd64/release-notes/
I am not aware of any gotchas that are specific to the BitFolk
environment, but if you think you have found one please do let us
know.
If planning a clean install, the "buster" release has been available
for some time in our Xen Shell, but under the code name
"debian_testing", because right now it still is technically the
testing release.
If you issue the command:
xen shell> install debian_testing
now or at any time after the release of Debian 10 then I believe
this should result in a working install of Debian 10. I just tested
it with a minimal install (base system + openssh) and it seems to
(still) work.
It may be several days after the release before we can get around to
updating the labels in the Xen Shell so that "debian_buster" is there
and "debian_testing" gets you "bullseye". It does tell you what it's
going to install so there should be no confusion.
Cheers,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting
_______________________________________________
announce mailing list
announce(a)lists.bitfolk.com
https://lists.bitfolk.com/mailman/listinfo/announce
---------- Forwarded message ---------
From: Keith Williams <keithwilliamsnp(a)gmail.com>
Date: Sun, 7 Jul 2019 at 14:57
Subject: Re: [bitfolk] The forthcoming Debian 10.0 (buster) release
To: Hugo Mills <hugo-bf(a)carfax.org.uk>
I was reading in the pages and pages of guidance notes that there can be a
problem with entropy starvation, even to the extent of SSH not working
properly. Debian recommend doing a lot of pings as soon as you can to build
up the entropy. Of course, how you do that during an install is another
matter...
Keith
On Sun, 7 Jul 2019 at 14:06, Hugo Mills <hugo-bf(a)carfax.org.uk> wrote:
> On Sun, Jul 07, 2019 at 01:55:46PM +0100, Keith Williams wrote:
> > Well I have done the upgrade on one VPS. Preparation including backing up
> > all db and /etc/ plus one or two other "just in case" files and
> > uninstalling packages that were never installed from official archives 3
> or
> > 4 hours, upgrade itself few minutes, sorting out problems all the rest of
> > the morning.
> > Problems encountered:-
> > Bind. Over several upgrades I have always kept the old config files. It
> > seems that some ancient deprecated options now throw an error not a
> > warning. systemctl start followed by journalctl -xe details all the
> > problems, even the line numbers in the files so it was a matter of
> minutes
> > to fix
> > Wireguard still seems to need the unstable repository, so changing that
> > back it all worked, the conf file was still there so OK, same could not
> be
> > said of NFTables, had to reload conf file from back up.
> > Then the 3 bigger ones:-
> > Roundcube. During install it said it had to reconfigure the database. I
> > will have to purge, drop that database and reinstall from scratch
> > unfortunately
> > Dovecot. My initial setting up, a few years back took ages (I was
> learning
> > as I went) so I said no to replacing conf files. Had same problem as with
> > Bind, setting which before led to a warning, now stop it from starting.
> > Same trick as before and only one setting to change. The error message
> even
> > tells you what to change it to. I should have heeded the warnings before.
> > But it does mean that although Dovecot is delivering the mail to the
> boxes,
> > I am unable to log onto Postfix as it uses Dovecot to verify credentials.
> > But then my webmail uses Roundcube so I can't get at that mail at the
> > moment anyway
> > Webmin. I use this as a graphical interface when working with big
> databases
> > or updating and cleaning up all my zonefiles. It's just easier. Handy for
> > editing Apache virtual host files. I was able to install it and start it
> > then the connection drops to the miniserv server. I think it is related
> to
> > an upgrading of the perl libraries in the upgrade. Did not have the same
> > with my home boxes a couple of weeks ago. That is non urgent though.
> > Hopefully some lessons learnt so mistakes won't be repeated during
> upgrade
> > of my other VPS tomorrow. Most of these irritations would probably not
> have
> > arisen if I had cleaned up the conf files beforehand.
> > Hope there is something useful there for anyone else upgrading
>
> I'm doing a reinstall from scratch on a new VPS. So far, I haven't
> hit anything awkward (other than not knowing how to set up nginx -- I
> decided to switch from Apache).
>
> My only real issue so far is that writing random data to the 250
> GiB encrypted archive-storage volume took about 6 hours. I'm not sure
> if that's entropy starvation on the randomness, very slow storage, or
> slow CPU doing the encryption. I was doing it in the installer, so I
> didn't have much leeway to investigate deeper.
>
> Hugo.
>
> > Keith
> >
> > On Sat, 6 Jul 2019 at 00:16, Andy Smith <andy(a)bitfolk.com> wrote:
> >
> > > Hello,
> > >
> > > Debian 10 (buster) is supposed to be released later today. Those who
> > > wish to upgrade to it in the usual Debian way should be able to do
> > > so after reading the release notes for any gotchas:
> > >
> > > https://www.debian.org/releases/testing/amd64/release-notes/
> > >
> > > I am not aware of any gotchas that are specific to the BitFolk
> > > environment, but if you think you have found one please do let us
> > > know.
> > >
> > > If planning a clean install, the "buster" release has been available
> > > for some time in our Xen Shell, but under the code name
> > > "debian_testing", because right now it still is technically the
> > > testing release.
> > >
> > > If you issue the command:
> > >
> > > xen shell> install debian_testing
> > >
> > > now or at any time after the release of Debian 10 then I believe
> > > this should result in a working install of Debian 10. I just tested
> > > it with a minimal install (base system + openssh) and it seems to
> > > (still) work.
> > >
> > > It may be several days after the release before we can get around to
> > > updating the labels in the Xen Shell so that "debian_buster" is there
> > > and "debian_testing" gets you "bullseye". It does tell you what it's
> > > going to install so there should be no confusion.
> > >
> > > Cheers,
> > > Andy
> > >
>
> --
> Hugo Mills | One of these days, I'll catch that man without a
> hugo@... carfax.org.uk | quotation, and he'll look undressed.
> http://carfax.org.uk/ |
> PGP: E2AB1DE4 | Leto Atreides,
> Dune
>
