[00:35] Ok, just installed 12.04 server on a vm. After getting to a login and running "apt-get update;apt-get dist-upgrade", when I try "apt-get install oem-config" it tries to install the KDE stack (347 packages). Not the gtk stack, just the kde stack. [00:36] Something is pulling in ubiquity-frontend-kde (which wants the rest I would assume). [00:45] http://paste.ubuntu.com/5678383/ [00:49] * GrueMaster is out for the day. [08:52] GrueMaster: as we said. "apt-get-install oem-config" is not enough, you want "apt-get install ubiquity-frontend-debconf oem-config-debconf oem-config" instead. There is no way to sanely specify alternatives, thus one must list the desired frontend first. [15:50] Ok, so that works around the dependency issue. Now to work around the real problem. [16:01] yeap. We "expected it to just work™" [16:09] xnox: If it "just worked", do you honestly think I would be asking questions here?? Please try to remember that I was doing QA for Ubuntu on Arm for 3 years before being booted due to office politics above my pay grade. [16:10] Sorry, it was a joke. I understand that you are hitting a bug in oem-config-debconf, which frankly is not tested that well. [16:11] That I am aware of (and part of the reason I am no longer at Canonical). [16:12] But I really do not want to go down that path. What I need is a solution. [16:18] Currently I am staring at a screen full of init output and no oem-config. This is in a kvm session after doing a server install, logging in, then installing oem-config (as listed above) and running oem-config-prepare and rebooting. [16:18] I'll try to post a screenshot somewhere. [16:21] http://members.dsl-only.net/~tdavis/Ubuntu-server-post-oem-config.png [16:21] Will try on bare hardware soon (hopefully in the next hour or so). [16:21] is there a Ubiquity developer here? We have a critical bug that affects 13.04. [16:22] GrueMaster: hm. I'd install the VM differently, let me test here something. [16:22] simosx: post a bug number? [16:22] https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1158750 [16:22] Launchpad bug 1158750 in ubiquity "Ubiquity does not create correct UTF-8 locales" [High,Confirmed] [16:23] The solution should be very simple, just append ".UTF-8" to the generated locale. [16:23] With this bug, LibreOffice crashes on start. Other apps do not work. [16:24] How would you install the VM differently??? The purpoose of this install was to test the ability to run oem-config after installation and system modification. The later part cannot be automated via preseed. [16:26] The problem happens when you install Ubuntu with the default English locale, but if you are located in another country (such as Greece), then through geoip/timezone, the installer sets the "el_GR" locale as well. [16:26] GrueMaster: not install oem-config manually, but instead let the installer put it in place. I'm running an installation here at the moment. Might take 10minutes or so. [16:26] And it's "el_GR" instead of "el_GR.UTF-8". [16:26] that is, 8-bit character set and all the problems that come from that. [16:28] xnox: That won't work for this situation. I need to install and build our test environemt (which includes kernel modules) and run it on the test hardware prior to configuring the system for shipping to customers. [16:29] In otherwords, I cannot just do an install and ship. [16:29] xnox, how can I assign the bug to someone from the Ubuntu Installer team? [16:30] GrueMaster: one gets a root account & allowed to boot and customize system many times. Before shipping, one needs to touch a magic file and then the next boot will be expected to be done by the customer. [16:30] GrueMaster: it's a two step installation. [16:31] xnox: That has never been my experience with the server installs when selecting oem-config during install. Next reboot it prompts for user info. [16:32] And the "magic file" is /var/lib/oem-config/run (which is created by oem-config-prepare). [16:32] well it did work correctly on the alternate cd installs during quantal cycle which should be very similar. [16:33] anyway testing at the moment with a raring cd. [16:34] sigh. Can't use Raring. requirements here are for LTS releases only. [16:34] And I am trying really hard to push for Ubuntu first. Just not getting very far. [16:35] sure, sure. I'm just making sure it works with raring (if it does great, if precise doesn't behave the same way i have somewhere to cherry pick a fix from). If it doesn't even work with raring, then there will be some extra digging required. [16:36] Makes sense. [16:37] GrueMaster: and alas, it fails to boot with grub not finding it's modules. *sigh* [16:38] The bug that simosx reported creates a bug issue on Ubuntu GNOME 13.04 (which will be official). [16:38] The problem with the locales affects datemenu.js file and gdm nor gnome-shell are able to load. [16:59] bug 1165092 [16:59] Launchpad bug 1165092 in debian-installer (Ubuntu) "oem-config fails with ubuntu-server images" [High,Confirmed] https://launchpad.net/bugs/1165092 [16:59] GrueMaster: broken in raring in a similar manner. [17:00] ogra_: how does oem-config manage to work at all with debconf frontend in e.g. precise/server/panda images? [17:25] xnox: Give me a sec, I can look at jasper-initramfs and figure it out. Just need to remote into my home system (which is currently processing updates). [18:13] xnox: Ok, jasper does the following: [18:13] mkdir -p /root/var/lib/oem-config [18:13] touch /root/var/lib/oem-config/run [18:13] That's all. [18:14] This is from the preinstalled images (panda, beagle, etc). [18:16] hm..... but panda/beagle/etc all have a single serial/known tty to boot to. With typical intel server it's grub & vt handovers. (e.g. on first boot in the vm I had to manually switch to tty1) [18:36] xnox: I have to image a new system this afternoon, so will also be able to test again on bare hw (which is my main focus for this). I'll try to post the python errors I saw earlier. === superm1_ is now known as superm1