[00:27] Hi all, I'm trying to install the omap4 extras from TI on my Pandaboard. I have reached a screen which wants me to agree to the "TI TSPA Object cod Software License Agreement". It looks like a dialog box made with text graphics and has an at the bottom. I can't figure out how to click "OK" :-) [00:29] tab and enter? [00:30] Lol that works! [00:30] np [03:14] joined [03:15] excuse me [03:18] excuse me [04:23] I am trying to build ubuntu oneiric kernel in a armel cross chroot [04:23] I am unable to build because of the following error: scripts/kconfig/zconf.tab.c:2505:0: internal compiler error: in insert_vi_for_tree, at tree-ssa-structalias.c:2740 [04:24] I was wondering if anyone has seen this [04:33] hmm... wouldn't it be easier to cross-compile it outside the qemu-environment with CROSS_COMPILE=arm-linux-gnueabi-? [04:35] mythos: I thought using a cross chroot I can leave my host environment unmodified [04:36] qemu does have some issues if a process needs to much memory (in my experience) [04:36] hmm [04:36] and you can set up a cross-compile-environment inside the chroot ;-) [04:37] ;) [04:40] but in fact, that was my my first shot/try also... it works, but has it's limits [04:41] ok [04:41] I tried removing -O2 from KBUILD_CFLAGS still no luck :) [04:41] s/)/(/ [04:42] yeah, that's the first hit google gives you, if you run in such problems ;-) [04:42] i was lucky and it worked with python2.4... [04:43] so, you should really try a cross-compilation or a native build [04:44] I tried a native build [04:44] I am seeing segfaults [04:44] I already have the 768MB work around [04:44] http://pastebin.com/pmSbm4pd [04:45] oh, than your last shot is cross-compilation [04:46] *then [04:46] I am trying to avoid it if possible [04:46] probably setup a chroot and cross build inside that [04:47] wonder how the kernels are built in ports [04:48] are they cross built or in cross chroot :p [04:48] if you are idling long enough, one from canonical's arm-team will surely answer your question [04:49] but, i'think, they said that they use panda-boards to compile their packages [04:50] that would take forever [04:50] compiling on the pandaboard is so slow [04:50] look at the topic... [04:52] interesting if they are building everything on pandaboards [04:58] yeah... i have to consider this too... [04:59] if they use native builds for everything, maybe i should that too for my projects [05:03] probably some of the devs could answer this [05:09] krosswindz, maybe out of context, but that's what i found in the channel history http://pastebin.com/DEcZvhj9 [05:11] mythos: guess they are using pandaboards as buildd [05:12] i guess so too [05:14] guess I might switch precise and see if that solves my build issues [05:14] go for it =) [05:20] will try armhf if it doesnt work I can always revert back to oneiric [05:20] should get a couple of more sd cards :p [05:21] if possible, i would use a nfs configuration [05:22] my board is able to load linux via tftp and rootfs via nfs [05:22] but it is a uncommon ti board. i don't have a panda or anything else [05:23] maybe all u-boots can do this... [05:26] uboots can do it [05:26] the x-loader has an option on the pandaboard to boot using tftp [05:26] I havent tried it though [05:27] it is a really neat feature =) [05:41] where can i get debian-installer images for qemu? [05:46] scientes_, i think, you are looking for this http://wiki.debian.org/ArmEabiHowto [05:47] no, found what i needed: https://wiki.ubuntu.com/Core [05:47] (if there are arm versions...) [05:47] i am trying to install ubuntu arm in qemu [05:47] to test some software that fails in debian arm and x86_64, but works in ubuntu x86_64 [05:48] *debian armel, when compiled from source [05:48] "Installing armel to qemu with d-i" <-- but if you found what you are looking for, that's also awesome =) [05:48] hmmmm, actually, emulated compiling is probably too slow [05:49] mythos, yes, but where is the d-i for UBUNTU [05:49] i.e. alternate installer in ubuntu-land [05:49] I guess i will need to use a chroot or something on my arm device [05:49] that was not what you asked for ;-) [05:49] well, this is #ubuntu-arm [05:49] mythos: Sure it is. [05:49] i thought it was implied [05:50] mythos: debian-installer implies the software, not the distro. [05:50] infinity, precisely [05:50] scientes_: http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armel/current/images/linaro-vexpress/netboot/ [05:50] infinity, hmm... i'm not sure, if i understood that? so debian-installer ist capable to install ubuntu? [05:51] scientes_: Unfortunately, we don't provide vexpress netboot images for armhf yet. I should put that on my TODO before I forget again. [05:51] mythos: debian-installer is the underlying technology for all our installers. [05:51] infinity, which one would be faster for emulation? [05:51] infinity, except liveCD IIRC [05:52] scientes_: ubiquity uses d-i components to do all the "real work". [05:52] scientes_: (ubiquity being the GUI livecd installer) [05:52] infinity, ahh, now i know [05:52] i though it just copied the image [05:52] Copying is the easy part. ;) [05:52] (ish) [05:52] the squashfs image, with cp -a or something [05:52] It copies the squashfs, and then runs all the d-i bits inside the target. [05:52] instead of installing every deb seperately [05:53] infinity, i don't want to argue against it. so i apologize [05:53] fedora is differn't, cause their livecd doesn't support anything but ext4 [05:53] mythos: I suppose you could argue if you wanted. ;) [05:53] as a limitation of the way they are doing it IIRC [05:53] infinity, sure... ;-) [05:54] but on a differn't note: is compiling in qemu going to be horribly slow? [05:54] scientes_: Yes. [05:54] and will i have better luck with a chroot on a real, but slow, arm device [05:54] scientes_: On the fastest hardware we can get our hands on, qemu barely beats out a pandaboard. [05:55] scientes_: And you probably don't have that hardware. [05:55] I have a sheevaplug [05:55] but it has debian wheezy on it [05:55] Oh, well, the sheeva's not exactly speedy either. [05:56] infinity: do you have any suggestion for size of the sd card for building things natively on the pandaboard [05:56] pandaboard at least supports VFP [05:56] Wait, you can't even run Ubuntu on a sheeva, can you? [05:56] Isn't in ARMv5? [05:56] infinity, so which should I try, chroot on sheeva, or qemu? [05:56] oh, your right [05:56] s/in/it/ [05:56] only old version [05:57] it actually ships with some version of ubuntu [05:57] (don't remember cause i replaced it very quickly with debian) [05:57] krosswindz: I recommend a tiny SD card, a netboot image, and installing to a nice external USB drive. [05:57] krosswindz: Honestly, while running from SD makes for cute demos, it's slow, and it kills SD cards. [05:57] infinity: true [05:57] infinity, ahhh, its bad to run embedded from SD? [05:58] scientes_: Yeah, we used to support v5 for a while, then v6 for a while, but we've been v7-only for ages. [05:58] with or without VFP? [05:58] v7 implies vfp. [05:58] so basically armhg [05:58] *armhf [05:58] infinity: if I install on to the usb drive I should be able to use the normal USB port right and not the OTG [05:59] Out armel port uses softfp calling conventions (but still uses the vfp unit), and armhf uses hardfp calling conventions. [05:59] krosswindz: Yeah, either of the two normal USB ports. [05:59] why? if armv7 implies VFP? [05:59] you would get 40% better performance on some hardware (armhf info page) [06:00] scientes_: Hence the armhf port. [06:00] nice I think thats what I will do then [06:00] I should have an old 80G sata drive lying around some where [06:00] seems like you should drop the soft float conventions all together [06:00] scientes_: armel uses the softfp ABI because that's just the way things were done for compatibility (and sanity) reasons. Porting everything to the hardfp ABI was some effort. [06:01] scientes_: The armel port will likely become unsupported this cycle. [06:01] gotcha [06:01] scientes_: We're trying to move the world to armhf. I've put a lot of work into this. :P [06:02] krosswindz: http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/current/images/omap4/netboot/ [06:02] krosswindz: If you just write out one of those images (boot.img-serial or boot.img-fb) to an SD and boot, you should be able to install to an external drive and save a lot of pain. [06:02] infinity: thanks for the link [06:02] eek, it seems like testing this software will be a PITA [06:03] infinity: thanks [06:03] once I am done installing I dont need the sd card to boot or would I need it still [06:03] maybe i can use the packages i built in debian [06:03] krosswindz: It'll still need an SD card around to flash a bootloader to, so you don't get to go completely SD free (the Panda has no firmware), but reading a bootloader on boot is a heck of a lot better than running your whole OS from the card) [06:03] agreed [06:03] I can build natively on the pandaboard [06:04] whats the package for qemu-arm? [06:04] krosswindz, thx, its opencpn.org [06:04] scientes_: qemu [06:04] infinity, that just installs qemu-kvm now [06:04] apt-file search qemu-arm [06:04] scientes_: Or, if you want to do binfmt-misc emulation (which is much less annoying), qemu-user-static [06:05] scientes_: Yeah, qemu-kvm should include qemu-system-arm, does it not? [06:05] don't know i was trying to use virt-manager [06:05] Oh, those may have been split off into qemu-system [06:06] Anyhow, qemu system emulation is almost never what you want, unless you're debugging bootloaders. [06:06] qemu binfmt emulation is much less annoying. [06:08] infinity: are there md5sums for the files around some where [06:09] http://ports.ubuntu.com/ubuntu-ports/dists/precise/main/installer-armhf/current/images/MD5SUMS [06:09] thans [06:09] thanks* [06:09] poof!, my computer randomly rebooted [06:09] scientes_: Welcome back. [06:09] wierd [06:09] scientes_: So, as I was saying. ;) [06:09] anyways, no infinity qemu-kvm only has qemu-system-i386 and -x86-64 [06:09] apt-file search qemu-arm [06:10] scientes_: Yeah, the others were broken out into qemu-system [06:10] exactly [06:10] installing now.... [06:10] scientes_: However, you almost certainly don't want an actual qemu-system, unless you're debugging bootloaders. [06:10] oh ok [06:10] oh yes, there is multiarch !!!!! :):):) [06:10] scientes_: If you install qemu-user-static, then you can work with ARM binaries as if they were native. [06:11] I don't see -static, just qemu-user [06:11] but that is OK [06:11] search for qemu-arm-static [06:12] krosswindz, should i just use what i built on my sheevaplug in debian wheezy, or do you want to build opencpn ( opencpn.org ) ? [06:12] scientes_: I am sorry I guess you there was some miscommunication [06:12] scientes_: qemu-user-static definitely exists (and is the required one in this case), I just installed it. [06:13] ahh it does, what is the difference? [06:13] oh, i read the desc, nvm [06:14] wait, no I don't know why [06:14] dpkg --add-architecture armel ? now [06:14] scientes_: http://paste.ubuntu.com/829726/ <-- witness the magic. [06:15] scientes_: You could do multiarch too, but that gets messy. Do you really do your builds in your base system, not in chroots? [06:16] oh gotcha, that looks much cleaner [06:18] krosswindz, oh, gotcha [06:18] OK, all this talk about SD cards----so if I launch an embedded device, it is smart to not use a SD root? [06:19] scientes_: If you're building an actual embedded device, hopefully that assumes you're taking great pains to make sure you're not doing things like logging to filesystems, etc. [06:20] scientes_: If you never write to the card except to update software, SD's a fine choice. [06:20] ok, so all the problems with SD are going to be the same with NAND flash? [06:20] scientes_: If you run a general purpose OS on it, and call it "embedded" without making sure you neuter that sort of behaviour, you're going to kill a lot of flash. [06:20] not the FTL? [06:20] *do any come from the FTL? [06:21] scientes_: Hrm? [06:21] I'm not sure I understand what you're asking. [06:21] flash translation layer---why SD is a block device, not a mtd [06:21] Yes... But I'm not sure what you're asking about FTLs. [06:21] well is that the source of SD problems? [06:22] or are their problems shared with raw NAND flash? [06:22] No, the source of problems is rewriting flash, full stop. [06:22] ok, that is what i was asking [06:22] And raw flash is usually worse than something with a decent FTL implementation, cause at least decent FTLs (like those found on SSD disks) do proper wear-leveling. [06:22] But, at the end of the day, excessive writes kill flash, even SSD disks. [06:22] infinity, ubifs does wear-leveling just great [06:23] SD cards tend to die much faster than SSDs, though. :P [06:23] (I've killed a lot of SD cards working on ARM porting...) [06:23] ahh, very heavy usage [06:23] would you recommend logging to tmpfs? [06:23] Logging to a tmpfs is reasonable, sure. Means you don't get permanence, but it's enough for spot disagnostics. [06:23] is it just the number of writes, or maybe to fast, etc? [06:24] Most embedded projects really don't need logs, though. [06:24] Or, really shouldn't? [06:24] i think, a minimal logging into ram is fine. for the rest a log-server should be used [06:24] Cause once you sell it to a customer, do you really expect them to be mailing you lofs? ;) [06:24] logs* [06:24] yes i do [06:25] scientes_: Speed doesn't really matter, it's just the number of writes, period. And yeah, logs are the worst culprit right after atime (but sane people always disable atime on flash) [06:26] mythos: If every set top box, phone, and smart TV in my parents' house expected them to be "informed and educated" users who filed bug reports with logs, I suspect they'd just stop buying these computers disguised as appliances. [06:26] infinity, what about relatime? [06:26] (mainly for completeness) [06:26] infinity, i have to care about thinclients, so... ;-) [06:27] scientes_: I've never seen the point in relatime. [06:28] scientes_: But it would fall in betweenish, I suppose. Much less likely to update, but it's still unnecessary writes for a flash device. [06:28] yeah, go with atime [06:28] i mean noatime [06:29] seems like btrfs might be smarter for a flash device---ugh [06:29] i still hate that ugly FTL [06:29] and would rather just put ubifs on it [06:29] mythos: Well, I tend to view thinclients more like "really crappy computers" than appliances, in the enviroments where most people use them. That said, it would be much nicer if they were appliances. [06:30] i don't like them either [06:30] but what shall i say... somehow i have to earn money [06:30] And back in the days when you could buy X terminals off the shelf from IBM and Wyse, and thin clients were much less fat than they are today, they were very appliancy. [06:31] ;___; i'm sorry [06:33] Oddly enough, I think we've almost come full circle. The full-features "appliance" IBM thin clients I used to work with that did seamless desktop convergence between X11 and WinNT/Metaframe were, if I recall, running StrongARM CPUs. [06:33] Really, really slow ones. :P [06:33] infinity, do you use udev in your chroots, or bind mount /dev ? [06:33] scientes_: Neither, I just mount devpts. But if you actually need all the nodes, bindmounting /dev is the sane option, yes. === LetoTheII is now known as LetoThe2nd [06:36] Oh, no. Wikipedia has educated me. Those were PPC (first gen) and Pentium (second gen). [06:36] how do i see what breaks a package without installing aptitude? [06:36] nvm, it just printed it out [06:39] infinity, as far as i know is arm rather new for thinclients.... i know a hp armv3-device, but that's it [06:40] mythos, even if it is new, it seems like it would be the way to go in the long run, considering the power consumption [06:40] mythos: Yeah, I'm trying to think of why I got confused about that one. Well, other than the part where it was 15 years ago and I'm old. :P [06:40] *g [06:41] scientes_, yes, you are right [06:41] it is the new hot stuff for citrix and vmware... (lot of work for me... that's why i'm here) [06:43] infinity, oh your right, multiarch wouldn't work because it doesn't include binaries [06:44] *executables [06:44] http://www.ebay.com/itm/IBM-07L8402-Network-Station-1000-/320556566601?pt=LH_DefaultDomain_0&hash=item4aa2a90849 [06:44] ^-- Memories. [06:44] And 95 bucks for nostalgia is tempting. [06:45] is there a multiarch way to have the binaries put in a special place, and then you just set your $PATH approiately [06:45] and have binfmtmisc with qemu do the rest?\ [06:45] scientes_: No. [06:45] scientes_: Multiarch pretty much assumes that you don't want the same binary twice. (which is a fair assumption, generally) [06:45] infinity, i have to support the emulator for this device ;-) [06:45] that way you could still use all your installed utilies in the not-chroot, like git, etc [06:45] scientes_: Of course, for development, this isn't a big deal, as you usually only need the foreign-arch libraries, not binaries. [06:46] scientes_: Still, chroots are much cleaner. [06:46] instead of having to have two terminals open for the chroot :) [06:46] infinity: is there a US mirror for ports [06:46] yes, two terminals at once isn't that big of a deal [06:46] infinity: netboot gives the otion of only UK [06:46] krosswindz: There may be one or two, but I don't know of any. [06:46] option* [06:46] infinity: thanks [06:46] krosswindz: The only official ports mirror is ports.ubuntu.com [06:47] infinity: ok [06:47] scientes_: Yeah, I guess I don't notice how or why it bugs people, because I've always done all my development in chroots, long before I could also do fancy emulated chroots. :) [06:48] scientes_: My laptop has pretty much nothing installed in the base system, and each bit of software I work on gets a new clean chroot. [06:48] (waste of space, maybe, but it helps maintain sanity) [06:48] http://paste.ubuntu.com/829746/ [06:49] scientes_: sed -i -e 's/main/main universe restricted multiverse/' /etc/apt/sources.list && apt-get update [06:49] hmm, why don't you use vserver with vhashify then? [06:49] so that all the duplicate files get hardlinked together in a sane way [06:49] which reduces both disk AND ram consumption [06:50] along with security which doesn't exist with chroots [06:50] Security's a non-issue. [06:50] For my use-case. [06:50] but what about vhashify? [06:50] This is just about not having junk in my base system, and not polluting package builds. [06:51] The de-duping might be neat, but *shrug*... Don't care? ;) [06:51] I build and delete chroots several times a day, it's not like they live long. [06:51] are you at least running the ram consolidation thingy designed primarily for KVM? [06:51] My workflow comes from more than a decade of buildd maintenance, it's not "sane" to most people, but it works for me. [06:51] it just scans ram and loops for things that are the same [06:52] sooo... chroot is a "good enough"-solution :o [06:52] RAM consolodation doesn't matter, I'm not running long-running processes in these chroots. [06:52] Build, compile, wipe. [06:52] http://paste.ubuntu.com/829746/ <----help [06:52] scientes_: sed -i -e 's/main/main universe multiverse/' /etc/apt/sources.list && apt-get update [06:53] ^-- I did. [06:53] infinity, ahh, yes universe needs to be on, thx [06:53] no multiverse thxuverymuch however [06:53] ;) [06:54] You shouldn't need restricted either, but you have it on. [06:54] (If you're trying to avoid non-free software sneaking up and biting you in your sleep) [06:54] that was just the default for the ubuntu core tar.gz [06:55] Yeah. I should revisit that. [06:55] I picked "main restricted" pretty arbitrarily when I first put core together, just based on the fact that it used to be our default in, like, dapper? [06:56] what is the default now? [06:56] I sometimes live in the past. [06:56] The default now is, I believe, all 4 components enabled after install. But I'm not positive of that either, I'd have to install a fresh Ubuntu. :P [06:56] definitely not [06:57] it just feels like that the way software-center works by default [06:57] Yeah, maybe. [06:57] Perhaps the default is still "main restricted", or possibly just "main". [06:57] I'm too lazy to dig through code right now. [06:57] Plus, "default" depends on how you install. Keeping those things in sync is annoying. [06:58] infinity, I think you should just enable main [06:58] oh wait, its not just armel [06:58] It's all arches. [06:58] i was thinking that the hardware that gets restricted put on default is not present with arm [06:59] But, that said, people shouldn't need fancy binary opengl drivers in a minimal chroot. [06:59] And if they do, they can edit sources.list. :P [06:59] ^^ precisely [06:59] so just put it main, and be done with it [06:59] Well, I was tossing around the idea of going the other way too. [06:59] Since people constantly say "I tried to install $foo and it's not found, is ubuntu-core crap somehow?" [07:00] Or "is this built on ARM?!" [07:00] i havn't looked for a while but it seemed like ubuntu was shipping some pretty schetchy stuff in multiverse [07:00] When the answer is, invariably, "enable universe". [07:00] compared to debian's non-free being pretty reasonable when i looked at it [07:00] scientes_: Well, multiverse is just the non-free component of universe. So, sure. I guess that's sketchy on top of sketchy. :) [07:00] But it's not like enabling it forces people to install things from it. [07:00] infinity, but it was bigger than debian's non-free [07:01] infinity: I am installing precise on an usb hard drive, I dont need a separate boot partition on it since that will come from the SD card right? [07:01] And we don't allow dependencies from main to universe or from universe to multiverse, so... [07:01] krosswindz: Right. [07:01] debian was like: nasa worldwind (open source, but bad license), xtides-data-nonfree (asshole govmnts), and hardware support [07:01] scientes_: Debian has, historically, been kinder to their mirrors with regard to non-free. [07:02] scientes_: If something was widely non-redistributable in, say, several EU countries, or the US, or whatever, they wouldn't carry it. [07:02] scientes_: multiverse, we just say "look, it's hosted in the UK, mirrors don't have to mirror it, if they do, we assume they've read the licenses, HTH, HAND". [07:02] it drives me nuts how governments, that need good map data in order to do taxes, etc, double charge their citizens [07:03] the US is like the only sane country in this regard [07:03] scientes_: Yeah, well. The US and software sanity is a sore topic for Debian too. It took us FOREVER to get rid of the stupid "non-US" split for crypto. :( [07:04] the NSA managed to hold back encryption for 10 years with that stupid shit [07:04] And even then it involved something like 850 pages being sent to the US government. [07:04] By hand. [07:04] also: software patents [07:04] StevenK: Yeah, it was tons of special. [07:05] StevenK: I haven't kept up, do you know if Debian's finally managed to obtain a blanket waiver, or if ftpmaster is still automating an e-mail to the US govt for every NEW package? [07:05] I think its the latter. [07:05] Ridiculous. ;) [07:08] infinity, what percentage of packages correctly cross-compile? [07:09] scientes_: Like xdeb, cross-build the package style? Probably a much lower number than you'd like. [07:09] scientes_: Building natively (or "natively" under emulation) is still the way to go. [07:09] yeah, i just assumed that I should default to natively [07:10] We've been working on improving the numbers for cross support for specific dependency chains. [07:10] sure the kernel can do it, but not much else [07:10] are there any list of what chains work? [07:10] But, personally, I think it's wasted effort. ARM hardware is getting faster every day and, while I appreciate that people are spoiled and all, if I can build the entire armhf archive in ~15 days, it's not "slow". [07:11] it supposedly fixes alot of bugs to get cross-compile working [07:11] scientes_: Not sure how far that's gone. It was mostly being done by Linaro folks, IIRC. I'll be at Linaro Connect in, like, 2 days though, and I think we have a catch-up session on it. :P [07:11] scientes_: Err, what? How would cross-compiling fix bugs? [07:11] scientes_: That sounds a whole like like misinformation. [07:11] s/a whole/a whole lot/ [07:11] probably is, only read it once [07:12] some random comment on lwn or something [07:12] At best, cross-compiling will provide you with binary-identical output, at worst, the cross version will be horribly broken compared to the native. [07:12] I can think of any scenario where it would be better. :) [07:12] I built the linux kernel with distcc on x86_64 and arm at the same time, and it booted! [07:12] s/can/can't/ [07:13] In general, cross should get you binary-identical output these days. GCC and binutils are much saner than they used to be. [07:13] But. [07:13] There's always a but. [07:13] And the buts never favour the cross environment. [07:13] infinity: what about cross chroot using qemu [07:13] krosswindz: That's essentially "native", for the purpose of this discussion. [07:13] yes [07:13] ok [07:14] cross-compiling is much faster [07:14] emulation is not [07:14] but I was definitely impressed with i could use distcc with arm and x86_64 cross at the same time, and boot what came out [07:15] infinity, oh geeze, you should have put no-install-recommend in the core..... [07:16] oh wait, i guess it did that [07:16] just alot of stuff [07:19] scientes_: You can specify it on the command line. [07:20] i know that, i thought it was installing a bunch of worthless stuff, but i scrolled up, and it listed the recommends sep, which IIRC means it didn't install them [07:20] I type "apt-get --no-install-recommends --purge install $foo" so often that it's muscle memory. :P [07:20] scientes_: No, it lists them even if they're also in the install list. If you didn't specify it, you got recommends. It's our default. [07:21] ahh ok, tons of worthless stuff [07:21] as i suspenected [07:21] it was alrady installing when i was like O shi... i forgot [07:21] Heh. Oh well, not world-ending. :P [07:22] The only place where we actually have no-install-recommends in the apt config is our buildd chroots. [07:22] For obvious reasons. [07:22] i have added it to apt.conf.d so many times..... [07:22] I also forgot to use my apt-cacher-ng..... [07:22] infinity: I was trying to install using net boot to USB drive [07:23] kernel fails to install [07:23] any way to check the log over serial console? [07:23] krosswindz: Weird. It definitely shouldn't. [07:23] krosswindz: It logs to syslog. [07:23] krosswindz: But I'm about to head out. You might try poking GrueMaster tomorrow about it, he netinstalls all day, every day. [07:24] lol k [07:24] if I want to check syslog [07:24]