Ticket #322 (closed defect: wontfix)

Opened 12 years ago

Last modified 10 years ago

Installer should verify installability

Reported by: jdreed Owned by: amb
Priority: normal Milestone: Natty Alpha
Component: installer Keywords:
Cc: Fixed in version:
Upstream bug:

Description

Currently, it is possible to end up with a b0rked machine (say, because the openafs modules aren't available for a new kernel version) via the PXE installer. This is bad. Thankfully, the difference is noticeable enough that it's an inconvenience as opposed to a major problem (ie: the greeter is missing, the ability to log in is missing, etc).

However, users who attempt to install Debathena should either end up with Debathena or with a message saying "Sorry, try again later."

We should make the installer more foolproof.

Change History

comment:1 Changed 12 years ago by jdreed

  • Component changed from -- to installer
  • Milestone set to Summer 2010

At release-team, we talked about having the auto-debathena-whatever-ifier push openafs-modules directly into production.

But I'd still like the installer to do a bit more sanity checking.

comment:2 Changed 12 years ago by jdreed

  • Status changed from new to assigned
  • Owner set to amb

comment:3 Changed 12 years ago by jdreed

So, this is actually two issues:

  • ensuring there's enough disk space
  • ensuring critical modules (like openafs) exist in the repo.

The former is less of an issue, but is apparently a trivial fix according to amb. THe latter is much harder.

comment:4 Changed 11 years ago by jdreed

Here's a terrible idea:

As was the case with Athena 9, the installer installs from a different repository, which is known good and updated periodically from production.

comment:5 follow-up: ↓ 6 Changed 11 years ago by andersk

If production isn’t known good, we’re doing something wrong.

The openafs problem will go away with DKMS (#243).

comment:6 in reply to: ↑ 5 Changed 11 years ago by broder

Replying to andersk:

If production isn’t known good, we’re doing something wrong.

I wish I shared your confidence in my perfection.

Yes, we shouldn't break things. But it doesn't mean that we don't. Or haven't. The fact that we shouldn't break things doesn't mean we shouldn't code protections for when we do.

comment:7 Changed 11 years ago by jdreed

  • Milestone changed from Summer 2010 (Lucid Deploy) to Fall 2010

comment:8 Changed 10 years ago by jdreed

  • Status changed from assigned to closed
  • Resolution set to wontfix

dkms "fixes" this.

Note: See TracTickets for help on using tickets.