You installed from at least two daily-live images before. They were both successful.

Then you tried the most recent two daily-lives when they came out, and they failed. You've gone the extra mile and verified that it fails by attempting to reinstall with it several more times. It's continued to fail at the same point and in the same way as before.

You should file your bug report now.

You don't have to go back again and make sure it still works the way it used to work. It's a daily-live. It's expected to work, fail, and (with hope, eventually) work again, from one day to the next.

Some Guidelines for Hard-to-Report Bugs in Daily Builds

If you haven't done so already, make sure to read this thoroughly. For good general information (not specific to Ubuntu) for reporting bugs, take a look here. It may be a good idea to be familiar with this and this too.

Which package you'll report the bug against, and what kind of technical information you should try to collect, will be determined by how the error occurs and what it looks like.

This is less of a flowchart and more of an explanation of basic bug troubleshooting and reporting for alpha/beta releases, starting with the chronologically earliest (after booting) and hardest to report bugs, and building up to the later and often more easily filed bugs.

You will need a keyboard in order to do some of this, but if you're unable to provide as much information in your bug reports as a consequence, you should still report bugs as you find them.

I have written this to address the general case of your situation (with the hope that it will help others too in a variety of daily-live testing scenarios); don't worry when some of this doesn't apply to you.

However, you may want to attempt to install a Bluetooth keyboard so that you can perform a wider range of troubleshooting methods. Depending on where the bug happens, this might or might not be practical. If you want to attempt that, these resources may help. Also, please note that a laptop with Bluetooth can be used as a Bluetooth keyboard for your tablet.

1. If you never get as far as the GUI loading, and the Plymouth splash screen (with Ubuntu and the colored dots) doesn't even come up, try booting with nomodeset. Whether or not that succeeds, report the bug against the package linux.

   If it succeeds, that's important information, plus it lets you report the bug better by starting with ubuntu-bug linux or, if you only have a command-line, apport-cli linux. For more information, see man ubuntu-bug and man apport-cli.

2. If the GUI never loads but you get a virtual console, or you are able to get one by pressing Ctrl+Alt+F1 or Ctrl+Alt+F2, then report the bug against xserver-xorg (unless you suspect it's a particular video driver and know or can find the name of the package that provides it). Use apport-cli if possible.

   Make sure /var/log/Xorg.0.log gets attached to the bug report. On a live system, especially one that fails early such that you cannot get the GUI up and working again, there will usually be no Xorg.0.log.old in /var/log, but if there is one, make sure it gets attached too.

   Also make sure /home/ubuntu/.xsession-errors and /home/ubuntu/.xsession-errors.old are attached, if they exist. If the problem happens early, it's likely neither will exist.

   If you can get a virtual console at any point, and you can connect to the Internet, it's not too hard to file bugs with excellent technical information included.

   You can use apport-cli, and you can transfer any additional files you need to attach to the bug report to another machine (as you might find Launchpad cumbersome to use with a text-based web browser like links2).

   It's usually hard to connect a machine to the Internet via wireless without a GUI (most wireless users have GUI's so it's sort of a niche thing and there hasn't been a command-line client for the Network Manager for several releases now). So if possible, the easiest way to connect to the Internet may be via Ethernet (if you have the necessary hardware, including an Ethernet card in your computer). Of course, if you're testing on a virtual machine, connecting it to the Internet should be no problem.

   If you have another machine (or this is a virtual machine), sometimes it's quite useful to install an SSH server so you can connect to it from outside. This makes copying and pasting text from the terminal easy, and for that reason I almost always do this when I have to use apport-cli.

   You can also run graphical programs on the testing system and have their interfaces appear on the SSH client (this works even if the GUI on the testing system has problems and even if the X server does not start at all). This can be very handy--you can run ubuntu-bug graphically, for example. (You can also run the ubiquity installer even when the GUI isn't working on the the machine...but when the GUI isn't working, your energy as a tester would usually be better devoted to investigating and bugreporting that.)

3. If the desktop loads but you cannot select between Try Ubuntu and Install Ubuntu, see if the text-based boot menu works to let you choose one. Press Spacebar (or any key) as the keyboard and person icons appear near the bottom of the screen (this is around when the DVD/USB is first starting to boot). This should make the text-based boot menu appear. You can select the option you want with the arrow keys and press Enter.

   If selecting between trying and installing Ubuntu is just broken on the graphical screen, it's likely you've found a bug in the ubiquity-dm executable, which is provided by ubiquity, the same package that provides Ubiquity, the graphical installer. In this case, the best thing to do would be to produce the bug, then go to a virtual console, use pidof or pgrep, or ps piped to grep (ps ax | grep ubiquity-dm) to get the PID for ubiquity-dm, then run apport-cli PID (replacing PID with the actual number of course).

4. If you can select between Try Ubuntu and Install Ubuntu but one of them doesn't work, that's important information. Try again and pick the other one.

   • If Try Ubuntu works and you get a fully functional desktop, try running the installer. It will likely (though not necessarily) not work. Then you can report a bug against it. (You have a fully working desktop environment, after all.) Sometimes additional information about what goes wrong can be obtained by running Ubiquity from a terminal window. To do this, press Ctrl+Alt+T. For Ubuntu, run ubiquity gtk_ui; for Kubuntu, ubiquity kde-ui. The --debug/-d flag is sometimes useful but read the manpage first so you understand where it's putting the verbose debugging output, and remember it causes just about everything to be logged including any passwords you enter during installation!
   • If Install Ubuntu works, the installer runs. Normally, it's possible to cancel the installer, which drops the user to a fully functional desktop. See if that works.

   Whatever doesn't work, you can bugreport (which is the most important thing). Whatever does work, you can test (and bugreport anything about it that turns out not to work, or not to work right). In all your bug reports, make sure to report exactly what you were trying to cause to happen, what you did, and what did happen.

5. If you're in the installer, or another application, and the GUI stops working (to such an extent that you cannot continue running graphical applications on the machine), see if it's reliably triggered by the same event. If it is, cool! That should definitely be reported as a bug. (If it just happens from time to time, that should still be reported as a bug.)

   Go to a virtual console and see if it's due to a crash. One easy way to do this is to check if there is a .crash file in /var/crash. If there is not, then either Apport crash reporting is disabled (which has sometimes been the case for early alphas, you can run cat /etc/default/apport, if enabled=1 it's enabled).

   If there is a crash file, run apport-cli on it to report the crash. If the problem wasn't a crash, report it against xserver-xorg (unless there's another package you suspect is the cause), using apport-cli xserver-xorg if you can.

6. If the GUI stops responding but still looks OK, that might be triggered by an application (such as Ubiquity) freezing in such a way that it monopolizes the X server and prevents new input from given.

   ^{If someone can explain better how and why that happens, an edit would be most welcome!}

   I'm not sure if it's better to report that against the app that triggered it or against the X server, but I think probably the app, as something went wrong there first.

   In any case the first thing to do is see if this is the case, by quitting the application. You can use the same process utilities explained in part 3 above to figure out the PID (or PID's, some applications, including Ubiquity, have more than one associated process) of the application you suspect is the trigger. Then you can attempt to terminate them with kill, killall, or pkill. For example, to terminate a process whose PID is 4000, run kill 4000. If that doesn't do the trick (you can use ps or similar utilities again to see), try kill -KILL 4000 (which sends SIGKILL instead of SIGTERM). If you get a Permission denied or similar error, try running it as root--that is, sudo kill 4000 or sudo kill -KILL 4000.

   After you've killed the application successfully, go back to the GUI (Alt+F7) and see if it's responding again. If so, that reasonably well confirms that the application whose process(es) you just killed were responsible for, or at least involved in, the problem.

   Once you've verified that this is what's happening, reproduce the freeze, then switch to a virtual console and report the bug with apport-cli PID.

7. If a problem occurs that doesn't keep the GUI from working right, great! Finding bugs is the main purpose of testing, and finding bugs that don't make their own reporting difficult is the best scenario.

   • If it's a crash, let Apport collect and send the stack trace and other important technical information, then fill out the report.
   • If it's any other kind of bug, use ubuntu-bug whenever possible as some valuable information is still sent. Generally, if it's a bug that's showing itself in the way an application is running--especially if the application is not responding--it's especially valuable to invoke ubuntu-bug with the PID of the application. Or, since your GUI is working, you can run ubuntu-bug -w and click on the ailing application window.

Here are some general considerations to keep in mind, no matter when your bug occurs, what it looks like, and what information you're able to discover about it:

• When you report a bug that isn't a crash, what package it's in is often a guess. It's best to make it as educated as possible a guess, but sometimes the bug has to be seriously investigated before anyone can know. Furthermore, there's no way for me to give a thorough explanation of how always to figure out what package is affected (mainly because I often don't know how, but also because there are many considerations; a full treatment of the subject might be an entire book).

  The package for a bug can be changed after the bug is reported, so you shouldn't let not knowing what package a bug affects keep you from reporting it for too long.

  It's also possible to have a bug filed against more than one package at a time. After you submit a bug report on Launchpad, you can add additional packages. You can also add upstream projects (typically those corresponding to the affected package or packages in Ubuntu against which the bug was first reported), and packages in other distributions (but you should generally only add them if you know the bug occurs there, and there is a bug report on the other distribution's bug tracker).

• Search first before submitting a bug report, especially if it's not a crash bug. (The materials linked to near the top of this answer explain how to do this properly.)

• Your bug report should be clear, and as detailed as you can reasonably be. Bugs in daily-lives should indicate the date of the daily-live if possible. If you know what daily-live appears to have introduced the bug, definitely include that information!

Obtaining a Particular Daily Build

Usually, you want to use the latest daily-live. See if there's a newer one here than what you already have. It's virtually always best to test with the latest daily-live.

^{(Or the latest daily-preinstalled, if that's what you're testing...though that's largely outside the scope of this answer.)}

If a bug appears to arise with a particular daily build, it's often unnecessary to test again with a previous one. This is especially true for bugs that always happen (which appears to be the case in the example scenario you have). For random crashes, on the other hand, it might be worthwhile to go back to a recent previous daily-live to see if you can produce them. However, typically this should only be done if (a) it's reasonably quick and easy for you to accomplish, or (b) something is known about the bug that indicates it's especially important to figure out exactly when it started.

Usually, it's sufficient to go back one daily-live. The server always stores two. (On rare occasion there's more than one daily-live in a day, and then the server will sometimes have three at a time, but still not spanning more than two days.)

If you feel you really do need (or want) an even earlier daily-live than what's on cdimage.ubuntu.com, I don't think old daily-lives are officially retained for distribution, but it's sometimes possible to get a three-day old (or perhaps occasionally even older) daily-live from a mirror that is not yet fully up to date.

You can search the web for this, with ubuntu, the string of digits representing the date of the daily live you want, and "daily live". For example, to get the daily live you were looking for in your question, I searched Google for:

ubuntu "daily live" 20130110

Usually, most of the results will be from cdimage.ubuntu.com itself. Since you've checked that the daily-live you want isn't still there, you can disregard these. It's just cached data (and Google does not cache the ISO's themselves).

When you find a server other than cdimage, check it out. I found this:

• ftp://ftp.tu-chemnitz.de/pub/linux/ubuntu-cdimage/_LASTMIRROR.txt

^{(I am providing this for illustrative purposes; anyone reading this more than a day or two after I post it shouldn't expect any significant likelihood of this server still carrying that particular daily-live. But that doesn't matter. This to show how to do it for an arbitrary daily-live.)}

That's actually a log showing what files the mirror downloaded from the central server. The key is to navigate up the directory tree. So, I went up to ftp://ftp.tu-chemnitz.de/pub/linux/ubuntu-cdimage/.

There I found a daily-live directory containing the daily-lives shown in the log Google had found for me. One of those files was the daily-live I was looking for, 20130110.

Often an FTP site will have a web server also, so it's worth trying to replace ftp:// with http:// in the URL. (The rest is usually the same, even if it starts like ftp..) Sometimes the HTTP server will be faster, and sometimes the FTP server will be the fastest. Mirrors that update slower might be slower to download from, too, so the difference in speed could matter. Generally both the FTP and HTTP versions of a site will be updated at the same time (or almost exactly the same time) as typically they serve the same files from the same server, though this isn't universally the case.

If you have a later daily-live, you can "update" to an older one withzsync, just as you'd update from an older one to a newer one. zsync is packaged for Ubuntu, and is available for other OSes as well. If you want to use is on Windows, there's information in this answer about how to do that. zsync requires HTTP to work; it will not download a file via FTP. (It will of course download a file via HTTP where the domain name starts with ftp., though.)

_{If you need this particular old daily-live and you're not able to grab it in time, please comment to let me know. I might be able to come up with something else.}