[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Grub Scripting

From: Chris Umphress
Subject: Re: Grub Scripting
Date: Fri, 8 May 2009 12:52:50 -0500

On Fri, May 8, 2009 at 8:30 AM, Isaac Dupree
<address@hidden> wrote:
> I can think of a couple ways to do what you say:
> - if there is a date/time command in GRUB, have the `grub.cfg` check the date
> and refuse to offer any booting options after that date (where I suppose the
> hardware-clock supplies that date)

I was told by Mr. Gerards that he thought support for querying the
date/time from the system BIOS was already implemented for scripting
purposes. Even if it weren't, I have queried information directly
before -- back when QuickBASIC was in wider use.

> - alternatively to "not booting", you could have it boot DBAN which will erase
> everything on all disks :-)

We don't want to destroy the entire system but are considering the
destruction of the partition table (after creating a backup). Slightly
complicated, yes, but we do need the data on these systems to be
accessible for us to recover.

> Or have a human manually boot the self-destruct option (which should require
> an administrator password probably)
> (how do you expect to re-use these computers, if they have a nonfunctional
> boot-loader, by the way?)

We'll overwrite the boot loader and restore the partition table if it
was destroyed. That would be handled from a custom, bootable live-CD
or thumbdrive. This is going to be used on laptops that are lent out
and it is one more way that we can try to force people to return them
without sending the police out. This is why we need it automated.

If they do something silly to their system clock, we'll have to have
them bring it in. It might be possible to lock the system BIOS,
depending on what others decide the users need to be able to do.

Yes, we are relying on the inexperience of most of the students. We
intend to have a backup method in Windows to restore the boot loader
should it be changed.

Hopefully this explains our reasoning a little better.

> -Isaac

Chris Umphress <>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]