| dijenerate | hi all | 00:33 |
|---|---|---|
| dijenerate | I've just created a custom build of ubuntu-mobile for a trial enterprise deployment... | 00:34 |
| dijenerate | I need to make an easy installer/recovery disk from the prototype build | 00:34 |
| dijenerate | what is the easiest/fastest way to make a bootable iso that will install this build to new hardware | 00:35 |
| dijenerate | I can do this presently by using the 'dd' command to overwrite the target device | 00:36 |
| dijenerate | I'd prefer to automate | 00:36 |
| persia | Do you know the set of changes you made to a default image? | 00:36 |
| dijenerate | they are documented but the list is looooong | 00:37 |
| dijenerate | I'd prefer to just have an auto-installer dump this onto a new drive | 00:37 |
| persia | Was it just package changes, or config changes as well? | 00:37 |
| dijenerate | configs as well | 00:37 |
| dijenerate | plus custom packages etc | 00:37 |
| persia | Hrm. That gets tricky then. | 00:38 |
| persia | So, there's no good way to get an installed system back into an installer | 00:38 |
| dijenerate | it no longer uses hildon, but boots to the company's custom window manager | 00:38 |
| dijenerate | oh... that sucks | 00:38 |
| persia | And using dd has a number of frustrating associated issues related to install-time stuff. | 00:38 |
| persia | But there are a number of tools that can help to modify a live image. | 00:39 |
| dijenerate | well I have prepped an image that is ready to be configured | 00:39 |
| persia | And that can then be used for an install of the modified system. | 00:39 |
| dijenerate | so it boots up, creates the new /etc/udev/rules.d/70*persistent-net... etc | 00:39 |
| persia | You've already prepared a custom live image for your target? | 00:39 |
| dijenerate | as well as prepping all necessary scripts for the stuff that's unique for the hardware | 00:39 |
| dijenerate | yes, that's what I dump using dd | 00:40 |
| dijenerate | it takes care of the filesystem (ext4) and the mbr | 00:40 |
| dijenerate | so I was just looking for an automated way to do this from a cd/usb drive that someone who isn't from engineering could use | 00:40 |
| persia | I think we're running into a definition issue. A "live image" is something like a USB stick or ISO that will run live OR perform an install. An "installed image" is the result of having performed an install. | 00:41 |
| dijenerate | we currently dump with dd, then grow the fs to fill the new drive | 00:41 |
| persia | Which have you prepared? | 00:41 |
| dijenerate | installed, but ready for setup | 00:41 |
| dijenerate | so in the 'first time' state | 00:41 |
| persia | Right. I get it. | 00:41 |
| persia | Are you using oem-config? | 00:42 |
| dijenerate | nope... actually a lot of the custom ubuntu stuff has been stripped to give a lighter thinner ubuntu | 00:42 |
| dijenerate | needs only 170MB RAM and 800MB disk space | 00:42 |
| dijenerate | so the special oem-config stuff is no longer there | 00:43 |
| persia | OK. I think I understand your current state. | 00:43 |
| persia | I don't know of any tools that would construct an installer image from that. | 00:43 |
| dijenerate | oh... crap | 00:43 |
| persia | I can walk you through the process of modifying an installer image to include the changes. | 00:43 |
| dijenerate | hmmm... I'd probably would be better off, scripting the dd and grow fs commands then creating a tarball in a folder on a live cd image | 00:44 |
| persia | But that is mostly for changes in package selection. If you have additional configuration, that usually involves a combination of a special foo-default-setttings package and some changes to existing packages. | 00:44 |
| dijenerate | just set to boot then run the script | 00:44 |
| persia | There are a number of issues with using dd on an installed image for mass-production. | 00:44 |
| dijenerate | some of the packages are from our own repo and are foreign to ubuntu | 00:45 |
| persia | Some examples are that all installed devices would have the same initial cryptographic salt. | 00:45 |
| persia | Some tools contain information about volume sizes that are confused by grow_fs | 00:45 |
| persia | And some configuration of the system is *only* done by the installer. | 00:46 |
| dijenerate | hmmm... the thing is, so far we have done multiple lab trials and tests with the image and used dd for each install on test hardware | 00:46 |
| persia | Using foreign packages is not a problem at all. | 00:46 |
| dijenerate | we have scripts for the configs | 00:46 |
| dijenerate | so that is taken care of on first boot | 00:46 |
| dijenerate | it's a seriously hacked build | 00:47 |
| persia | Indeed. I wish I'd caught you earlier in the process :) | 00:47 |
| dijenerate | lol... that would have saved us both a lot of probs at this stage eh? | 00:47 |
| persia | Yeah. | 00:48 |
| dijenerate | I wonder if we can still call this ubuntu or should it be renamed 'xyz distro based on ubuntu'? | 00:48 |
| persia | Are you using a swap partition? | 00:48 |
| dijenerate | sorta like mer | 00:48 |
| dijenerate | no swap part | 00:48 |
| dijenerate | single part install | 00:48 |
| persia | You can't call it "Ubuntu" if you modified it with stuff not in Ubuntu. | 00:48 |
| dijenerate | figured... we'll have to come up with a name for this one | 00:49 |
| dijenerate | it's extremely lightweight, like linux distros of old | 00:49 |
| persia | No swap partition solves some of the issues with resizing the filesystem. | 00:49 |
| dijenerate | yeah, we used the single ext4 from the get go to make installations 'easier' | 00:50 |
| dijenerate | so much for that | 00:50 |
| persia | Rather than using the installer :) Heh. | 00:50 |
| dijenerate | the image is stored as a clean tarball with no lost+found, no bash history, no log files, not apt cache... it's clean as a whistle | 00:51 |
| dijenerate | just needs to be extracted to a bootable ext4 | 00:52 |
| dijenerate | we created a dd image to take care of the installation of grub | 00:52 |
| persia | And the bootloader installed, etc.? | 00:52 |
| dijenerate | one less step | 00:52 |
| persia | I thought that grub stored the disk geometries in the config. | 00:52 |
| dijenerate | all scripts installed just needs the mbr | 00:52 |
| dijenerate | the mbr needs to know what the first boot device is | 00:53 |
| dijenerate | and what the fs of that device is... so still need to have the right mbr entry | 00:53 |
| dijenerate | other than the mbr entry, everything is in the tarball | 00:54 |
| persia | And how are you deploying the tarball, or is that what brings you here? | 00:54 |
| dijenerate | that's why I'm here | 00:56 |
| persia | Right. | 00:57 |
| dijenerate | I was trying to find an automated way to do it | 00:57 |
| persia | So, we have two installers. | 00:57 |
| dijenerate | it just needs to be extracted to root of a single bootable ext4 partition | 00:57 |
| dijenerate | then we install grub to the mbr and we're ready to go | 00:57 |
| persia | One of them does the base setup, then installs each package from a pool, then does final setup. | 00:57 |
| dijenerate | actually, they both do the same | 00:58 |
| dijenerate | neither has to install any packages | 00:58 |
| persia | The other puts the result of an installation of all the packages in a chroot into a squashfs, and then boots with that as a unionfs and runs some special scripts in the initramfs. | 00:58 |
| dijenerate | everything is in an installed state in the tarball | 00:58 |
| dijenerate | not even necessary | 00:59 |
| persia | I don't think the first will help you, as I have the impression that you'd end up needing to massively rework your configuration scripts. | 00:59 |
| dijenerate | we literally just have to extract the tarball to the bootable ext4 partition, install grub to the mbr and the system is ready to boot | 00:59 |
| persia | The second relies on there being an installer tool included in the squashfs, which would require modifications to your image that would not be preserved on deployment, which would probably mess up your prior testing. | 01:00 |
| dijenerate | the initial setup is for user id and network security config of the terminal | 01:00 |
| persia | So, if you wanted to use an Ubuntu installer, I'd suggest attempting to stuff your tarball into a squashfs, and trying that. | 01:01 |
| persia | But that might well be fairly painful as you have to differentiate the boot of the live image and the first-time boot. | 01:01 |
| persia | So, I think you need a new installer. | 01:01 |
| persia | Are you expecting mass-installs or end-user installs? | 01:02 |
| dijenerate | is there no way to get a live ubuntu disk to just boot, format the host drive according to a script, install grub to the mbr then extract the tarball to root? | 01:03 |
| dijenerate | mass installs | 01:03 |
| dijenerate | but it needs to be 'non-tech' proof for recovery or emergency installs | 01:03 |
| persia | There are lots of ways to do it, none happen to be recommended as an install method. | 01:03 |
| dijenerate | lol | 01:04 |
| persia | For your specific case, you might want to perform a minimal installation of Ubuntu Server (without any servers) onto a USB stick. | 01:04 |
| persia | Then copy your installation images into that media | 01:04 |
| dijenerate | well the installed doesn't need to be x-based either... a simple terminal with progress output is fine | 01:05 |
| persia | And then create an initscript that would perform the required actions to partition, create the filesystem, copy the data, etc. | 01:05 |
| persia | Ubuntu Server doesn't include X by default, which is why I suggested it :) | 01:05 |
| dijenerate | ok, perfect | 01:05 |
| persia | For mass-installs, bringing up a whole GUI is often considered slow. | 01:05 |
| persia | Again, this is not a recommended way to install, and I predict you'll encounter issues later. | 01:06 |
| persia | When that happens, I do encourage you to come back, and we'll look at how to create a mass-install image in a recommended fashion. | 01:06 |
| dijenerate | ok, thanks | 01:06 |
| dijenerate | lol | 01:06 |
| persia | Good luck. | 01:08 |
| dijenerate | thanks | 01:08 |
| === asac_ is now known as asac | ||
| === robbiew_ is now known as robbiew | ||
| === robbiew is now known as robbiew-AF | ||
| === robbiew-AF is now known as robbiew-afk | ||
| === kung|away is now known as kung | ||
| === robbiew-afk is now known as robbiew | ||
| === kung is now known as kung|away | ||
| === robbiew is now known as robbiew_ | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!