Re: Inhibiting device startup at boot

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2020-12-01 at 13:21 -0700, Chris Murphy wrote:
> On Tue, Dec 1, 2020 at 9:42 AM Patrick O'Callaghan
> <pocallaghan@xxxxxxxxx> wrote:
> > 
> > On Tue, 2020-12-01 at 09:01 -0700, Chris Murphy wrote:
> > > On Tue, Dec 1, 2020 at 6:59 AM Tom Horsley <horsley1953@xxxxxxxxx> wrote:
> > > > 
> > > > On Tue, 1 Dec 2020 14:52:21 +0100
> > > > Roberto Ragusa wrote:
> > > > 
> > > > > How do you power them down?
> > > > 
> > > > I don't know about the original poster, but my "noauto" disks
> > > > timeout and power down all by themselves, then even when they aren't
> > > > mounted at all, every time I reboot, the reboot hangs while it
> > > > spins up the disks for some reason. I constantly wish I could make
> > > > it stop doing that.
> > > 
> > > Enumeration. I'm not sure if it's udev scanning everything, or the
> > > kernel or both. And also maybe libblkid, to know what everything is.
> > > The only way it can know what it is, it needs to be spun up to read
> > > the partition map and all the signatures on each partition.
> > 
> > Obviously it needs to spin up if it needs to know these things. My
> > point is that it doesn't need to know them until I tell it.
> 
> Yeah that's not how it works.
> 
> $ dmesg | grep sda
> [    2.149354] sd 0:0:0:0: [sda] 3907029168 512-byte logical blocks:
> (2.00 TB/1.82 TiB)
> [    2.149397] sd 0:0:0:0: [sda] 4096-byte physical blocks
> [    2.149514] sd 0:0:0:0: [sda] Write Protect is off
> [    2.149545] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
> [    2.149722] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
> enabled, doesn't support DPO or FUA
> [    2.235611]  sda: sda1
> [    2.236610] sd 0:0:0:0: [sda] Attached SCSI disk
> $
> 
> The second to last line, where it discovers the sda1 partition, is
> needed in order to create all the symlinks for all the various parts
> of that drive. Not just the dev node, but also the /dev/disk/by-
> things.
> 
> If you don't want that to happen, you'd need a udev rule to inhibit
> that. And then when it goes looking for a particular fs UUID in fstab
> to mount, of course it doesn't exist, so the mount will fail. It
> doesn't know it needs to scan everything NOW. There's no correlation
> between fs UUID in fstab to a particular device until it's scanned,
> which happens by udev during early startup.

That wouldn't worry me so much in this case as it's only used by my
backup script which starts and stops the dock directly and can do
whatever is needed. If it was an automount drive of course it would be
different.

poc
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux