[00:00] <cjwatson> I think those may be regrettably missing.
[00:00] <jkitchen> ok
[00:00] <jkitchen> maybe I'll fire up another netconsole install and poke around :)
[00:00] <jkitchen> thanks!
[00:00] <cjwatson> http://d-i.alioth.debian.org/doc/internals/index.html covers them.
[00:01] <jkitchen> perfect
[00:01] <jkitchen> seriously googling for this stuff is nearly impossible :(
[00:02] <cjwatson> The downside of popularity.  It used to be easier.
[00:02] <jkitchen> hehe
[00:12] <jkitchen> and there's no way to define hooks directly in the preseed file apparently?
[00:12] <jkitchen> other than using an early_command to write them out that is
[00:15] <jkitchen> hook/post-base-installer/1 string "foo"
[00:15] <jkitchen> for instance
[00:15] <jkitchen> (would be really cool if it could do that)
[00:15] <cjwatson> Sadly not.  I've always kind of meant to get roudn to that
[00:15] <cjwatson> *round
[00:16] <jkitchen> is there a preferred place to submit feature requests? I'll go ahead and put one in
[00:16] <jkitchen> not that I'm gonna wait for it to get done, but it might be helpful for folks in the future or such
[00:18] <cjwatson> https://bugs.launchpad.net/ubuntu/+source/debian-installer/+filebug I guess
[00:19] <jkitchen> cool, thanks!
[00:19] <cjwatson> Actually you might need to use https://bugs.launchpad.net/ubuntu/+source/debian-installer/+filebug?no-redirect to stop it sending you through ubuntu-bug or whatever
[00:19] <cjwatson> (Which isn't going to be helpful in this case, although it often is)
[00:28] <jkitchen> submitted. thanks!
[01:11] <jkitchen> root@ns1:~# id puppet
[01:11] <jkitchen> uid=600(puppet) gid=600(puppet) groups=600(puppet)
[01:11] <jkitchen> cjwatson: thanks again, got it working
[07:18] <cjwatson> jkitchen: excellent
[08:51] <FourDollars> What grub's debug parameter should I use when I encounter some problem that it can not boot to the grub menu?
[08:51] <FourDollars> But I can see grub menu after several cool boots.
[08:55] <cjwatson> Simplest way is to use the --debug-image=all parameter to grub-install and try to capture the last screenful of output
[08:56] <FourDollars> The issue is happening in GRUB instead of Linux kernel.
[08:57] <FourDollars> I thought it is to put some command in /boot/grub/grub.cfg .
[09:00] <FourDollars> OK. I may understand.
[09:02] <FourDollars> cjwatson: Thanks a lot.
[09:08] <FourDollars> I put 'set debug=all' in /boot/grub/grub.cfg . It should be the same.
[09:11] <cjwatson> Not if it fails to even get to the point of reading grub.cfg
[09:11] <cjwatson> But I guess you know best and don't need me then :-P
[09:11] <FourDollars> So far it can read k
[09:11] <FourDollars> So far it can read /boot/grub/grub.cfg .
[09:12] <FourDollars> So I can see the debug messages.
[09:12] <FourDollars> Somehow it gets stuck before entering GRUB menu. :(
[09:33] <KnorrieBorrie-HP> after new install on new Dell-Inspiron14z(pre-loaded-withwin8), installed from live-USB ubuntu13-64bit on space created next to win8 (using Gparted) install finished nicely, yet failed to boot, used boot-repair-live-media to repair, after reboot, showed Grub menu, loads windows correctly, but when trying to load Ubuntu from grub menu, just hangs showing blank purple screen see: paste.ubuntu.com/5883944/ Anybody got ideas?
[09:42] <FourDollars> 'debug=all' is the most verbose parameter. Which is the second one?
[09:44] <FourDollars> Or is there a list of debug parameters?
[09:46] <cjwatson> FourDollars: from there you just have to find the debug category you're interested in and enable only that
[09:46] <cjwatson> (or categories, separated by ,)
[09:48] <FourDollars> cjwatson: Is there any category list available?
[09:48] <cjwatson> Only in the source I'm afraid
[09:48] <FourDollars> :(
[09:49] <cjwatson> But debug=all is for developers anyway ...
[09:49] <cjwatson> So you're expected to accompany it with source-diving
[09:49] <FourDollars> 'debug=all' shows too many messages and it is slow.
[09:50] <cjwatson> However the last thing it outputs should give an idea of where it hangs
[09:50] <cjwatson> I never actually read all of debug=all, it's just a way to get an approximation of how far it got
[09:50] <FourDollars> I see.
[09:52] <FourDollars> Is it possible to redirect the output to a serial console?
[09:53] <FourDollars> https://help.ubuntu.com/community/SerialConsoleHowto
[09:54] <cjwatson> https://www.gnu.org/software/grub/manual/grub.html#Serial-terminal
[09:59] <FourDollars> Is it possible via USB?
[10:01] <FourDollars> debug=usb ?
[10:04] <FourDollars> No, it is not this way.
[10:11] <FourDollars> The screen is cleared by the purple background, and then it halts. :(
[10:12] <FourDollars> All debug messages are disappeared.
[10:13] <FourDollars> Maybe I should try it by entering grub commands manually.
[21:38] <stgraber> gah, seriously... those autopilot changes in ubiquity could have done with a tests/run before being pushed...
[21:39] <stgraber> the files contained mixed spaces and tabs, a ton of unneeded imports, broken indent and a ton of whitespaces not to mention 20 or so blank lines at the end of the files...
[21:39] <stgraber> I was hoping for a quick ubiquity upload, not having to fix all that mess...
[21:44] <stgraber> yay, I've got a source package! now let's see if I can get that thing to build (I have a feeling that even if it does, it's going to blow up in autopkgtest when I upload, but oh well...)
[21:44] <xnox> stgraber: fork. and upload. sorry about that.
[21:44] <xnox> stgraber: yeah, i'm trying to stage the autopilot test run, it will blow up at the moment.
[21:45] <xnox> stgraber: sorry, it's been a big piece of work i am hoping to land today..... =/
[21:46] <stgraber> xnox: hmm, ok, well I fixed a bunch of the obvious issues in lp:ubiquity
[21:46] <stgraber> xnox: and now running a build locally to see what else explodes. If that passes, do we have an easy way of turning off the bits we know will fail at test time?
[21:47] <stgraber> so I can just upload from the branch instead of having to deal with branching and rebasing
[21:47] <xnox> stgraber: debian/tests/control should not list "autopilot"
[21:47] <stgraber> xnox: it doesn't at the moment
[21:48] <xnox> right, than it shouldn't run =)
[21:48] <stgraber> good, so let's hope the other existing tests will be happy then ;)
[21:48] <stgraber> ah, apparently not, just got a FTBFS from sbuild...
[21:48] <xnox> stgraber: push the branch, and I can run the adt test runner on my machine quickly to check.
[21:48] <stgraber> xnox: lp:ubiquity is up to date (just haven't tagged for release)
[21:49] <stgraber> my sbuild failure was network related... retrying
[21:49] <xnox> stgraber: autopilot stuff is python2, yet the checkers are python3 =/ so whole autopilot/ should be ignored.
[21:50] <stgraber> well, pyflakes seems to be happy at the moment, but yeah, if it's always going to be python2, it probably should be added to the ignore list
[21:51] <xnox> and well, automatic update of d-i stuff needs running (unless you did that on your end) to pick up your updated grub-installer
[21:51] <stgraber> I did that here
[21:51] <stgraber> that's one of the reason why I want an ubiquity upload
[22:09] <stgraber> xnox: looks like it built succesfuly! (didn't remember it taking so long to build...)
[22:09] <stgraber> will do a quick spot check of the binaries and push to the archive
[22:11] <xnox> ack.
[22:14] <stgraber> and uploaded, will test that stuff tomorrow and then figure out how to get it into precise (that's quite a few packages to land in the right order...)
[22:48] <xnox> ohhh it worked.
[23:11] <stgraber> well, we'll see tomorrow if the images work too ;)
[23:13] <xnox> stgraber: nah, I'm about autopilot tests in nested qemu =) so our autopkgtests performs ubuntu installs in qemu \o/ =)