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

Bug#394145: install base system doesn't time out when link dies

On Sat, Oct 28, 2006 at 05:19:20AM +0200, Frans Pop wrote:
> On Thursday 19 October 2006 23:40, dtutty@porchlight.ca wrote:
> > Wanted to make USB stick the whole 2 GB so followed the manual section
> > 4.3.2.
> >
> > 	mkdosfs needs the -F16 option.  Otherwise makes F12 which
> > 	doesn't support long filenames under vfat.
> Hmm. I've tried with my 256 MB USB stick, and it creates a 16-bit table by 
> default and I'd be surprised if it would default to a 12-bit table for 
> larger sized sticks.

I think I know the problem and the solution would be a note in the
manual instructions.  Since my only computer that runs (the 486) doesn't
have USB, I have to make the USB stick on the new computer.  It doesn't
have Debian and my debian 3.0 won't run on it.  I end up using a RIP
linux CD.  It probably has different defaults compiled into mkdosfs.  

Since the installation instructions are for installation, they should
not assume that the preparation of the install media is done under
Debian.  Perhaps for commands issued prior to installation, instructions
should not rely on defaults but give all explicit options to the

> - What size was the partition you created?
> - What partition type did you set the partition to when you partitioned
>   the stick? Or: what does 'fdisk -l /dev/sda' give?
> - What does 'mkdosfs -v /dev/sda1' give?
> (replace sda and sda1 by correct devices for your USB stick)

The partition was the whole device, e.g. all free space, 2 GB.  It was sdc
(sda and sdb are the two 80 GB SATA drives).

> > 	mkdosfs man page says it can't make bootable fs.  Used
> > 	install-mbr.
> No, but I think syslinux takes care of that (as used in the manual).

No, it didn't, so I needed install-mbr.  Perhaps, again, this is a
non-debian syslinux thing.  At least the note about perhaps needing
install-mbr was in the manual so it was no biggie.

> > Would like a way to interrupt the whole install process incase need to
> > power-off or if power dies.
> That's easier said than done. How would you propose we determine the state 
> of the installation and especially if nothing was corrupted during power 
> loss. Remember that the installer runs completely in memory, so when 
> power is gone, the installer is completely gone too.

I guess I'm thinking USB centric where some sort of 'state' info could
be stored.  That could be an option, either onto the same USB stick
booted or a separate USB stick (especially if CD or net booting was
used), in the same way that saving the logs from a failed install lets
you tell it where to save the logs.  

As far as how to determine the state, when running, the installer seems
to keep track of the state of things.  If the sum of all that state
could be dumped to a file, then a menu item 'restore saved state' could
bring that back into memory, especially the choices made e.g.
partitioning, and all steps recreated using that state info.

Once this worked, then in case of unreliable power, a menu item of
keep-state-on-file could keep the state up-to-date as the install
progressed so that if the power goes then the install can be resumed

Thanks Frans.  I spent yesterday (10/27) downloading the netinst.iso 
daily and will try to install today using that so I won't need the
internet during the initial install.  I'm hoping that this gets me up
and running with aptitude which does handle a flaky internet gracefully.


Reply to: