Re: The end of my Ultrasparc 5?!?

[Petr Vorel]

Hi Adrian,

> > Interesting behaviour :-). So the problem is somewhere in 
> > btrfs_scan_devices() [1], [2].
> > Are you avare about any bug report of this behavior? I haven't found it in 
> > btrfs-progs
> > issues list [3] nor in kernel bugzilla BTRFS issues.

> No, I never bothered reporting it, I just blacklisted the floppy kernel 
> module.

> My assumption is that it was never reported because the floppy module for PC
> floppy controllers behaves differently and hence btrfs doesn't scan those and
> since Amigas and UltraSPARC machines are less common these days, no one run 
> into
> this situation before.

Thanks for info. Make sense.
I might try to have a look if I manage to reproduce it with qemu.

Kind regards,
Petr

> Adrian

Re: The end of my Ultrasparc 5?!?

[John Paul Adrian Glaubitz]

On 01/26/2018 02:52 AM, Petr Vorel wrote:
>> As for btrfs: The filesystem detection code is just plain stupid.
> 
> Interesting behaviour :-). So the problem is somewhere in 
> btrfs_scan_devices() [1], [2].
> Are you avare about any bug report of this behavior? I haven't found it in 
> btrfs-progs
> issues list [3] nor in kernel bugzilla BTRFS issues.

No, I never bothered reporting it, I just blacklisted the floppy kernel module.

My assumption is that it was never reported because the floppy module for PC
floppy controllers behaves differently and hence btrfs doesn't scan those and
since Amigas and UltraSPARC machines are less common these days, no one run into
this situation before.

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: The end of my Ultrasparc 5?!?

[Petr Vorel]

Hi Adrian,

> I've seen that on my Amiga 4000 as well.

> The problem is that btrfs tries to determine whether a block device is
> a hard drive or not and if the block device driver misses a certain
> flag (e.g. removable) it will just scan forever.

> In the case of my Amiga, the btrfs module was scanning the floppy drive
> for a btrfs filesystem and without a floppy disk inserted, it would
> scan forever.

> If your UltraSPARC 5 has a floppy disk drive, it might be doing the
> same in your case. And if your machine has a floppy disk controller
> but no drive attached to it, this might explain why seemingly nothing
> is happening.

> As for btrfs: The filesystem detection code is just plain stupid.

Interesting behaviour :-). So the problem is somewhere in btrfs_scan_devices() 
[1], [2].
Are you avare about any bug report of this behavior? I haven't found it in 
btrfs-progs
issues list [3] nor in kernel bugzilla BTRFS issues.

> Adrian


Kind regards,
Petr

[1] https://github.com/kdave/btrfs-progs/blob/master/cmds-device.c#L296
[2] https://github.com/kdave/btrfs-progs/blob/master/utils.c#L1953
[3] https://github.com/kdave/btrfs-progs/issues
[4] https://bugzilla.kernel.org/buglist.cgi?component=btrfs

Re: The end of my Ultrasparc 5?!?

[Sean Whitney]

On 01/25/2018 04:24 PM, John Paul Adrian Glaubitz wrote:

On 01/26/2018 01:13 AM, James Clarke wrote:

It' will stay like this for days

Actually looking back through my backups, I reinstalled sparc64 in March 2017, 
and the btrfs packages are included in the next backup.  These have been 
installed all along, but the timeout behavior must have changed at some point.


Interesting. You should be able to stop it loading by adding
modprobe.blacklist=btrfs to the kernel command line.


I've seen that on my Amiga 4000 as well.

The problem is that btrfs tries to determine whether a block device is
a hard drive or not and if the block device driver misses a certain
flag (e.g. removable) it will just scan forever.

In the case of my Amiga, the btrfs module was scanning the floppy drive
for a btrfs filesystem and without a floppy disk inserted, it would
scan forever.

If your UltraSPARC 5 has a floppy disk drive, it might be doing the
same in your case. And if your machine has a floppy disk controller
but no drive attached to it, this might explain why seemingly nothing
is happening.

Don't worry, your UltraSPARC is fine. Classic Unix workstations were
built like tanks, they usually don't die unless you drop them from a
skyscraper. The only issue that can happen is the CMOS battery dying
which makes the machine sometimes behave erratically. Replacing the
battery helps wonders, sometimes a NVRAM reset is necessary.

As for btrfs: The filesystem detection code is just plain stupid.

Adrian



Well with a little insight from James and John I was able to boot it 
from a 4.12.0-1 kernel which didn't seem to exhibit the same hanging 
behavior that the 4.14.0-1 and 4.14.0-2 kernels displayed.  Currently 
removing btrfs packages and will attempt to boot into the 4.14.0-2 kernel.


Sean
--
The difference between you and a real soldier is that you are willing to 
kill for "your rights". A soldier is somebody who is willing to die to 
protect somebody else's rights.

― Eliot Spencer (Leverage TV Show)

Re: The end of my Ultrasparc 5?!?

[Sean Whitney]

On 01/25/2018 04:24 PM, John Paul Adrian Glaubitz wrote:

On 01/26/2018 01:13 AM, James Clarke wrote:

It' will stay like this for days

Actually looking back through my backups, I reinstalled sparc64 in March 2017, 
and the btrfs packages are included in the next backup.  These have been 
installed all along, but the timeout behavior must have changed at some point.


Interesting. You should be able to stop it loading by adding
modprobe.blacklist=btrfs to the kernel command line.


I've seen that on my Amiga 4000 as well.

The problem is that btrfs tries to determine whether a block device is
a hard drive or not and if the block device driver misses a certain
flag (e.g. removable) it will just scan forever.

In the case of my Amiga, the btrfs module was scanning the floppy drive
for a btrfs filesystem and without a floppy disk inserted, it would
scan forever.

If your UltraSPARC 5 has a floppy disk drive, it might be doing the
same in your case. And if your machine has a floppy disk controller
but no drive attached to it, this might explain why seemingly nothing
is happening.

Don't worry, your UltraSPARC is fine. Classic Unix workstations were
built like tanks, they usually don't die unless you drop them from a
skyscraper. The only issue that can happen is the CMOS battery dying
which makes the machine sometimes behave erratically. Replacing the
battery helps wonders, sometimes a NVRAM reset is necessary.

As for btrfs: The filesystem detection code is just plain stupid.

Adrian



I believe you are correct, that there is a floppy disk controller and no 
drive.  Now if I can just figure out how where the disk controller is



Sean

--
The difference between you and a real soldier is that you are willing to 
kill for "your rights". A soldier is somebody who is willing to die to 
protect somebody else's rights.

― Eliot Spencer (Leverage TV Show)

Re: The end of my Ultrasparc 5?!?

[John Paul Adrian Glaubitz]

On 01/26/2018 01:13 AM, James Clarke wrote:
>> It' will stay like this for days
>>
>> Actually looking back through my backups, I reinstalled sparc64 in March 
>> 2017, and the btrfs packages are included in the next backup.  These have 
>> been installed all along, but the timeout behavior must have changed at some 
>> point.
> 
> Interesting. You should be able to stop it loading by adding
> modprobe.blacklist=btrfs to the kernel command line.

I've seen that on my Amiga 4000 as well.

The problem is that btrfs tries to determine whether a block device is
a hard drive or not and if the block device driver misses a certain
flag (e.g. removable) it will just scan forever.

In the case of my Amiga, the btrfs module was scanning the floppy drive
for a btrfs filesystem and without a floppy disk inserted, it would
scan forever.

If your UltraSPARC 5 has a floppy disk drive, it might be doing the
same in your case. And if your machine has a floppy disk controller
but no drive attached to it, this might explain why seemingly nothing
is happening.

Don't worry, your UltraSPARC is fine. Classic Unix workstations were
built like tanks, they usually don't die unless you drop them from a
skyscraper. The only issue that can happen is the CMOS battery dying
which makes the machine sometimes behave erratically. Replacing the
battery helps wonders, sometimes a NVRAM reset is necessary.

As for btrfs: The filesystem detection code is just plain stupid.

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: The end of my Ultrasparc 5?!?

[James Clarke]

On 26 Jan 2018, at 00:10, Sean Whitney  wrote:
> On 01/25/2018 04:03 PM, James Clarke wrote:
>> On 25 Jan 2018, at 23:58, Sean Whitney  wrote:
>>> 
>>> I recently switched from sparc to sparc64 using the cdrom drive in 
>>> September.  Sometime in the last two weeks the server rebooted and when it 
>>> tried to restart it hung trying to find a btrfs filesystem, which I don't 
>>> have.  This seems to be a problem for PCs, but it resolves itself in 15 
>>> seconds, and is an annoyance, while my hangs indefinately.  The solution is 
>>> to remove the btrfs packages installed on your system.  But I can't do this 
>>> because I can't get it complete a boot to get a prompt. Both aliases silo 
>>> images seem to have the same btrfs packages included. I'm not sure when the 
>>> btrfs packages were installed, not knowing it was an issue, I guess I 
>>> allowed them to be installed with updates.
>>> 
>>> Here is the rub, I can't seem to boot from the cdrom anymore. When I do I 
>>> get the following error.
>>> 
>>> Rebooting with command: boot cdrom
>>> Boot device: /pci@1f,0/pci@1,1/ide@3/cdrom@2,0:f  File and args:
>>> Can't read disk label.
>>> Can't open disk label package
>>> Evaluating: boot cdrom
>>> 
>>> Can't open boot device
>>> 
>>> 
>>> I can't boot with the net because the net install image for debian hasn't 
>>> worked for ultra 5's since lenny.
>>> 
>>> Right now I've turned off the Ultra 5 for the next 12 hours to see if it 
>>> makes any difference with the CDROM.
>>> 
>>> If anyone has any other suggestions as to any sort of recovery I'm all 
>>> ears, otherwise I guess it's time to go to recycle.
>>> 
>>> Thanks in advance,
>> No idea what's causing all your issues, unfortunately. Have you tried booting
>> with "linux init=/bin/bash" or similar? What exact error are you getting?
>> Regards,
>> James
> 
> yes, I've tried passing in init=/bin/bash but, it still trys to process the 
> btrfs filesystem before a prompt is available.
> 
> The boot process hangs here:
> 
> [   44.070355] raid6: int64x1  xor()43 MB/s
> [   44.190108] raid6: int64x2  gen()   125 MB/s
> [   44.310194] raid6: int64x2  xor()62 MB/s
> [   44.429980] raid6: int64x4  gen()   151 MB/s
> [   44.550073] raid6: int64x4  xor()80 MB/s
> [   44.669932] raid6: int64x8  gen()   133 MB/s
> [   44.790009] raid6: int64x8  xor()84 MB/s
> [   44.844728] raid6: using algorithm int64x4 gen() 151 MB/s
> [   44.912879] raid6:  xor() 80 MB/s, rmw enabled
> [   44.973689] raid6: using intx1 recovery algorithm
> [   45.101360] xor: automatically using best checksumming function   VIS 
> [   45.208607] crc32c_sparc64: sparc64 crc32c opcode not available.
> [   45.456022] Btrfs loaded, crc32c=crc32c-generic
> Scanning for Btrfs filesystems
> 
> 
> It' will stay like this for days
> 
> Actually looking back through my backups, I reinstalled sparc64 in March 
> 2017, and the btrfs packages are included in the next backup.  These have 
> been installed all along, but the timeout behavior must have changed at some 
> point.

Interesting. You should be able to stop it loading by adding
modprobe.blacklist=btrfs to the kernel command line.

James

Re: The end of my Ultrasparc 5?!?

[Sean Whitney]

yes, I've tried passing in init=/bin/bash but, it still trys to process 
the btrfs filesystem before a prompt is available.


The boot process hangs here:

[   44.070355] raid6: int64x1  xor()43 MB/s
[   44.190108] raid6: int64x2  gen()   125 MB/s
[   44.310194] raid6: int64x2  xor()62 MB/s
[   44.429980] raid6: int64x4  gen()   151 MB/s
[   44.550073] raid6: int64x4  xor()80 MB/s
[   44.669932] raid6: int64x8  gen()   133 MB/s
[   44.790009] raid6: int64x8  xor()84 MB/s
[   44.844728] raid6: using algorithm int64x4 gen() 151 MB/s
[   44.912879] raid6:  xor() 80 MB/s, rmw enabled
[   44.973689] raid6: using intx1 recovery algorithm
[   45.101360] xor: automatically using best checksumming function   VIS 


[   45.208607] crc32c_sparc64: sparc64 crc32c opcode not available.
[   45.456022] Btrfs loaded, crc32c=crc32c-generic
Scanning for Btrfs filesystems


It' will stay like this for days

Actually looking back through my backups, I reinstalled sparc64 in March 
2017, and the btrfs packages are included in the next backup.  These 
have been installed all along, but the timeout behavior must have 
changed at some point.


Sean

On 01/25/2018 04:03 PM, James Clarke wrote:

On 25 Jan 2018, at 23:58, Sean Whitney  wrote:


I recently switched from sparc to sparc64 using the cdrom drive in September.  
Sometime in the last two weeks the server rebooted and when it tried to restart 
it hung trying to find a btrfs filesystem, which I don't have.  This seems to 
be a problem for PCs, but it resolves itself in 15 seconds, and is an 
annoyance, while my hangs indefinately.  The solution is to remove the btrfs 
packages installed on your system.  But I can't do this because I can't get it 
complete a boot to get a prompt. Both aliases silo images seem to have the same 
btrfs packages included. I'm not sure when the btrfs packages were installed, 
not knowing it was an issue, I guess I allowed them to be installed with 
updates.

Here is the rub, I can't seem to boot from the cdrom anymore. When I do I get 
the following error.

Rebooting with command: boot cdrom
Boot device: /pci@1f,0/pci@1,1/ide@3/cdrom@2,0:f  File and args:
Can't read disk label.
Can't open disk label package
Evaluating: boot cdrom

Can't open boot device


I can't boot with the net because the net install image for debian hasn't 
worked for ultra 5's since lenny.

Right now I've turned off the Ultra 5 for the next 12 hours to see if it makes 
any difference with the CDROM.

If anyone has any other suggestions as to any sort of recovery I'm all ears, 
otherwise I guess it's time to go to recycle.

Thanks in advance,


No idea what's causing all your issues, unfortunately. Have you tried booting
with "linux init=/bin/bash" or similar? What exact error are you getting?

Regards,
James



--
The only time you should look in your neighbor's bowl it to make sure 
that they have enough.  You don't look in your neighbor's bowl to see if 
you have … as much as them.

― Louis CK

Re: The end of my Ultrasparc 5?!?

[James Clarke]

On 25 Jan 2018, at 23:58, Sean Whitney  wrote:
> 
> I recently switched from sparc to sparc64 using the cdrom drive in September. 
>  Sometime in the last two weeks the server rebooted and when it tried to 
> restart it hung trying to find a btrfs filesystem, which I don't have.  This 
> seems to be a problem for PCs, but it resolves itself in 15 seconds, and is 
> an annoyance, while my hangs indefinately.  The solution is to remove the 
> btrfs packages installed on your system.  But I can't do this because I can't 
> get it complete a boot to get a prompt. Both aliases silo images seem to have 
> the same btrfs packages included. I'm not sure when the btrfs packages were 
> installed, not knowing it was an issue, I guess I allowed them to be 
> installed with updates.
> 
> Here is the rub, I can't seem to boot from the cdrom anymore. When I do I get 
> the following error.
> 
> Rebooting with command: boot cdrom
> Boot device: /pci@1f,0/pci@1,1/ide@3/cdrom@2,0:f  File and args:
> Can't read disk label.
> Can't open disk label package
> Evaluating: boot cdrom
> 
> Can't open boot device
> 
> 
> I can't boot with the net because the net install image for debian hasn't 
> worked for ultra 5's since lenny.
> 
> Right now I've turned off the Ultra 5 for the next 12 hours to see if it 
> makes any difference with the CDROM.
> 
> If anyone has any other suggestions as to any sort of recovery I'm all ears, 
> otherwise I guess it's time to go to recycle.
> 
> Thanks in advance,

No idea what's causing all your issues, unfortunately. Have you tried booting
with "linux init=/bin/bash" or similar? What exact error are you getting?

Regards,
James