Re: [Xen-devel] [PATCH 4/7] osstest: add a FreeBSD host install recipe

[Ian Jackson <ian.jackson@xxxxxxxxxxxxx>]

Roger Pau Monne writes ("Re: [PATCH 4/7] osstest: add a FreeBSD host install 
recipe"):
> OK, so then I will just drop FreeBSDBase and just use
> $ho->{Tftp}{TmpDir}/freebsd-images. I don't think there's a lot of
> value in have it in a standard folder, since those are just random
> builds. I guess this makes more sense for Debian because they are
> actual releases, and thus can be used for other stuff also?

Yes.  Indeed they might not be managed by osstest at all.

> > > +    my $installer_sets = join(" ", @sets);
> > > +    my $target_sets = "/tmp/osstest_sets";
> > 
> > Hardcoded /tmp antipattern.  Maybe this is technicallty OK because
> > it's an installer environment, but I think it sets a very bad
> > example.  Is there some other path you could use ?
> 
> I'm open to suggestions. We could also use ~/osstest_sets. I don't
> really have a preference. I've used /tmp because I though it would be
> less controversial.

Hah :-).

I'm fine with almost any path other than /tmp/FIXED_STRING.

> > > +    target_cmd_root($ho, 'chsh -s /bin/sh', 10);
> > 
> > !!  What's the default ?
> 
> csh.

omg wtf bbq.  Right.  Fine.

> > I have found that on some hosts, when installing Debian GNU/Linux, I
> > have to expect a nonstandard disk name.  Currently in the DB I can
> > only find this
> >    hydrazine          disk-device                    /dev/cciss/c0d0
> > (in Cambridge; referring to a gone-away machine; NB that the property
> > name is in the obsolete containing-spaces syntax and is equivalent to
> > DiskDevice.)
> > 
> > I think you may want to check a host property.  It should probably be
> > called Freebsd_DiskDevice or something.  (Weird capitalisation required
> > by the word splitting name transformation rules for host propertiess.)
> 
> Yes, I can do that, but we would have to fill the DB manually. Would
> you be OK with leaving this as-is in this patch and me adding the
> property fetching later on?

OK.  Hopefully it won't come up.

> > What would happen if you tried to run this setup on a host where
> > FreeBSD's idea of the first network interface is not the one which
> > osstest did the install on ?
> 
> FreeBSD doesn't really have an idea of the first network interface
> (unless you count the order in the output from ifconfig -l).
> 
> Also, on FreeBSD each driver has it's own device, with different name,
> ie: there are em0, em1, bge0, bce0... interfaces. We could add
> a host property like Freebsd_NicDevice, but this fallback should stay
> in case the parameter is not defined?

I think this is too complicated and hypothetical.  Let's leave it for
now, as you have it.

> > > +    logm("Creating the installer script");
> > > +    target_cmd_root($ho, <<END, 60);
> > > +        set -e
> > > +        cat << ENDSCRIPT > installscript
> > 
> > OK, my brain is fully bent now.  Can we not create installscript on
> > the controller and transfer it with target_putfilecontents_root_stash ?
> > That way the logs would contain a copy, too.
> 
> Yes, that's much better, thanks!

:-)

> > > +# Setup serial console
> > > +printf "%s" "-h -S$c{Baud}" >> /boot.config
> > > +cat << ENDBOOT >> /boot/loader.conf
> > > +boot_serial="YES"
> > > +comconsole_speed="$c{Baud}"
> > > +console="comconsole"
> > > +boot_verbose="YES"
> > > +beastie_disable="YES"
> > > +ENDBOOT
> > 
> > Where does the installer's output go ?  Ie, does booting the installer
> > image produce serial log output ?
> 
> Yes, the installer image is built with serial output already.
> 
> The output of the installer itself (bsdinstall) goes to the job log
> file.

Great.  Looking good :-).

Thanks,
Ian./

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel