Re: [gentoo-dev] newsitem: important fstab update

2016-11-05 Thread Rich Freeman
On Fri, Nov 4, 2016 at 11:48 PM, Christopher Head  wrote:
> On Thu, 27 Oct 2016 10:25:39 -0400
> Rich Freeman  wrote:
>
>> It would be nice if standards like USB incorporated some kind of GUID.
>> I ended up having to write a udev rule for a pl2303 RS232 adapter to
>> tie it to a specific USB port precisely so that I could have more than
>> one and know which one talked to which device.
>>
>> I'd argue that the udev network interface names were a better (if
>> painful to transition to) solution to a problem created by somebody
>> else.  Being able to use wildcards in configuration files is probably
>> an adequate solution for those who are using a single device.
>>
>
> You mean like a device serial number? Which is totally part of the USB
> standard, but many devices don’t bother to include one because they
> would have to be serially programmed in the factory? If your device has
> a serial number, you can generally see it as a udev attribute and use
> it to set up meaningful persistent names for multiple
> otherwise-identical devices.

++
Though stuff like this is why sometimes it makes sense to make things
a required part of the standard.  If the device had access to some
source of randomness perhaps it could at least flash one on first
powerup.  Of course the only thing that would be worse than not having
a unique ID would be having a unique ID that isn't unique...

-- 
Rich



Re: [gentoo-dev] newsitem: important fstab update

2016-11-04 Thread Christopher Head
On Thu, 27 Oct 2016 10:25:39 -0400
Rich Freeman  wrote:

> It would be nice if standards like USB incorporated some kind of GUID.
> I ended up having to write a udev rule for a pl2303 RS232 adapter to
> tie it to a specific USB port precisely so that I could have more than
> one and know which one talked to which device.
> 
> I'd argue that the udev network interface names were a better (if
> painful to transition to) solution to a problem created by somebody
> else.  Being able to use wildcards in configuration files is probably
> an adequate solution for those who are using a single device.
> 

You mean like a device serial number? Which is totally part of the USB
standard, but many devices don’t bother to include one because they
would have to be serially programmed in the factory? If your device has
a serial number, you can generally see it as a udev attribute and use
it to set up meaningful persistent names for multiple
otherwise-identical devices.
-- 
Christopher Head


pgphi7PNcCbPu.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-29 Thread Peter Stuge
Peter Stuge wrote:
> --8<-- mount(8)
..
>   portable. The mount(8) command internally uses udev symlinks
> -->8--

That's of course only the mount in util-linux.


//Peter



Re: [gentoo-dev] newsitem: important fstab update

2016-10-29 Thread Peter Stuge
Ian Stakenvicius wrote:
> > WilliamH wants everyone using /dev/disk/by-label/
> > paths in fstab to instead use LABEL= , to avoid issues if udev
> > doesn't create the symlinks before localmount tries to use them.
..
> UUID is the same situation in this case -- in fstab you can do it by
> UUID= or you can do it by /dev/disk/by-uuid/.  The latter
> form depends on udev finishing up and would have the same issue.

It seems that the former form may also depend on udev having settled.

--8<-- mount(8)
   The device indication.
..
  The recommended setup is to use tags (e.g. LABEL=) rather
  than  /dev/disk/by-{label,uuid,partuuid,partlabel} udev symlinks
  in the /etc/fstab file. The tags are more readable,  robust  and
  portable. The mount(8) command internally uses udev symlinks, so
  use the symlinks in /etc/fstab has no advantage over  the  tags.
  For more details see libblkid(3).
-->8--

Oops. Let's look further:

--8<-- libblkid(3)
   The  high-level  part  of  the library supports two methods to evaluate
   LABEL/UUID.  It reads information directly from a block device or  read
   information  from  /dev/disk/by-*  udev symlinks. The udev is preferred
   method by default.
-->8--

..so when is the non-default method (querying devices) used?


//Peter



Re: [gentoo-dev] newsitem: important fstab update

2016-10-29 Thread Daniel Campbell
On 10/28/2016 06:00 AM, Mike Gilbert wrote:
> On Fri, Oct 28, 2016 at 12:56 AM, Daniel Campbell  wrote:
>> On 10/25/2016 10:01 AM, William Hubbs wrote:
>>> All,
>>>
>>> this item is about an important fstab update. In short, people need to
>>> move away from /dev/disk-by/* in their fstab vfiles.
>>>
>>> I do have a question about the newsitem -- how do I make it display only
>>> for Linux users?
>>>
>>> Thanks,
>>>
>>> William
>>>
>> Replying to top level since it doesn't seem to fit elsewhere.
>>
>> I have an external HDD that I use for periodic, air-gapped backups. I
>> use /dev/disk/by-label for it. With that support being removed (or
>> rather, problematic for some system configurations), which method is
>> most future-proof? I saw mention of UUIDs; is that what we should switch to?
>>
>> In my case, it's a removable drive so it may be assigned to something
>> besides sdc at times.
> 
> If it is a removable drive, you probably do *not* have it set to mount
> on bootup, correct?
> 
> If so, none of this applies to you since the udev-provided symlinks
> will be available to you.
> 
I didn't think about that, actually. Yeah, I don't expect it on boot up
since I don't have a regular backup schedule. I just plug it in, run a
script, sync and unmount.

Still, I learned about LABEL= and UUID= with vanilla fstab. Good stuff
to know.

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-28 Thread Francesco Riosa
2016-10-28 16:42 GMT+02:00 Ian Stakenvicius :

> On 27/10/16 09:54 PM, Francesco Riosa wrote:
> > 2016-10-28 3:32 GMT+02:00 Ian Stakenvicius  > >:
> >
> > On 27/10/16 09:23 PM, Gregory Woodbury wrote:
> > > Out of curiosity, why do folks say that the use of LABEL= is
> not
> > > good?  I realize that s are not required when doing a mkfs,
> but
> > > if the admin does so reliably and wants to use LABEL= thereafter,
> why should
> > > it be "deprecated"?
> >
> > I don't think anyone said that the LABEL= syntax is bad; quite the
> > opposite -- WilliamH wants everyone using /dev/disk/by-label/
> > paths in fstab to instead use LABEL= , to avoid issues if udev
> > doesn't create the symlinks before localmount tries to use them.
> >
> >
> > Indeed nobody ever said "deprecated" some people (/me too) don't like
> > to use labels and prefer UUIDs instead.
> > - in some situations -
> > To complete the statement labels are very good with fleets of servers
> > with predefined and consistent disk layouts, or for some people desktop.
> > When it come to a small number of server with different layouts they
> > are equivalent in functionality but need managing and memory, when you
> > substitute disk for example, simply not worth it.
> >
> > Best,
> > Francesco
>
>
> UUID is the same situation in this case -- in fstab you can do it by
> UUID= or you can do it by /dev/disk/by-uuid/.  The latter
> form depends on udev finishing up and would have the same issue.
>
> The identifier itself that you use for the partition doesn't need to
> change at all, its just the means with which you use this identifier
> that WilliamH is recommending you change.
>
>
> I did already understood the difference, but thanks for clarifying


Re: [gentoo-dev] newsitem: important fstab update

2016-10-28 Thread Ian Stakenvicius
On 28/10/16 12:56 AM, Daniel Campbell wrote:
> On 10/25/2016 10:01 AM, William Hubbs wrote:
>> All,
>>
>> this item is about an important fstab update. In short, people need to
>> move away from /dev/disk-by/* in their fstab vfiles.
>>
>> I do have a question about the newsitem -- how do I make it display only
>> for Linux users?
>>
>> Thanks,
>>
>> William
>>
> Replying to top level since it doesn't seem to fit elsewhere.
> 
> I have an external HDD that I use for periodic, air-gapped backups. I
> use /dev/disk/by-label for it. With that support being removed (or
> rather, problematic for some system configurations), which method is
> most future-proof? I saw mention of UUIDs; is that what we should switch to?
> 
> In my case, it's a removable drive so it may be assigned to something
> besides sdc at times.
> 

What is being recommended here is that instead of
/dev/disk/by-label/ in fstab, you would use LABEL=

man fstab for more info on LABEL= , UUID= , etc.




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-28 Thread Ian Stakenvicius
On 27/10/16 09:54 PM, Francesco Riosa wrote:
> 2016-10-28 3:32 GMT+02:00 Ian Stakenvicius  >:
> 
> On 27/10/16 09:23 PM, Gregory Woodbury wrote:
> > Out of curiosity, why do folks say that the use of LABEL= is not
> > good?  I realize that s are not required when doing a mkfs, but
> > if the admin does so reliably and wants to use LABEL= thereafter, why 
> should
> > it be "deprecated"?
> 
> I don't think anyone said that the LABEL= syntax is bad; quite the
> opposite -- WilliamH wants everyone using /dev/disk/by-label/
> paths in fstab to instead use LABEL= , to avoid issues if udev
> doesn't create the symlinks before localmount tries to use them.
> 
> 
> Indeed nobody ever said "deprecated" some people (/me too) don't like
> to use labels and prefer UUIDs instead.
> - in some situations -
> To complete the statement labels are very good with fleets of servers
> with predefined and consistent disk layouts, or for some people desktop.
> When it come to a small number of server with different layouts they
> are equivalent in functionality but need managing and memory, when you
> substitute disk for example, simply not worth it.
> 
> Best,
> Francesco


UUID is the same situation in this case -- in fstab you can do it by
UUID= or you can do it by /dev/disk/by-uuid/.  The latter
form depends on udev finishing up and would have the same issue.

The identifier itself that you use for the partition doesn't need to
change at all, its just the means with which you use this identifier
that WilliamH is recommending you change.




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-28 Thread Mike Gilbert
On Fri, Oct 28, 2016 at 12:56 AM, Daniel Campbell  wrote:
> On 10/25/2016 10:01 AM, William Hubbs wrote:
>> All,
>>
>> this item is about an important fstab update. In short, people need to
>> move away from /dev/disk-by/* in their fstab vfiles.
>>
>> I do have a question about the newsitem -- how do I make it display only
>> for Linux users?
>>
>> Thanks,
>>
>> William
>>
> Replying to top level since it doesn't seem to fit elsewhere.
>
> I have an external HDD that I use for periodic, air-gapped backups. I
> use /dev/disk/by-label for it. With that support being removed (or
> rather, problematic for some system configurations), which method is
> most future-proof? I saw mention of UUIDs; is that what we should switch to?
>
> In my case, it's a removable drive so it may be assigned to something
> besides sdc at times.

If it is a removable drive, you probably do *not* have it set to mount
on bootup, correct?

If so, none of this applies to you since the udev-provided symlinks
will be available to you.



Re: [gentoo-dev] newsitem: important fstab update

2016-10-28 Thread Michał Górny
On Thu, 27 Oct 2016 21:56:45 -0700
Daniel Campbell  wrote:

> On 10/25/2016 10:01 AM, William Hubbs wrote:
> > All,
> > 
> > this item is about an important fstab update. In short, people need to
> > move away from /dev/disk-by/* in their fstab vfiles.
> > 
> > I do have a question about the newsitem -- how do I make it display only
> > for Linux users?
> > 
> > Thanks,
> > 
> > William
> >   
> Replying to top level since it doesn't seem to fit elsewhere.
> 
> I have an external HDD that I use for periodic, air-gapped backups. I
> use /dev/disk/by-label for it. With that support being removed (or
> rather, problematic for some system configurations), which method is
> most future-proof? I saw mention of UUIDs; is that what we should switch to?

LABEL=foo. The canonical ever-existing syntax which a lot of people seem
to be ignorant about.

-- 
Best regards,
Michał Górny



pgpTH8HhaLPXa.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-27 Thread Daniel Campbell
On 10/26/2016 01:49 AM, Joshua Kinard wrote:
> On 10/25/2016 13:15, William Hubbs wrote:
>> On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote:
>>> On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs  wrote:
 If you are not using /dev/disk/by-* paths in fstab, you do not need to
>>> take any action for this news item.

 If you are, it is very critical that you update fstab AS SOON AS
>>> POSSIBLE. Your system will become unbootable in the future if you do
>>> not  do so.
>>>
>>> Err, what is changing that will make systems unbootable?
>>>
>>> I am fairly certain systems running systemd will continue to work
>>> properly with either syntax.
>>  
>>  They probably will.
>>
>>> If this is about the udev-settle issue for OpenRC, I would urge you to
>>> reconsider that.
>>  
>>  There isn't anything to reconsider afaik. The problem is that
>>  /dev/disk/by-* are only created by udev/eudev, but the other syntax
>>  works regardless of which device manager  you use, so this is the safer
>>  route.
>>
>>  William
>>
> 
> I take it us museum relics still using jurassic-era device names like
> /dev/sd* or /dev/md* aren't affected by this?  Cthulhu-forbid Linux device
> naming gets any more complicated than using UUID's.  What's next, saving the
> serial numbers of discovered disks in an overly-complicated key/value-based
> non-SQL database format?
> 
Stop, you'll give them ideas! :P

-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-27 Thread Daniel Campbell
On 10/25/2016 10:01 AM, William Hubbs wrote:
> All,
> 
> this item is about an important fstab update. In short, people need to
> move away from /dev/disk-by/* in their fstab vfiles.
> 
> I do have a question about the newsitem -- how do I make it display only
> for Linux users?
> 
> Thanks,
> 
> William
> 
Replying to top level since it doesn't seem to fit elsewhere.

I have an external HDD that I use for periodic, air-gapped backups. I
use /dev/disk/by-label for it. With that support being removed (or
rather, problematic for some system configurations), which method is
most future-proof? I saw mention of UUIDs; is that what we should switch to?

In my case, it's a removable drive so it may be assigned to something
besides sdc at times.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-27 Thread Peter Stuge
Rich Freeman wrote:
> We give you the tools when you install your system, and we give you
> the tools when it is time for renovations...

On that note - thank you very much to everyone who contributes to Gentoo!

<3


//Peter



Re: [gentoo-dev] newsitem: important fstab update

2016-10-27 Thread Rich Freeman
On Thu, Oct 27, 2016 at 9:23 PM, Gregory Woodbury  wrote:
>
> This is not unlike the kerfufle that occurred when systemD was introduced
> not so long ago. To use it folks had to make major changes to their systems
> that took several months to iron out the kinks.  Additionally, some of the
> folks
> pusing the change seemed to have a bad attitude about not caring that what
> they did had unintended consequences. (Enough so that Linus had some bad
> words for them!)

Are you maybe referring to some of the udev changes like persistent
network interface names?  Systemd was never pushed out as a default
and switching over to it isn't a huge ordeal but it is certainly a
VERY deliberate one.

The exchange between Linus and Kay concerned an issue that only
happened when you were actually running systemd.  It certainly
wouldn't impact any Gentoo user who didn't intentionally switch, or
users of just udev.

As far as I'm aware the udev changes were very well communicated using
news, and users were given options both for adapting to the change or
blocking the change from taking place.  This is a fairly typical way
of handling something like this in Gentoo; we've never really been a
distro that automatically takes care of things if you don't read news.

Other distros can be a bit more auto-magic because they restrict the
user's options.  When I set up a Gentoo box I need to pick my
preferred network manager and configure it.  When I go installing some
other distro the interfaces all come up auto-magically, but if I want
to tweak something I end up having to hunt endlessly to figure out how
that distro does things, and try to make my tweaks in a way such that
the package manager won't revert it on the next update.  I also
suspect that after I'm done all my tweaks the next time the distro
does some auto-magic updates (such as after something like the udev
change) I'll end up having to re-tweak things as it steps all over me.

And that is the benefit and cost of using Gentoo.  You get to do
things your way, and we know you're going to do it your way, so we try
to warn you and equip you when things change and not step all over
you.  However, it does limit the sorts of things we can automatically
update for you, because we have no idea how you've set it all up.  We
give you the tools when you install your system, and we give you the
tools when it is time for renovations...

-- 
Rich



Re: [gentoo-dev] newsitem: important fstab update

2016-10-27 Thread Francesco Riosa
2016-10-28 3:32 GMT+02:00 Ian Stakenvicius :

> On 27/10/16 09:23 PM, Gregory Woodbury wrote:
> > Out of curiosity, why do folks say that the use of LABEL= is not
> > good?  I realize that s are not required when doing a mkfs, but
> > if the admin does so reliably and wants to use LABEL= thereafter, why
> should
> > it be "deprecated"?
>
> I don't think anyone said that the LABEL= syntax is bad; quite the
> opposite -- WilliamH wants everyone using /dev/disk/by-label/
> paths in fstab to instead use LABEL= , to avoid issues if udev
> doesn't create the symlinks before localmount tries to use them.
>
>
> Indeed nobody ever said "deprecated" some people (/me too) don't like to
use labels and prefer UUIDs instead.
- in some situations -
To complete the statement labels are very good with fleets of servers with
predefined and consistent disk layouts, or for some people desktop.
When it come to a small number of server with different layouts they are
equivalent in functionality but need managing and memory, when you
substitute disk for example, simply not worth it.

Best,
Francesco


Re: [gentoo-dev] newsitem: important fstab update

2016-10-27 Thread Ian Stakenvicius
On 27/10/16 09:23 PM, Gregory Woodbury wrote:
> Out of curiosity, why do folks say that the use of LABEL= is not
> good?  I realize that s are not required when doing a mkfs, but
> if the admin does so reliably and wants to use LABEL= thereafter, why should
> it be "deprecated"?

I don't think anyone said that the LABEL= syntax is bad; quite the
opposite -- WilliamH wants everyone using /dev/disk/by-label/
paths in fstab to instead use LABEL= , to avoid issues if udev
doesn't create the symlinks before localmount tries to use them.




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-27 Thread Gregory Woodbury
On Thu, Oct 27, 2016 at 11:37 AM, Mike Gilbert  wrote:

>
> Seriously though, it makes more sense to have a conservative default
> (udev-settle). Especially since OpenRC is not well-equipped to deal
> with event-based device management.
>
>
It seems to me that the problem is one of somebody not caring that the
solution chosen can break an already functioning and stable system.

This is not unlike the kerfufle that occurred when systemD was introduced
not so long ago. To use it folks had to make major changes to their systems
that took several months to iron out the kinks.  Additionally, some of the
folks
pusing the change seemed to have a bad attitude about not caring that what
they did had unintended consequences. (Enough so that Linus had some bad
words for them!)

It isn't that progress or systemD is "bad", (it did solve some problems) but
that the manner in which it was introduced and pushed was poorly handled.

To select a "solution" that breaks functioning systems is not (to me) an
acceptable course of action.  It is no justification to remove udev-settle
to say that it "will speed thing up" as the only real advantage.

Out of curiosity, why do folks say that the use of LABEL= is not
good?  I realize that s are not required when doing a mkfs, but if the
admin does so reliably and wants to use LABEL= thereafter, why should it be
"deprecated"?


-- 
G.Wolfe Woodbury
redwo...@gmail.com


Re: [gentoo-dev] newsitem: important fstab update

2016-10-27 Thread Mike Gilbert
On Thu, Oct 27, 2016 at 9:04 AM, Michał Górny  wrote:
> On Thu, 27 Oct 2016 07:13:48 -0400
> Rich Freeman  wrote:
>
>> On Thu, Oct 27, 2016 at 7:01 AM, Roy Bamford  wrote:
>> > On 2016.10.25 22:52, Ian Stakenvicius wrote:
>> >>
>> >> Personally I'd rather see us go the other way, ensure udev settles
>> >> before localmount runs, and maybe ewarn if /dev/disk/by-* is in fstab
>> >> or something.  Leave the migration away from these paths to general
>> >> education of system setup, since they technically are valid, just not
>> >> ideal.
>> >>
>> >>
>> > +1
>> >
>> > Add udev-settle now.
>> > Have an advisory news item that says why its been done and what
>> > users can do if they don't like it or don't need it, and what will happen
>> > long term.
>>
>>
>> That seems sensible.
>>
>> > At the same time, depreciate the use of udev symlinks in fstab.
>> >
>> > Some time later, remove udev-settle and have another news item.
>> > By now, users will have reacted to the first news item or sympathy
>> > can be minimal.
>>
>> Why ever remove udev-settle, or deprecate the udev symlinks?  Is there
>> something wrong with them, other than a bug when you try to mount
>> things before they are created?
>>
>> If anything the udev syntax seems a lot more "standard" since it
>> follows the normal device, mountpoint, etc syntax in fstab.
>>
>> Nothing would prevent users from using the other syntax and removing
>> the settle step if they desire.  It just seems odd to not support a
>> fairly standard syntax in OpenRC, unless this is part of some larger
>> trend where udev itself is moving away from it, etc.
>
> The reliance on udev-settle doesn't follow the long-term Gentoo policy
> of being blazing impossibly fast.

I'm pretty sure you are joking around here.

Seriously though, it makes more sense to have a conservative default
(udev-settle). Especially since OpenRC is not well-equipped to deal
with event-based device management.



Re: [gentoo-dev] newsitem: important fstab update

2016-10-27 Thread Rich Freeman
On Thu, Oct 27, 2016 at 9:59 AM, Michał Górny  wrote:
>
> Neither were network device names. But now they are! As long as you
> predict to which USB port the dongle will be plugged ;-).
>

It would be nice if standards like USB incorporated some kind of GUID.
I ended up having to write a udev rule for a pl2303 RS232 adapter to
tie it to a specific USB port precisely so that I could have more than
one and know which one talked to which device.

I'd argue that the udev network interface names were a better (if
painful to transition to) solution to a problem created by somebody
else.  Being able to use wildcards in configuration files is probably
an adequate solution for those who are using a single device.

-- 
Rich



Re: [gentoo-dev] newsitem: important fstab update

2016-10-27 Thread Michał Górny
On Thu, 27 Oct 2016 15:42:53 +0200
Greg KH  wrote:

> On Wed, Oct 26, 2016 at 11:04:34AM +0200, Michał Górny wrote:
> > Dnia 26 października 2016 10:49:04 CEST, Joshua Kinard  
> > napisał(a):  
> > >On 10/25/2016 13:15, William Hubbs wrote:  
> > >> On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote:  
> > >>> On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs   
> > >wrote:  
> >  If you are not using /dev/disk/by-* paths in fstab, you do not need  
> > >to  
> > >>> take any action for this news item.  
> > 
> >  If you are, it is very critical that you update fstab AS SOON AS  
> > >>> POSSIBLE. Your system will become unbootable in the future if you do
> > >>> not  do so.
> > >>>
> > >>> Err, what is changing that will make systems unbootable?
> > >>>
> > >>> I am fairly certain systems running systemd will continue to work
> > >>> properly with either syntax.  
> > >>  
> > >>  They probably will.
> > >>   
> > >>> If this is about the udev-settle issue for OpenRC, I would urge you  
> > >to  
> > >>> reconsider that.  
> > >>  
> > >>  There isn't anything to reconsider afaik. The problem is that
> > >>  /dev/disk/by-* are only created by udev/eudev, but the other syntax
> > >>  works regardless of which device manager  you use, so this is the  
> > >safer  
> > >>  route.
> > >> 
> > >>  William
> > >>   
> > >
> > >I take it us museum relics still using jurassic-era device names like
> > >/dev/sd* or /dev/md* aren't affected by this?  Cthulhu-forbid Linux
> > >device
> > >naming gets any more complicated than using UUID's.  What's next,
> > >saving the
> > >serial numbers of discovered disks in an overly-complicated
> > >key/value-based
> > >non-SQL database format?  
> > 
> > Wait full you-know-who notices that disk device names are not predictable 
> > and fixes that.  
> 
> disk device names have never been predictable, don't get comfortable :)
> 
> If you rely on them, you need to be aware that they can change at
> times...

Neither were network device names. But now they are! As long as you
predict to which USB port the dongle will be plugged ;-).

-- 
Best regards,
Michał Górny



pgpqfwy5aQWV1.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-27 Thread Greg KH
On Wed, Oct 26, 2016 at 11:04:34AM +0200, Michał Górny wrote:
> Dnia 26 października 2016 10:49:04 CEST, Joshua Kinard  
> napisał(a):
> >On 10/25/2016 13:15, William Hubbs wrote:
> >> On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote:
> >>> On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs 
> >wrote:
>  If you are not using /dev/disk/by-* paths in fstab, you do not need
> >to
> >>> take any action for this news item.
> 
>  If you are, it is very critical that you update fstab AS SOON AS
> >>> POSSIBLE. Your system will become unbootable in the future if you do
> >>> not  do so.
> >>>
> >>> Err, what is changing that will make systems unbootable?
> >>>
> >>> I am fairly certain systems running systemd will continue to work
> >>> properly with either syntax.
> >>  
> >>  They probably will.
> >> 
> >>> If this is about the udev-settle issue for OpenRC, I would urge you
> >to
> >>> reconsider that.
> >>  
> >>  There isn't anything to reconsider afaik. The problem is that
> >>  /dev/disk/by-* are only created by udev/eudev, but the other syntax
> >>  works regardless of which device manager  you use, so this is the
> >safer
> >>  route.
> >> 
> >>  William
> >> 
> >
> >I take it us museum relics still using jurassic-era device names like
> >/dev/sd* or /dev/md* aren't affected by this?  Cthulhu-forbid Linux
> >device
> >naming gets any more complicated than using UUID's.  What's next,
> >saving the
> >serial numbers of discovered disks in an overly-complicated
> >key/value-based
> >non-SQL database format?
> 
> Wait full you-know-who notices that disk device names are not predictable and 
> fixes that.

disk device names have never been predictable, don't get comfortable :)

If you rely on them, you need to be aware that they can change at
times...

good luck!

greg k-h



Re: [gentoo-dev] newsitem: important fstab update

2016-10-27 Thread Michał Górny
On Thu, 27 Oct 2016 07:13:48 -0400
Rich Freeman  wrote:

> On Thu, Oct 27, 2016 at 7:01 AM, Roy Bamford  wrote:
> > On 2016.10.25 22:52, Ian Stakenvicius wrote:  
> >>
> >> Personally I'd rather see us go the other way, ensure udev settles
> >> before localmount runs, and maybe ewarn if /dev/disk/by-* is in fstab
> >> or something.  Leave the migration away from these paths to general
> >> education of system setup, since they technically are valid, just not
> >> ideal.
> >>
> >>  
> > +1
> >
> > Add udev-settle now.
> > Have an advisory news item that says why its been done and what
> > users can do if they don't like it or don't need it, and what will happen
> > long term.  
> 
> 
> That seems sensible.
> 
> > At the same time, depreciate the use of udev symlinks in fstab.
> >
> > Some time later, remove udev-settle and have another news item.
> > By now, users will have reacted to the first news item or sympathy
> > can be minimal.  
> 
> Why ever remove udev-settle, or deprecate the udev symlinks?  Is there
> something wrong with them, other than a bug when you try to mount
> things before they are created?
> 
> If anything the udev syntax seems a lot more "standard" since it
> follows the normal device, mountpoint, etc syntax in fstab.
> 
> Nothing would prevent users from using the other syntax and removing
> the settle step if they desire.  It just seems odd to not support a
> fairly standard syntax in OpenRC, unless this is part of some larger
> trend where udev itself is moving away from it, etc.

The reliance on udev-settle doesn't follow the long-term Gentoo policy
of being blazing impossibly fast.

-- 
Best regards,
Michał Górny



pgpLUjX7c26iz.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-27 Thread Ian Stakenvicius
On 26/10/16 11:43 PM, Gordon Pettey wrote:
> On Wed, Oct 26, 2016 at 9:05 PM, Ian Stakenvicius  > wrote:
> 
> On 26/10/16 04:49 AM, Joshua Kinard wrote:
> > On 10/25/2016 13:15, William Hubbs wrote:
> >> On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote:
> >>> On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs
> > wrote:
>  If you are not using /dev/disk/by-* paths in fstab, you do
> not need to
> >>> take any action for this news item.
> 
>  If you are, it is very critical that you update fstab AS SOON AS
> >>> POSSIBLE. Your system will become unbootable in the future if
> you do
> >>> not  do so.
> >>>
> >>> Err, what is changing that will make systems unbootable?
> >>>
> >>> I am fairly certain systems running systemd will continue to work
> >>> properly with either syntax.
> >>
> >>  They probably will.
> >>
> >>> If this is about the udev-settle issue for OpenRC, I would
> urge you to
> >>> reconsider that.
> >>
> >>  There isn't anything to reconsider afaik. The problem is that
> >>  /dev/disk/by-* are only created by udev/eudev, but the other
> syntax
> >>  works regardless of which device manager  you use, so this is
> the safer
> >>  route.
> >>
> >>  William
> >>
> >
> > I take it us museum relics still using jurassic-era device names like
> > /dev/sd* or /dev/md* aren't affected by this?
> 
> That's correct -- the kernel's 'devtmpfs' creates those ones, whereas
> the /dev/disk/by-* symlinks (pretty well all symlinks in /dev i think,
> actually) are generated by udev rules.
> 
> Actually, I wonder if the /dev/[vgname]/[lvname] paths would be
> affected by this too -- those are symlinks to the actual nodes in
> /dev/mapper/ after all, and are created by 11-dm-lvm.rules
> 
> 
> Those are already problematic; udev and/or lvm2 seem to randomly
> forget to set those up sometimes. I use /dev/mapped/vg-lv in
> /etc/fstab because of that.
>  

If they aren't there at mount time but do show up after everything is
mounted, I'm willing to bet that is caused by the same issue.  I think
I'll add another paragraph to the second draft about this.




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-27 Thread Rich Freeman
On Thu, Oct 27, 2016 at 7:01 AM, Roy Bamford  wrote:
> On 2016.10.25 22:52, Ian Stakenvicius wrote:
>>
>> Personally I'd rather see us go the other way, ensure udev settles
>> before localmount runs, and maybe ewarn if /dev/disk/by-* is in fstab
>> or something.  Leave the migration away from these paths to general
>> education of system setup, since they technically are valid, just not
>> ideal.
>>
>>
> +1
>
> Add udev-settle now.
> Have an advisory news item that says why its been done and what
> users can do if they don't like it or don't need it, and what will happen
> long term.


That seems sensible.

> At the same time, depreciate the use of udev symlinks in fstab.
>
> Some time later, remove udev-settle and have another news item.
> By now, users will have reacted to the first news item or sympathy
> can be minimal.

Why ever remove udev-settle, or deprecate the udev symlinks?  Is there
something wrong with them, other than a bug when you try to mount
things before they are created?

If anything the udev syntax seems a lot more "standard" since it
follows the normal device, mountpoint, etc syntax in fstab.

Nothing would prevent users from using the other syntax and removing
the settle step if they desire.  It just seems odd to not support a
fairly standard syntax in OpenRC, unless this is part of some larger
trend where udev itself is moving away from it, etc.

-- 
Rich



Re: [gentoo-dev] newsitem: important fstab update

2016-10-27 Thread Roy Bamford
On 2016.10.25 22:52, Ian Stakenvicius wrote:
> On 25/10/16 05:12 PM, Michał Górny wrote:
> > On Tue, 25 Oct 2016 12:01:06 -0500
> > William Hubbs  wrote:
> > 
> >> Title: Inportant fstab update
> >> Author: William Hubbs 
> >> Content-Type: text/plain
> >> Posted: 2016-10-28
> >> Revision: 1
> >> News-Item-Format: 1.0
> >>
> >> If you are not using /dev/disk/by-* paths in fstab, you do not need
> to
> >> take any action for this news item.
> >>
> >> If you are, it is very critical that you update fstab AS SOON AS
> >> POSSIBLE. Your system will become unbootable in the future if you
> do
> >> not  do so.
> > 
> > I don't think this is a good way to start any text. You should start
> > with a short introduction on what's happening, when and how.
> > 
> > Right now the news item sounds like the world is going to suddenly
> fall
> > apart for no specific reason. Reading it, I don't know what's
> changing,
> > and how to check if it impacts me already (i.e. if it's 'do not
> > reboot' kind of problem) and if it will impact me at all.
> > 
> >> You need to replace the /dev/disk/by-* paths in your fstab with the
> >> equivalent information from the output of the blkid utility.
> > 
> > This is at least unclear, if not misguiding. I read it as 'blkid
> will
> > give you fs info'. However, you're not telling me which of those
> > information I can use and how. I should also point out that blkid
> > supports multiple output formats.
> > 
> > I think it would be better if you explicitly listed the thingies
> > supported by mount(1).
> > 
> 
> Reading mgorny's response, I'm wondering if a news item really makes
> any sense at all for this.  What's being done here is essentially a
> warning/recommendation for users to act so they don't run into a
> problem that's sort-of already there (at least in ~arch)...
> 
> Personally I'd rather see us go the other way, ensure udev settles
> before localmount runs, and maybe ewarn if /dev/disk/by-* is in fstab
> or something.  Leave the migration away from these paths to general
> education of system setup, since they technically are valid, just not
> ideal.
> 
> 
+1

Add udev-settle now.
Have an advisory news item that says why its been done and what 
users can do if they don't like it or don't need it, and what will happen
long term.
At the same time, depreciate the use of udev symlinks in fstab.

Some time later, remove udev-settle and have another news item.
By now, users will have reacted to the first news item or sympathy 
can be minimal.
 
In the interim, nothing should break because a news item was not
read and acted on immediately. 

That's the important bit ... nothing breaks on user systems.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods


pgpRXKeMRcwoT.pgp
Description: PGP signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-26 Thread Gordon Pettey
On Wed, Oct 26, 2016 at 9:05 PM, Ian Stakenvicius  wrote:

> On 26/10/16 04:49 AM, Joshua Kinard wrote:
> > On 10/25/2016 13:15, William Hubbs wrote:
> >> On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote:
> >>> On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs 
> wrote:
>  If you are not using /dev/disk/by-* paths in fstab, you do not need to
> >>> take any action for this news item.
> 
>  If you are, it is very critical that you update fstab AS SOON AS
> >>> POSSIBLE. Your system will become unbootable in the future if you do
> >>> not  do so.
> >>>
> >>> Err, what is changing that will make systems unbootable?
> >>>
> >>> I am fairly certain systems running systemd will continue to work
> >>> properly with either syntax.
> >>
> >>  They probably will.
> >>
> >>> If this is about the udev-settle issue for OpenRC, I would urge you to
> >>> reconsider that.
> >>
> >>  There isn't anything to reconsider afaik. The problem is that
> >>  /dev/disk/by-* are only created by udev/eudev, but the other syntax
> >>  works regardless of which device manager  you use, so this is the safer
> >>  route.
> >>
> >>  William
> >>
> >
> > I take it us museum relics still using jurassic-era device names like
> > /dev/sd* or /dev/md* aren't affected by this?
>
> That's correct -- the kernel's 'devtmpfs' creates those ones, whereas
> the /dev/disk/by-* symlinks (pretty well all symlinks in /dev i think,
> actually) are generated by udev rules.
>
> Actually, I wonder if the /dev/[vgname]/[lvname] paths would be
> affected by this too -- those are symlinks to the actual nodes in
> /dev/mapper/ after all, and are created by 11-dm-lvm.rules
>

Those are already problematic; udev and/or lvm2 seem to randomly forget to
set those up sometimes. I use /dev/mapped/vg-lv in /etc/fstab because of
that.


Re: [gentoo-dev] newsitem: important fstab update

2016-10-26 Thread Robin H. Johnson
On Wed, Oct 26, 2016 at 04:49:04AM -0400, Joshua Kinard wrote:
> I take it us museum relics still using jurassic-era device names like
> /dev/sd* or /dev/md* aren't affected by this?  
Actually, I can see a use case for it even with classical device names:
Specifically if the nodes (or symlinks) you want to use are created
too-late by the device manager or other tools.

-- 
Robin Hugh Johnson
Gentoo Linux: Dev, Infra Lead, Foundation Trustee & Treasurer
E-Mail   : robb...@gentoo.org
GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136



Re: [gentoo-dev] newsitem: important fstab update

2016-10-26 Thread Peter Stuge
Ian Stakenvicius wrote:
> by mount and works regardless of device manager, therefore removing
> the the dependency of having udev-settle before mounting these paths.

the the


Looks good. Thanks.


//Peter



Re: [gentoo-dev] newsitem: important fstab update

2016-10-26 Thread Tom H
On Wed, Oct 26, 2016 at 12:04 PM, Ian Stakenvicius  wrote:
>
> requirement for udev to "settle" before it's startup completes. The

its startup



Re: [gentoo-dev] newsitem: important fstab update

2016-10-26 Thread Ian Stakenvicius
Here's a revised possibility -- it diverges a little from the original
message but I think its more inclusive as to the issue.

Thoughts?

-

Title: Important fstab and localmount update
Author: William Hubbs 
Content-Type: text/plain
Posted: 2016-10-28
Revision: 1
News-Item-Format: 1.0
[rules-that-limits-this-to-openrc-and-udev??]

Recent updates to init scripts in OpenRC and (e)udev have removed the
requirement for udev to "settle" before it's startup completes.  The
result of this is that services which used to wait for udev to finish
processing all kernel events will now start earlier.  One such service
is localmount.

If "/dev/disk/by-*" source paths for are used for mount points in
fstab, then it is possible that udev may not have created those
symlinks before localmount starts and tries to mount them.

One possible way to address this is to ensure that udev-settle is
started before localmount starts, to enforce the old behaviour.  This
can be done simply by adding it to sysinit the runlevel, or adding an
'rc_want=udev-settle' in /etc/conf.d/localmount.

The more generic solution is to move away from using "/dev/disk/by-*"
source paths and instead convert to using the LABEL= , UUID= , or
PARTUUID= syntax in fstab instead.  This syntax is supported directly
by mount and works regardless of device manager, therefore removing
the the dependency of having udev-settle before mounting these paths.
More information can be found in the fstab manpage.





signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-26 Thread Francesco Riosa
2016-10-26 11:04 GMT+02:00 Michał Górny :

> Dnia 26 października 2016 10:49:04 CEST, Joshua Kinard 
> napisał(a):
> >On 10/25/2016 13:15, William Hubbs wrote:
> >> On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote:
> >>> On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs 
> >wrote:
>  If you are not using /dev/disk/by-* paths in fstab, you do not need
> >to
> >>> take any action for this news item.
> 
>  If you are, it is very critical that you update fstab AS SOON AS
> >>> POSSIBLE. Your system will become unbootable in the future if you do
> >>> not  do so.
> >>>
> >>> Err, what is changing that will make systems unbootable?
> >>>
> >>> I am fairly certain systems running systemd will continue to work
> >>> properly with either syntax.
> >>
> >>  They probably will.
> >>
> >>> If this is about the udev-settle issue for OpenRC, I would urge you
> >to
> >>> reconsider that.
> >>
> >>  There isn't anything to reconsider afaik. The problem is that
> >>  /dev/disk/by-* are only created by udev/eudev, but the other syntax
> >>  works regardless of which device manager  you use, so this is the
> >safer
> >>  route.
> >>
> >>  William
> >>
> >
> >I take it us museum relics still using jurassic-era device names like
> >/dev/sd* or /dev/md* aren't affected by this?  Cthulhu-forbid Linux
> >device
> >naming gets any more complicated than using UUID's.  What's next,
> >saving the
> >serial numbers of discovered disks in an overly-complicated
> >key/value-based
> >non-SQL database format?
>
> Wait full you-know-who notices that disk device names are not predictable
> and fixes that.
>

that's easy just make fstab parser able to read the content of
HWPATH=/sys/devices/pci:00/:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda/sda1/dev
;-)


>
>
> --
> Best regards,
> Michał Górny (by phone)
>
>


Re: [gentoo-dev] newsitem: important fstab update

2016-10-26 Thread Michał Górny
Dnia 26 października 2016 10:49:04 CEST, Joshua Kinard  
napisał(a):
>On 10/25/2016 13:15, William Hubbs wrote:
>> On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote:
>>> On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs 
>wrote:
 If you are not using /dev/disk/by-* paths in fstab, you do not need
>to
>>> take any action for this news item.

 If you are, it is very critical that you update fstab AS SOON AS
>>> POSSIBLE. Your system will become unbootable in the future if you do
>>> not  do so.
>>>
>>> Err, what is changing that will make systems unbootable?
>>>
>>> I am fairly certain systems running systemd will continue to work
>>> properly with either syntax.
>>  
>>  They probably will.
>> 
>>> If this is about the udev-settle issue for OpenRC, I would urge you
>to
>>> reconsider that.
>>  
>>  There isn't anything to reconsider afaik. The problem is that
>>  /dev/disk/by-* are only created by udev/eudev, but the other syntax
>>  works regardless of which device manager  you use, so this is the
>safer
>>  route.
>> 
>>  William
>> 
>
>I take it us museum relics still using jurassic-era device names like
>/dev/sd* or /dev/md* aren't affected by this?  Cthulhu-forbid Linux
>device
>naming gets any more complicated than using UUID's.  What's next,
>saving the
>serial numbers of discovered disks in an overly-complicated
>key/value-based
>non-SQL database format?

Wait full you-know-who notices that disk device names are not predictable and 
fixes that.


-- 
Best regards,
Michał Górny (by phone)



Re: [gentoo-dev] newsitem: important fstab update

2016-10-26 Thread Joshua Kinard
On 10/25/2016 13:15, William Hubbs wrote:
> On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote:
>> On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs  wrote:
>>> If you are not using /dev/disk/by-* paths in fstab, you do not need to
>> take any action for this news item.
>>>
>>> If you are, it is very critical that you update fstab AS SOON AS
>> POSSIBLE. Your system will become unbootable in the future if you do
>> not  do so.
>>
>> Err, what is changing that will make systems unbootable?
>>
>> I am fairly certain systems running systemd will continue to work
>> properly with either syntax.
>  
>  They probably will.
> 
>> If this is about the udev-settle issue for OpenRC, I would urge you to
>> reconsider that.
>  
>  There isn't anything to reconsider afaik. The problem is that
>  /dev/disk/by-* are only created by udev/eudev, but the other syntax
>  works regardless of which device manager  you use, so this is the safer
>  route.
> 
>  William
> 

I take it us museum relics still using jurassic-era device names like
/dev/sd* or /dev/md* aren't affected by this?  Cthulhu-forbid Linux device
naming gets any more complicated than using UUID's.  What's next, saving the
serial numbers of discovered disks in an overly-complicated key/value-based
non-SQL database format?

-- 
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic



Re: [gentoo-dev] newsitem: important fstab update

2016-10-25 Thread M. J. Everitt
On 25/10/16 18:27, William Hubbs wrote:
> On Tue, Oct 25, 2016 at 06:07:51PM +0100, James Le Cuirot wrote:
>> On Tue, 25 Oct 2016 12:01:06 -0500
>> William Hubbs  wrote:
>>
>>> this item is about an important fstab update. In short, people need to
>>> move away from /dev/disk-by/* in their fstab vfiles.
>> "Inportant" typo in the title.
>>
>> Even before you posted this, I was wondering why this is a problem now?
> This was changed in baselayout git years ago [1], and someone hit a race
> condition caused by not making the changes in their fstab [2].
>
> The "new" syntax is device-manager agnostic, and supported by both
> util-linux and busybox, so imo it is the best route to take.
>
> William
>
> [1] https://bugs.gentoo.org/show_bug.cgi?id=496562
> [2] https://bugs.gentoo.org/show_bug.cgi?id=596346
+2



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-25 Thread Matthias Maier

> please make also clear that UUID=... syntax will still work, one for all I
> don't like labels and will gladly continu to use this format:
> UUID=debd07a3-fbbc-4433-89db-29e6f91d25e4 /boot ext2 noauto,noatime  1 2

+1

Slightly revising the example given later on by simply showing one
example for LABELs and one for UUIDs should be enough.

Best,
Matthias



Re: [gentoo-dev] newsitem: important fstab update

2016-10-25 Thread Ian Stakenvicius
On 25/10/16 05:12 PM, Michał Górny wrote:
> On Tue, 25 Oct 2016 12:01:06 -0500
> William Hubbs  wrote:
> 
>> Title: Inportant fstab update
>> Author: William Hubbs 
>> Content-Type: text/plain
>> Posted: 2016-10-28
>> Revision: 1
>> News-Item-Format: 1.0
>>
>> If you are not using /dev/disk/by-* paths in fstab, you do not need to
>> take any action for this news item.
>>
>> If you are, it is very critical that you update fstab AS SOON AS
>> POSSIBLE. Your system will become unbootable in the future if you do
>> not  do so.
> 
> I don't think this is a good way to start any text. You should start
> with a short introduction on what's happening, when and how.
> 
> Right now the news item sounds like the world is going to suddenly fall
> apart for no specific reason. Reading it, I don't know what's changing,
> and how to check if it impacts me already (i.e. if it's 'do not
> reboot' kind of problem) and if it will impact me at all.
> 
>> You need to replace the /dev/disk/by-* paths in your fstab with the
>> equivalent information from the output of the blkid utility.
> 
> This is at least unclear, if not misguiding. I read it as 'blkid will
> give you fs info'. However, you're not telling me which of those
> information I can use and how. I should also point out that blkid
> supports multiple output formats.
> 
> I think it would be better if you explicitly listed the thingies
> supported by mount(1).
> 

Reading mgorny's response, I'm wondering if a news item really makes
any sense at all for this.  What's being done here is essentially a
warning/recommendation for users to act so they don't run into a
problem that's sort-of already there (at least in ~arch)...

Personally I'd rather see us go the other way, ensure udev settles
before localmount runs, and maybe ewarn if /dev/disk/by-* is in fstab
or something.  Leave the migration away from these paths to general
education of system setup, since they technically are valid, just not
ideal.





signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-25 Thread Michał Górny
On Tue, 25 Oct 2016 12:01:06 -0500
William Hubbs  wrote:

> Title: Inportant fstab update
> Author: William Hubbs 
> Content-Type: text/plain
> Posted: 2016-10-28
> Revision: 1
> News-Item-Format: 1.0
> 
> If you are not using /dev/disk/by-* paths in fstab, you do not need to
> take any action for this news item.
>
> If you are, it is very critical that you update fstab AS SOON AS
> POSSIBLE. Your system will become unbootable in the future if you do
> not  do so.

I don't think this is a good way to start any text. You should start
with a short introduction on what's happening, when and how.

Right now the news item sounds like the world is going to suddenly fall
apart for no specific reason. Reading it, I don't know what's changing,
and how to check if it impacts me already (i.e. if it's 'do not
reboot' kind of problem) and if it will impact me at all.

> You need to replace the /dev/disk/by-* paths in your fstab with the
> equivalent information from the output of the blkid utility.

This is at least unclear, if not misguiding. I read it as 'blkid will
give you fs info'. However, you're not telling me which of those
information I can use and how. I should also point out that blkid
supports multiple output formats.

I think it would be better if you explicitly listed the thingies
supported by mount(1).

> For example, here is out from blkid on my system:
> 
> # blkid
> 
> /dev/sda2: LABEL="boot" UUID="371432e9-7e6c-4205-9d4e-b23f6212e54b" 
> TYPE="ext2" PARTLABEL="boot" PARTUUID="2451c4a9-0405-425e-8d53-4567beae8651"
> /dev/sda3: LABEL="swap" UUID="d579b037-615c-441f-8f83-03e3c4919c21" 
> TYPE="swap" PARTLABEL="swap" PARTUUID="14c0d838-6dc5-4fdb-9a9d-c9523acdadc7"
> /dev/sda4: LABEL="root" UUID="5c496429-c836-4b23-9b11-7efd609c7cde" 
> TYPE="ext4" PARTLABEL="rootfs" PARTUUID="8a9765a4-7a20-4fa4-87e2-7a64d782e0d0"
> /dev/sda5: LABEL="home" UUID="bb63928e-67c0-4522-b4a0-66be507c2c2f" 
> TYPE="ext4" PARTLABEL="home" PARTUUID="000848d8-b51b-4671-8754-6d3b0c8df465"
> /dev/sda6: LABEL="var" UUID="fcb8046b-283b-45c0-a2c0-ae1001bebf82" 
> TYPE="ext4" PARTLABEL="var" PARTUUID="e1d8ccf6-3523-4c13-baae-e674ee0b43bf"
> /dev/sda1: PARTLABEL="grub" PARTUUID="700e8338-399f-4d33-9e15-73c85b136f3d"
> 
> My fstab can use any of the labels or ids, so I use labels:
> 
> LABEL=boot/boot   ext2defaults1 2
> LABEL=swapnoneswapsw  0 0
> LABEL=root/   ext4defaults
> 0 1
> LABEL=home/home   ext4defaults
> 0 1
> LABEL=var /varext4defaults
> 0 1

I'm afraid those examples are not really readable. Furthermore, I don't
see much point in pasting the whole fstab if all entries use LABEL=.
Try to keep them below 72 (or 80?) chars, skip blkid or paste just one
entry (wrapped), paste a minimal fstab just as example how the tags can
be used.

-- 
Best regards,
Michał Górny



pgpviFoJ7bTNB.pgp
Description: OpenPGP digital signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-25 Thread Francesco Riosa
2016-10-25 19:15 GMT+02:00 William Hubbs :

> On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote:
> > On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs 
> wrote:
> > > If you are not using /dev/disk/by-* paths in fstab, you do not need to
> > take any action for this news item.
> > >
> > > If you are, it is very critical that you update fstab AS SOON AS
> > POSSIBLE. Your system will become unbootable in the future if you do
> > not  do so.
> >
> > Err, what is changing that will make systems unbootable?
> >
> > I am fairly certain systems running systemd will continue to work
> > properly with either syntax.
>
>  They probably will.
>
> > If this is about the udev-settle issue for OpenRC, I would urge you to
> > reconsider that.
>
>  There isn't anything to reconsider afaik. The problem is that
>  /dev/disk/by-* are only created by udev/eudev, but the other syntax
>  works regardless of which device manager  you use, so this is the safer
>  route.
>

please make also clear that UUID=... syntax will still work, one for all I
don't like labels and will gladly continu to use this format:
UUID=debd07a3-fbbc-4433-89db-29e6f91d25e4 /boot ext2 noauto,noatime  1 2



>
>  William
>
>


Re: [gentoo-dev] newsitem: important fstab update

2016-10-25 Thread William Hubbs
On Tue, Oct 25, 2016 at 06:07:51PM +0100, James Le Cuirot wrote:
> On Tue, 25 Oct 2016 12:01:06 -0500
> William Hubbs  wrote:
> 
> > this item is about an important fstab update. In short, people need to
> > move away from /dev/disk-by/* in their fstab vfiles.
> 
> "Inportant" typo in the title.
> 
> Even before you posted this, I was wondering why this is a problem now?

This was changed in baselayout git years ago [1], and someone hit a race
condition caused by not making the changes in their fstab [2].

The "new" syntax is device-manager agnostic, and supported by both
util-linux and busybox, so imo it is the best route to take.

William

[1] https://bugs.gentoo.org/show_bug.cgi?id=496562
[2] https://bugs.gentoo.org/show_bug.cgi?id=596346


signature.asc
Description: Digital signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-25 Thread Mike Gilbert
On Tue, Oct 25, 2016 at 1:15 PM, William Hubbs  wrote:
> On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote:
>> On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs  wrote:
>> > If you are not using /dev/disk/by-* paths in fstab, you do not need to
>> take any action for this news item.
>> >
>> > If you are, it is very critical that you update fstab AS SOON AS
>> POSSIBLE. Your system will become unbootable in the future if you do
>> not  do so.
>>
>> Err, what is changing that will make systems unbootable?
>>
>> I am fairly certain systems running systemd will continue to work
>> properly with either syntax.
>
>  They probably will.
>
>> If this is about the udev-settle issue for OpenRC, I would urge you to
>> reconsider that.
>
>  There isn't anything to reconsider afaik. The problem is that
>  /dev/disk/by-* are only created by udev/eudev, but the other syntax
>  works regardless of which device manager  you use, so this is the safer
>  route.

People do not randomly switch device managers. If the symlinks
currently work for them, they can/should continue to work in the
future.



Re: [gentoo-dev] newsitem: important fstab update

2016-10-25 Thread William Hubbs
On Tue, Oct 25, 2016 at 01:10:06PM -0400, Mike Gilbert wrote:
> On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs  wrote:
> > If you are not using /dev/disk/by-* paths in fstab, you do not need to
> take any action for this news item.
> >
> > If you are, it is very critical that you update fstab AS SOON AS
> POSSIBLE. Your system will become unbootable in the future if you do
> not  do so.
> 
> Err, what is changing that will make systems unbootable?
> 
> I am fairly certain systems running systemd will continue to work
> properly with either syntax.
 
 They probably will.

> If this is about the udev-settle issue for OpenRC, I would urge you to
> reconsider that.
 
 There isn't anything to reconsider afaik. The problem is that
 /dev/disk/by-* are only created by udev/eudev, but the other syntax
 works regardless of which device manager  you use, so this is the safer
 route.

 William



signature.asc
Description: Digital signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-25 Thread Ian Stakenvicius
On 25/10/16 01:10 PM, Mike Gilbert wrote:
> 
> If this is about the udev-settle issue for OpenRC, I would urge you to
> reconsider that.
> 

+1



signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-25 Thread Mike Gilbert
On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs  wrote:
> I do have a question about the newsitem -- how do I make it display only
> for Linux users?

Once >=sys-apps/portage-2.3.2 is stable, you could use the new
Display-If-Profile wildcard syntax to display it only for
default/linux/*.



Re: [gentoo-dev] newsitem: important fstab update

2016-10-25 Thread Ian Stakenvicius
On 25/10/16 01:07 PM, James Le Cuirot wrote:
> On Tue, 25 Oct 2016 12:01:06 -0500
> William Hubbs  wrote:
> 
>> this item is about an important fstab update. In short, people need to
>> move away from /dev/disk-by/* in their fstab vfiles.
> 
> "Inportant" typo in the title.
> 
> Even before you posted this, I was wondering why this is a problem now?
> 

Openrc's localmount doesn't wait for udev to finish anymore (partially
because udev doesn't 'settle' by default), and so instead of adding a
'use udev-settle' WilliamH decided to notify people to just not use
udev-triggered symlinks.

The LABEL= or UUID= syntax in /etc/fstab is more robust so it makes
sense for users to use that instead of these symlinks anyhow.




signature.asc
Description: OpenPGP digital signature


Re: [gentoo-dev] newsitem: important fstab update

2016-10-25 Thread Mike Gilbert
On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs  wrote:
> If you are not using /dev/disk/by-* paths in fstab, you do not need to
take any action for this news item.
>
> If you are, it is very critical that you update fstab AS SOON AS
POSSIBLE. Your system will become unbootable in the future if you do
not  do so.

Err, what is changing that will make systems unbootable?

I am fairly certain systems running systemd will continue to work
properly with either syntax.

If this is about the udev-settle issue for OpenRC, I would urge you to
reconsider that.



Re: [gentoo-dev] newsitem: important fstab update

2016-10-25 Thread James Le Cuirot
On Tue, 25 Oct 2016 12:01:06 -0500
William Hubbs  wrote:

> this item is about an important fstab update. In short, people need to
> move away from /dev/disk-by/* in their fstab vfiles.

"Inportant" typo in the title.

Even before you posted this, I was wondering why this is a problem now?

-- 
James Le Cuirot (chewi)
Gentoo Linux Developer



Re: [gentoo-dev] newsitem: important fstab update

2016-10-25 Thread Rich Freeman
On Tue, Oct 25, 2016 at 1:01 PM, William Hubbs  wrote:
>
> this item is about an important fstab update. In short, people need to
> move away from /dev/disk-by/* in their fstab vfiles.
>
> I do have a question about the newsitem -- how do I make it display only
> for Linux users?
>

Presumably you'd also only want it to show for openrc users.  Other
mounting tools handle the udev names fine as far as I'm aware.

-- 
Rich



[gentoo-dev] newsitem: important fstab update

2016-10-25 Thread William Hubbs
All,

this item is about an important fstab update. In short, people need to
move away from /dev/disk-by/* in their fstab vfiles.

I do have a question about the newsitem -- how do I make it display only
for Linux users?

Thanks,

William

Title: Inportant fstab update
Author: William Hubbs 
Content-Type: text/plain
Posted: 2016-10-28
Revision: 1
News-Item-Format: 1.0

If you are not using /dev/disk/by-* paths in fstab, you do not need to
take any action for this news item.

If you are, it is very critical that you update fstab AS SOON AS
POSSIBLE. Your system will become unbootable in the future if you do
not  do so.

You need to replace the /dev/disk/by-* paths in your fstab with the
equivalent information from the output of the blkid utility.

For example, here is out from blkid on my system:

# blkid

/dev/sda2: LABEL="boot" UUID="371432e9-7e6c-4205-9d4e-b23f6212e54b" TYPE="ext2" 
PARTLABEL="boot" PARTUUID="2451c4a9-0405-425e-8d53-4567beae8651"
/dev/sda3: LABEL="swap" UUID="d579b037-615c-441f-8f83-03e3c4919c21" TYPE="swap" 
PARTLABEL="swap" PARTUUID="14c0d838-6dc5-4fdb-9a9d-c9523acdadc7"
/dev/sda4: LABEL="root" UUID="5c496429-c836-4b23-9b11-7efd609c7cde" TYPE="ext4" 
PARTLABEL="rootfs" PARTUUID="8a9765a4-7a20-4fa4-87e2-7a64d782e0d0"
/dev/sda5: LABEL="home" UUID="bb63928e-67c0-4522-b4a0-66be507c2c2f" TYPE="ext4" 
PARTLABEL="home" PARTUUID="000848d8-b51b-4671-8754-6d3b0c8df465"
/dev/sda6: LABEL="var" UUID="fcb8046b-283b-45c0-a2c0-ae1001bebf82" TYPE="ext4" 
PARTLABEL="var" PARTUUID="e1d8ccf6-3523-4c13-baae-e674ee0b43bf"
/dev/sda1: PARTLABEL="grub" PARTUUID="700e8338-399f-4d33-9e15-73c85b136f3d"

My fstab can use any of the labels or ids, so I use labels:

LABEL=boot  /boot   ext2defaults1 2
LABEL=swap  noneswapsw  0 0
LABEL=root  /   ext4defaults
0 1
LABEL=home  /home   ext4defaults
0 1
LABEL=var   /varext4defaults
0 1


signature.asc
Description: Digital signature