XPost: alt.os.linux

Having successfully upgraded my two primary QNAP 251+ NASs, I've handed
down two of the HDs to the Zyxel NSA221s NASs that were my original
backup solution. The disks are Seagate Iron Wolf 8TB ST8000VN004,
originally from Amazon ...

https://www.amazon.co.uk/dp/B07SZVVBBK

... but they are giving problems in their new home, or, I should say,
housing.

The problem is the same for each, they spin up too slowly to be found as
the NSA221 boots, so after a cold boot I have to reboot, so that then
they can be found on the reboot. Once that is done, they seem to be
perfectly satisfactory, and, despite the NAS specs saying that they only
work up to a max of 4TB per disk, I'm actually getting the full
(nominal) 8TB added to the capacity of the other Toshiba HDs which have
always been free of such problems.

I've had similar problems in the past with other Seagate HDs in these
NASs, which at the time I got around by using a reboot flag in a rather convoluted manner, and which now won't work anyway because I have since configured the NASs to use the combined disk space of the two disks as
one large virtual HD volume, which means that now I have nowhere to
write a reboot flag unless both HD are running and found at boot, in
which case I wouldn't need to write it anyway. I might be able to get
round this by using RAM, but it would need some investigation as to what
would survive a reboot.

This reboot requirement will be easy to forget and should be avoidable
by making the system wait longer for the disks to spin up. Setting
aside the problem of altering firmware (see next para), in a normal
Linux installation, how normally would one accomplish this? A boot
parameter? An /etc setting?

I have some scope for making changes, as in the past I've recompiled the firmware to be Gnu GPL and both NASs are running the result. Also the
command run by UBoot is stored in an environment variable, which means
that I could add a boot parameter to that fairly easily.

The Zyxel DK to build a GPL firmware dates from the Ubuntu 7 era (!),
but I was still running it satisfactorily somewhere around Ubuntu 16 or
18. Also, the NASs each have a serial header which I can use to
interrupt their boot and change things, though I wouldn't want to be
doing that on a permanent basis, only for temporary fixes to see if they
work. There are also OpenWRT versions of the firmware, but having
obtained already a pretty good result from my own firmware, I haven't
gone down that road, as it would be too time consuming for such old
hardware.

Can anyone suggest how to fix this slow spin-up problem?

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 05/05/2025 in message <vva03q$5ulg$1@dont-email.me> Java Jive wrote:

Can anyone suggest how to fix this slow spin-up problem?

Seriously?

How much is your data worth, more or less than £163.94?

--
Jeff Gaines Dorset UK
Did you know on the Canary Islands there is not one canary?
And on the Virgin Islands same thing, not one canary.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

Java Jive wrote:

Seagate Iron Wolf 8TB ST8000VN004
Can anyone suggest how to fix this slow spin-up problem?

I see several complaints about that drive being slow to spin-up, the
manual says 23s (typ) to 30s (max), so I suspect there's nothing you can
do to the drives themselves.

in your grub.cfg maybe experiment with boot_delay=xxx values in ms to
delay all the kernel messages?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

In uk.comp.os.linux Andy Burns <usenet@andyburns.uk> wrote:

Java Jive wrote:

Seagate Iron Wolf 8TB ST8000VN004
Can anyone suggest how to fix this slow spin-up problem?

I see several complaints about that drive being slow to spin-up, the
manual says 23s (typ) to 30s (max), so I suspect there's nothing you can
do to the drives themselves.

in your grub.cfg maybe experiment with boot_delay=xxx values in ms to
delay all the kernel messages?

boot_delay appears to slow down kernel printouts, which is likely to be a
bit dependent on how many there are. Instead I'd use rootdelay=30 to delay
the kernel start by 30 seconds, and then it'll boot at full speed.

(It'll be in the u-boot command line variable not grub.cfg, since this is a non-x86 device)

In regular Linux you could write a udev/systemd rule to mount the drive(s)
when it/they became ready, whenever that might be. This system is too old
for systemd though.

Theo

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On Mon, 5/5/2025 5:24 AM, Java Jive wrote:

Having successfully upgraded my two primary QNAP 251+ NASs, I've handed down two of the HDs to the Zyxel NSA221s NASs that were my original backup solution.  The disks are Seagate Iron Wolf 8TB ST8000VN004, originally from Amazon ...

https://www.amazon.co.uk/dp/B07SZVVBBK

... but they are giving problems in their new home, or, I should say, housing.

The problem is the same for each, they spin up too slowly to be found as the NSA221 boots, so after a cold boot I have to reboot, so that then they can be found on the reboot.  Once that is done, they seem to be perfectly satisfactory, and, despite

the NAS specs saying that they only work up to a max of 4TB per disk, I'm actually getting the full (nominal) 8TB added to the capacity of the other Toshiba HDs which have always been free of such problems.

I've had similar problems in the past with other Seagate HDs in these NASs, which at the time I got around by using a reboot flag in a rather convoluted manner, and which now won't work anyway because I have since configured the NASs to use the

combined disk space of the two disks as one large virtual HD volume, which means that now I have nowhere to write a reboot flag unless both HD are running and found at boot, in which case I wouldn't need to write it anyway.  I might be able to get round
this by using RAM, but it would need some investigation as to what would survive a reboot.

This reboot requirement will be easy to forget and should be avoidable by making the system wait longer for the disks to spin up.  Setting aside the problem of altering firmware (see next para), in a normal Linux installation, how normally would one

accomplish this?  A boot parameter?  An /etc setting?

I have some scope for making changes, as in the past I've recompiled the firmware to be Gnu GPL and both NASs are running the result.  Also the command run by UBoot is stored in an environment variable, which means that I could add a boot parameter to

that fairly easily.

The Zyxel DK to build a GPL firmware dates from the Ubuntu 7 era (!), but I was still running it satisfactorily somewhere around Ubuntu 16 or 18.  Also, the NASs each have a serial header which I can use to interrupt their boot and change things,

though I wouldn't want to be doing that on a permanent basis, only for temporary fixes to see if they work.  There are also OpenWRT versions of the firmware, but having obtained already a pretty good result from my own firmware, I haven't gone down that
road, as it would be too time consuming for such old hardware.

Can anyone suggest how to fix this slow spin-up problem?

I don't really see a "fix" for this.

The disk drive has a motor controller. It is a three phase waveform
generator in a sense. It is somehow programmed for an acceleration profile,
and that profile leads to a "constrained current draw". When the spindle
is seized, there is a modulation pattern applied to the waveform generator giving a characteristic sound, but this is mostly useless and too little
torque is generated to overcome a dry bearing or head stiction.

For such a slow startup, it could be drawing 12V @ 1A into the motor
controller chip. The frequency of the waveform generator ramps up, and
the motor accelerates. Current is drawn to make the motor accelerate
like that. It looks like the current draw is still open loop (the tops
of the current draw excursions are not lopped off), so the current
draw target is mostly maintained by the firmware watching for overload.

Three phase is used, for controlling torque ripple. The signal coming
off the head, is supposed to be at a fixed frequency for a zone. The
disk has zones, and the drive has to compensate for where it is reading
data. But while it is reading data, they don't want the clock rate
to vary. And the motor controller attempts to regulate the speed and
reduce the variation in speed. The servo wedges presumably have a strong
clock signal, and afford an opportunity to keep the PLL locked. The platter alternates between servo wedges and data sectors, as the heads stay on
a cylinder.

1TB drives can accelerate to 7200 RPM in five seconds. Hitachi-HGST-IBM
drives, are pokey, and can take more than 20 seconds for spinup.
(No other brands are supposed to be quite as pokey as some of those!
WD owns the remains of that stream of ownership and owns HGST.)

The five second drive, likely draws 12V @ 2A for five seconds. The
pokey drive draws 12V @ 1A for 20 seconds. The assumption is that
the slow drives are not "boot drives", whereas the fast drives gate
forward progress, so the power footprint is allowed to be larger.
At one time, the whole disk drive power envelope was 40W total,
and drives required laminar airflow over the top to keep the
temperature down. Modern drives at idle, can be as low as 5 watts idling
(not as much current needed to maintain constant platter speed).

You're not going to change the disk drive firmware. The technical details
of that are unknown. Even the command line language for the disk
interpreter is cryptic and mostly unknown by laymen. Some of the language
was exposed, in a Seagate data recovery procedure for a broken firmware.

*******

The PC compatible BIOS, has a timer setting, and the max time is 35 seconds. This is the time constant the NAS should be using at its "BIOS level".
That is, if it had a BIOS level.

A drive will NOT respond to an ID command, until up to speed. The re-enforcement for this is simple. The drive won't do anything until
the motor controller chip says "we are now at 7200RPM". Then the heads
load onto the platter edge, using the bootstrap HDD controller ROM.
Then around 2 megabytes of additional firmware is read off the
platter, as the first read operation. This is loaded into
controller RAM. The 2 megabytes would contain items such as an
ATA command parser. Now, when the "ID yourself" command comes in,
the drive is willing to answer. "Seagate Pokey Drive ABC12345".

Normally, the PC BIOS waits the 35 seconds, using repeated ID yourself commands, to eventually get an answer.

*******

The system response then, to a rotating drive, whether done by
NAS BIOS or NAS OS, is to wait up to 35 seconds for ID to complete.

*******

The SATA bus has no RESET signal. (The IDE ribbon cable interface
did have a hardware RESET, which is handy for getting insane
controller processors to restart. The only way to fix insanity
on SATA drives, is to cycle the power!)

This is why your reboot strategy works. When the NAS is told to
reboot, the drive is up to speed, and the drive is in a sense,
unaware of the system state. It continues spinning at 7200 RPM,
the command parser is loaded, the very first "ID yourself" that
comes in during boot, will be answered. That is why your current
double-boot method is working.

Paul

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

Theo wrote:

boot_delay appears to slow down kernel printouts, which is likely to be a
bit dependent on how many there are.

hence "experiment"

Instead I'd use rootdelay=30 to delay
the kernel start by 30 seconds, and then it'll boot at full speed.

I read that as waiting xx seconds before mounting the root fs, but if it
can't see any disks, will it wait, or bail-out?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

In uk.comp.os.linux Andy Burns <usenet@andyburns.uk> wrote:

Theo wrote:

boot_delay appears to slow down kernel printouts, which is likely to be a bit dependent on how many there are.

hence "experiment"

Instead I'd use rootdelay=30 to delay
the kernel start by 30 seconds, and then it'll boot at full speed.

I read that as waiting xx seconds before mounting the root fs, but if it can't see any disks, will it wait, or bail-out?

It'll pause the boot for 30 seconds at the point the root fs is mounted.
The rootfs is not on HDD, it'll be in flash, so the boot will then proceed
once the 30s is up - it won't then fail for lack of a rootfs. If the discs still aren't up at the end of 30s (or 120s or whatever number you write
there) then they will be missing, just as they are at the moment. But if
they are not reliable enough to start given a large enough timeout then that points to a problem with the discs, rather than just a regular but slow
spinup.

(if you did have your rootfs on the HDD you could use 'rootwait' to pause
until the rootfs volume was ready. But that only applies for the rootfs and not other volumes)

Theo

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

Apologies for a slight delay in replying, thanks for all the replies ...

On 2025-05-05 20:02, Theo wrote:

In uk.comp.os.linux Andy Burns <usenet@andyburns.uk> wrote:

Theo wrote:

Instead I'd use rootdelay=30 to delay
the kernel start by 30 seconds, and then it'll boot at full speed.

I read that as waiting xx seconds before mounting the root fs, but if it
can't see any disks, will it wait, or bail-out?

It'll pause the boot for 30 seconds at the point the root fs is mounted.
The rootfs is not on HDD, it'll be in flash, so the boot will then proceed once the 30s is up - it won't then fail for lack of a rootfs. If the discs still aren't up at the end of 30s (or 120s or whatever number you write there) then they will be missing, just as they are at the moment. But if they are not reliable enough to start given a large enough timeout then that points to a problem with the discs, rather than just a regular but slow spinup.

Don't think that's the problem here, rather Seagate generally just seem
to be too slow in spinning up for this box's liking.

(if you did have your rootfs on the HDD you could use 'rootwait' to pause until the rootfs volume was ready. But that only applies for the rootfs and not other volumes)

I spent yesterday evening trying to remember the name of the program
that reads and sets UBoot environment variable, and finally found it
this morning. Here are the current settings:

~ # /zyxel/sbin/fw_printenv
bootcmd=cp 0x411e0000 0x4a000000 0x25c000; bootm 0x41020000
baudrate=115200
autoload=n
netmask=255.255.255.0
bootfile="uImage"
MODEL_ID=DC01
PRODUCT_NAME=NSA-221
FEATURE_BIT=00
CONTRY_TYPE=FF
VENDOR_NAME=ZyXEL Communications Corp.
ethaddr=50:67:F0:93:49:90
ipaddr=192.168.1.233
tftpblocksize=512
tftprun=cp 0x411e0000 0x4a000000 0x25c000; tftpboot 0x57000000 uImage;
bootm 0x57000000
stdin=serial
stdout=serial
stderr=serial
bootargs=console=ttyS0,115200n8 root=/dev/ram0 rw init=/sbin/init initrd=0x4a000000,4M elevator=cfq mtdparts=physmap-flash.0:128k(uboot),1792k(kernel),1664k(initrd),448k(etc),48k(empty),8k(env1),8k(env2)
mem=256M poweroutage=yes
serverip=[anonymised]

There is a corresponding /zyxel/sbin/fw_setenv which doesn't have a
--help parameter, but which nevertheless seems understandable enough:

~ # /zyxel/sbin/fw_setenv test "This is a test"
~ # /zyxel/sbin/fw_printenv test
test=This is a test
~ # /zyxel/sbin/fw_setenv test
~ # /zyxel/sbin/fw_printenv test
## Error: "test" not defined

So I guessed that I needed to try adding 'rootdelay=30' to the bootargs
setting ...

~ # /zyxel/sbin/fw_setenv bootargs "console=ttyS0,115200n8
root=/dev/ram0 rootdelay=30 rw init=/sbin/init initrd=0x4a000
000,4M elevator=cfq mtdparts=physmap-flash.0:128k(uboot),1792k(kernel),1664k(initrd),448k(etc),48k(empty),8k(env1),8k(en
v2) mem=256M poweroutage=yes"
~ # /zyxel/sbin/fw_printenv bootargs
bootargs=console=ttyS0,115200n8 root=/dev/ram0 rootdelay=30 rw
init=/sbin/init initrd=0x4a000000,4M elevator=cfq mtdparts=physmap-flash.0:128k(uboot),1792k(kernel),1664k(initrd),448k(etc),48k(empty),8k(env1),8k(env2)
mem=256M poweroutage=yes

... but, from the sound, I was suspicious that the drives are only
powered up when the kernel loads the driver, and then the driver almost immediately expects them to be present, which would mean that this ploy wouldn't work. However, I was game to try it, as I didn't think it
could do any harm, but, as I feared, it didn't work. The delay comes
long after this point, and too late to affect things. Further
information about the actual point of failure is in the dmesg logs below.

Thanks for trying anyway.

What I think is needed is some way of telling the driver to wait longer
for the drives after spinning them up, or a way of spinning up the
drives on power on.

Appendix:
---------

Two things that I meant to add to my OP yesterday, but forgot, I add now
below, in case they prove to be important ...

1) The Zyxel NSA221 NAS is based on an Oxford Semiconductor NAS
controller board design, commonly known as Oxnas. There is some
historical information about the box on the Wayback Machine, for example:

<https://web.archive.org/web/20150422213204/http://zyxel.nas-central.org/wiki/Category:NSA-221>

2) In case anybody spots anything important that I'd missed, these are
the relevant parts of a serial log from two successive boots, first from
cold where it fails to find the second drive, then from a successful
reboot when the drive is already spinning:

ox810sata: OX810 sata core.
scsi0 : oxnassata
ata1: SATA max UDMA/133 irq 18
ata_eh_reset(2207):Sleep 1 sec before any error happens
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata_dev_read_id(2037): Give 100ms while getting HW ID
ata1.00: qc timeout (cmd 0xec)
ox810sata_bmdma_stop - aborting DMA
ox810sata aborting DMA.
ox810sata sending sync escapes
ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata1: failed to recover some devices, retrying in 1 secs ata_eh_reset(2207):Sleep 1 sec before any error happens ata_wait_after_reset(3500):msleep(6000);
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata_dev_read_id(2037): Give 100ms while getting HW ID
ata1.00: qc timeout (cmd 0xec)
ox810sata_bmdma_stop - aborting DMA
ox810sata aborting DMA.
ox810sata sending sync escapes
ata1.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata1: failed to recover some devices, retrying in 1 secs ata_eh_reset(2207):Sleep 1 sec before any error happens ata_wait_after_reset(3500):msleep(6000);
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata_dev_read_id(2037): Give 100ms while getting HW ID
ata1.00: HPA detected: current 7814037168, native 18446744072933654192
ata1.00: ATA-8: TOSHIBA HDWE140, FP2A, max UDMA/100
ata1.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata1.00: Drive reports diagnostics failure. This may indicate a drive
ata1.00: fault or invalid emulation. Contact drive vendor for information. ata_dev_read_id(2037): Give 100ms while getting HW ID
ata1.00: configured for UDMA/100
scsi 0:0:0:0: Direct-Access ATA TOSHIBA HDWE140 FP2A PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
sd 0:0:0:0: [sda] 7814037168 512-byte hardware sectors (4000787 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
sd 0:0:0:0: [sda] 7814037168 512-byte hardware sectors (4000787 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sda: sda1 sda2
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
ox810sata: OX810 sata core.
scsi1 : oxnassata
ata2: SATA max UDMA/133 irq 18
ata_eh_reset(2207):Sleep 1 sec before any error happens
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata_dev_read_id(2037): Give 100ms while getting HW ID
ata2.00: qc timeout (cmd 0xec)
ox810sata_bmdma_stop - aborting DMA
ox810sata aborting DMA.
ox810sata sending sync escapes
Port 0 High level registers

[snip long register dump]

oxnas_dma_dump_registers() - end
ox810sata core reset
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: failed to recover some devices, retrying in 1 secs ata_eh_reset(2207):Sleep 1 sec before any error happens ata_wait_after_reset(3500):msleep(6000);
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata_dev_read_id(2037): Give 100ms while getting HW ID
ata2.00: qc timeout (cmd 0xec)
ox810sata_bmdma_stop - aborting DMA
ox810sata aborting DMA.
ox810sata sending sync escapes
Port 0 High level registers

[snip long register dump]

oxnas_dma_dump_registers() - end
ox810sata core reset
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: failed to recover some devices, retrying in 1 secs ata_eh_reset(2207):Sleep 1 sec before any error happens ata_wait_after_reset(3500):msleep(6000);
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata_dev_read_id(2037): Give 100ms while getting HW ID
ata2.00: qc timeout (cmd 0xec)
ox810sata_bmdma_stop - aborting DMA
ox810sata aborting DMA.
ox810sata sending sync escapes
Port 0 High level registers

[snip long register dump]

oxnas_dma_dump_registers() - end
ox810sata core reset
ata2.00: failed to IDENTIFY (I/O error, err_mask=0x4)
ata2: failed to recover some devices, retrying in 1 secs ata_eh_reset(2207):Sleep 1 sec before any error happens ata_wait_after_reset(3500):msleep(6000);
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)


This is what it looks like on the reboot, when the Seagate disk is
already spun up:


ox810sata: OX810 sata core.
scsi0 : oxnassata
ata1: SATA max UDMA/133 irq 18
ata_eh_reset(2207):Sleep 1 sec before any error happens
Copy button release
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata_dev_read_id(2037): Give 100ms while getting HW ID
ata1.00: HPA detected: current 7814037168, native 18446744072933654192
ata1.00: ATA-8: TOSHIBA HDWE140, FP2A, max UDMA/100
ata1.00: 7814037168 sectors, multi 16: LBA48 NCQ (depth 0/32) ata_dev_read_id(2037): Give 100ms while getting HW ID
ata1.00: configured for UDMA/100
ata1: exception Emask 0x10 SAct 0x0 SErr 0x0 action 0xb t4
ata1: soft resetting link
ata_eh_reset(2207):Sleep 1 sec before any error happens
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata_dev_read_id(2037): Give 100ms while getting HW ID
ata_dev_read_id(2037): Give 100ms while getting HW ID
ata1.00: configured for UDMA/100
ata1: EH complete
scsi 0:0:0:0: Direct-Access ATA TOSHIBA HDWE140 FP2A PQ: 0 ANSI: 5
sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
sd 0:0:0:0: [sda] 7814037168 512-byte hardware sectors (4000787 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 0:0:0:0: [sda] Very big device. Trying to use READ CAPACITY(16).
sd 0:0:0:0: [sda] 7814037168 512-byte hardware sectors (4000787 MB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sda: sda1 sda2
sd 0:0:0:0: [sda] Attached SCSI disk
sd 0:0:0:0: Attached scsi generic sg0 type 0
ox810sata: OX810 sata core.
scsi1 : oxnassata
ata2: SATA max UDMA/133 irq 18
ata_eh_reset(2207):Sleep 1 sec before any error happens
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata_dev_read_id(2037): Give 100ms while getting HW ID
ata2.00: ATA-11: ST8000VN004-2M2101, SC60, max UDMA/133
ata2.00: 15628053168 sectors, multi 16: LBA48 NCQ (depth 0/32) ata_dev_read_id(2037): Give 100ms while getting HW ID
ata2.00: configured for UDMA/133
scsi 1:0:0:0: Direct-Access ATA ST8000VN004-2M21 SC60 PQ: 0 ANSI: 5
sd 1:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16).
sd 1:0:0:0: [sdb] 15628053168 512-byte hardware sectors (8001563 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sd 1:0:0:0: [sdb] Very big device. Trying to use READ CAPACITY(16).
sd 1:0:0:0: [sdb] 15628053168 512-byte hardware sectors (8001563 MB)
sd 1:0:0:0: [sdb] Write Protect is off
sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sdb: sdb1 sdb2
sd 1:0:0:0: [sdb] Attached SCSI disk
sd 1:0:0:0: Attached scsi generic sg1 type 0

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

Java Jive wrote:

from the sound, I was suspicious that the drives are only powered up
when the kernel loads the driver, and then the driver almost immediately expects them to be present, which would mean that this ploy wouldn't
work.  However, I was game to try it, as I didn't think it could do any harm, but, as I feared, it didn't work.  The delay comes long after this point, and too late to affect things.

A wild thought (which I can't test as I no longer run openWRT so no
u-boot device) add the normal kernel as a crash kernel, let the first
kernel boot and spin the drives up too late ... then find a way to crash
it, so the crash kernel starts up affer the drives are spinning?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

In uk.comp.os.linux Andy Burns <usenet@andyburns.uk> wrote:

Java Jive wrote:

from the sound, I was suspicious that the drives are only powered up
when the kernel loads the driver, and then the driver almost immediately expects them to be present, which would mean that this ploy wouldn't work.  However, I was game to try it, as I didn't think it could do any harm, but, as I feared, it didn't work.  The delay comes long after this point, and too late to affect things.

A wild thought (which I can't test as I no longer run openWRT so no
u-boot device) add the normal kernel as a crash kernel, let the first
kernel boot and spin the drives up too late ... then find a way to crash
it, so the crash kernel starts up affer the drives are spinning?

I'm not sure that's an intrinsic feature of uboot - the idea of booting into something different second time around is a feature of OpenWRT I think. I don't know how they do it. None of the other systems I've worked on with u-boot do that.

However uboot does have its own boot delay. You:

setenv bootdelay 120

to delay 120 seconds. In the Zyxel case it appears that would be:

~ # /zyxel/sbin/fw_setenv bootdelay 120

The difference is that this is prior to the kernel booting so the SATA
driver does not fire up. However, if spinup only happens when the driver begins talking to the drive then this won't help.

I suppose another option if that happens is to try to talk to the SATA drive
in uboot, which might commence spinup. Docs: https://github.com/u-boot/u-boot/blob/master/doc/README.sata

maybe the 'sata info' command is enough to wake the HDD, and even if it
fails you can then 'sleep 30' or something while the drive spins up, and
then boot Linux.

(I'm assuming the Zyxel firmware will let you edit the u-boot command
script, not just the u-boot environment variables)

Theo

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

Theo wrote:

I'm not sure that's an intrinsic feature of uboot - the idea of booting into something different second time around is a feature of OpenWRT I think.

Crash kernels aren't an openẀRT thing, just a Linux thing, I'm sure
years ago they were more generic, but now seems focused just as a kdump
kernel, probably too memory hungry for a uboot type of device anyway ...

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 2025-05-06 15:07, Theo wrote:

~ # /zyxel/sbin/fw_setenv bootdelay 120

The difference is that this is prior to the kernel booting so the SATA
driver does not fire up. However, if spinup only happens when the driver begins talking to the drive then this won't help.

Yes, I tried 20 seconds, so now the message ...

Hit any key to stop autoboot:

... displays for 20 seconds instead of the 3 seconds previously, but
this did not help because the HDs didn't spin up upon power on, only
when the driver loaded.

I suppose another option if that happens is to try to talk to the SATA drive in uboot, which might commence spinup. Docs: https://github.com/u-boot/u-boot/blob/master/doc/README.sata

maybe the 'sata info' command is enough to wake the HDD, and even if it
fails you can then 'sleep 30' or something while the drive spins up, and
then boot Linux.

(I'm assuming the Zyxel firmware will let you edit the u-boot command
script, not just the u-boot environment variables)

I may look into this, though I think the best solution would be to fix
the short delay in the SATA driver module, and I'm trying to find a
suitable place in the source files to do that. Meanwhile, a simpler possibility would be to write the autoreboot flag into the UBoot
environment, because that doesn't need the HDs to be found to provide
storage, and would survive a reboot. I may try this as a temporary fix,
until and if I can investigate a better solution.

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

In uk.comp.os.linux Java Jive <java@evij.com.invalid> wrote:

On 2025-05-06 15:07, Theo wrote:

~ # /zyxel/sbin/fw_setenv bootdelay 120

The difference is that this is prior to the kernel booting so the SATA driver does not fire up. However, if spinup only happens when the driver begins talking to the drive then this won't help.

Yes, I tried 20 seconds, so now the message ...

Hit any key to stop autoboot:

... displays for 20 seconds instead of the 3 seconds previously, but
this did not help because the HDs didn't spin up upon power on, only
when the driver loaded.

I suppose another option if that happens is to try to talk to the SATA drive
in uboot, which might commence spinup. Docs: https://github.com/u-boot/u-boot/blob/master/doc/README.sata

maybe the 'sata info' command is enough to wake the HDD, and even if it fails you can then 'sleep 30' or something while the drive spins up, and then boot Linux.

(I'm assuming the Zyxel firmware will let you edit the u-boot command script, not just the u-boot environment variables)

I may look into this, though I think the best solution would be to fix
the short delay in the SATA driver module, and I'm trying to find a
suitable place in the source files to do that. Meanwhile, a simpler possibility would be to write the autoreboot flag into the UBoot
environment, because that doesn't need the HDs to be found to provide storage, and would survive a reboot. I may try this as a temporary fix, until and if I can investigate a better solution.

Are you sure this delay isn't just the drive set to spin down when not used? Perhaps they boot in the spun-down state. When you try to access a drive that's spun down, the system will often hang waiting for it to spin up.
Since the kernel wants to read the partition table stored on the disc I'm
not surprised if it hangs if the drive isn't spinning, and maybe times out.

The simplest way to adjust it with a Windows tool like SeaTools - there's
now a version for Linux and a bootable USB version too.

It's also worth checking if there's updated drive firmware, which may also address the problem.

Theo

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 2025-05-07 15:50, Theo wrote:

Are you sure this delay isn't just the drive set to spin down when not used? Perhaps they boot in the spun-down state. When you try to access a drive that's spun down, the system will often hang waiting for it to spin up.
Since the kernel wants to read the partition table stored on the disc I'm
not surprised if it hangs if the drive isn't spinning, and maybe times out.

The simplest way to adjust it with a Windows tool like SeaTools - there's
now a version for Linux and a bootable USB version too.

Some boxes set that OFF timeout themselves, not in the disks, so that it
is impossible to modify. At ten minutes of no activity, they power down
the disks.

--
Cheers, Carlos.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

XPost: alt.os.linux

On 2025-05-08 12:57, Carlos E.R. wrote:

On 2025-05-07 15:50, Theo wrote:

Are you sure this delay isn't just the drive set to spin down when not
used?
Perhaps they boot in the spun-down state.  When you try to access a drive >> that's spun down, the system will often hang waiting for it to spin up.
Since the kernel wants to read the partition table stored on the disc I'm
not surprised if it hangs if the drive isn't spinning, and maybe times
out.

The simplest way to adjust it with a Windows tool like SeaTools - there's
now a version for Linux and a bootable USB version too.

Some boxes set that OFF timeout themselves, not in the disks, so that it
is impossible to modify. At ten minutes of no activity, they power down
the disks.

It's not the problem here anyway. The disks are set to sleep, but, so
far at least, that simply means a short delay until the box responds
over the network and the directory is listed or whatever. That is
different behaviour from what is happening, or rather not happening, on
first boot.

--

Fake news kills!

I may be contacted via the contact address given on my website:
www.macfh.co.uk

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)