Failed flash archive extraction during Solaris Installation

I really don't know where to start from...
I tried the best I can to work things out but I kept getting the same results no matter what I did.

Solaris Installer flash archive ends with a failed status.

I will post several photos I gathered for your review.

And I will add all the observations I have gathered.



Actually, I made 4 flash archives. I repeated the standard cpio archive without any -y included directories.

I tried two more times with -y included directory (/usr/home/kunde) which contains all the applications and control software.
It was strange that the size of the archive after -y was 100 MB smaller!.

Anyway, I tried the installation from flash archive with NFS. It found the .flar file and proceeded with the layout filesystem in the disk.
It asked me if I need to preserve any data and I selected no every time.
The photo shows the filesystem layout it configures by itself. The first attempt I didn't modify anything. And went ahead with the installation. Untill I got a failed extraction after progress bar reached 100%!!!
The error details are shown in the uploaded photos above.

In all attempts, the errors were the same. And the extraction was only for the first 900ish MB(41%).

It is worth mentioning that I tried once to modify the disk slices and space allocation on the disk. I tried to slice it exactly as I have seen it sliced in the good disk. I will attach the details of the good disk shortly.

There is a slight difference in the number of cylinders with the bad disk(slightly less).
However, I tried to partition it like the good disk with a minor volume difference in the unassigned partitions. I just wanted to try things out before asking you guys. Anyhow, I got the same failed extraction result with the same error log.

Many things don't make sense to me. I hope it makes sense to you.

If there is any reference to read about this procedure I would appreciate sharing its link.

I look forward to your valuable feedback.

Partitions of the good disk.

Paritions with the default slicing.

As I said earlier, I have tried once to copy the slicing that was on the good disk.
But it didn't change a thing and extraction failed exactly the same.

Recreate the same (or similar) partitions in the installer's "Lay Out File Systems" screen.

1 Like

Having followed your issue from the beginning the first thing I must recommend is that you do NOT delete the flash archives you have. There is no reason to think that they are faulty (see below for comment on that) and they will be a life saver is disaster strikes your good system.

I have a feeling that this post might turn out to be a long one, perhaps not, but I would comment as follows. Here goes!!

Firstly, famous last words, this shouldn't be happening. What questions is the flash install process asking you exactly? You are not opting to "preserve" anything on the hard drive from what you say, but is there another question tripping you up I wonder? Please post the questions you are answering if this continues.

A flash install should mimic the VTOC from the original machine BUT the bad machine drive is several cylinders smaller than the good machine. Good machine 38307 cyl, bad machine 38275 cyl, so the install process has no chance of duplicating that VTOC. Slices (partitions in Microsoft speak) must start and end on a cylinder boundary so are therefore specified with the start cylinder and end cylinder numbers. NO OVERLAPS allowed, of course.

Now looking at your screenshots of the good disk and bad disk VTOCs, it is immediately apparent that the good disk has filesystems /root, /var and /usr in addition to, of course, a defined swap space. The bad disk has the whole drive (apart from swap, etc) defined as root filesystem. So it's no surprise to me that when the flash install is extracting the filesystems and gets to /var and /usr it has nowhere to restore the data to and so will likely crash. The question is why the flash install hasn't configured /var and /usr and, if it couldn't do that, why it didn't crash much earlier in the process.

Integrity of the flash archive
This can be tested by using the 'flar split' command (see the man page) to split the flash archive into its component parts. You must specify the target directory where you want these components dumped. It won't delete the original archive. The largest of the files produced will be the cpio archive of the whole system (which, if you learn to use cpio, you could list out the contents of that to see what files you have and whether it looks like the whole system or not). If the flar split completes without an error and produces the components in the target directory, then I would say that the flash archive is fine.

Incidentally, I would comment from your post that you should not be using any -y includes on your command line; the archive should just take the whole system anyway. the common use of -y is when you've used a -n to exclude a high level directory but want to -y include one of its sub-directories. You shouldn't need any such switches on your command line.

You might also consider looking at the command 'fmthard' that will export a VTOC configuration in order to import that identical VTOC onto an empty drive. You could export the good system VTOC to a file, and then try importing that into the bad machine. The question is how to get the file across between the boxes. Anyway though, there's the question of the cylinder count that I've already mentioned.

You could use 'format' (in single user) to set the VTOC on the bad machine as near as damit to the original by editing the slices with the same cylinder start/end numbers for /root, /var and /usr, and also swap space, etc. Remember that you then must write 'w' that VTOC to the drive otherwise all your edits will be lost. Re-enter 'format' and check your edits have been written. Then you use the command 'newfs' to create new empty filesystems on the slices with /root, /var and /usr. Do not write new filesystems anywhere else; not needed.

CRITICAL NOTE: When editing VTOCs NEVER edit slice 2 (s2 backup slice) because this always represents the whole disk and the system depends on it to determine disk geometry.

If you get that far then you could mount /root, mount the /var slice on /var, mount the /usr slice on /usr, change directory to the top of the hard disk root filesystem, and then restore the cpio archive produced by flar split handraulically. However, I understand that you are new to Solaris so might well have to ask questions about this approach.

In summary, I think the cylinder count of the two disks might be the problem why flash extract is falling over, along with the VTOC having no /var or /usr specified.

Hope that helps a little.

1 Like

First of all, I would like to express my admiration of your efforts and patience in following this case from the beginning as I do appreciate everyone who shared their valuable expertise to help.

I have read and understood every single word. I will make sure your recommendations are followed properly.

Let me mention something before I add my comments on your notes. If you refer to the photo uploaded from a previous post on flarcreate, you would notice that it always shows "1 error(s) after determining the size of the archive. I googled this incident and I found many people encountered this thing and they were told it was no problem. Maybe nobody paid attention to this. And I couldn't find a way to check this error from any error log.
However, after completion and postcreation scripts are done, no error is displayed. I will wait for your feedback on this point.

Furthermore, about the disk geometry...I could try and get another disk with identical number of cylinders...what do think?

about VTOC , I new that it wasn't right when it showed the suggested VTOC. So I tried the next time to duplicate it manually on the bad disk, atleast for the assigned slices, and sacrificed the missing cylinders for the unassigned slices. Anyway, it didn't make a difference in the progress of the archive extraction(40%).

About

To summarize, and before I go through your steps tomorrow, I would like to know your response on both points discussed above.

  1. 1 error after determining archive size
  2. Getting another disk with identical geometry.

You can see the prompt "1 error(s)" after determining size of the archive.

The geometry of the disk you tried is close enough in my book; I think flar install should cope with such a small difference. However, I can well imagine that with only a root filesystem specified in the VTOC, that during extraction it could complete the restore of root but then fall over looking for /var. That might explain the 41% or whatever before it fails.

I would also say that a larger disk than the original should certainly work, with the excess space unallocated by the flash install.

About the questions the installer asked me...I wasked whether I want kerberos security and I chose not to. I was asked if I want NIS, and I answered once with a no and once with a yes.
I was asked if I need to setup IPv6 and I chose not to. I was asked if there is anymore archive file that I need to add and I selected none and archive file is complete.

The last part was about the disk and whether I want to preserve data and I chose not to preserve anything.

Then it displayed the screen with the suggested VTOC and whether I need to modify it or not.

That was it.

Sounds good. So, I will arrange another IDE disk drive with a larger capacity.

I still need your comment on this error prompt before creating the flash archive, please. Is it normal??? This is for the sake of the confirming the integrity of my flash archives.

You mean the error on /etc/mnttab?
Not important; this file is recreated at system boot.
I think it is even a special filesystem in memory; check with df
You can exclude it in the flarcreate.

Well noted.

Yes, well, does that VTOC look correct? /root, /var and /usr???

As per the link that I posted, it seems fairly common to have an error reported during flar create. See that link.

As far as the integrity of the flash is concerned, I covered that in my long post. I suggest (if you have the disk space on the NFS server) that you split the flash into it's component parts ('flar split') and see if you get an error splitting it. If not, the largest file producted will be the cpio archive of all the files. Try listing that with:

# cpio -ivt -I <cpio archive file>

That listing will tell you what files the flash archive contains. Does it look like all the files on the original system? If so, keep that flash in case you have a disaster.

1 Like

No it didn't...It had only root and swap and that's it.

Okay, noted!