User: Password:
|
|
Subscribe / Log in / New account

Sunday's stable kernel updates

Sunday's stable kernel updates

Posted Oct 22, 2012 15:54 UTC (Mon) by nix (subscriber, #2304)
In reply to: Sunday's stable kernel updates by nix
Parent article: Sunday's stable kernel updates

... but first there's some ext4 fs corruption to recover from -- looks like bzr doesn't use fsync() properly, zero-byte files all over my branch of the emacs repo. I'll just have to hope that the only corruption is zero-byte files, because a back-of-the-envelope calculation after letting it run for an hour suggests that 'bzr check' of that repo will take on the order of three *weeks* to finish.


(Log in to post comments)

Talk about bad timing

Posted Oct 22, 2012 16:46 UTC (Mon) by man_ls (guest, #15091) [Link]

Heh, I just upgraded to 3.6.3 after seeing my first kernel panic for years with 3.3.5. No idea why, I somehow suspect it may be sound-related -- the trace did not give me a clue (which is not surprising anyway as my kernel knowledge does not go beyond patching the occasional driver with hammer and anvil).

I am using NFSv3 on this machine but only as a client. What part of NFS is giving you grief, client or server? Because I have:

# zcat /proc/config.gz | grep NFS | grep V4
CONFIG_NFS_V4=m
# CONFIG_NFS_V4_1 is not set
CONFIG_NFSD_V4=y
and I have not seen any issues yet.
'bzr check' of that repo will take on the order of three *weeks* to finish.
Time to move to git, perhaps?

Talk about bad timing

Posted Oct 22, 2012 17:07 UTC (Mon) by nix (subscriber, #2304) [Link]

Interesting. I've got nfsdv4 *and* nfsv4 built in: this box is an nfsv3 server only, though. Obviously I should try again (well, I should anyway, to try to reproduce the oops in a useful fashion).

As for that bzr check, well, this is the Emacs repo, which is using bzr for purely political reasons (bzr is 'the GNU version control system' so RMS insists that Emacs use it). bazaar itself, Emacs, calibre, and the obnam dependencies are the only bazaar-using projects on my system, and I have no inclination whatsoever to add any more. The more I use bazaar the more bizarrely counterintuitive, overcomplicated, and sluggishly buggy it feels...

Talk about bad timing

Posted Oct 22, 2012 17:25 UTC (Mon) by man_ls (guest, #15091) [Link]

Sorry, I read the "emacs repo" bit but then managed to overlook it completely when I replied. I am now tempted to recommend something like git-bzr to access bzr repos using git. But:
  • The many git-bzr's I find seem to be poorly maintained, which by the way is relevant to another item on the front-page.
  • I am using git-svn currently and it is not as great as you would expect: the commands feel alien both to git and to svn
Perhaps it is time to lobby the FSF to abandon bzr and use git instead, as they so pragmatically did with the Linux kernel; I can assure you that most projects on Savannah use git. Although that might start another apocalyptic flamewar like with the Linux kernel. Also, the FSF might be tempted to start calling it GNU/git in a few years... just joking (as only a card-carrying FSFE member officially can).

Talk about bad timing

Posted Oct 23, 2012 18:37 UTC (Tue) by nix (subscriber, #2304) [Link]

Those apocalyptic flamewars happen regularly on the emacs list :( RMS is unmoved. bzr it shall be, even though projects like Gnus which Emacs draws from use git :( even more amusingly, joining two git repos together is trivial (git remote add and then pull or fetch and merge as usual). Joining two bzr repos together requires 'bzr join', which despite the lack of a comment in the manpage is widely known to work only for trivial cases.

bzr is indeed bizarre

Posted Oct 23, 2012 14:35 UTC (Tue) by przemoc (subscriber, #67594) [Link]

Using bazaar is strongly recommended in GNU community, but the fact is that most projects already moved away from it (usually toward git). I just checked and even wget moved this year.

Previous wget maintainer (Micah Cowan) said once, that it "become tradition for each new maintainer to change the repository". He switched to Mercurial (from Subversion) back then (and chose it over git because of decent handling of Windows). Current wget mainainer (Giuseppe Scrivano) was the one behind choosing bzr (due to RMS guidelines), and that lasted for some time, but thankfully he realized his mistake and a few months ago the project finally went to git.

I remember when I wanted to work on wget with bzr (but don't remember what was it actually, debugging and tracking some bug maybe?) - I simply had to convert it to git to be able to work with it sanely.

Nowadays if I clone some non-git repo I almost always clone it via some gitifying app like svn2git, which is a wrapper on git-svn. (Only when I'm short on time I go directly with original tools e.g. svn co.) I guess that convenient git log and grep tools are enough reason for that, but you know there is much more like bisect and all other stuff.

Sunday's stable kernel updates

Posted Oct 23, 2012 19:46 UTC (Tue) by nix (subscriber, #2304) [Link]

Aside: there is at least one ext4 bug here, causing repeated corruption of /var, but whether it's in 3.6.1 or 3.6.3 is unclear: reported upstream but there's so little info ('/var keeps getting corrupted, here are some terrifying messages from dmesg and a BUG') that I'd not be surprised if nobody can do anything with it. I've reported the NFS server bug (lockd bug really, introduced in 3.6.3, in all likelihood problematic only if you have network namespaces built in but only have one in use, so in extremis starting a copy of Chromium with the suid sandbox might work around it!)

Testing a fix now, courtesy of Trond.

Sunday's stable kernel updates

Posted Oct 23, 2012 21:04 UTC (Tue) by nix (subscriber, #2304) [Link]

Stopped testing fix, on account of getting more and more massive filesystem corruption the longer I stayed in 3.6.3. Reported upstream...


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds