[01:06] ScottK: hi. i think micah already talked to you that this was coming :) ... seamonkey 2 is in the queue and chrisccoulson confirmd that its working properly etc. so should be fine. [04:06] asac: Yes. We've discussed. What about lightning? [04:09] ScottK: chrisccoulson will talk to pitti about it in the morning [04:09] OK [04:10] By the time I wake up tomorrow it'll likely be later than I'm comfortable accepting it, so don't wait on me. [04:12] ScottK: we're not uploading for lightning, so either it'll be a binary drop or a source+binary drop [04:13] OK, but IIRC the binary removal requires a publisher run which needs an upload to stimulate it, so don't wait too long. [04:13] ScottK: ok, I'll check with pitti before I go to sleep than and let chrisccoulson make the final decision [04:14] They can always sync clamav-data again if they need something to upload. [04:14] ScottK: I have a universe package that could use a fix :) [04:15] Tonight I'm still reviewing/accepting. [04:15] mediatomb currently has the JS part disabled and someone attached a partial fix [04:15] If stuff is uploaded I'll review it, but that sounds to me like a good SRU candidate. [04:16] ScottK: yeah, I was going to leave it for SRU, but if you need an upload :) [04:16] Don't, yet. [04:16] ScottK: k, I don't have upload rights anyways ;) [04:16] I've still got one I'm holding back for slangasek in case of emergency. [04:16] ScottK: k, sounds good, thanks [04:25] ScottK: I assume most things should be held for SRU now? [04:26] ajmitch: I'll still take FTBFS and things that it's important to get in. [04:26] But it won't be much longer. [04:26] OK [04:31] ScottK: a sparc FTBFS on seamonkey isn't a big deal is it? (we'll be updating in about 2 weeks) [04:31] micahg: No. Sparc is pretty broken these days. [04:32] Fixing it is preferred, but it would be stunning if there were any sparc seamonkey users. [04:32] ScottK: it's a just a disable flag to fix, but since it's pretty broke anyways, I figure we can wait till 2.0.5 [04:33] That's fine. [04:35] ScottK: how much longer will you be up? [04:36] Depends on how my headache does. [04:36] An hour or two, probably [04:36] ScottK: sorry to hear that, I might try for firegpg FTBFS [05:38] stgraber: the grub2 issue has been triaged off to release notes, no respins for it - it's straightforward to fix in SRU [05:50] slangasek: I'm done reviewing stuff and headed to bed. I didn't yet call a halt to people uploading Universe FTBFS fixes, so please tell them when it's time to stop. I still left you anjsp if you need something. [05:50] I assume it'll be too late in the morning to for me to accept stuff, so I'll leave it to you to review or not. [05:54] thanks for firegpg ScottK, I'm trying one more FTBFS [05:55] Good morning [05:55] ScottK: well, the mail sent out at https://lists.ubuntu.com/archives/ubuntu-devel-announce/2010-April/000705.html said we would cut off universe packages at April 26, so anything else is going to be only if I'm twiddling my thumbs :) [05:55] * slangasek waves to pitti [05:55] micahg: I'm heading to bed, so it'll be up to one of the other release team members to approve if they have time. [05:55] slangasek: should I not bother with this other FTBFS than? [05:55] slangasek: OK. [05:55] *then [05:56] ScottK: k, feel better [05:56] micahg: you can - I just can't promise that *I* will have time to review and accept it [05:57] pitti: chrisccoulson will be chatting with you later, but I figured that I'd prime the pump so to speak, WRT lightning-sunbird, we're not sure if we should drop some of the binaries that wouldn't be updated with an SRU or to drop the whole package [06:00] slangasek: nevermind, the FTBFS is too much for me at this hour [06:04] micahg: if the current one is unsupportable, then we should perhaps drop the entire package? I remember a discussion about updating it to 2.0? [06:17] pitti: well, the problem with that one is that upstream is only continuing development of a piece of it [06:18] ev, cjwatson: bug #570843 is odd, not sure why this would be turning up so late when we know lucid has already been tested in networked-but-not-really environments before now [06:18] Launchpad bug 570843 in ubiquity "[Lucid Lynx RC] Install hangs on a LAN-connected (but no internet) workstation" [Undecided,New] https://launchpad.net/bugs/570843 [06:22] micahg: I'm not a big fan of just removing some binaries of a source; I don't remember a precedent for this, and don't know what could go wrong in soyuz for that [06:22] micahg: so I'd actually prefer an upload which properly drops those packages, or just remove it completely if it doesn't break (too many) rdepends [06:22] pitti: k, then we'll probably remove then chrisccoulson can confirm in a few hours [06:22] thanks [06:50] morning! [06:53] slangasek: got your response on https://bugs.edge.launchpad.net/ubuntu/+source/etherboot/+bug/570870 ... what about motu-sru ... still the same? [06:53] Ubuntu bug 570870 in etherboot "pxe boot doesn't work with kvm" [Low,In progress] [06:53] slangasek: or is that merged with ubuntu-sru too? [06:53] oh, how was the sparc kde issue sorted out? http://people.canonical.com/~ubuntu-archive/component-mismatches.txt lost all its vpn stuff [06:54] I approved/promoted the texinfo-doc-nonfree MIR, so that'll be gone soon, too [06:54] kirkland: it's just ubuntu-sru now [06:55] pitti: thanks [07:20] pitti: per-arch binary removal :/ the kde failure has mysql-dfsg-5.1 at its root, and doesn't seem tractable - cjwatson gave it a try yesterday [07:21] KDE is entirely uninstallable on sparc right now anyway, so I didn't feel bad about doing the binary removal [07:21] slangasek: ah, ok; I thought as much, thanks for confirming [07:21] the sparc users will be furious! [07:22] . o O { both of them! } *cough* [07:24] :) [09:06] slangasek: fingers crossed that he was using the RC and not a daily [09:06] it sounds like it might be bug 567749, which we fixed post-RC [09:06] Launchpad bug 567749 in ubiquity "Broken packages during oem-config" [Undecided,Fix released] https://launchpad.net/bugs/567749 [09:06] erm, nevermind. He wasn't using oem-config. [09:12] trying to reproduce now [10:05] Riddell, around? [10:26] ara: hola [10:27] ara: grub always says "Ubuntu" to answer your question from yesterday [10:27] Riddell, ok, thanks. Another one :) [10:28] Kubuntu Netbook, when installed in English I get "Konqueror" "KMail" "System Settings" and "Home" in Bookmarks [10:28] but, when installed in Spanish, I only get the first three items [10:28] (not Home) [10:30] that'll be a beastie [10:31] * ogra sees the headlines already "No home for that spanish in ubuntu !!!" [10:31] *the [10:32] hehee [10:34] ScottK: i dont think he has time to do it ... but in case: killing sunbird and just keeping lighting is ok from my pov [10:34] not perfect, but better than killing it completely. [10:38] ara: it's patch kubuntu_105_netbook_favourites.diff which adds that, although I think that patch is upstream now. file a bug on kdebase-workspace anyway [10:40] Riddell, ok, will do, thanks [11:04] cjwatson: bug #567592 [11:04] Launchpad bug 567592 in plymouth "rm: cannot remove `/var/lib/urandom/random-seed': Read-only file system" [Undecided,New] https://launchpad.net/bugs/567592 [11:10] lool, ttx , cjwatson , ttx tells me of mountall issue ? [11:10] lool and I have been trying to run the UEC image under kvm (alone, not via eucalyptus) [11:11] I understand this isn't the usual path, so I don't think there's any cause for panic if your usual tests are passing [11:11] however it did show up an issue or two in plymouth [11:11] smoser: we were wondering if those could be the source of some of the racy behavior of the images under uec [11:12] is there backscroll i should read? [11:12] specifically attaching to the session fails if you don't have an initramfs, and if you're then also running the details plugin then plymouth crashes [11:12] smoser: no, the discussion was live so far :) [11:13] ok. so you have modified /etc/fstab in the image ? [11:13] it has hard coded /dev/sda1 as root filesystem [11:14] never mind that. [11:14] -append "root=/dev/sda" [11:14] didn't touch /etc/fstab [11:14] yeah, but mountall still gets all upset on /etc/fstab [11:14] when /dev/sda1 is never going to appear [11:15] so filesystems event is never going to fire (... i think ... this is memory of a while ago) [11:16] smoser: I understand that the setup I have is going to break for other reasons :) [11:16] so I don't think it's a UEC blocker of any kind [11:16] smoser: but having run into this problem I've been trying to assess what its impact would be outside UEC [11:17] at the moment, I think that the answer is that server boots with no initramfs and without the 'splash' argument are broken [11:17] broken how ? [11:17] because instances boot that way both on ec2 and uec [11:19] oh. if youre running the details plugin. i see. which (i guesss?) is not running in our instances by default. [11:19] cjwatson, ^^ [11:20] details plugin happens if you boot without 'splash' [11:20] my suspicion is that you just don't notice problems because you're running headless :) [11:21] there are some scary messages appearing on the get-console-output, nevertheless [11:21] certainly to some extent I'm only seeing this because mountall needs to ask questions due to other bugs [11:21] smoser: and FWIW the problem I'm debugging here is the same segfault you reported in https://bugs.launchpad.net/ubuntu/+source/plymouth/+bug/567592/comments/3, so I do not believe that you are not seeing it at all :-) [11:21] Ubuntu bug 567592 in plymouth "rm: cannot remove `/var/lib/urandom/random-seed': Read-only file system" [Undecided,New] [11:21] ah. i see. [11:22] yes, we dont see stuff lke "starting" [11:22] or "started" [11:22] ah, though to be fair you were triaging hggdh's bug [11:22] i can point you at ec2 logs if you're interested. [11:22] starting/started are only meaningful terms in conjunction with a job name [11:22] not really, laser-focusing on this bug :-) [11:22] I don't want to get sucked into debugging ec2 in general [11:23] ok. so yeah, i would say that we're in trouble if plymouth wants to promt the user for information on uec/ec2. [11:24] we would be anyway [11:24] that's not a bug in plymouth, that's a failure to boot the UEC image correctly [11:25] right, but leaving UEC aside, a server boot without initramfs looks like it'll fail if it needs to prompt [11:25] * slangasek nods [11:25] right now, I'm trying to figure out why it's prompting for /tmp [11:26] as far as release noting, this should probably be tacked onto https://wiki.ubuntu.com/LucidLynx/ReleaseNotes#Changes%20in%20boot-time%20output%20on%20Ubuntu%20Server [11:27] an initramfs-less install outside of ec2/euc instances is not really something that is supported. [11:27] right? already it means the user is using a custom kernel [11:27] my understanding from Keybuk is that that is false [11:27] it's not a default Ubuntu installation, sure, but it's not an uncommon thing for people to want to do and it's something we want to support [11:27] which, obviously should be supported, but if they're rolling their own kernel then they can just roll it with an initramfs. [11:28] in the sense of "make not hideously fail", not in the sense of "accept paid support calls" [11:28] cjwatson: ok [11:28] so we are in agreement that this precise issue doesn't change anything fro UEC users [11:29] though supporting no-initramfs + no-splash would be good to have. [11:29] (for server generally) [11:30] fwiw, it was a pain to get "no-initramfs" working in ec2/uec. [11:30] we ran into several bumps in the road causing that feature to wobble back and forth [11:31] I realise that [11:31] the server in general is simpler though [11:37] sorry was in a call [11:44] i dont necissarily think that the server is a simpler case. ec2/uec has the "single set of hardware" simple-ness. ie, console is serial, network driver is X... its all known and explicitly supported. [11:44] slangasek: should I add bug 557429 to the release notes targets ? [11:44] Launchpad bug 557429 in mdadm "array with conflicting changes is assembled with data corruption/silent loss" [High,Triaged] https://launchpad.net/bugs/557429 [11:46] smoser: *shrug* by simpler I was referring to the fact that it doesn't tend to have a set of complicated and delicate upstart jobs. anyway, it's something we should make work, and in most cases it is not that hard. I don't think it's release-critical or anything. [11:46] that is, simpler in userspace. [11:50] fwiw, i do hope on maverick, what you were attempting (booting in "stock kvm") will be much better supported and ideally "just work" [11:51] well what I'm trying to do here is to contribute to that, not just complain! :-) [11:52] slangasek, are all your rebuilds done already ? seems ports -server is still old [11:54] ogra: I'll do ports builds shortly [11:54] thanks [11:55] i still have a netinst running so no hurry [11:55] ttx: 557429> eh? already has a release notes task ): [11:55] arh [11:56] slangasek: I missed it. I guess I need another massage [11:56] sorry for the noise [13:11] cjwatson, yeah, i didn't think you were just complaining. was just saying, i hope that in maverick this test , your running of the instance would have worked better than it did. (ie, wouldnh't have failed to get to 'filesystems' event) === rgreening_ is now known as rgreening [13:20] smoser: what specifically is planned for maverick in this regard? [13:20] I'd expect most of the work to be essentially in the foundations arena, and to be bug-fixes [13:50] smoser: I see published-ec2-release.txt, which should tell me that you've pre-published these to EC2 for final release, yes? [13:51] yes. [13:51] great, thanks! [14:33] slangasek: did you accept linux lucid-proposed, or did I screw up with my langpack accept? [14:33] pitti: that was me [14:34] ok, thanks [14:34] did it specifically before asking you about langpacks :) [14:34] ok, langpacks flushed [14:34] https://edge.launchpad.net/ubuntu/lucid/+queue?queue_state=1 is useful again, yay! [14:34] And queuediff too (it was timing out for me) [14:57] slangasek: llvm, clang and llvm-gcc-4.2 all in the queue. let me know if I have to reupload to -proposed =) [15:02] doko_: odds are better if you can get a member of the release team *other* than me to review it... [15:07] * pitti reviews [15:07] slangasek: ok. thanks pitti [15:09] doko_: oh, clang looks easy :) 50 line diff [15:09] pitti: llvm has to go first, clang b-d on it [15:09] okay [15:13] pitti: the b-d's are correctly set, so you could accept all at once after review [15:13] doko_: I'm though with all three; diffs are very small, nice [15:13] pitti: cool, thanks! [15:13] * pitti reviews the other stragglers while he's at it [15:14] now a working jit for the powerpc jvm [15:21] slangasek: ok, I accepted two more universe packages (simple FTBFS); for the remaining ones, xsane is on ubuntustudio and wine1.0 might take too long to build [15:22] oh, and wine is on u-studio, too [15:22] oops, that was 1.2 [15:22] the wine1.0 diff looks reasonable [15:22] pitti: did you leave the one in there that ScottK was leaving in case we needed to provoke a publisher run? [15:23] I didn't see that, sorry [15:23] no worries, just means we'll do it by hand if necessary :) [15:23] if we need one, I can find/fix another universe FTBFS [15:23] ok [15:23] sorry if one was deliberately held [15:24] wine1.0 would actually be suitable; takes 30 mins to build on i386/amd64, no other arches [15:24] * slangasek nods [15:24] thats a shame ! [15:24] * pitti needs to run now, about an hour [15:24] * ogra wants wine on ARM !!! [15:25] ogra: talk to me in 4 months [15:25] slangasek, lol ... [15:25] maybe I'll have something for you then [15:25] slangasek, like the famous wince emu in wine on ARM ? *g* [15:25] er, probably not that [15:25] heh [15:26] i doubt you can port it to arm [15:26] but who knows [15:26] no, I'm not going to port it to arm [15:32] ogra: I'd recommend a red wine for ARM. [15:32] yummy ... [15:33] * ogra has plenty boxes with rioja in the cellar... i should try that [15:34] rioja with a bagel board :) === bjf is now known as elBoto === elBoto is now known as bjf [16:52] slangasek: https://bugs.edge.launchpad.net/ubuntu/+source/akonadi/+bug/564263 should be release noted if you're collecting them [16:52] Launchpad bug 564263 in akonadi ""No resource agents found" error when starting for the first time" [Undecided,Confirmed] [16:54] Riddell: got it - you can just add an ubuntu-release-notes task to bugs, fwiw [16:56] wohoo [16:56] so its possible to do an ubuntu-netbook install with netinst [16:56] it only takes 6h ! [16:57] (on omap) [17:05] ok, on to server image testing [17:06] slangasek, ^^^ omap netinst is good [17:06] alrighty [17:41] cjwatson: can I get a second opinion on https://bugs.launchpad.net/ubuntu-release-notes/+bug/546245 ? [17:41] Launchpad bug 546245 in ubuntu-release-notes "warn about using ubuntu with md raid (unreliable raid config)" [Undecided,New] [18:27] jjohansen: so should we have a release note about how crappy ext4 can be and suggesting the use of ext3 ? [18:27] there's already a release note task about the dpkg performance problems [18:28] yes, I'd say that's enough -- but jib and jjohansen were discussing a more generic warning [18:28] it's not just intsallation taking longer [18:28] it's actual service performance after installation [18:29] have we run our server tests with ext3? [18:29] ttx: well yes we could do that [18:29] cjwatson: we know why ext4 is slower than ext3 and there's a benchmark available publicly that shows it [18:29] I'm not sure that answers my question ... [18:29] jiboumans: I'd argue that you should choose your FS based on your workload, so unless ext3 beats ext4 on most scenarios, it's difficult to write that in release notes [18:29] cjwatson: the answer is no [18:29] I was talking to psurbi and she hasn't done anything more with it lately. Its still basically the same cases [18:30] cjwatson: we dont have numbers no [18:30] jiboumans: yes sort of, that isn't a great benchmark [18:30] jiboumans: I wasn't asking for numbers [18:30] jiboumans: I was asking for server validation with ext3, just as we're doing validation with ext4 [18:30] anyway, I think "ext4 is slower than ext3" is too simplistic [18:30] we should have a release note, but it needs to be in slightly more depth than that [18:31] cjwatson: agreed [18:31] i'm not attached to any wording, but i want to make it clear you have ext4 by default and what that may mean [18:31] for example I recall the kernel team switching to ext4 in droves at one point upon realising that its unlink was much faster orsome such [18:31] *or some [18:32] A "pick your FS wisely" section warning on advantages/drawbacks of each ? [18:32] "File system selection" perhaps [18:32] it could note that btrfs won't work yet :-) [18:32] i'm happy with our choice of default, but only if we point out why we picked it [18:32] Who would know the issue well enough to be able to draft that ? [18:33] i suggest 'data safety' [18:33] that sounds inappropriate? it's not a safety issue [18:33] cjwatson: sorry, multitasking and not phrasing myself well [18:34] I can draft some of it, as it relates to installation [18:34] I'm not convinced that I can draft the whole thing well [18:34] so perhaps I can tag-team on it with somebody else [18:35] I wouldn't phrase it "data safety or performance" [18:35] but rather "performance on workload A vs. perf on workload B" [18:36] that highlights the best practice of doing that perf test yourself before choosing [18:37] jjohansen: anyone in kernel that would know this issue particularly well that could help Colin ? [18:37] do we have enough information to write a note like that at this point? [18:37] in short, disk reads/writes seem slower compared to 8.04 and whinging will happen if we dont disclose [18:37] jiboumans: in dpkg, certainly not in general? [18:37] I think that's too short. I haven't seen evidence that actual disk read/write throughput is much slower. Isn't the issue regarding write *barriers*, which is a slightly different matter? [18:38] pitti: in general according to the benchmarks we've seen [18:38] this is what i refer to: http://www.phoronix.com/scan.php?page=article&item=ubuntu_lts_perf&num=2 [18:38] (poorly-explained phoronix benchmarks aren't evidence here) [18:38] subjectively my system feels not slower, rather a bit faster with ext4 [18:38] ttx, cjwatson: it was csurbi who looked into it and did some benchmarking [18:38] other than that, anecdotal only [18:38] especially with things like large rm -r, fsck, and reading of files [18:38] 'we are not using ext4 as it doenst perform as well as X' [18:38] where X isn't necessarily ext3 [18:39] I've read the article, I'm not entirely sure I believe it without more of a microbenchmark. I'm aware of certain things that will be much slower in ext4 and static web pages weren't one of them. Perhaps something to do with log file writes? [18:39] please don't generalize from dpkg to overall behaviour? [18:39] if apache is fsyncing its log file, that would explain it [18:39] although it would be a bit odd! [18:39] jiboumans: right, well that doesn't even cover ext3 on the same OS version, a lot more than ext4 has changed [18:39] pitti: i'm not. this is from my friends & network in operations [18:40] release notes really need to be evidence-based and not rumour-based [18:40] cjwatson: it's not a rumour [18:40] 'we did the benchmarks and we picked X instead' [18:40] where's the science in that phoronix article? [18:40] where's the method? [18:41] right, the are cases where it doesn't perform as well, this is known [18:41] i dont have those numbers or specifics. the only thing public i can point at is that article [18:41] jjohansen: this is known to...? [18:41] everyone upgrading from 8.04? [18:41] without method, it's rumour [18:41] jiboumans: the developers [18:41] we know of certain things that aren't rumour [18:41] we should stick to those for the time being [18:41] they have been working on stability and other issues first [18:41] cjwatson: again, not caring about the specifics here. i'm only addressing pitti who said 'only for dpkg, right?' [18:42] they know there are some corner cases [18:42] jjohansen: i care about the people installing it and making sure they're not surprised, or that there's any FUD around our default [18:42] jiboumans: do we care about the specifics for the release note, or not? [18:42] cjwatson: sure [18:42] pick any specifics you want to include [18:42] you're saying "disk reads/writes seem slower", and I'm saying that we should not be specific about the operations that are slower unless we have evidence [18:43] I agree it isn't just dpkg; that's merely the situation where we have most immediate evidence [18:43] cjwatson: i think you're mixing up my conversation with you to point out my concerns with my suggested text for the release notes [18:43] jiboumans: understood [18:43] I hadn't actually seen any suggested text yet :-) [18:44] all I'm saying is that we shouldn't just say "it sucks, use ext3" on the basis of phoronix :-) [18:44] cjwatson: we violently agree [18:46] jiboumans: ok, good :) [18:47] I have a bit of a thing about phoronix I'm afraid - I've seen some pretty disgracefully bad things masquerading as science there (complete unawareness of statistical significance), so I tend to have a negative knee-jerk reaction to them [18:48] cjwatson: appreciated. it's unfortunately the only public thing i can point at =/ [18:50] I think it would be interesting to time ext4 with write barriers turned off, and possibly ext3 with write barriers turned on [18:50] the most recent hypothesis is that that's the specific property that changes dpkg's performance characteristics between ext3 and ext4 [18:51] it would further be interesting to know what difference that makes to phoronix' benchmarks [18:56] apache2 doesn't appear to be using fsync or fdatasync [18:57] unless it's wrapped up in something outside the apache2 source [18:57] ah, separate library source [18:58] still not seeing any references from C code though [18:59] so I think it would be a good idea to further analyse where the apache slowness is coming from [18:59] is anyone able to take that on? [19:05] I've started a benchmark run in kvm, with the aim of comparing installation time with and without write barriers [19:05] kvm probably isn't a great benchmark for this but it's better than nothing [19:13] cjwatson: I can kick it off on real hardware. Which installer are you using? [19:16] server [19:17] there's nothing built-in to disable barriers - you'd have to edit /lib/partman/mount.d/70ext3 before starting the partitioner to get it to do that [19:18] actually no, make that /lib/partman/fstab.d/ext3 [19:19] and unless you can be bothered to preseed everything, probably best to just compare times of the base-installer and pkgsel segments from syslog [19:19] okay, I'll give it a run [19:24] Food time for Londoners. === bjf is now known as bjf[afk] [21:54] Riddell: heya; is LP #564263 still present and worth a release note? Would you have some sample text? [21:54] Launchpad bug 564263 in akonadi ""No resource agents found" error when starting for the first time" [Undecided,Confirmed] https://launchpad.net/bugs/564263 [22:04] lool: yes we'd like a release note for that [22:05] "Akonadi startup is sometimes faulty preventing access to the addressbook and other resources, close and restart Kontact when this happens to work around" [22:18] Riddell: thanks [22:21] FWIW disabling write barriers shows no obvious improvement in kvm (and actually seems to disimprove the pkgsel stage, though it's possible my system was just a bit busier) [22:27] cjwatson: At the ext4 or kvm backend level? [22:28] ScottK: release notes task for LP #290153 seems to have been opened a long time ago, and I understand that the scope of the problem is smaller now, since the systems actually boot albeit slowly; so I'm closing the task, but please reopen if it necessary [22:28] Launchpad bug 290153 in linux "Fails to find boot device in Intel D945Gnt" [High,Confirmed] https://launchpad.net/bugs/290153 [22:29] - [22:47] lool: where I disabled write barriers? I mounted the ext4 file system with barriers=0 [22:47] er barrier=0 [22:53] slangasek: LP #470776 still an issue in final? cjwatson seemed to think it might be fixed now with the latest lucid packages [22:53] Launchpad bug 470776 in mountall "retry remote devices when parent is ready after SIGUSR1" [Medium,Fix released] https://launchpad.net/bugs/470776 [22:53] slangasek: That is, the part which relates to the mount.nfs errors reaching the console === bjf[afk] is now known as bjf