Installation problem on amd64 on secondary disk

Installation problem on amd64 on secondary disk

[tlaronde]

Hello,

Since I had a report from somebody trying to install kerTeX on 9front
and was unable to reproduce with my current installation which was an
old one, so I wiped the installation and started a new one.

I ran into problems reaching bootsetup.

The "dossrv" fails and, IIUC, this is (mount /srv/dos...) and there is
no dos server under /srv at least in my installation.

I have almost 428GB of disk dedicated to 9front, with---by default---58
GB for the cache. Since data is copied form the CD, it should be
sufficient?

The installation media is a CDROM with an amd64 iso retrieved today.

The disk is a secondary one, appearing as sdE3 if this matters.

 From what I have looked, the distribution seems to be copied, but
depending on the moment, in another window, some commands are found and
some are not (and unfortunately, ns(1) is not available making
things difficult).

What is the best course? To boot from the CD and inspect without
attempting inst/*? 

Any help will be appreciated.

TIA,
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9front] Installation problem on amd64 on secondary disk

[cinap_lenrek]

it sounds to me like your iso image is corrupted. dossrv and ns
are both part of the iso. in fact ALL binaries are available
on the iso filesystem (in the live system before installation),
the installation merely helps with setting up a new fileserver
like cwfs or hjfs and copies the contents of the iso filesystem
over. there is no stuff that gets unpacked or is not otherwise
accessible from the life system.

please verify the sha1 sum of the iso you downloaded or use
the torrent.

cpu% sha1sum 9front-7781.38dcaeaa222c.amd64.iso.gz
e58a3f7d67e3937593ae0bf8b8c0dc7ed47c7535	9front-7781.38dcaeaa222c.amd64.iso.gz
cpu% gunzip < 9front-7781.38dcaeaa222c.amd64.iso.gz | sha1sum
255d250ae7801012847a4a9d58d67c7617250935

it could also be that there are problems with the cdrom media
you have. you could try to dd the uncompressed iso image directly
on a usb pen drive and boot from that.

--
cinap

Re: [9front] Installation problem on amd64 on secondary disk

[tlaronde]

Hello,

On Tue, Jul 07, 2020 at 12:03:46AM +0200, cinap_lenrek@felloff.net wrote:
> it sounds to me like your iso image is corrupted. dossrv and ns
> are both part of the iso. in fact ALL binaries are available
> on the iso filesystem (in the live system before installation),
> the installation merely helps with setting up a new fileserver
> like cwfs or hjfs and copies the contents of the iso filesystem
> over. there is no stuff that gets unpacked or is not otherwise
> accessible from the life system.
> 
> please verify the sha1 sum of the iso you downloaded or use
> the torrent.
> 
> cpu% sha1sum 9front-7781.38dcaeaa222c.amd64.iso.gz
> e58a3f7d67e3937593ae0bf8b8c0dc7ed47c7535	9front-7781.38dcaeaa222c.amd64.iso.gz
> cpu% gunzip < 9front-7781.38dcaeaa222c.amd64.iso.gz | sha1sum
> 255d250ae7801012847a4a9d58d67c7617250935

I have verified the downloaded file and it is OK.

> 
> it could also be that there are problems with the cdrom media
> you have. you could try to dd the uncompressed iso image directly
> on a usb pen drive and boot from that.

I mounted the ISO under another OS and all the files and programs are
here.

I have restarted the installation with the same burnt CD. This time it succeeded.

The three differences between the installation attempts I know of:

1) The first time I had several Plan9 slices on two different disks. I
have now removed before trying the installation the slices (in the MBR, under another OS)
except on the one disk I wanted the install;

2) This time I did not switch the kbmap to azerty but kept the default
ascii until the end;

3) From a superficial look, copydist took more time during this last
attempt, so chances are that during the other attempts indeed not everything was copied.

(I don't think, though, that this information will be of great use to somebody...)

Now, at least, I can reproduce the failure of generating the fonts under
kerTeX with the very same message the user had (putc erroring because of
ENOENT).

Best regards,
-- 
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                       http://www.sbfa.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C