FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 03-11-2012, 01:27 AM
William Hubbs
 
Default newsitem: unmasking udev-181

All,

here is the udev 181 unmasking news item.

If all goes well, this will be committed to the tree on 3/14 UTC.

William
Title: udev-181 unmasking
Author: William Hubbs <williamh@gentoo.org>
Content-Type: text/plain
Posted: 2012-03-14
Revision: 1
News-Item-Format: 1.0
Display-If-Installed: <sys-fs/udev-181

udev-181 is being unmasked the same day this newsitem is being published.

This news item is to inform you that once you upgrade to a version of
udev >=181, if you have /usr on a separate partition, you must boot your
system with an initramfs which pre-mounts /usr.

An initramfs which does this is created by >=sys-kernel/genkernel-3.4.25 or
>=sys-kernel/dracut-017-r1. If you do not want to use these tools, be
sure any initramfs you create pre-mounts /usr.

Also, if you are using OpenRC, you must upgrade to >= openrc-0.9.9.

For more information on why this has been done, see the following url:
http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken
 
Old 03-11-2012, 01:53 AM
Rich Freeman
 
Default newsitem: unmasking udev-181

On Sat, Mar 10, 2012 at 9:27 PM, William Hubbs <williamh@gentoo.org> wrote:
> here is the udev 181 unmasking news item.
>
> If all goes well, this will be committed to the tree *on 3/14 UTC.

I guess this might be OK for unstable, but before this goes stable we
really need to improve the docs around this. As far as I can tell
neither the genkernel nor dracut docs have specific instructions about
how to handle mounting /usr. Since having a separate /usr is often
the result of having a more complex configuration (nfs, lvm, mdraid,
etc), instructions explaining how things work and how to handle
variations is pretty important. Perhaps genkernel automagically does
the right thing in some cases, but I know that dracut does not unless
you properly configure it. I doubt either tool will handle more
complex situations without some scripting.

I'm not really asking for automation here - just documentation and
reasonable stability in how things work.

Again, this is likely more of a concern before this is stabilized.
However, knowing what I went through to get my bind-mounted /usr on
LVM+mdraid working with dracut, I can imagine that any unstable users
with tricky setups could face a fun weekend.

Perhaps a suggestion for the news item. I'd recommend that anybody
who needs an initramfs to mount /usr get that working BEFORE they
upgrade udev. This situation is a heck of a lot easier to figure out
if the system still can be booted when the initramfs doesn't work.

Rich
 
Old 03-11-2012, 02:28 AM
Luca Barbato
 
Default newsitem: unmasking udev-181

On 3/10/12 6:53 PM, Rich Freeman wrote:

neither the genkernel nor dracut docs have specific instructions about


I guess we could pour more effort in getting dracut more easy to use
and/or try to figure out which are the items that should be moved to /
and fix the remaining ones...


lu
 
Old 03-11-2012, 02:44 AM
Dale
 
Default newsitem: unmasking udev-181

Rich Freeman wrote:
> On Sat, Mar 10, 2012 at 9:27 PM, William Hubbs <williamh@gentoo.org> wrote:
>> here is the udev 181 unmasking news item.
>>
>> If all goes well, this will be committed to the tree on 3/14 UTC.
>
> I guess this might be OK for unstable, but before this goes stable we
> really need to improve the docs around this. As far as I can tell
> neither the genkernel nor dracut docs have specific instructions about
> how to handle mounting /usr. Since having a separate /usr is often
> the result of having a more complex configuration (nfs, lvm, mdraid,
> etc), instructions explaining how things work and how to handle
> variations is pretty important. Perhaps genkernel automagically does
> the right thing in some cases, but I know that dracut does not unless
> you properly configure it. I doubt either tool will handle more
> complex situations without some scripting.
>
> I'm not really asking for automation here - just documentation and
> reasonable stability in how things work.
>
> Again, this is likely more of a concern before this is stabilized.
> However, knowing what I went through to get my bind-mounted /usr on
> LVM+mdraid working with dracut, I can imagine that any unstable users
> with tricky setups could face a fun weekend.
>
> Perhaps a suggestion for the news item. I'd recommend that anybody
> who needs an initramfs to mount /usr get that working BEFORE they
> upgrade udev. This situation is a heck of a lot easier to figure out
> if the system still can be booted when the initramfs doesn't work.
>
> Rich
>
>


+1

Dale

:-) :-)

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

Miss the compile output? Hint:
EMERGE_DEFAULT_OPTS="--quiet-build=n"
 
Old 03-11-2012, 02:50 AM
Rich Freeman
 
Default newsitem: unmasking udev-181

On Sat, Mar 10, 2012 at 10:28 PM, Luca Barbato <lu_zero@gentoo.org> wrote:
> I guess we could pour more effort in getting dracut more easy to use and/or
> try to figure out which are the items that should be moved to / and fix the
> remaining ones...
>

Well, I'm trying not to take sides in that war. Unless we want to
patch the living daylights out of upsteam it seems almost moot.

I'm not even so much interested in making dracut easy to use. I'd
just appreciate it if there were even a single sentence written on
each of its modules and options, let alone some kind of coherent guide
to how to make it all work.

There is a guide out there, but it hasn't really kept pace with the
very rapidly evolving tool, and it doesn't really cover all the
nuances.

Another useful thing would be to update our official RAID+LVM guide so
that when you're done following it your system will boot.

Rich
 
Old 03-11-2012, 04:12 AM
Luca Barbato
 
Default newsitem: unmasking udev-181

On 3/10/12 7:50 PM, Rich Freeman wrote:

Well, I'm trying not to take sides in that war. Unless we want to
patch the living daylights out of upsteam it seems almost moot.


It is not a matter about siding. If our boot process requires glib or
dbus we are sore idiots if we aren't either of them available by that time.


Luckily we do not *need* that at boot time but we can use daemons
leveraging it after the file system hosting them is mounted.


Same could be said for udev rules. If udev by itself can survive on the
bare / till we mount our filesystem we are fine, if it does need to
access the pci-id database we have either to provide it in a way or another.



I'm not even so much interested in making dracut easy to use. I'd
just appreciate it if there were even a single sentence written on
each of its modules and options, let alone some kind of coherent guide
to how to make it all work.


That would be great.


There is a guide out there, but it hasn't really kept pace with the
very rapidly evolving tool, and it doesn't really cover all the
nuances.


Ouch.


Another useful thing would be to update our official RAID+LVM guide so
that when you're done following it your system will boot.


indeed.
 
Old 03-11-2012, 04:48 AM
Duncan
 
Default newsitem: unmasking udev-181

Rich Freeman posted on Sat, 10 Mar 2012 21:53:25 -0500 as excerpted:

> On Sat, Mar 10, 2012 at 9:27 PM, William Hubbs <williamh@gentoo.org>
> wrote:
>> here is the udev 181 unmasking news item.
>>
>> If all goes well, this will be committed to the tree *on 3/14 UTC.
>
> I guess this might be OK for unstable, but before this goes stable we
> really need to improve the docs around this.

Definitely agreed. Before it's unmasked to stable, there should be a
nice step-by-step upgrade guide. In general, ~arch users are expected to
be able to take care of themselves to a large degree, while stable users,
pretty much simply need to know how to follow the step-by-step
instructions in the handbook well enough to get a running system. Thus,
for critical upgrades that are likely to leave the system unbootable if
they're not handled correctly, they need and gentoo has in the past
normally provided, a nice step-by-step upgrade guide.

It's a tall order in some ways, and I /think/ the baselayout-2/openrc
upgrade broke that tradition to some extent as it was unmasked to stable
before the docs were done properly, but that's in the past now and should
remain the exception.

That is, unless we're prepared to change the definition of stable (or
even simply get rid of it entirely, referring people that need it to arch
or some other distro), and if we're doing that, there really should be a
discussion about it and a proper decision, council or even full active
dev vote, story on the gentoo.org front page, etc. As I run ~arch
anyway, I personally would certainly not oppose such an idea, but we
shouldn't just let gentoo slip into it; if it's going to happen, it
should be a deliberate decision taken after a discussion on the merits.

> I'm not really asking for automation here - just documentation and
> reasonable stability in how things work.

Exactly.

> Again, this is likely more of a concern before this is stabilized.

Right, but as it's headed for ~arch now, this is the time to get planning
for stabilization.

> However, knowing what I went through to get my bind-mounted /usr on
> LVM+mdraid working with dracut, I can imagine that any unstable users
> with tricky setups could face a fun weekend.

Yes, indeed. I'd actually suggest a 1-2 week advance notice news item
for exactly that reason, even for ~arch, perhaps /especially/ for ~arch,
since the nice upgrade guide isn't there yet. Yes, that means delaying
the unmasking at this point, but it can be done well, or it can be done
haphazardly.

Actually, ideally, there'd be a good start on the upgrade guide for ~arch
as well, tho it wouldn't need to be perfect. Then ~arch users could be
more effectively encouraged to do what they're /supposed/ to do, report
bugs when things don't go well, so they can be fixed before unmasking to
stable, for the upgrade guide that goes along with it, too! =:^)

But that's simply the ideal. ~arch users should be able to take care of
themselves, given a few days notice, anyway. Using them to help debug
the upgrade doc at the same time is indeed the ideal, but regardless of
that, arch users should still get by, the chance to use them to debug
corner-cases in the docs before unmasking to stable, is just lost.

> Perhaps a suggestion for the news item. I'd recommend that anybody who
> needs an initramfs to mount /usr get that working BEFORE they upgrade
> udev. This situation is a heck of a lot easier to figure out if the
> system still can be booted when the initramfs doesn't work.

Yes. This is another reason to put the news item out there a couple
weeks early, with the "strong recommendation" for those with a separate
/usr to get the initramfs up and working BEFORE udev-181 is unmasked, and
a couple weeks lead time on the news item, in ordered to let them do it.

IMO, I'm not the package maintainer or the arch folks that will be doing
the stabilizing, nor the one that will have to deal with the bugs, etc.
So just IMO.

--
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
 
Old 03-11-2012, 05:49 AM
Ryan Hill
 
Default newsitem: unmasking udev-181

On Sat, 10 Mar 2012 20:27:06 -0600
William Hubbs <williamh@gentoo.org> wrote:

> An initramfs which does this is created by >=sys-kernel/genkernel-3.4.25 or
> >=sys-kernel/dracut-017-r1. If you do not want to use these tools, be
> sure any initramfs you create pre-mounts /usr.

We should really have some documentation on how to create a minimal initramfs
that mounts /usr (if we don't already, I haven't looked). I've never needed
one until now and don't have the foggiest idea how it's done. I can't be the
only one.

Also, the handbook still endorses having a separate partition for /usr and
includes it in the example setup. This should be changed now, not when
stabilization time comes.


--
fonts, gcc-porting
toolchain, wxwidgets
@ gentoo.org
 
Old 03-11-2012, 07:06 AM
Neil Bothwick
 
Default newsitem: unmasking udev-181

On Sat, 10 Mar 2012 20:27:06 -0600, William Hubbs wrote:

> If all goes well, this will be committed to the tree on 3/14 UTC.

A major change like this needs more notice than this. The news item
should give some reasonable notice of the change to give people time to
get their initramfs setup working and tested before it is needed in anger.


--
Neil Bothwick

Deja Foobar: A feeling of having made the same mistake before.
 
Old 03-11-2012, 07:41 AM
Michał Górny
 
Default newsitem: unmasking udev-181

On Sun, 11 Mar 2012 08:06:35 +0000
Neil Bothwick <neil@digimed.co.uk> wrote:

> On Sat, 10 Mar 2012 20:27:06 -0600, William Hubbs wrote:
>
> > If all goes well, this will be committed to the tree on 3/14 UTC.
>
> A major change like this needs more notice than this. The news item
> should give some reasonable notice of the change to give people time
> to get their initramfs setup working and tested before it is needed
> in anger.

Maybe the ebuild should try to autodetect broken systems and prevent
merge then. Better safe than sorry; I guess we could even go with
having to set something in make.conf when /usr is on separate partition.

--
Best regards,
Michał Górny
 

Thread Tools




All times are GMT. The time now is 04:46 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org