[OpenIndiana-discuss] More N40L fun :-(

[Reginald Beardsley]

--- On Fri, 2/1/13, Jim Klimov <jimklimov at cos.ru> wrote:


> 
> I think I used the command-line parted to pre-label the
> partitions
> when I was concerned about this on my home NAS (hand-made
> box), and
> then allowed the installer to use the whole partition - with
> the
> alignment I deemed correct. At least, I didn't ever see the
> errors
> and messages you've just quoted ;)

A bit more data:  format(1m) in the text installer shell produces corrupted output for a "save" operation.  Code has "%ld% where it needs "%lu".  Also looking at the output of prtvtoc, the slice boundaries are not properly aligned for 4k disks.  I plan to file bug reports when I've collected more information.  I was trying to find the source code for format(1m) earlier.  It certainly would be nice if someone who knew what went into 151a7 prepared an index showing what repository each of files was derived from.


> You can also try to ZDB the pool components' labels, i.e.
> # zdb -l c0t0d0s0
> 
> Also you can use "-e GUID" to enforce inspection of a pool
> found
> by its GUID (which you can infer from the labels or from
> the
> "zpool status" listing).
> 
> Interestingly, just "zdb" with no params dumps the labels of
> all
> imported pools for me on several hosts of varying OS
> revisions,
> including sol10u8, sxce 117 and oi 151a7.

That's good to know.  It would be nice if someone w/ zdb knowledge wrote a brief bit of documentation.  That might free up enough time to work on OI rather than doing our own forensics.

> 
> > Memtest reports the memory is fine.
> 
> Is it possible that the DIMM was inserted somehow
> incorrectly, i.e. the
> clip did not click? Another thing I'd look at is mismatch of
> memory
> module speeds (clock, latency, etc.), chip bitness (amount
> of chips
> on the module, basically) and other such asymmetrical
> mismatches to
> your other modules.

BIOS provides no data.  DIMM is what Kingston indicates is a match for the system, so I'm reasonably sure it's the correct memory.  I really don't think the DIMM is a factor.  I think more likely some weirdness in drive labeling courtesy of either the BIOS or someone's clever trick.  Linux drove me nuts w/ the drive renaming BS.


> Well, from evidence and confirmed hypotheses, for many
> people it
> just works to rsync the running OS from a booted LiveCD onto
> an
> rpool created manually - along the lines of my Wiki page on
> these
> manual installs. There are some post-installation
> customizations
> which differentiate a Live image from an installed one, i.e.
> the
> set of alternate SMF services to mount one or another
> "fs/root",
> user accounts, network/naming config and so on, but I think
> many
> or all of these can be done on the installed system after a
> reboot.
> 
> In particular, the possibility of adding
> unsupported-by-default
> storage/net drivers into the live booted environment and
> then
> having the installer carry them over onto HDD does confirm
> that
> it copies the live environment and not the default .zlib
> contents.

I think I'm beginning to understand how the installer is structured, so I'm going to have another go at it after I take care of the slice alignment and size issues. S10 on 4k disk makes me nervous, though so does OI.

> 
> I do agree that an advanced installer (text or AI) on the
> GUI
> media image, for those advanced users or ones with special
> needs
> like us, would be useful. Perhaps just a stub one that would
> only
> basically wrap the proper copying and then customization of
> the
> live image to a given dataset of the user's choice would
> indeed
> be super-useful for custom installations (like into old
> rpools
> or new ones tailored to a specific layout).
> 
> IIRC the old (pre-Caiman) Solaris installer was a series of
> scripts
> and programs that requested installation set and
> configuration data
> from the users, and ultimately fed these inputs to a
> separate install
> program - and these feeds could also come from jumpstart
> profiles
> and such. I can't exclude that similar logic exists in
> Caiman i.e.
> for the Automated Installer function, but I don't know any
> more to
> elaborate on this.

The SunOS 4.1.1 installer was just a set of Bourne shell scripts.  It loaded miniroot into the swap partition and fed the scripts to the shell.

The old Solaris installer is more elaborate, but not very different.  I think the text installer for OI is a python script, but there are so many things which match '*install*' it's really hard to be sure which file is being used.  I've got to find the menu that the text installer puts up to find out.  


I may try making a custom LiveCD w/ the text installer on it and give that a go.  That might be the easiest option.  But I want to collect some data on the format(1m) issue.  That might explain why people have hard to diagnose problems installing successfully.  

For the Seagate ST2000DM001 disks there are 8032.5 4k sectors per cylinder.  Starting at cylinder 2 would align whereas starting at cylinder 1 would not.  What I don't know is how format(1m) is getting the tracks and sector values.  Is it reading something from the disk or is it doing faulty arithmetic for 4k sector disks?  The disk obviously does not have 255 heads.


Oh well.  Time to trash my S10 install and mess around with the disk labels.

Once more into the breach!
Reg

BTW Why are we using Confluence rather than Meidawiki?  Can anyone explain that?  I'm really not happy about having to learn another package for doing the same thing.  Particularly one that is proprietary and as obtuse as Confluence.