[gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Samuli Suominen]

[-- Attachment #1: Type: text/plain, Size: 58 bytes --]

please review this news item, seems we need one after all

[-- Attachment #2: 2013-01-23-udev-upgrade.en.txt --]
[-- Type: text/plain, Size: 1790 bytes --]

Title: Upgrading udev from 171 (or older) to 197
Author: Samuli Suominen <ssuominen@gentoo.org>
Content-Type: text/plain
Posted: 2013-01-23
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <sys-fs/udev-9999

Upgrading udev from 171 (or older) to 197 will require special attention:

- Remove udev-postmount from runlevels.

- The need of CONFIG_DEVTMPFS=y in the kernel; need to verify the fstype for
  possible /dev line in /etc/fstab is devtmpfs (and not, for example, tmpfs)

- The case of predictable network interface names; if the file
  /etc/udev/rules.d/70-persistent-net.rules is being used for renaming
  network interface names to already existing names, then you need to
  read following bug[1] because it's no longer possible. This won't
  be a problem with the new predictable network interface name scheme[2].

  [1] http://bugs.gentoo.org/453494
  [2] http://www.freedesktop.org/wiki/Software/systemd/
      PredictableNetworkInterfaceNames

- Support for older kernels than 2.6.39 is dropped. If you need older kernel
  we recommend you to look into sys-fs/eudev or use local overlay for keeping
  the old ebuild. Remember to also get the distfiles where the patchsets are.
  The upgrade into current stable version of gentoo-sources is recommended.

- The case of separate /usr; if it worked for you with 171 it will continue
  to work for you with 197. We still recommend initramfs with separate /usr
  mounting capabilities because you might need packages like sys-apps/kbd
  (keymaps in /usr) or net-wireless/bluez (possible keyboard) in early boot.

And read every message printed by the emerge of udev and udev-init-scripts
to ensure the system is in order before booting as this news item might
not be complete.

Apologies if this news came too late for you.

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Dirkjan Ochtman]

On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> please review this news item, seems we need one after all

+1, this would have been useful.

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Markos Chandras]

On 23 January 2013 13:32, Dirkjan Ochtman <djc@gentoo.org> wrote:
> On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>> please review this news item, seems we need one after all
>
> +1, this would have been useful.
>

Looks ok but as the news item says, it's a bit too late ...

-- 
Regards,
Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Samuli Suominen]

On 23/01/13 15:34, Markos Chandras wrote:
> On 23 January 2013 13:32, Dirkjan Ochtman <djc@gentoo.org> wrote:
>> On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>>> please review this news item, seems we need one after all
>>
>> +1, this would have been useful.
>>
>
> Looks ok but as the news item says, it's a bit too late ...
>

not for everyone, not everyone upgrades this often, and it's usually the 
servers that get updated last

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Rich Freeman]

On Wed, Jan 23, 2013 at 8:41 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> not for everyone, not everyone upgrades this often, and it's usually the
> servers that get updated last

Agreed, but best to get this out ASAP.

Only question - display-if-installed is set to <9999.  Would it make
sense to make it <198 instead?  Does a new install 5 years from now
really need to see this?

If sent out in advance I'd make it <197, but if we want to catch
anybody who hasn't rebooted yet or who might have missed a detail <198
would handle that.

Rich

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Samuli Suominen]

On 23/01/13 15:44, Rich Freeman wrote:
> On Wed, Jan 23, 2013 at 8:41 AM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>> not for everyone, not everyone upgrades this often, and it's usually the
>> servers that get updated last
>
> Agreed, but best to get this out ASAP.
>
> Only question - display-if-installed is set to <9999.  Would it make
> sense to make it <198 instead?  Does a new install 5 years from now
> really need to see this?
>
> If sent out in advance I'd make it <197, but if we want to catch
> anybody who hasn't rebooted yet or who might have missed a detail <198
> would handle that.
>
> Rich
>

Right, I've used <198 and pushed the item now

I welcome anyone to edit it if it needs editing, just do it

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Philip Webb]

130123 Samuli Suominen wrote:
> please review this news item, seems we need one after all
 ...
> - The need of CONFIG_DEVTMPFS=y in the kernel; need to verify the fstype for
>   possible /dev line in /etc/fstab is devtmpfs (and not, for example, tmpfs)
 ...

I have  2  such lines :

  tmpfs			/tmp		tmpfs		defaults,noatime,mode=1777  0 0
  none			/dev/shm	tmpfs		defaults		0 0

Are either or both involved ? -- if so, what to do ?

-- 
========================,,============================================
SUPPORT     ___________//___,   Philip Webb
ELECTRIC   /] [] [] [] [] []|   Cities Centre, University of Toronto
TRANSIT    `-O----------O---'   purslowatchassdotutorontodotca

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Diego Elio Pettenò]

On 23/01/2013 15:02, Philip Webb wrote:
>> > - The need of CONFIG_DEVTMPFS=y in the kernel; need to verify the fstype for
>> >   possible /dev line in /etc/fstab is devtmpfs (and not, for example, tmpfs)
>  ...
> 
> I have  2  such lines :
> 
>   tmpfs			/tmp		tmpfs		defaults,noatime,mode=1777  0 0
>   none			/dev/shm	tmpfs		defaults		0 0
> 
> Are either or both involved ? -- if so, what to do ?

None are involved. The second column would read /dev if it was involved.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Rich Freeman]

On Wed, Jan 23, 2013 at 9:05 AM, Diego Elio Pettenò
<flameeyes@flameeyes.eu> wrote:
>
> None are involved. The second column would read /dev if it was involved.

The news item doesn't mention what to do if there is no line to mount
/dev.  I don't see one in my fstab, and I simply followed the handbook
(as it was written ~2001), and all announced migration documents
since.  I can't imagine I'm the only one...

System seems to work fine, so I'm not sure how essential that line is.
 The fact that I'm using an initramfs might also have an effect.

Rich

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Diego Elio Pettenò]

On 23/01/2013 16:04, Rich Freeman wrote:
> System seems to work fine, so I'm not sure how essential that line is.
>  The fact that I'm using an initramfs might also have an effect.

AFAICT if you do NOT have a /dev entry you're the best off because the
init script will mount it for you.

I think the same is true of /sys and /proc.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Michael Weber]

Hi,

On 01/23/2013 04:04 PM, Rich Freeman wrote:
> System seems to work fine, so I'm not sure how essential that line is.
>  The fact that I'm using an initramfs might also have an effect.

I'd strongly suggest using CONFIG_DEVTMPFS_MOUNT=y.
and stop worring about udev/openrc.

udev/openrc stopped re-mounting /dev that last year.

Michael
-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Christopher Head]

Are you sure? I have CONFIG_DEVTMPFS_MOUNT disabled, latest stable udev
(197-r3) and openrc (0.11.8), and no /dev line in my fstab, yet my /dev
is still a devtmpfs with a proper set of device nodes.

Chris

On Wed, 23 Jan 2013 17:03:15 +0100
Michael Weber <xmw@gentoo.org> wrote:

> Hi,
> 
> On 01/23/2013 04:04 PM, Rich Freeman wrote:
> > System seems to work fine, so I'm not sure how essential that line
> > is. The fact that I'm using an initramfs might also have an effect.
> 
> I'd strongly suggest using CONFIG_DEVTMPFS_MOUNT=y.
> and stop worring about udev/openrc.
> 
> udev/openrc stopped re-mounting /dev that last year.
> 
> Michael

[gentoo-dev] Re: news item for udev 197-r3 upgrade (yes, I know, it's late)

[»Q«]

On Wed, 23 Jan 2013 13:49:09 -0800
Christopher Head <chead@chead.ca> wrote:

> On Wed, 23 Jan 2013 17:03:15 +0100
> Michael Weber <xmw@gentoo.org> wrote:
> 
> > On 01/23/2013 04:04 PM, Rich Freeman wrote:  
> > > System seems to work fine, so I'm not sure how essential that line
> > > is. The fact that I'm using an initramfs might also have an
> > > effect.  
> > 
> > I'd strongly suggest using CONFIG_DEVTMPFS_MOUNT=y.
> > and stop worring about udev/openrc.
> > 
> > udev/openrc stopped re-mounting /dev that last year.
>
> Are you sure? I have CONFIG_DEVTMPFS_MOUNT disabled, latest stable
> udev (197-r3) and openrc (0.11.8), and no /dev line in my fstab, yet
> my /dev is still a devtmpfs with a proper set of device nodes.

Me too.  It looks like /etc/init.d/udev-mount mounts it if the kernel
hasn't, but I'd like to know more about whatever best practice is.

Re: [gentoo-dev] Re: news item for udev 197-r3 upgrade (yes, I know, it's late)

[Michael Weber]

On 01/24/2013 02:45 AM, »Q« wrote:
> On Wed, 23 Jan 2013 13:49:09 -0800
> Christopher Head <chead@chead.ca> wrote:
> 
>> On Wed, 23 Jan 2013 17:03:15 +0100
>> Michael Weber <xmw@gentoo.org> wrote:
>>> udev/openrc stopped re-mounting /dev that last year.
>>
>> Are you sure? I have CONFIG_DEVTMPFS_MOUNT disabled, latest stable
>> udev (197-r3) and openrc (0.11.8), and no /dev line in my fstab, yet
>> my /dev is still a devtmpfs with a proper set of device nodes.
> 
> Me too.  It looks like /etc/init.d/udev-mount mounts it if the kernel
> hasn't, but I'd like to know more about whatever best practice is.

Mind the _re_-mount,
if udev discovers /dev not being mounted, udev does.
if udev discovers /dev mounted, no mount action is taken.
Earlier versions remounted /dev regardless.

My best practice is to have CONFIG_DEVTMPFS_MOUNT enabled:
I don't use initrd (except for disk encryption) and
I still find my disks during init=/bin/bash recovery.

and it does not hurt, anymore.

-- 
Michael Weber
Gentoo Developer
web: https://xmw.de/
mailto: Michael Weber <xmw@gentoo.org>

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Felix Kuperjans]

Samuli Suominen wrote:
> please review this news item, seems we need one after all

Hello Samuli,

/dev/root is no longer available in this udev version, so people who put
this in their /etc/fstab might end up with an unbootable system.

I suggest including in the news item, that /dev/root must be replaced
with the actual root device or LABEL=..., UUID=... and the like in
/etc/fstab.

Regards,
Felix

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Mike Gilbert]

On Wed, Jan 23, 2013 at 1:29 PM, Felix Kuperjans
<felix@desaster-games.com> wrote:
> Samuli Suominen wrote:
>> please review this news item, seems we need one after all
>
> Hello Samuli,
>
> /dev/root is no longer available in this udev version, so people who put
> this in their /etc/fstab might end up with an unbootable system.
>
> I suggest including in the news item, that /dev/root must be replaced
> with the actual root device or LABEL=..., UUID=... and the like in
> /etc/fstab.
>

fstab is not consulted for mounting the root filesystem, so it doesn't
really matter what you have in there. Either the kernel mounts it
based on the kernel command line, or your initramfs mounts it based on
whatever your /init programs does.

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Rich Freeman]

On Wed, Jan 23, 2013 at 1:42 PM, Mike Gilbert <floppym@gentoo.org> wrote:
> fstab is not consulted for mounting the root filesystem, so it doesn't
> really matter what you have in there. Either the kernel mounts it
> based on the kernel command line, or your initramfs mounts it based on
> whatever your /init programs does.

Keep in mind that for some implementations "whatever your /init
programs does" includes checking fstab.  When I switched to dracut I
discovered this when the system would not boot - my fstab had the
wrong filesystem type for the root (it dated back to the ext2 days)...

Rich

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Mike Gilbert]

On Wed, Jan 23, 2013 at 1:52 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Wed, Jan 23, 2013 at 1:42 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>> fstab is not consulted for mounting the root filesystem, so it doesn't
>> really matter what you have in there. Either the kernel mounts it
>> based on the kernel command line, or your initramfs mounts it based on
>> whatever your /init programs does.
>
> Keep in mind that for some implementations "whatever your /init
> programs does" includes checking fstab.  When I switched to dracut I
> discovered this when the system would not boot - my fstab had the
> wrong filesystem type for the root (it dated back to the ext2 days)...
>

Ah, good to know. I'm used to dealing with my little homegrown
initramfs, where I parse root from the kernel command line in /init.
genkernel does the same thing.

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Rich Freeman]

On Wed, Jan 23, 2013 at 1:56 PM, Mike Gilbert <floppym@gentoo.org> wrote:
>
> Ah, good to know. I'm used to dealing with my little homegrown
> initramfs, where I parse root from the kernel command line in /init.
> genkernel does the same thing.

Yeah, dracut generally "does the right thing" but that generally
assumes that things like fstab are correct.  It still uses the root=
option (I'm not sure if it can work without it - I believe it does
snapshot the fstab at time of creation).  My understanding is that
dracut actually remounts root a few times as it moves along, starting
with the kernel command line, then after setting up mounts in
fstab.sys (which is how you handle a separate /usr), and finally based
on the contents of fstab (which it can't read until it actually has
root mounted).  When it is done the root filesystem is mounted using
all options in /etc/fstab, which is probably a good thing.

That said, it hasn't been without bugs.  I think they're mostly fixed
at this point, but I haven't tried removing all of my workarounds
(mainly around the fact that it wasn't auto-assembling my raid unless
I hardcoded an mdadm -As in a script).

The best thing about dracut though is that it is pretty powerful, with
modules/hooks/etc.  When it wasn't quite working right for me I just
added my own module to it.  It also has the side-benefit of working
well even when mdadm decides to renumber all my md minor device
numbers (tends to happen when booting for CD or whatever - probably
because I'm using older metadata for some of the arrays).

Rich

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Felix Kuperjans]

Mike Gilbert:
> On Wed, Jan 23, 2013 at 1:29 PM, Felix Kuperjans
> <felix@desaster-games.com> wrote:
>> Samuli Suominen wrote:
>>> please review this news item, seems we need one after all
>> Hello Samuli,
>>
>> /dev/root is no longer available in this udev version, so people who put
>> this in their /etc/fstab might end up with an unbootable system.
>>
>> I suggest including in the news item, that /dev/root must be replaced
>> with the actual root device or LABEL=..., UUID=... and the like in
>> /etc/fstab.
>>
> fstab is not consulted for mounting the root filesystem, so it doesn't
> really matter what you have in there. Either the kernel mounts it
> based on the kernel command line, or your initramfs mounts it based on
> whatever your /init programs does.
Well, *if* a line with /dev/root is present in /etc/fstab, the system
does not boot up properly (tested it right now).
I always though such a line in /etc/fstab is needed so that fsck is run
on the root filesystem...

Removing the line completely boots up fine, but the filesystem has not
been fscked on boot.

Regards,
Felix

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Samuli Suominen]

On 23/01/13 21:06, Felix Kuperjans wrote:
> Mike Gilbert:
>> On Wed, Jan 23, 2013 at 1:29 PM, Felix Kuperjans
>> <felix@desaster-games.com> wrote:
>>> Samuli Suominen wrote:
>>>> please review this news item, seems we need one after all
>>> Hello Samuli,
>>>
>>> /dev/root is no longer available in this udev version, so people who put
>>> this in their /etc/fstab might end up with an unbootable system.
>>>
>>> I suggest including in the news item, that /dev/root must be replaced
>>> with the actual root device or LABEL=..., UUID=... and the like in
>>> /etc/fstab.
>>>
>> fstab is not consulted for mounting the root filesystem, so it doesn't
>> really matter what you have in there. Either the kernel mounts it
>> based on the kernel command line, or your initramfs mounts it based on
>> whatever your /init programs does.
> Well, *if* a line with /dev/root is present in /etc/fstab, the system
> does not boot up properly (tested it right now).
> I always though such a line in /etc/fstab is needed so that fsck is run
> on the root filesystem...
>
> Removing the line completely boots up fine, but the filesystem has not
> been fscked on boot.

I don't think we ever instructed users for adding such line... if we 
did, I'll eat my words.
So, I don't think it's necessary to instruct them away from it either, 
never seen such fstab line.

Maybe I'm too naive.

- Samuli

[gentoo-dev] Re: news item for udev 197-r3 upgrade (yes, I know, it's late)

[Duncan]

Samuli Suominen posted on Thu, 24 Jan 2013 04:04:19 +0200 as excerpted:

> On 23/01/13 21:06, Felix Kuperjans wrote:
>>> On Wed, Jan 23, 2013 at 1:29 PM, Felix Kuperjans
>>> <felix@desaster-games.com> wrote:
>>>> Samuli Suominen wrote:
>>>>> please review this news item
>>>>
>>>> /dev/root is no longer available in this udev version
>>>>
>>>> I suggest including in the news item, that /dev/root must be replaced
>>>> with the actual root device or LABEL=..., UUID=... and the like in
>>>> /etc/fstab.
>>>>
>> Well, *if* a line with /dev/root is present in /etc/fstab, the system
>> does not boot up properly (tested it right now).
>> I always though such a line in /etc/fstab is needed so that fsck is run
>> on the root filesystem...
>>
>> Removing the line completely boots up fine, but the filesystem has not
>> been fscked on boot.
> 
> I don't think we ever instructed users for adding such line... if we
> did, I'll eat my words.
> So, I don't think it's necessary to instruct them away from it either,
> never seen such fstab line.

Well technically, we used (and still use, see below) the uppercase 
/dev/ROOT, with instructions documenting what to replace it with.  But 
some users apparently simply lowercased that ROOT, and for years it "just 
worked". (Below output edited slightly for posting. $>> indicates the 
shell prompt.):

$>>equery b fstab
 * Searching for fstab ... 
sys-apps/baselayout-2.2 (/usr/share/baselayout/fstab)

$>>grep -i /dev/root /usr/share/baselayout/fstab
/dev/ROOT           /            ext3         noatime         0 1

$>>

[TLDR folks can stop there.  The rest is historic observation, arguably 
interesting, admittedly ranty, but not vital.]

Years ago (remember, my first successful gentoo install was 2004.1), the 
fstab example file found in /usr/share/baselayout/fstab was packaged as 
/etc/fstab directly.  Now, the handbook of the era took great pains to 
guide people thru editing it appropriately, saying the ALLCAPS entries 
were intended to be replaced as appropriate for the individual install, 
AND people were expected to actually use etc-update or the like for its 
intended purpose, so people weren't /supposed/ to have it simply 
overwritten.

Unfortunately, a lot of folks (<sarcasm> yes, gentooers, could you 
believe it? </sarcasm>) couldn't read instructions properly, and I'd say 
gentoo-user averaged at least two threads a month from folks who had 
killed their fstab with an update and a simple etc-update direct-replace, 
or couldn't get gentoo self-booting in the first place due to not editing 
the file at all, despite the instructions to do so.

And I'm sure many more read the threads on the list and in the forums, 
and didn't make a mistake they otherwise would have...  I know I 
certainly did.  I've said before that I was actively helping people on 
the lists well before I got my own gentoo system up and running.  (Turned 
out there was a bug in at least amd64's 2004.0 handling of the then still 
new NPTL, that I ran into somewhere along the way.  I don't know what the 
fix was, but 2004.1 installed just fine from stage-1, so it must have 
been fixed...  As a result, I was active on the lists for several months 
before I actually got my own install working, by which time I knew the 
documentation pretty well, given the help I was giving to others based on 
it the whole time.)


Some of us were actually rather sad to see the file moved to /usr/share, 
since with it working as it did, gentoo newbies tended to learn to 
actually pay attention to the instructions reasonably early on, after 
being pointed to them.  As I've said before, it was well known and 
frequently posted in the user lists back then that gentoo wasn't a 
handholding distribution.  Gentooers, as sysadmins of their own systems, 
were expected to take responsibility for them, reading instructions, 
etc.  If they preferred not to or couldn't learn to do so after a couple 
mistakes like that, well, there were (and are still) other distributions 
more suited to them, and in all seriousness, not to put people down but 
simply to recommend a distro that would be a better fit for them, it 
wasn't rare at all to see a recommendation that people seriously assess 
whether they wanted to take on that responsibility, and if not, they 
really should be on a different distro, as gentoo definitely wasn't for 
them!


So a /dev/ROOT entry was and actually still is part of the default fstab, 
it's just that the baselayout package places that fstab elsewhere, these 
days.

Evidently, some users saw the example and simply lowercased that 
/dev/ROOT entry into /dev/root, despite the handbook specifically 
recommending replacing it with the appropriate /dev/[sh]daX parameter, 
and because of the kernel/devfs/udev entry for that, it "just worked".

Now that long stale entry is beginning to cause issues.


Meanwhile, if we still shipped /etc/fstab directly, as back then, I 
expect we'd have way less troubles with people not paying attention to 
instructions and trying to foist their responsibilities as sysadmin onto 
gentoo devs, as they'd either learn how vital it is early on, or 
ultimately go looking for a distribution more appropriately matched to 
their needs.  IMO the mistake we've made is that we TRY TOO HARD to 
coddle users, doing a good enough job of it most of the time that they 
expect it ALL the time now.  But as I've said before, gentoo's not ABOUT 
handholding/babysitting, or at least it wasn't.  If that's what people 
want/need/expect, no shame in admitting it.  Rather, there's pride in the 
fact that a user could intelligently assess the situation and make a 
reasonable decision that gentoo is NOT for them.  There's all sorts of 
distros standing in /line/ to fill that coddling spot, and it's something 
gentoo simply cannot and will not ever be good at, so why do we try so 
hard, only to let people down at the worst time because we're effectively 
promising them a coddling service we can't reliably deliver?


Yes, deliver the documentation.  Print a warning in pkg_pretend and in 
pkg_postinst as well.  Maybe even do a news item if we think it's worth 
the trouble.  But after that, RESOLVED/READTHEDOCS.  It'll be worse for a 
few months, but soon enough, we should have far fewer bugs of that sort, 
as people will have learned.


And yes, that may seem a rather harsh policy.  But gentoo was attracting 
users in droves back then and was a seriously up and coming distro.  Now 
look at it.  We have are nitch, yes, but we're afraid to properly claim 
it and unhesitatingly recommend that people look elsewhere if they find 
it inappropriate for them.  We've lost the identity that make gentoo what 
it /was/, and in the process, we've simply become one among many, an 
"also-ran".

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: news item for udev 197-r3 upgrade (yes, I know, it's late)

[Dale]

[-- Attachment #1: Type: text/plain, Size: 2822 bytes --]

Duncan wrote:
> Samuli Suominen posted on Thu, 24 Jan 2013 04:04:19 +0200 as excerpted:
>
>> > On 23/01/13 21:06, Felix Kuperjans wrote:
>>>> >>> On Wed, Jan 23, 2013 at 1:29 PM, Felix Kuperjans
>>>> >>> <felix@desaster-games.com> wrote:
>>>>> >>>> Samuli Suominen wrote:
>>>>>> >>>>> please review this news item
>>>>> >>>>
>>>>> >>>> /dev/root is no longer available in this udev version
>>>>> >>>>
>>>>> >>>> I suggest including in the news item, that /dev/root must be replaced
>>>>> >>>> with the actual root device or LABEL=..., UUID=... and the like in
>>>>> >>>> /etc/fstab.
>>>>> >>>>
>>> >> Well, *if* a line with /dev/root is present in /etc/fstab, the system
>>> >> does not boot up properly (tested it right now).
>>> >> I always though such a line in /etc/fstab is needed so that fsck is run
>>> >> on the root filesystem...
>>> >>
>>> >> Removing the line completely boots up fine, but the filesystem has not
>>> >> been fscked on boot.
>> > 
>> > I don't think we ever instructed users for adding such line... if we
>> > did, I'll eat my words.
>> > So, I don't think it's necessary to instruct them away from it either,
>> > never seen such fstab line.
> Well technically, we used (and still use, see below) the uppercase 
> /dev/ROOT, with instructions documenting what to replace it with.  But 
> some users apparently simply lowercased that ROOT, and for years it "just 
> worked". (Below output edited slightly for posting. $>> indicates the 
> shell prompt.):
>
> $>>equery b fstab
>  * Searching for fstab ... 
> sys-apps/baselayout-2.2 (/usr/share/baselayout/fstab)
>
> $>>grep -i /dev/root /usr/share/baselayout/fstab
> /dev/ROOT           /            ext3         noatime         0 1
>
> $>>
>
> [TLDR folks can stop there.  The rest is historic observation, arguably 
> interesting, admittedly ranty, but not vital.]
>
> Years ago (remember, my first successful gentoo install was 2004.1), the 
> fstab example file found in /usr/share/baselayout/fstab was packaged as 
> /etc/fstab directly.  Now, the handbook of the era took great pains to 
> guide people thru editing it appropriately, saying the ALLCAPS entries 
> were intended to be replaced as appropriate for the individual install, 
> AND people were expected to actually use etc-update or the like for its 
> intended purpose, so people weren't /supposed/ to have it simply 
> overwritten.


I started using Gentoo in the 1.4 days.  I to changed /dev/ROOT to
/dev/root and added the proper locations/options for root and every
other mount point I have.  This is the first I have heard of fstab not
needing the root mount line.  If this is a change, someone needs to tell
the users, even us old timers.  ;-)

Dale

:-)  :-) 

-- 
I am only responsible for what I said ... Not for what you understood or how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 5190 bytes --]

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1255 bytes --]

On Wed, Jan 23, 2013 at 08:06:48PM +0100, Felix Kuperjans wrote:
> Mike Gilbert:
> > On Wed, Jan 23, 2013 at 1:29 PM, Felix Kuperjans
> > <felix@desaster-games.com> wrote:
> >> Samuli Suominen wrote:
> >>> please review this news item, seems we need one after all
> >> Hello Samuli,
> >>
> >> /dev/root is no longer available in this udev version, so people who put
> >> this in their /etc/fstab might end up with an unbootable system.
> >>
> >> I suggest including in the news item, that /dev/root must be replaced
> >> with the actual root device or LABEL=..., UUID=... and the like in
> >> /etc/fstab.
> >>
> > fstab is not consulted for mounting the root filesystem, so it doesn't
> > really matter what you have in there. Either the kernel mounts it
> > based on the kernel command line, or your initramfs mounts it based on
> > whatever your /init programs does.
> Well, *if* a line with /dev/root is present in /etc/fstab, the system
> does not boot up properly (tested it right now).
> I always though such a line in /etc/fstab is needed so that fsck is run
> on the root filesystem...

That was an example in the fstab in the stages, but the handbook always
told you to replace /dev/root with the reference to the specific root
device.

William


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Michael Haubenwallner]

On 01/23/13 19:29, Felix Kuperjans wrote:
> Samuli Suominen wrote:
>> please review this news item, seems we need one after all
> 
> /dev/root is no longer available in this udev version, so people who put
> this in their /etc/fstab might end up with an unbootable system.
> 
> I suggest including in the news item, that /dev/root must be replaced
> with the actual root device or LABEL=..., UUID=... and the like in
> /etc/fstab.

I've recently upgraded some server from kernel-2.6.28 to kernel-3.5.7 and
encountered that the root-device was renamed from /dev/cciss/c0d0p1 to
/dev/sda1 due to some kernel driver change (took me a while to find out).
I'm not using genkernel or any initramfs, nor do I have separate /usr.

The only way I've found to keep the system bootable with both kernels
(for the upgrade process until the new kernel config was good enough)
was to replace /dev/cciss/c0d0p1 by /dev/root in /etc/fstab.

How would this be done when there is no /dev/root any more?

So yes, please include the /dev/root drop (at least) in the news item.

/haubi/

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Rich Freeman]

On Thu, Jan 24, 2013 at 5:02 AM, Michael Haubenwallner <haubi@gentoo.org> wrote:
>
> The only way I've found to keep the system bootable with both kernels
> (for the upgrade process until the new kernel config was good enough)
> was to replace /dev/cciss/c0d0p1 by /dev/root in /etc/fstab.
>
> How would this be done when there is no /dev/root any more?

I would think that you could just use LABEL=, UUID=, or /dev/disk/by-uuid/foo.

Those device names only work on the kernel boot line if you're using
an initramfs, but I suspect that they'd work fine in fstab regardless.
 Situations like this of course are one of the reasons initramfs is so
popular - they can be far smarter about finding the root filesystem.

Disclaimer: I'm using an initramfs, so I can't vouch for what happens
without one.

Rich

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Michael Orlitzky]

On 01/24/13 05:02, Michael Haubenwallner wrote:
> 
> I've recently upgraded some server from kernel-2.6.28 to kernel-3.5.7 and
> encountered that the root-device was renamed from /dev/cciss/c0d0p1 to
> /dev/sda1 due to some kernel driver change (took me a while to find out).
> I'm not using genkernel or any initramfs, nor do I have separate /usr.
> 
> The only way I've found to keep the system bootable with both kernels
> (for the upgrade process until the new kernel config was good enough)
> was to replace /dev/cciss/c0d0p1 by /dev/root in /etc/fstab.
> 
> How would this be done when there is no /dev/root any more?
> 

These are the Compaq SmartArray controllers (usually found in HP
Proliants). They used to have their own block driver, but these days
they're just grouped with the rest of the SCSI drives.

The old driver:

  Block Devices -> BLK_CPQ_CISS_DA

The new one is under,

  SCSI device support -> SCSI low-level drivers -> SCSI_HPSA

  This driver supports HP Smart Array Controllers (circa 2009).
  It is a SCSI alternative to the cciss driver, which is a block
  driver.  Anyone wishing to use HP Smart Array controllers who
  would prefer the devices be presented to linux as SCSI devices,
  rather than as generic block devices should say Y here.

The HPSA driver does *not* work on older Proliants, so I can only assume
that HPSA is receiving active maintenance while the old block driver is
not. Nevertheless, if the block driver worked for you in an old kernel,
you could simply disable HPSA on the new one.

When the time comes that you need to boot two newish kernels, you can
re-enable HPSA and update fstab to use the new name.

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Michael Haubenwallner]

On 01/24/13 16:49, Michael Orlitzky wrote:
> On 01/24/13 05:02, Michael Haubenwallner wrote:
>>
>> I've recently upgraded some server from kernel-2.6.28 to kernel-3.5.7 and
>> encountered that the root-device was renamed from /dev/cciss/c0d0p1 to
>> /dev/sda1 due to some kernel driver change (took me a while to find out).
>> I'm not using genkernel or any initramfs, nor do I have separate /usr.
>>
>> The only way I've found to keep the system bootable with both kernels
>> (for the upgrade process until the new kernel config was good enough)
>> was to replace /dev/cciss/c0d0p1 by /dev/root in /etc/fstab.
>>
>> How would this be done when there is no /dev/root any more?
> 
> These are the Compaq SmartArray controllers (usually found in HP
> Proliants). They used to have their own block driver, but these days
> they're just grouped with the rest of the SCSI drives.

Yep, this is a HP DL380 G6, and lspci says:
04:00.0 RAID bus controller: Hewlett-Packard Company Smart Array G6 controllers (rev 01)

> The old driver:
> 
>   Block Devices -> BLK_CPQ_CISS_DA
> 
> The new one is under,
> 
>   SCSI device support -> SCSI low-level drivers -> SCSI_HPSA
 
> The HPSA driver does *not* work on older Proliants, so I can only assume
> that HPSA is receiving active maintenance while the old block driver is
> not. Nevertheless, if the block driver worked for you in an old kernel,
> you could simply disable HPSA on the new one.

Well, I'm pretty sure to have started with BLK_CPQ_CISS_DA=y in the new kernel
config, but this driver doesn't seem to feel responsible for that controller
any more - or what else could have make me wonder where /dev/cciss/* has gone?
Finally I went along [1] to identify SCSI_HPSA as the correct driver.
[1] http://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/ch08s02.html

> When the time comes that you need to boot two newish kernels, you can
> re-enable HPSA and update fstab to use the new name.

So this didn't work out IIRC - but I won't retest that now. For the curious:
  $ cat /sys/bus/pci/devices/0000\:04\:00.0/vendor 
  0x103c
  $ cat /sys/bus/pci/devices/0000\:04\:00.0/device 
  0x323a

/haubi/

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Diego Elio Pettenò]

On 24/01/2013 20:19, Michael Haubenwallner wrote:
> Yep, this is a HP DL380 G6, and lspci says:
> 04:00.0 RAID bus controller: Hewlett-Packard Company Smart Array G6 controllers (rev 01)

Hrm just for reference, I've got a number of G6s and they all work fine
with the old cciss — although they do work better with HPSA.

It's the same RAID bus controller there.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 270 bytes --]

El mié, 23-01-2013 a las 15:14 +0200, Samuli Suominen escribió:
> please review this news item, seems we need one after all

Why don't you drop "~" from:
        CONFIG_CHECK="~DEVTMPFS"

to ensure people really changes it in their kernel and prevent breakage?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Samuli Suominen]

On 23/01/13 23:21, Pacho Ramos wrote:
> El mié, 23-01-2013 a las 15:14 +0200, Samuli Suominen escribió:
>> please review this news item, seems we need one after all
>
> Why don't you drop "~" from:
>          CONFIG_CHECK="~DEVTMPFS"
>
> to ensure people really changes it in their kernel and prevent breakage?
>

That won't work because the host you run the package isn't necessarily 
same as the one you are building it on
The build host doesn't need DEVTMPFS

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Pacho Ramos]

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

El mié, 23-01-2013 a las 23:45 +0200, Samuli Suominen escribió:
> On 23/01/13 23:21, Pacho Ramos wrote:
> > El mié, 23-01-2013 a las 15:14 +0200, Samuli Suominen escribió:
> >> please review this news item, seems we need one after all
> >
> > Why don't you drop "~" from:
> >          CONFIG_CHECK="~DEVTMPFS"
> >
> > to ensure people really changes it in their kernel and prevent breakage?
> >
> 
> That won't work because the host you run the package isn't necessarily 
> same as the one you are building it on
> The build host doesn't need DEVTMPFS
> 
> 

And couldn't that be done at install time? I mean, you can build and
package new udev but installation will die if udev is going to be
installed on a system without DEVTMPFS

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Francesco Riosa]

[-- Attachment #1: Type: text/plain, Size: 950 bytes --]

2013/1/23 Pacho Ramos <pacho@gentoo.org>

> El mié, 23-01-2013 a las 23:45 +0200, Samuli Suominen escribió:
> > On 23/01/13 23:21, Pacho Ramos wrote:
> > > El mié, 23-01-2013 a las 15:14 +0200, Samuli Suominen escribió:
> > >> please review this news item, seems we need one after all
> > >
> > > Why don't you drop "~" from:
> > >          CONFIG_CHECK="~DEVTMPFS"
> > >
> > > to ensure people really changes it in their kernel and prevent
> breakage?
> > >
> >
> > That won't work because the host you run the package isn't necessarily
> > same as the one you are building it on
> > The build host doesn't need DEVTMPFS
> >
> >
>
> And couldn't that be done at install time? I mean, you can build and
> package new udev but installation will die if udev is going to be
> installed on a system without DEVTMPFS
>

Pacho, see the message from robbat2 titled "RFC: CONFIG_CHECK_FATAL, making
CONFIG_CHECKS fatal by default"

[-- Attachment #2: Type: text/html, Size: 1642 bytes --]

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 23/01/13 05:21 PM, Pacho Ramos wrote:
> El mié, 23-01-2013 a las 23:45 +0200, Samuli Suominen escribió:
>> On 23/01/13 23:21, Pacho Ramos wrote:
>>> El mié, 23-01-2013 a las 15:14 +0200, Samuli Suominen
>>> escribió:
>>>> please review this news item, seems we need one after all
>>> 
>>> Why don't you drop "~" from: CONFIG_CHECK="~DEVTMPFS"
>>> 
>>> to ensure people really changes it in their kernel and prevent
>>> breakage?
>>> 
>> 
>> That won't work because the host you run the package isn't
>> necessarily same as the one you are building it on The build host
>> doesn't need DEVTMPFS
>> 
>> 
> 
> And couldn't that be done at install time? I mean, you can build
> and package new udev but installation will die if udev is going to
> be installed on a system without DEVTMPFS


There's too many variables, though -- firstly, /usr/src/linux/.config
may not match /proc/config.gz.  And even if both are checked there's
nothing to say that the next boot is going to use a kernel that
matches either one.

Realistically, what udev needs is something at runtime to report the
error and temporarily bypass the requirement, because this really is a
runtime issue instead of something that can be properly controlled or
contained at build/install time.



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlEBVgIACgkQ2ugaI38ACPBzfQD/ZAE4UHgQJ3zB9wuVkCcPAhXS
21C+7k+mjS2YSg8BgqcA/0iv12JreFnvmybX2H8a/g8BBKm30+Xbt1+bGC+rijYN
=qA5Y
-----END PGP SIGNATURE-----

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Dirkjan Ochtman]

On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
> please review this news item, seems we need one after all

Here's a crazy idea: can we patch our kernel to let "make oldconfig"
default CONFIG_DEVTMPFS to true? Or better yet, request that this is
changed upstream?

Also, after installing udev-197, are there any negative consequences
to just downgrading to -171 again?

Cheers,

Dirkjan

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Rich Freeman]

On Fri, Jan 25, 2013 at 4:19 AM, Dirkjan Ochtman <djc@gentoo.org> wrote:
> On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen <ssuominen@gentoo.org> wrote:
>> please review this news item, seems we need one after all
>
> Here's a crazy idea: can we patch our kernel to let "make oldconfig"
> default CONFIG_DEVTMPFS to true? Or better yet, request that this is
> changed upstream?

I could see making that the default if there is no .config file
present and a new one is being created, and perhaps upstream would
support that since udev is popular.  However, make oldconfig is
usually used when you have a .config file and you just want to update
it.  In that case I don't think we should be changing settings - what
if a user doesn't want this set?  They'd have to remember to manually
unset it every single time they compile a new kernel, as we'd be
"helpfully" changing it back.

Not everybody uses udev.

Somebody already brought this up, but the main thing users need is
notice for changes like this, and warnings.  By all means mention in
the warnings that their systems will be unbootable.  And by all means
let's cut down on spurious elog traffic otherwise.

Oh, here's another thought - when elog traffic gets sent out as email
can the subject line be changed based on the most serious message in
the log?  That is, can a log-only email be distinguished from one that
has a warning in it?

Rich

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Dirkjan Ochtman]

On Fri, Jan 25, 2013 at 12:59 PM, Rich Freeman <rich0@gentoo.org> wrote:
> I could see making that the default if there is no .config file
> present and a new one is being created, and perhaps upstream would
> support that since udev is popular.  However, make oldconfig is
> usually used when you have a .config file and you just want to update
> it.  In that case I don't think we should be changing settings - what
> if a user doesn't want this set?  They'd have to remember to manually
> unset it every single time they compile a new kernel, as we'd be
> "helpfully" changing it back.

Ah yeah, I mistakenly assumed that DEVTMPFS was a relatively new option.

Cheers,

Dirkjan

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Ian Stakenvicius]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 25/01/13 04:19 AM, Dirkjan Ochtman wrote:
> On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen
> <ssuominen@gentoo.org> wrote:
>>> 
> Also, after installing udev-197, are there any negative
> consequences to just downgrading to -171 again?
> 

Depends on whether or not you rebuilt the rdeps -- udev-197 provides
libudev.so.1 while udev-171 provides libudev.so.0 , so there's
breakage on stuffs like lvm2 and other ebuilds that link to libudev


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlECk+IACgkQ2ugaI38ACPDiPQEArL3Abb2QWi+/uM31+2Nr2wmY
GnNGk0ScrqjMA0YuH5gBAI2y8hnzVP/99GwqlwRBnfOav/IftQMSEDzwkKIJhLi4
=EUug
-----END PGP SIGNATURE-----

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Dirkjan Ochtman]

On Fri, Jan 25, 2013 at 3:17 PM, Ian Stakenvicius <axs@gentoo.org> wrote:
> Depends on whether or not you rebuilt the rdeps -- udev-197 provides
> libudev.so.1 while udev-171 provides libudev.so.0 , so there's
> breakage on stuffs like lvm2 and other ebuilds that link to libudev

Even so, I could downgrade and revdep-rebuild after that, and it
should Just Work, right?

IIRC, I had nothing rebuilt by revdep-rebuilt after merging udev-197,
so maybe this is not an issue for me.

Maybe you could add a note about this to the news item?

Cheers,

Dirkjan

Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)

[Diego Elio Pettenò]

On 25/01/2013 15:23, Dirkjan Ochtman wrote:
> Even so, I could downgrade and revdep-rebuild after that, and it
> should Just Work, right?

Yes and no — you're safer if you get rid of the .so.1 first then
revdep-rebuild (if you're using preserved-libs). I know there should be
support for ldconfig NOT to re-create the links to the highest library
by default for .so files, but I wouldn't bet on it as I've seen other
things causing ldconfig to run and overwrite them outside Portage.

-- 
Diego Elio Pettenò — Flameeyes
flameeyes@flameeyes.eu — http://blog.flameeyes.eu/