[Ubuntu PA] Disk Imaging Solutions

[Kevin Valentine]

Brian Stempin wrote:
>
>        5) run script that creates/formats partitions
>        6) power cycle the drive (pull USB plug or toggle on/off switch)
>        7) check if partition table gets read correctly
>
>
> Is (6) needed?  I recall trying to create an "install USB hd" (think
> the Ubuntu install CD...except the media is a USB hd), which required
> me to partition and re-partition my USB hd.  I don't recall having to
> unplug and replug my drive.
>
> Does anybody know this off of the top of their head, or should I go
> ahead and invest the time in testing it?
It may not be necessary to power cycle.  I've seen it suggested in the
DSL frugal install howto and a few other places.  I've also seen it's
usefulness during manual testing.  It seems to be the only reliable way
to get the OS to reread the partition table after you've created new
partitions.  Is there a way to force the OS to reread the table?  I may
be thinking too much in terms of cfdisk and fdisk.  parted may handle
all this nicely already.

>     There's no real need to create an "image".  I thought it would
>     be nice to use some existing tools.  I've decided to keep it
>     simple and
>     go with a "deep" copy of all the files and create two archives for
>     hda2
>     and hda3.  This is the general idea:
>
> *snip*
>
> I was just thinking to myself....wouldn't it be easier to to the
> following:
>
> 1.  Write a bash script to do the partitioning.  You can pass the
> device (/dev/hdc, etc) as a parameter, and the bash script will call
> parted to do the partitioning.
> 2.  Mount the DSL ISO
> 3.  Using the previous bash script (and it's argument), have the
> script automate the running dsl-hdinstall.
I like most of this, especially use of the ISO image for easy updates. 
btw, we can python, bash, ruby, whatever.  I only suggested Python
because I already have some stuff that could be easily modified to do
most of what we want.
> This has several advantages:
> 1.  Other than writing the script, no manual labor has to be done (ie,
> creating the "deep copy")
The only reason for the deep copy is that we have customized the
interface.  On a frugal install, this includes different desktop
backgrounds in hidden folders, the mydsl extensions (extra apps), and
anything else in the /opt folder.  We are also planning to include grub
0.97.  The version that comes with DSL by default doesn't include
splashimages.  We can use the host OS's (ubuntu) version of grub to
write to the MBR to write to the MBR.

> 2.  Older and new versions of DSL can be used, simply by downloading
> the ISO and calling it's "dsl-hdinstall" script.  You could write the
> script to either look to a certain mount location (/media/dsl), ask
> for the location of the mounted DSL ISO, or ask for the ISO image
> location so that it could mount it for the user.
Yes!  I really like this idea of mounting the ISO image to get the main
DSL files.  Not so sure about the benefits using their scripts as-is. 
We may have to modify them quite a bit.  One problem Jim and I noticed
with their scripts is they changed from version 3.x to 4.x.  Not sure if
it's isolated to just those major versions.  I suppose if we stick with
DSL 3.x we'll be safe.

> 3.  Once the script finishes executing, we could have it call other
> sub-scripts to do different types of special configs.  Ie, this batch
> of HDs needs a few non-default apps, so InstallDSL.sh will then call
> Installxx.sh , passing it all of the needed arguments, thus preventing
> any further user interaction and saving time.
OK.  My reply to 1. above goes to some of this.

My main concern is automating the creation of the partitions via a
script.  I've already tried it manually from the command line and it
failed in ways I can't comprehend.  If we can do this, everything will
be easy.  As you already suggested, just reuse many of the scripts
already provided by DSL and we're golden :)  Here's what I was doing
manually with 'parted' from the command line:

## Start by removing all partitions and the MBR:
dd if=/dev/zero of=/dev/sdb bs=512 count=1

## Create the partitions usign parted
parted --script /dev/sdb mklabel msdos
parted --script /dev/sdb mkpartfs primary linux-swap 1 64
parted --script /dev/sdb mkpartfs primary ext2 65 125
parted --script /dev/sdb set 2 boot on
parted --script /dev/sdb mkpartfs primary ext2 125 325   <--- normally
this will be (disksize-usedspace) to use all of the disk

This turned the partition table into a toxic soup.  This is what fdisk
shows on a table print out:

Disk /dev/sdb: 6007 MB, 6007357440 bytes
185 heads, 62 sectors/track, 1022 cylinders
Units = cylinders of 11470 * 512 = 5872640 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1          11       62500   82  Linux swap / Solaris
Partition 1 has different physical/logical endings:
     phys=(7, 199, 9) logical=(10, 166, 9)
Partition 1 does not end on cylinder boundary.
/dev/sdb2   *          11          22       59570   83  Linux
Partition 2 has different physical/logical beginnings (non-Linux?):
     phys=(7, 199, 10) logical=(10, 166, 10)
Partition 2 has different physical/logical endings:
     phys=(15, 50, 16) logical=(21, 52, 47)
Partition 2 does not end on cylinder boundary.
/dev/sdb3              22          56      195312+  83  Linux
Partition 3 has different physical/logical beginnings (non-Linux?):
     phys=(15, 50, 17) logical=(21, 52, 48)
Partition 3 has different physical/logical endings:
     phys=(39, 130, 41) logical=(55, 63, 10)
Partition 3 does not end on cylinder boundary.


I'm sure it has something to do with the start and end points and
partitions sizes.  Maybe there's a simple fix.  If there is, we just
dump it into mix of bash scripts and we're done :)

-kevin