FYI, I had a similar problem booting from a USB drive on an old Debian
machine a long time ago. May have been Wheezy, or ever Sarge.
The problem in my case was that the kernel was taking a while to settle
the USB module, so at the early boot stage, it "knew" it was supposed to
mount the USB
On Mon, 15 Jun 2020 13:15:57 +0100
g4sra via Dng wrote:
> > No need IMHO, it was the core issue...
>
> So you have solved the issue, great!
Nope, we found a Quick and Dirty workaround
--
richard lucassen
http://contact.xaq.nl/
___
Dng mailing list
On 15/06/2020 12:59, richard lucassen via Dng wrote:
> On Mon, 15 Jun 2020 12:48:16 +0100
> g4sra via Dng wrote:
>
How do you know the mount is failing ?
>>>
>>> It's not mounted after mount command.
>>
>> I have not seen any evidence of that, can you point me to it please.
>
> No need
On Mon, 15 Jun 2020 12:48:16 +0100
g4sra via Dng wrote:
> >> How do you know the mount is failing ?
> >
> > It's not mounted after mount command.
>
> I have not seen any evidence of that, can you point me to it please.
No need IMHO, it was the core issue...
--
richard lucassen
On 15/06/2020 05:33, J. Fahrner via Dng wrote:
> Am 2020-06-14 22:54, schrieb g4sra via Dng:
>> How do you know the mount is failing ?
>
> It's not mounted after mount command.
I have not seen any evidence of that, can you point me to it please.
>
On Mon, 15 Jun 2020 06:31:40 +0200
"J. Fahrner" wrote:
It looks to me like your drive is in good health and supports (and
uses) all the good health features.
As the other poster suggested, using another drive to troubleshoot may
still be useful, but your drive appears fundamentally good.
--
Am 2020-06-14 22:54, schrieb g4sra via Dng:
How do you know the mount is failing ?
It's not mounted after mount command.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Am 2020-06-15 05:11, schrieb spiralofhope:
I wonder if there's anything S.M.A.R.T. information can tell you.
There is a spinup time test, and I wonder if perhaps there is SMART
logging within the drive that could reveal a problem with the drive not
spinning up as quickly as it should, and maybe
On Fri, 12 Jun 2020 17:01:14 +0200
"J. Fahrner via Dng" wrote:
> When this disk is active in /etc/fstab the boot process hangs
> forever.
I wonder if there's anything S.M.A.R.T. information can tell you.
There is a spinup time test, and I wonder if perhaps there is SMART
logging within the
J. Fahrner via Dng wrote:
> I don't see why this parameter is so important. When I read the description,
> this is the delay for scanning usb devices after power up. But as you can see
> in the logs, the device is responding and telling its characteristics. Only
> mounting the filesystem
On Sun, 14 Jun 2020 21:49:50 +0200
"J. Fahrner via Dng" wrote:
> > And an earlier suggestion to copy important things to a smaller disk
> > and use that disk, does that probably solve the issue?
>
> A smaller disk is no option, since this is my media server at home.
> It is filled with 66%.
I
-- snip --
> Only mounting the filesystem fails.
How do you know the mount is failing ?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Am 2020-06-14 21:25, schrieb richard lucassen via Dng:
Ok, I missed that, sorry. Maybe 5 is too low, try 10 or 15 I'd say.
I don't see why this parameter is so important. When I read the
description, this is the delay for scanning usb devices after power up.
But as you can see in the logs,
Am 2020-06-14 20:48, schrieb richard lucassen:
What happens if you change the content of that script:
#!/bin/dash
echo 5 > /sys/module/usb_storage/parameters/delay_use
For what reason? I had it in /boot/boot.ini and that worked. I looked up
/sys/module/usb_storage/parameters/delay_use and it
On Sun, 14 Jun 2020 20:31:22 +0200
"J. Fahrner via Dng" wrote:
> Am 2020-06-14 20:07, schrieb d...@d404.nl:
> > It is a kernel parameter not a module parameter. You have to add it
> > to your kernel boot line.
>
> Ok, I found out how to do that. It's in /boot/boot.ini
> But that made no
Am 2020-06-14 20:07, schrieb d...@d404.nl:
It is a kernel parameter not a module parameter. You have to add it to
your kernel boot line.
Ok, I found out how to do that. It's in /boot/boot.ini
But that made no difference to my problem.
This is my current setup:
/etc/fstab has the mount option
Am 2020-06-14 19:51, schrieb Tomasz Torcz:
Try files in /sys/module/usb_storage/parameters
Or you can put in kernel command line: usb_storage.parameter=…
as described at
https://www.kernel.org/doc/html/latest/admin-guide/kernel-parameters.html
Something is wrong her:
root@Odroid2:~#
On 14-06-2020 19:46, J. Fahrner via Dng wrote:
> Am 2020-06-14 19:39, schrieb d...@d404.nl:
>> Most likely the usb_storage module is compiled in the kernel.
>
> How can I set its parameters in this case?
> sysctl -a lists nothing about storage or usb.
From what i am able to find the kernel
On Sun, Jun 14, 2020 at 07:46:57PM +0200, J. Fahrner via Dng wrote:
> Am 2020-06-14 19:39, schrieb d...@d404.nl:
> > Most likely the usb_storage module is compiled in the kernel.
>
> How can I set its parameters in this case?
Try files in /sys/module/usb_storage/parameters
Or you can put in
Am 2020-06-14 19:39, schrieb d...@d404.nl:
Most likely the usb_storage module is compiled in the kernel.
How can I set its parameters in this case?
sysctl -a lists nothing about storage or usb.
___
Dng mailing list
Dng@lists.dyne.org
On 14-06-2020 19:36, J. Fahrner via Dng wrote:
> Am 2020-06-14 19:30, schrieb richard lucassen:
>> What tells "modinfo g_mass_storage"?
>
> $ sudo modinfo g_mass_storage
> filename:
> /lib/modules/3.16.82+/kernel/drivers/usb/gadget/g_mass_storage.ko
> license: GPL
> author:
Am 2020-06-14 19:30, schrieb richard lucassen:
What tells "modinfo g_mass_storage"?
$ sudo modinfo g_mass_storage
filename:
/lib/modules/3.16.82+/kernel/drivers/usb/gadget/g_mass_storage.ko
license:GPL
author: Michal Nazarewicz
description:Mass Storage Gadget
On Sun, 14 Jun 2020 19:11:38 +0200
"J. Fahrner via Dng" wrote:
> Am 2020-06-14 19:07, schrieb J. Fahrner via Dng:
> > modinfo: ERROR: Module usb_storage not found.
>
> Maybe they have their own drivers for usb?
>
> # find /lib/modules/3.16.82+/kernel/drivers -name '*storage*'
>
Am 2020-06-14 19:07, schrieb J. Fahrner via Dng:
modinfo: ERROR: Module usb_storage not found.
Maybe they have their own drivers for usb?
# find /lib/modules/3.16.82+/kernel/drivers -name '*storage*'
/lib/modules/3.16.82+/kernel/drivers/usb/gadget/g_mass_storage.ko
Am 2020-06-14 19:05, schrieb richard lucassen:
That's rather strange. From "modinfo usb_storage":
parm: delay_use:seconds to delay before using a new device (uint)
And what happens if you load the module in advance?:
echo "usb_storage" >> /etc/modules
modinfo: ERROR: Module usb_storage not
On Sun, 14 Jun 2020 18:38:48 +0200
"J. Fahrner via Dng" wrote:
> Am 2020-06-14 17:25, schrieb richard lucassen via Dng:
> > echo "options usb_storage delay_use=5" >
> > /etc/modprobe.d/usb_storage.conf
>
> seems not to work.
>
> After boot:
>
> cat
Am 2020-06-14 17:25, schrieb richard lucassen via Dng:
echo "options usb_storage delay_use=5" >
/etc/modprobe.d/usb_storage.conf
seems not to work.
After boot:
cat /sys/module/usb_storage/parameters/delay_use
1
___
Dng mailing list
On Sun, 14 Jun 2020 17:24:01 +0200
richard lucassen via Dng wrote:
Oops:
echo "options usb_storage delay_use=5" /etc/modprobe.d/usb_storage.conf
must be:
echo "options usb_storage delay_use=5" > /etc/modprobe.d/usb_storage.conf
--
richard lucassen
https://contact.xaq.nl/
On Sun, 14 Jun 2020 14:12:21 +0200
"J. Fahrner via Dng" wrote:
> Very big device. Trying to use READ CAPACITY
You may try this:
echo "options usb_storage delay_use=5" /etc/modprobe.d/usb_storage.conf
https://bbs.archlinux.org/viewtopic.php?id=125831
R.
--
richard lucassen
On 6/14/20 4:44 PM, J. Fahrner via Dng wrote:
> Am 2020-06-14 15:09, schrieb Dr. Nikolaus Klepp:
>> Anno domini 2020 Sun, 14 Jun 14:12:21 +0200
>> J. Fahrner via Dng scripsit:
>>> [ 22.579214] sd 0:0:0:0: [sda] Attached SCSI disk
>>> [ 1145.246051] EXT4-fs (sda1): mounted filesystem with
Am 2020-06-14 15:09, schrieb Dr. Nikolaus Klepp:
Anno domini 2020 Sun, 14 Jun 14:12:21 +0200
J. Fahrner via Dng scripsit:
[ 22.579214] sd 0:0:0:0: [sda] Attached SCSI disk
[ 1145.246051] EXT4-fs (sda1): mounted filesystem with ordered data
I see this on RPi, too, just the delay is smaller
Anno domini 2020 Sun, 14 Jun 14:12:21 +0200
J. Fahrner via Dng scripsit:
> [ 22.579214] sd 0:0:0:0: [sda] Attached SCSI disk
> [ 1145.246051] EXT4-fs (sda1): mounted filesystem with ordered data
I see this on RPi, too, just the delay is smaller (~ 30 secs) - but that's
anoying, too.
Nik
--
Am 2020-06-14 13:32, schrieb richard lucassen via Dng:
It's weird. What does "dmesg" tell?
dmesg > /tmp/dmesg
and look if there are any messages there
[0.00] Initializing cgroup subsys cpuset
[0.00] Initializing cgroup subsys cpu
[0.00] Initializing cgroup subsys
Am 2020-06-14 13:23, schrieb Dr. Nikolaus Klepp:
Are you 100% absolutely sure your board is not stuck at the bootloader
stage before the kernel is started?
Yes. It responds to ping, so network is running.
___
Dng mailing list
Dng@lists.dyne.org
On Sun, 14 Jun 2020 13:03:13 +0200
"J. Fahrner" wrote:
> But if I do it interactively with "sudo mount /hdd" the drive gets
> mounted and the waiting daemons are started.
>
> I'm very confused...
When you mount it interactively the path is different and maybe it's
waiting for some input.
Try
On Sun, 14 Jun 2020 13:03:13 +0200
"J. Fahrner" wrote:
> But if I do it interactively with "sudo mount /hdd" the drive gets
> mounted and the waiting daemons are started.
>
> I'm very confused...
It's weird. What does "dmesg" tell?
dmesg > /tmp/dmesg
and look if there are any messages there
Anno domini 2020 Sun, 14 Jun 13:03:13 +0200
J. Fahrner via Dng scripsit:
> Am 2020-06-14 10:11, schrieb richard lucassen:
> > Did you format the disk with a newer system than the system you run it
> > on? So, I wonder what happens if you remove the huge_file option
>
> I don't remember on which
Am 2020-06-14 10:11, schrieb richard lucassen:
Did you format the disk with a newer system than the system you run it
on? So, I wonder what happens if you remove the huge_file option
I don't remember on which system I formatted that drive.
After playing around the problem is very strange. It's
On Sun, 14 Jun 2020 08:21:51 +0200
"J. Fahrner via Dng" wrote:
> Am 2020-06-13 22:10, schrieb richard lucassen via Dng:
> > I have no idea. But mountall is in runlevel S, not 2. What if you
> > mount it explicitely in a temporary script
> > called /etc/rcS.d/99mount.sh ? That
> > is before
Am 2020-06-13 22:10, schrieb richard lucassen via Dng:
I have no idea. But mountall is in runlevel S, not 2. What if you mount
it explicitely in a temporary script called /etc/rcS.d/99mount.sh ?
That
is before runlevel 2 starts.
Looks like it has something to do with huge_file support:
On Sat, 13 Jun 2020 21:09:06 +0200
"J. Fahrner" wrote:
> > No, but I asked you why not create the root filesystem on that disk.
>
> If "mount -a" does not work in runlevel 2, why should it work in boot
> stage 1?
I have no idea. But mountall is in runlevel S, not 2. What if you mount
it
Am 2020-06-13 21:05, schrieb richard lucassen:
No, but I asked you why not create the root filesystem on that disk.
If "mount -a" does not work in runlevel 2, why should it work in boot
stage 1?
___
Dng mailing list
Dng@lists.dyne.org
On Sat, 13 Jun 2020 21:07:37 +0200
richard lucassen via Dng wrote:
> No, maybe it has got something to do with these "big disk" messages.
> Wouldn't it be an idea to copy a part of that dist to a "not such a
> big disk" and see what happens?
s/dist/disk/
--
richard lucassen
On Sat, 13 Jun 2020 20:28:03 +0200
"J. Fahrner via Dng" wrote:
> Am 2020-06-13 20:18, schrieb richard lucassen via Dng:
> > That was the "rootwait" parameter as I said somewhere. Used for USB
> > and MMC disks.
>
> "The rootwait kernel parameter only affects the first stage of boot,
> while
On Sat, 13 Jun 2020 20:28:03 +0200
"J. Fahrner via Dng" wrote:
> "The rootwait kernel parameter only affects the first stage of boot,
> while the kernel is waiting for its initial root device"
>
>
Am 2020-06-13 20:18, schrieb richard lucassen via Dng:
That was the "rootwait" parameter as I said somewhere. Used for USB and
MMC disks.
"The rootwait kernel parameter only affects the first stage of boot,
while the kernel is waiting for its initial root device"
On Sat, 13 Jun 2020 16:50:29 +0200
Didier Kryn wrote:
> I had a problem around 15 years ago booting a Powerpc SBC with
> rootfs on a USB disk and without initramfs. around 15 years ago. Even
> though the disk was powered on its own, it didn't start spinning
> before the driver started it. I
Le 13/06/2020 à 10:53, J. Fahrner via Dng a écrit :
> Am 2020-06-13 10:31, schrieb richard lucassen:
>> The nofail means that it wil mount automatically, but if the disk
>> is absent it won't give errors. But it does not wait for the device!
>
> The disk has itś own power supply and is always
On June 13, 2020 3:00:37 PM GMT+02:00, "J. Fahrner via Dng"
wrote:
> AFTER boot a "mount -a" waits until the disk is ready and mounts it
> without any failure. I don't see why this should not be the same during
> boot. I suspect it has more to do with disc size, see the warnings in
> dmesg.
Am 2020-06-13 14:19, schrieb Tito via Dng:
maybe rather than trying to mount the disk earlier, you could try
to spin it up so that it mounts when mountall is run.
AFTER boot a "mount -a" waits until the disk is ready and mounts it
without any failure. I don't see why this should not be the
On 6/13/20 9:49 AM, richard lucassen via Dng wrote:
> On Sat, 13 Jun 2020 08:52:18 +0200
> "J. Fahrner via Dng" wrote:
>
>> Am 2020-06-13 08:25, schrieb J. Fahrner via Dng:
>>> nofail was a good hint. Now the system boots, but the usb disk is
>>> still not mounted. "mount -a" mounts it without
On Friday 12 June 2020 at 17:01:14, J. Fahrner via Dng wrote:
> I'm running Devuan Beowulf on an Odroid C2 mini computer.
> I cannot attach a monitor because I have no suitable cable.
> Any ideas how to debug this problem?
I think my initial approach would be to just buy an HDMI cable -
On 13-06-2020 10:53, J. Fahrner via Dng wrote:
> Am 2020-06-13 10:31, schrieb richard lucassen:
>> The nofail means that it wil mount automatically, but if the disk
>> is absent it won't give errors. But it does not wait for the device!
>
> The disk has itś own power supply and is always
Anno domini 2020 Sat, 13 Jun 10:53:51 +0200
J. Fahrner via Dng scripsit:
> Am 2020-06-13 10:31, schrieb richard lucassen:
> > The nofail means that it wil mount automatically, but if the disk
> > is absent it won't give errors. But it does not wait for the device!
>
> The disk has itś own power
Am 2020-06-13 10:31, schrieb richard lucassen:
The nofail means that it wil mount automatically, but if the disk
is absent it won't give errors. But it does not wait for the device!
The disk has itś own power supply and is always connected. I think there
is something missing at the boot stage
On Sat, 13 Jun 2020 10:20:46 +0200
"J. Fahrner via Dng" wrote:
> Thats exactly what I'm expecting, waiting indefinitely. The same as
> mounting in fstab without nofail option.
The nofail means that it wil mount automatically, but if the disk
is absent it won't give errors. But it does not wait
Am 2020-06-13 10:05, schrieb richard lucassen via Dng:
That is why there is a rootwait option:
rootwait[KNL] Wait (indefinitely) for root device to show up.
Useful for devices that are detected asynchronously (e.g. USB and MMC
devices).
Thats exactly what I'm expecting, waiting
On Sat, 13 Jun 2020 09:55:54 +0200
"J. Fahrner" wrote:
> Am 2020-06-13 09:49, schrieb richard lucassen:
> > What is on that disk? Why not make that disk the root filesystem and
> > pass "rootwait" to the kernel?
>
> I'm afraid that won't work either. If there are problems mounting the
> disk
Am 2020-06-13 09:49, schrieb richard lucassen:
What is on that disk? Why not make that disk the root filesystem and
pass "rootwait" to the kernel?
I'm afraid that won't work either. If there are problems mounting the
disk at this early stage, even the root filesystem will not mount.
On Sat, 13 Jun 2020 08:52:18 +0200
"J. Fahrner via Dng" wrote:
> Am 2020-06-13 08:25, schrieb J. Fahrner via Dng:
> > nofail was a good hint. Now the system boots, but the usb disk is
> > still not mounted. "mount -a" mounts it without errors after boot.
>
> What is the best way to run "mount
Le 13/06/2020 à 09:31, J. Fahrner via Dng a écrit :
> Am 2020-06-13 09:24, schrieb Didier Kryn:
>> AFAIU defaults is a placeholder for when there's no option to pass.
>> Therefore, if you specify nofail or noauto, defaults isn't needed.
>
> According to the man page of mount:
>
> defaults
>
Am 2020-06-13 09:24, schrieb Didier Kryn:
AFAIU defaults is a placeholder for when there's no option to pass.
Therefore, if you specify nofail or noauto, defaults isn't needed.
According to the man page of mount:
defaults
Use the default options: rw, suid, dev, exec, auto,
Le 12/06/2020 à 20:25, richard lucassen via Dng a écrit :
> On Fri, 12 Jun 2020 17:01:14 +0200
> "J. Fahrner via Dng" wrote:
>
>> Any ideas how to debug this problem?
>>
>> This is the fstab entry:
>>
>> LABEL=Elements /hdd ext4 defaults 0 2
> Try to add "nofail" or "noauto":
>
> LABEL=Elements
Am 2020-06-13 08:25, schrieb J. Fahrner via Dng:
nofail was a good hint. Now the system boots, but the usb disk is
still not mounted. "mount -a" mounts it without errors after boot.
What is the best way to run "mount -a" before any initscripts in
runlevel 2?
There is a script
Am 2020-06-12 20:25, schrieb richard lucassen:
Try to add "nofail" or "noauto":
nofail was a good hint. Now the system boots, but the usb disk is still
not mounted. "mount -a" mounts it without errors after boot.
I see no errors in /var/log/boot and dmesg.
The only messages concerning this
On Fri, 12 Jun 2020 17:01:14 +0200
"J. Fahrner via Dng" wrote:
> Any ideas how to debug this problem?
>
> This is the fstab entry:
>
> LABEL=Elements /hdd ext4 defaults 0 2
Try to add "nofail" or "noauto":
LABEL=Elements /hdd ext4 defaults,nofail 0 2
LABEL=Elements /hdd ext4
J. Fahrner via Dng wrote:
> Hi,
> I'm running Devuan Beowulf on an Odroid C2 mini computer. Since it's
> internal flash disk is limited, I run it with an external usb drive
> attached.
> When this disk is active in /etc/fstab the boot process hangs forever. I
> can ping it, so networking is
On 12/06/2020 16:01, J. Fahrner via Dng wrote:
> Hi,
> I'm running Devuan Beowulf on an Odroid C2 mini computer. Since it's internal
> flash disk is limited, I run it with an external usb drive attached.
> When this disk is active in /etc/fstab the boot process hangs forever. I can
> ping it, so
On 12/06/2020 16:01, J. Fahrner via Dng wrote:
> Hi,
Hi, I know *nothing* about Odroid
> I'm running Devuan Beowulf on an Odroid C2 mini computer. Since it's internal
> flash disk is limited, I run it with an external usb drive attached.
> When this disk is active in /etc/fstab the boot process
On 12-06-2020 17:01, J. Fahrner via Dng wrote:
> Hi,
> I'm running Devuan Beowulf on an Odroid C2 mini computer. Since it's
> internal flash disk is limited, I run it with an external usb drive
> attached.
> When this disk is active in /etc/fstab the boot process hangs forever.
> I can ping it, so
On 2020-06-12 17:01, J. Fahrner via Dng wrote:
> I'm running Devuan Beowulf on an Odroid C2 mini computer. Since it's
> internal flash disk is limited, I run it with an external usb drive
> attached. When this disk is active in /etc/fstab the boot process
> hangs forever.
Distribution kernel or
Hi,
I'm running Devuan Beowulf on an Odroid C2 mini computer. Since it's
internal flash disk is limited, I run it with an external usb drive
attached.
When this disk is active in /etc/fstab the boot process hangs forever. I
can ping it, so networking is started, but I cannot login, because
72 matches
Mail list logo
