Re: qlogic fibrechannel

[Rick Leir]

Kevin,

Yes, I think so. Here is what I posted in March:

"""Now it is telling me that I need some non-free firmware, filename 
ql2200_fw.bin, and that I should load it from removable media. Does this 
firmware matter, and where can I get it? There is something by that name 
on the qlogic.com site. I guess it could be for the FibreChannel 
interface. OK, ignoring it for now.


After doing 'set up users and passwords' correctly it goes on to 
'Configure the clock'. It returns from that immediately without doing 
anything. I was hoping to set the timezone.


Now it is doing 'Detecting disks'. Gee, it took a long time on that, 
maybe a few minutes. Then it says 'No disk drive was detected' and gives 
me a list of drivers to select from. I am guessing now: qla2xxx ... long 
pause, then I am back to the list of drivers screen. Try 'qla1280' ... 
'qla4xxx' .. help! I think the disk hardware is OK because OpenBSD is 
installed and can boot. What can I use for a disk driver? How could I 
load the ql2200_fw.bin?


"""

I found ql220_fw.bin in a non-free package, and got a bit further, but 
did not get it booted after much trying. I am inclined to connect any 
surplus disk just to get it installed temporarily, then debug the driver 
problem. Maybe it is an endian problem, I understand drivers on older 
Unix systems but not on Debian.


Thanks -- Rick



On 2017-09-07 10:15 AM, Kevin Stabel wrote:

Hi Rick,

Is it qla2200?

Kind Regards,

-Kevin

On Sep 7, 2017 2:18 PM, "Rick Leir" > wrote:


Hi all
I am still hoping to get my Sun 2000 (vintage 2002) running with
Debian. The problem was the Qlogic fibrechannel disk driver, so
perhaps I can add in a different disk controller temporarily. What
economical solution would you recommend? Perhaps a USB disk?

By the way, OpenBSD installs fine. I might be able to compare
drivers and fix this bug, but the problem would be much easier to
debug with Debian booting from a SCSI or SATA disk.
Thanks
Rick

Re: Stretch bootstrap for sparc64 and sparc, optimized for ultrasparc3

[John Paul Adrian Glaubitz]

On 09/07/2017 07:05 PM, Tom Turelinckx wrote:

Because I want to move forward with upgrading some of those machines to a newer 
release,
and replacing some of the Sun Fire-series hardware with SPARC Enterprise-series 
hardware,
I'm working on bootstrapping Stretch for both sparc64 and sparc, preferably
--with-cpu(-32/-64)=ultrasparc3 instead of ultrasparc.


We are actually planning on implementing Britney for Debian Ports which means 
that
Debian Ports would also get a testing release. I'm not sure what the current 
status
is though.


Bootstrapping Stretch for sparc is less straightforward, as the latest/last 
packages
available from snapshot are from two years ago. Still, there is a large amount 
of
packages available that is not terribly old. Thanks to excellent work by Helmut 
Grohne
and others [2], it's also possible to cross-compile a recent version of the most
important packages from source.


But why 32-bit sparc? All the current development happens in sparc64. There 
isn't
really a point in bootstrapping for sparc these days unless you set the default
CPU to sparv8 to be able to run Debian on a sun4m machine. sun4u or newer 
machines
should use sparc64.


It took only minimal patches to get rebootstrap to work against Stretch 9.0. It
finishes successfully, and I have repositories available for both sparc and 
sparc64.
Unfortunately, build-essential is not (yet) fully complete: rebootstrap does 
not (yet)
produce a native gcc. At jenkins.debian.net, builds considered successful 
finish in
the same state, so I guess producing all the build dependencies to produce a 
native
gcc is (currently) out of the scope of rebootstrap.


You can just easily cross-compile a native gcc compiler with sbuild. That's 
actually
very easy using the cross-build toolchain available in Debian.


Having Stretch repositories with a significant number of packages available for 
both
sparc64 and sparc would open up a lot of opportunities for testing and actually 
using
the port, and having them optimized for ultrasparc3 would allow useful 
performance
testing on a broad range of currently relevant hardware. If I succeed in 
building the
repositories, I hope to make them public.


I think it makes more sense to help to make Britney and hence testing available 
in
Debian Ports. Your efforts sound like you're trying to reinvent the wheel in my
opinion.

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Stretch bootstrap for sparc64 and sparc, optimized for ultrasparc3

[Tom Turelinckx]

Hi,

On Thu, Sep 7, 2017, at 11:19 AM, John Paul Adrian Glaubitz wrote:
> On 09/07/2017 10:30 AM, Tom Turelinckx wrote:
>> Not all of those may be necessary anymore, but I've been doing it like
>> that since squeeze and up to the current sid on dozens of machines, and
>> it works reliably: when the first disk fails, I am able to boot from the
>> second disk.
> 
> On a sidenote: Would you mind enabling popcon for your sparc64
> installations,
> so we get more counts of people running Debian on sparc64 hardware?

Enabling it for my sparc64 installations wouldn't be very useful, as those are 
just two or three machines (V210, V240, T5140) with one or two LXC containers 
each, and they're only used for experiments, so they're not representative.

Enabling it for my sparc installations would cause quite a spike in the Wheezy 
deployments, as those are 15-20 machines (V120, V210, V240, V440) with ~4 LXC 
containers each. Those currently can't be upgraded because Sid is too volatile.

Because I want to move forward with upgrading some of those machines to a newer 
release, and replacing some of the Sun Fire-series hardware with SPARC 
Enterprise-series hardware, I'm working on bootstrapping Stretch for both 
sparc64 and sparc, preferably --with-cpu(-32/-64)=ultrasparc3 instead of 
ultrasparc.

Just bootstrapping Stretch 9.0 for sparc64 is relatively straightforward thanks 
to excellent work by Adrian Glaubitz and others: for most of the binary 
packages the correct version is readily available from snapshot.debian.org. 
I've built a repository of binary packages to create Stretch 9.0 for sparc64 
that has either the correct version of each package or slightly older, up to 
build-essential and some additional packages such as the kernel.

>From this repository I can create a pbuilder basetgz that's very close to 
>Stretch 9.0, and allows to build additional packages to bring the 
>"very-close-to-9.0" repo to "really-9.0", as well as up to 9.1. I've also 
>installed a physical machine using a fairly old sid cd where all package 
>versions were older than Stretch 9.0, then upgraded using this repository, so 
>I have a physical machine that's "very-close-to-9.0" but hasn't seen any 
>packages "from the future" to run pbuilder on.

The only problem here is how to automatically select the correct binNMU for 
sparc64 for a given source package version, for Stretch 9.0. I think it can't 
be automated (correctly), so I verified it manually for the packages that I've 
done, but it's unrealistic to do so for the entire archive. Once a certain 
amount of packages has been made available through this method, it seems easier 
to start (automatically) recompiling additional packages from source, rather 
than (manually) pulling in the correct binNMU from snapshot...

And if I do start recompiling a large amount of packages, I intend to optimize 
them for ultrasparc3 rather than ultrasparc, based on this [1] remark by David 
Miller.

Bootstrapping Stretch for sparc is less straightforward, as the latest/last 
packages available from snapshot are from two years ago. Still, there is a 
large amount of packages available that is not terribly old. Thanks to 
excellent work by Helmut Grohne and others [2], it's also possible to 
cross-compile a recent version of the most important packages from source.

It took only minimal patches to get rebootstrap to work against Stretch 9.0. It 
finishes successfully, and I have repositories available for both sparc and 
sparc64. Unfortunately, build-essential is not (yet) fully complete: 
rebootstrap does not (yet) produce a native gcc. At jenkins.debian.net, builds 
considered successful finish in the same state, so I guess producing all the 
build dependencies to produce a native gcc is (currently) out of the scope of 
rebootstrap. I'm working on creating a useful native pbuilder chroot for sparc 
(similar to what I have for sparc64), either by pulling packages from 
rebootstrap into a chroot created from snapshot, or by pulling packages from 
snapshot into the cross-compiling chroot from rebootstrap.

I'm also investigating botch and dose to determine the optimal order for 
mass-building all the packages. Because so many packages are available, build 
dependencies will probably not be a problem, but by doing them in the optimal 
order, it might be possible to get correctly ultrasparc3-optimized versions of 
all packages in one or maybe two runs, and I think a random order might require 
more such runs.

Having Stretch repositories with a significant number of packages available for 
both sparc64 and sparc would open up a lot of opportunities for testing and 
actually using the port, and having them optimized for ultrasparc3 would allow 
useful performance testing on a broad range of currently relevant hardware. If 
I succeed in building the repositories, I hope to make them public.

Tom

> [1] https://patchwork.ozlabs.org/comment/927979/
> [2] https://wiki.debian.org/HelmutGrohne/rebootstrap

Re: qlogic fibrechannel

[Kevin Stabel]

Hi Rick,

Is it qla2200?

Kind Regards,

-Kevin

On Sep 7, 2017 2:18 PM, "Rick Leir"  wrote:

> Hi all
> I am still hoping to get my Sun 2000 (vintage 2002) running with Debian.
> The problem was the Qlogic fibrechannel disk driver, so perhaps I can add
> in a different disk controller temporarily. What economical solution would
> you recommend? Perhaps a USB disk?
>
> By the way, OpenBSD installs fine. I might be able to compare drivers and
> fix this bug, but the problem would be much easier to debug with Debian
> booting from a SCSI or SATA disk.
> Thanks
> Rick
>
> More Oracle analysis:
> https://meshedinsights.com/2017/09/03/oracle-finally-killed-sun/
>
> --
> Sorry for being brief. Alternate email is rickleir at yahoo dot com

Re: qlogic fibrechannel

[Anatoly Pugachev]

On Thu, Sep 7, 2017 at 3:17 PM, Rick Leir  wrote:
> Hi all
> I am still hoping to get my Sun 2000 (vintage 2002) running with Debian. The
> problem was the Qlogic fibrechannel disk driver, so perhaps I can add in a
> different disk controller temporarily. What economical solution would you
> recommend? Perhaps a USB disk?

solaris 10 and solaris 11 lists sun blade 2000 as supported system, so
you can choose disk controller for your disks
using solaris 10 / solaris 11 HCL [1] query page for "disk controller"
[2] , and try to find out does your choosen controller would be
supported by linux kernel 4.12 (latest debian unstable / sid kernel),
should be quite cheap on "IT flea market" or on ebay...

1. http://www.oracle.com/webfolder/technetwork/hcl/data/sol/index.html
2. 
http://www.oracle.com/webfolder/technetwork/hcl/data/sol/components/views/disk_controller_all_results.page1.html

Re: qlogic fibrechannel

[John Paul Adrian Glaubitz]

On 09/07/2017 02:17 PM, Rick Leir wrote:

More Oracle analysis:
https://meshedinsights.com/2017/09/03/oracle-finally-killed-sun/


Please don't post these things here anymore, those become very annoying.

Oracle hasn't made any official statements yet, so any discussion regarding
this is pure speculation and doesn't help anyone.

Thank you!
Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: qlogic fibrechannel

[Rick Leir]

Hi all
I am still hoping to get my Sun 2000 (vintage 2002) running with Debian. The 
problem was the Qlogic fibrechannel disk driver, so perhaps I can add in a 
different disk controller temporarily. What economical solution would you 
recommend? Perhaps a USB disk?

By the way, OpenBSD installs fine. I might be able to compare drivers and fix 
this bug, but the problem would be much easier to debug with Debian booting 
from a SCSI or SATA disk.
Thanks
Rick

More Oracle analysis:
https://meshedinsights.com/2017/09/03/oracle-finally-killed-sun/

-- 
Sorry for being brief. Alternate email is rickleir at yahoo dot com 

Re: mdadm /boot mirror and sun disklabel corruption

[blmink]

06.09.2017 20:46, Frank Scheiner пишет:

On 09/06/2017 05:21 PM, Fedor Konstantinov wrote:

I'm creating mirrored system disk.
For example I make partitions on two disks like the following:
1. 500MB for /boot - boot partition
2. 2GB for swap - swap
3. Whole disk - sun's whole disk
4. 31,6GB for / - rest for the root fs

Then I create metadevices (mirrors) for partitions 1,2 and 4.

We know, that sun disk label (partition table) resides at the 
beginning of the disk. In our case partition 1 (for the /boot 
filesystem) is also at the beginning of the disk.
When debian installer creates mdadm metadata v1.2 for partition 1 it 
overwrites sun disklabel. As a result after installation OBP can't 
read disk label and boot the system.
Version 0.90 metadata resides at the end of partition, so it is safe 
to use it for partitions at the beginning of disks with sun disklabel.


Unfortunately, in the debian installer we don't have possibility to 
select metadata version during install. :(


I'm not familiar with all the details of mdadm, but the way you 
describe it, it sounds like mdadm metadata is per partition and not 
per disk.


Then couldn't this issue be worked around by creating a small unused 
partition at the beginning of the disk in question which hence offsets 
the partition for `/boot`? So that mdadm v1.2 metadata for the `/boot` 
partition does not end in the Sun disk label?
Yes. It's possible to create unused partition at track 0 of the disk. 
But we will lose some amount of disk space in such case.

Re: mdadm /boot mirror and sun disklabel corruption

[John Paul Adrian Glaubitz]

Hi Tom!

On 09/07/2017 10:30 AM, Tom Turelinckx wrote:

Not all of those may be necessary anymore, but I've been doing it like
that since squeeze and up to the current sid on dozens of machines, and
it works reliably: when the first disk fails, I am able to boot from the
second disk.


On a sidenote: Would you mind enabling popcon for your sparc64 installations,
so we get more counts of people running Debian on sparc64 hardware?

Adrian

--
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Re: mdadm /boot mirror and sun disklabel corruption

[Tom Turelinckx]

Hi Fedor,

> For example I make partitions on two disks like the following:
> 
> 1. 500MB for /boot - boot partition
> 2. 2GB for swap - swap
> 3. Whole disk - sun's whole disk
> 4. 31,6GB for / - rest for the root fs
> 
> Then I create metadevices (mirrors) for partitions 1,2 and 4.

I'm using a similar layout for boot disks.

I leave the first cylinder on the disk unused, except for partition 3 (whole 
disk); I limit partition 1 (boot partition) so the end of the partition falls 
within 512MB from the start of the disk; I use v0.90 metadata for md1 (/boot), 
and format it as ext2.

Not all of those may be necessary anymore, but I've been doing it like that 
since squeeze and up to the current sid on dozens of machines, and it works 
reliably: when the first disk fails, I am able to boot from the second disk.

Tom