This is a heads-up, not a request for help.

[OT for uk.d-i-y but there are interested people there]


An update for ZFS on Ubuntu 14.04 came out a day or two ago, version 0.6.3-3

It nearly gave me a heart attack as I rebooted and *poing* no ZFS
filesystems.

Luckily I'd done the sane thing and had the OS on a simple FS.

Managed to force load the zpool (which was the bit that was failing) with:

zpool import -f pool0

(or whatever your pool is called)


See here for the gory details:

https://github.com/zfsonlinux/zfs/issues/2927

https://groups.google.com/a/zfsonlin...ss/0QbmxJXZO5Y

In article ,
Tim Watts writes:
This is a heads-up, not a request for help.

[OT for uk.d-i-y but there are interested people there]


An update for ZFS on Ubuntu 14.04 came out a day or two ago, version 0.6.3-3

It nearly gave me a heart attack as I rebooted and *poing* no ZFS
filesystems.

Luckily I'd done the sane thing and had the OS on a simple FS.

Managed to force load the zpool (which was the bit that was failing) with:

zpool import -f pool0

(or whatever your pool is called)


See here for the gory details:

https://github.com/zfsonlinux/zfs/issues/2927

https://groups.google.com/a/zfsonlin...ss/0QbmxJXZO5Y

Looks like it was a deliberate change to stop ZFS automatically
mounting the pools at system start, so something else (systemd)
can do it instead, but that isn't implemented yet. This is going
to be a Linux-specific (or possibly Ubuntu-specific) issue.

--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

On 23/11/14 22:29, Andrew Gabriel wrote:

Looks like it was a deliberate change to stop ZFS automatically
mounting the pools at system start, so something else (systemd)
can do it instead, but that isn't implemented yet. This is going
to be a Linux-specific (or possibly Ubuntu-specific) issue.


The ZFSonLinux mailing list and bug tracker came to the rescue...

for some reason my system (and several other folk I summise) hat an
/etc/hostid file that contained a null host id (4 zero bytes).

This, since 0.6.3-3 seems to have been taken as a sentinel value instead
of a legitimate host ID - so ZFS thought the pool was from a foreign
system and did not want to auto mount it.

Setting the host id, doing a zpool export followed by an import and
updating (regenerating) the initramfs seems to have fixed it.

Your hunch may be right - someone else mentioned systemd.

Rather a bad breakage...

But ultimately, it did not lose any data (only temporarily).

So it's still one up on ReiserFS.

En el artículo , Tim Watts
escribió:

someone else mentioned systemd.

systemd is a pile of ****. It's a pity it's becoming more pervasive,
even CentOS have gone over to the dark side now.

There was nothing wrong with SysV init, why reinvent the wheel?

--
(\_/)
(='.'=)
(")_(")

On 25/11/14 04:46, Mike Tomlinson wrote:
En el artículo , Tim Watts
escribió:

someone else mentioned systemd.

systemd is a pile of ****. It's a pity it's becoming more pervasive,
even CentOS have gone over to the dark side now.

Even? They (well DeadRat) invented systemd

On Mon, 24 Nov 2014 23:46:17 -0500, Mike Tomlinson wrote:

systemd is a pile of ****. It's a pity it's becoming more pervasive,
even CentOS have gone over to the dark side now.
There was nothing wrong with SysV init, why reinvent the wheel?

There was plenty wrong with sysvinit. It was very difficult to get
things to start in the right order, and one third party init script
could totally mess up the the start order. While it was supposed to
take advantage of multiple cores, for parallel starting of things,
it didn't do it well. The chkconfig and lsb headers were rarely done
properly, and often ended up with a loop in dependencies.

Regards, Dave Hodgins

--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)

In article ,
"David W. Hodgins" writes:
On Mon, 24 Nov 2014 23:46:17 -0500, Mike Tomlinson wrote:

systemd is a pile of ****. It's a pity it's becoming more pervasive,
even CentOS have gone over to the dark side now.
There was nothing wrong with SysV init, why reinvent the wheel?

There was plenty wrong with sysvinit. It was very difficult to get
things to start in the right order, and one third party init script
could totally mess up the the start order. While it was supposed to
take advantage of multiple cores, for parallel starting of things,
it didn't do it well. The chkconfig and lsb headers were rarely done
properly, and often ended up with a loop in dependencies.

Looks like systemd is an attempt to reimplement SMF from Solaris.
Makes you wonder why they didn't simply use SMF - Sun opensourced it
for that purpose, and it's had over 10 years of use, so significant
bugs are long since shaken out, and it works very well.

--
Andrew Gabriel
[email address is not usable -- followup in the newsgroup]

In article , Mike Tomlinson wrote:
There was nothing wrong with SysV init, why reinvent the wheel?

The old wheel didn't have enough corners?

Cheers,
Daniel.

Andrew Gabriel (for it is he) wrote:

Makes you wonder why they didn't simply use SMF

License perhaps? That's why ZFS isn't in the kernel.

--
http://ale.cx/ (AIM:troffasky) )
11:53:58 up 34 days, 2:26, 5 users, load average: 0.39, 0.52, 0.50
Any sufficiently advanced incompetence is indistinguishable
from malice

En el artículo , Tim Watts
escribió:

Even? They (well DeadRat) invented systemd

Yes, but CentOS (which is built on the DeadRat Enterprise sources) has
traditionally been one or two steps behind bleeding edge, focusing on
reliability and stability. We use it for the servers at work.

I was disappointed when CentOS caved in and started using systemd. it
goes counter to the Unix philosophy of "do one thing and do it very
well." systemd tries to be the Swiss Army knife of *nix init and it
shows.

--
(\_/)
(='.'=)
(")_(")

Mike Tomlinson wrote:

Tim Watts wrote:

DeadRat invented systemd

Yes, but CentOS (which is built on the DeadRat Enterprise sources) has
traditionally been one or two steps behind bleeding edge, focusing on
reliability and stability.

Rubbish! CentOS tries to be as close to RHEL as possible, not lagging
behind it ...

En el artículo , Andy
Burns escribió:

Rubbish! CentOS tries to be as close to RHEL as possible, not lagging
behind it ...

It's usually one or two minor versions behind RHEL, but what I actually
meant was that Fedora is bleeding-edge, CentOS (which is aimed squarely
at servers) isn't.

http://danielmiessler.com/study/fedora_redhat_centos/

--
(\_/)
(='.'=)
(")_(")

Mike Tomlinson wrote:

Andy Burns escribió:

Rubbish! CentOS tries to be as close to RHEL as possible, not lagging
behind it ...

It's usually one or two minor versions behind RHEL

What do you mean by minor? if e.g. you mean CentOS would be at 6.3 when
RHEL 6.5 is available, I'd still say "rubbish", if you mean there might
be a few days delay getting some centOS security fixes out, sure that
can happen, it's the cost of free ...

but what I actually meant was that Fedora is bleeding-edge, CentOS
(which is aimed squarely at servers) isn't.

Certainly you wouldn't /normally/ want Fedora on a server, due to short
support lifecycle, and sometimes just not being ready for prime time,
it's handy for seeing what is coming down the pipe for future
RHEL/CentOS versions though.

En el artículo , Tim Watts
escribió:

Even? They (well DeadRat) invented systemd

Aaaaandd... right on cue...

http://www.theregister.co.uk/2014/12...ds_with_debian
_getting_forked/

--
(\_/)
(='.'=)
(")_(")

En el artículo , Mike Tomlinson
escribió:

Following up to myself, sorry.

http://www.theregister.co.uk/2014/12...ds_with_debian
_getting_forked/

The comments are well worth a read too.

--
(\_/)
(='.'=)
(")_(")