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