On Sat, Mar 17, 2012 at 03:12:11AM -0400, Walter Dnes wrote
> TOOT!!! (blowing my own horn). See http://www.waltdnes.org/mdev/ for
> instructions on replacing udev with mdev for simple Gentoo systems.
> Hopefully more info will start arriving, allowing more complex systems
> to work with mdev.
On Thu, Mar 15, 2012 at 04:44:11PM -0400, Richard Yao wrote
> Busybox is installed as part of the system profile on amd64. You can
> install mdev by doing this:
>
> ln -s /bin/busybox /sbin/mdev
The official method is to build busybox with the "mdev" USE flag. That
is the only way that virtua
On 03/14/2012 06:49 PM, Richard Yao wrote:
> On 03/14/12 21:06, Zac Medico wrote:
>> On 03/14/2012 05:58 PM, Richard Yao wrote:
>>> On 03/14/12 20:36, David Leverton wrote:
On 14 March 2012 23:47, Zac Medico wrote:
> It's more about what we're _not_ doing that what we're doing.
On 03/14/2012 06:49 PM, Richard Yao wrote:
> On 03/14/12 21:06, Zac Medico wrote:
>> On 03/14/2012 05:58 PM, Richard Yao wrote:
>>> On 03/14/12 20:36, David Leverton wrote:
On 14 March 2012 23:47, Zac Medico wrote:
> It's more about what we're _not_ doing that what we're doing.
Take your pick:
http://www.gentoo.org/proj/en/qa/treecleaners/maintainer-needed.xml
On Fri, Mar 16, 2012 at 11:18 AM, Greg KH wrote:
> On Thu, Mar 15, 2012 at 11:01:19PM -0400, Richard Yao wrote:
>> On 03/15/12 22:43, Greg KH wrote:
>> > On Thu, Mar 15, 2012 at 08:47:12PM -0400, Joshua Kinard wr
On 03/16/12 11:18, Greg KH wrote:
>
> At least find a package that people use :)
>
www-client/httrack?
On Thu, Mar 15, 2012 at 11:01:19PM -0400, Richard Yao wrote:
> On 03/15/12 22:43, Greg KH wrote:
> > On Thu, Mar 15, 2012 at 08:47:12PM -0400, Joshua Kinard wrote:
> >> On 03/15/2012 10:41, Greg KH wrote:
> >>
> >>>
> >>> There's always mudev if you don't want to run udev, good luck with that.
> >>
On 03/15/12 22:43, Greg KH wrote:
> On Thu, Mar 15, 2012 at 08:47:12PM -0400, Joshua Kinard wrote:
>> On 03/15/2012 10:41, Greg KH wrote:
>>
>>>
>>> There's always mudev if you don't want to run udev, good luck with that.
>>
>>
>> Got a link? We don't have anything matching in the tree, and Google
On Thu, Mar 15, 2012 at 08:47:12PM -0400, Joshua Kinard wrote:
> On 03/15/2012 10:41, Greg KH wrote:
>
> >
> > There's always mudev if you don't want to run udev, good luck with that.
>
>
> Got a link? We don't have anything matching in the tree, and Google turns
> up nothing relevant in the f
On Thu, Mar 15, 2012 at 7:17 PM, Canek Peláez Valdés wrote:
[...]
> https://bugs.gentoo.org/show_bug.cgi?id=366173
> https://bugs.gentoo.org/show_bug.cgi?id=373219
> https://bugs.gentoo.org/show_bug.cgi?id=399615
> https://bugs.gentoo.org/show_bug.cgi?id=405703
> https://bugs.gentoo.org/show_bug
On Wed, Mar 14, 2012 at 7:07 PM, Rich Freeman wrote:
> On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao wrote:
>>
>> I proposed a way that this could work with no effort on the part of the
>> Gentoo developers in one of my earlier emails:
>>
>
> Then go ahead and make it happen. If as you say no dev
On 03/15/2012 10:41, Greg KH wrote:
>
> There's always mudev if you don't want to run udev, good luck with that.
Got a link? We don't have anything matching in the tree, and Google turns
up nothing relevant in the first few pages.
--
Joshua Kinard
Gentoo/MIPS
ku...@gentoo.org
4096R/D25D95E3
On Thu, Mar 15, 2012 at 22:45, Richard Yao wrote:
> I know the UnionFS developer offline. I will ask him what the status of
> unionFS is the next time I see him. :)
Unionfs patchset is regularly released for new kernels, and bugs are
fixed. I wouldn't call the project "dead", I would call it "mat
On 03/15/12 08:34, Joshua Kinard wrote:
> On 03/14/2012 19:27, Richard Yao wrote:
>
>> On 03/14/12 18:49, Greg KH wrote:
2. Why not make rootfs a NFS mount with a unionfs at the SAN/NAS device?
>>>
>>> unionfs is still a "work in progress", some systems can't do that yet.
>>
>> That sounds li
On 03/15/12 08:40, Joshua Kinard wrote:
> I already looked in the tree and nothing really stands out as a suitable
> replacement for /dev management. mdev might, but it's part of busybox and
> not standalone as far as I know (at least, we don't have an independent
> package for it).
Busybox is in
On Thu, Mar 15, 2012 at 10:42 AM, Greg KH wrote:
>
> Why not use the links in /dev/serial/ which are there for this specific
> reason?
>
# ls -l /dev/serial
ls: cannot access /dev/serial: No such file or directory
Something in a newer version of udev perhaps? Or would my defining my
own symlink
On 03/15/2012 05:27 AM, Joshua Kinard wrote:
> On 03/14/2012 20:45, Zac Medico wrote:
>
>> On 03/14/2012 05:36 PM, David Leverton wrote:
>>> On 14 March 2012 23:47, Zac Medico wrote:
It's more about what we're _not_ doing that what we're doing.
>>>
>>> Clearly something must have changed in
On Thu, Mar 15, 2012 at 08:30:49AM -0400, Rich Freeman wrote:
> You know - I had a similar issue, but with a pair of PL2303 USB RS232
> interfaces. That makes me wonder if there is a possible way to
> enhance udev to better handle situations where devices have no unique
> ID and thus tend to be di
On Thu, Mar 15, 2012 at 07:04:52AM -0400, Joshua Kinard wrote:
> Devtmpfs quite literally handles 98% of my particular usage scenario. Does
> that apply to everyone? Nope. Just an interesting observation.
devtmpfs does not handle device permissions.
As for a "smaller" udev, feel free to try, p
On 03/14/2012 19:44, Greg KH wrote:
>
> Oh, and somehow "consensus" will work? No, sorry, it will not.
If compelling arguments were used, yes, you can sometimes trigger people to
change their minds and arrive at a consensus. But outright dismissing them
as if that will make them disappear is
On 03/14/2012 14:56, Zac Medico wrote:
> On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
>> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
>> wrote:
>>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
>>> nice to have a minimal recovery env in case mounting fails, etc, etc,
>>>
On 03/14/2012 12:28, Matthew Summers wrote:
>
> Gentoo provides a solution with genkernel, dracut provides a solution,
> even the linux kernel itself provides a solution (in my view the
> easiest solution at that).
The kernel doesn't appear to create the networking interfaces, though.
CONFIG_DE
On 03/14/2012 16:10, Kent Fredric wrote:
>
> Considering this pretty much eliminates using / for anything useful,
> we might as well rename "/usr" "/c"
>
> Even if it /is/ just to confuse the windows crowd =)
Unless you're one of those that installs Windows into D:\ :)
I'd say call it /sys f
On 03/15/2012 08:30, Rich Freeman wrote:
>
> You know - I had a similar issue, but with a pair of PL2303 USB RS232
> interfaces. That makes me wonder if there is a possible way to
> enhance udev to better handle situations where devices have no unique
> ID and thus tend to be difficult to access
On 03/14/2012 13:59, Rich Freeman wrote:
> On Wed, Mar 14, 2012 at 1:29 PM, Zac Medico wrote:
>> On 03/14/2012 10:11 AM, Maxim Kammerer wrote:
>>> What's wrong with:
>>> * having an "early mounts" list file
>>> * having an "early modules" list file
>>> * init system in early boot (e.g., Ope
On 03/14/2012 16:55, Zac Medico wrote:
>> Deprecation of this practice would mean that people could type
>> /bin/command instead of /usr/bin/command in situations where absolute
>> paths are necessary. We could symlink things in /usr to rootfs for
>> compatibility with legacy software. In a more e
On 03/14/2012 19:37, Greg KH wrote:
> On Wed, Mar 14, 2012 at 07:27:07PM -0400, Richard Yao wrote:
3. Why not let the users choose where these directories go and support
both locations?
>>>
>>> Because a plethera of options is a sure way to make sure that half of
>>> them don't work over
On 03/14/2012 19:27, Richard Yao wrote:
> On 03/14/12 18:49, Greg KH wrote:
>> On Wed, Mar 14, 2012 at 06:39:05PM -0400, Richard Yao wrote:
>>> With that said, I have a few questions:
>>>
>>> 1. Why does no one mention the enterprise use case at all?
>>
>> It has been pointed out before, why const
On Thu, Mar 15, 2012 at 7:04 AM, Joshua Kinard wrote:
> This does lead me to wonder if a light-weight udev could exist that lacks
> half or more of the functionality of the current udev. I'll be honest, I've
> only edited my udev rules file once, and that was only when I installed a
> Sun Happy M
On 03/14/2012 20:45, Zac Medico wrote:
> On 03/14/2012 05:36 PM, David Leverton wrote:
>> On 14 March 2012 23:47, Zac Medico wrote:
>>> It's more about what we're _not_ doing that what we're doing.
>>
>> Clearly something must have changed in udev 181 to make
>> /usr-without-initramfs not work an
On 03/15/2012 07:20, Stelian Ionescu wrote:
> On Thu, 2012-03-15 at 00:29 +, David Leverton wrote:
>> On 14 March 2012 23:44, Greg KH wrote:
>>> Oh, and somehow "consensus" will work? No, sorry, it will not.
>>
>> No, logical analysis will, as I said in the rest of my post which you
>> conve
On 03/14/2012 18:51, Greg KH wrote:
> On Wed, Mar 14, 2012 at 10:14:54PM +, David Leverton wrote:
>> On 14 March 2012 21:04, Greg KH wrote:
>>> Haveing a separate /usr is wonderful, and once we finish moving /sbin/
>>> and /bin/ into /usr/ it makes even more sense. See the /usr page at
>>> f
On 03/14/2012 18:14, David Leverton wrote:
> On 14 March 2012 21:04, Greg KH wrote:
>> Haveing a separate /usr is wonderful, and once we finish moving /sbin/
>> and /bin/ into /usr/ it makes even more sense. See the /usr page at
>> fedora for all of the great reasons why this is good.
>
> My po
On Thu, 2012-03-15 at 00:29 +, David Leverton wrote:
> On 14 March 2012 23:44, Greg KH wrote:
> > Oh, and somehow "consensus" will work? No, sorry, it will not.
>
> No, logical analysis will, as I said in the rest of my post which you
> conveniently ignored - either we conclude with evidence
On 03/14/2012 11:04, Greg KH wrote:
>
> Not always, no, it isn't obvious that something didn't start up
> correctly, or that it didn't fully load properly. Some programs later
> on recover and handle things better.
I'm well aware of what I run on my own box, and when something isn't
running, I
Am 15.03.2012 00:37, schrieb Greg KH:
> Not really, I don't think we support systems without udev anymore,
> right? And we get away with a lot of these different "options" at
> compile time, which makes it easier than what Debian has to handle, so
> perhaps it's not a fair comparison.
Sure Gentoo
Kent Fredric posted on Thu, 15 Mar 2012 09:10:53 +1300 as excerpted:
> On 15 March 2012 07:48, Duncan <1i5t5.dun...@cox.net> wrote:
>> It does, especially when it's literally the case, including a /usr/etc
>> bind-mounted on a tmpfs-based rootfs, that by login time, all that's
>> visible of rootfs
On 3/14/12 10:59 AM, Rich Freeman wrote:
Well, anybody is welcome to create any replacement/addition for
(/usr)/sbin/init or (/usr)/sbin/rc that they wish. If you make it
good enough, perhaps others will even use it.
There is a SoC out there for that.
Beyond that, anything else is just a sug
On 3/14/12 4:37 PM, Greg KH wrote:
Not really, I don't think we support systems without udev anymore,
right? And we get away with a lot of these different "options" at
compile time, which makes it easier than what Debian has to handle, so
perhaps it's not a fair comparison.
I think we support
On 3/14/12 10:58 AM, Matthew Summers wrote:
__Everyone__ is already using an initramfs, therefore there are no
initramfs-less systems anymore (it may just be empty). Every single
person reading this thread that has not already done so needs to
immediately go read the relevant documentation locat
On 03/14/2012 02:05 PM, Richard Yao wrote:
> How did RedHat justify that lack of conformity that resulted from moving
> everything into /usr in the first place?
Does it really matter? What people in the
separate-/usr-without-initramfs camp really want is continued support
for the "/ is a self-cont
On 03/14/12 21:06, Zac Medico wrote:
> On 03/14/2012 05:58 PM, Richard Yao wrote:
>> On 03/14/12 20:36, David Leverton wrote:
>>> On 14 March 2012 23:47, Zac Medico wrote:
It's more about what we're _not_ doing that what we're doing.
>>>
>>> Clearly something must have changed in udev 181 to
On 03/14/12 21:07, Rich Freeman wrote:
> On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao wrote:
>>
>> I proposed a way that this could work with no effort on the part of the
>> Gentoo developers in one of my earlier emails:
>>
>
> Then go ahead and make it happen. If as you say no dev participation
On 03/14/2012 06:07 PM, Rich Freeman wrote:
> For those who don't like the current direction, by all means create an
> overlay called udev-root, mdev-boot, noinitramfs, or whatever.
The simplest alternative to an initramfs that I can think of would be an
init wrapper like the one that I suggested
On Wed, Mar 14, 2012 at 7:51 PM, Richard Yao wrote:
>
> I proposed a way that this could work with no effort on the part of the
> Gentoo developers in one of my earlier emails:
>
Then go ahead and make it happen. If as you say no dev participation
is needed there is nothing Gentoo needs to do to
On 03/14/2012 05:58 PM, Richard Yao wrote:
> On 03/14/12 20:36, David Leverton wrote:
>> On 14 March 2012 23:47, Zac Medico wrote:
>>> It's more about what we're _not_ doing that what we're doing.
>>
>> Clearly something must have changed in udev 181 to make
>> /usr-without-initramfs not work anym
On 03/14/12 20:36, David Leverton wrote:
> On 14 March 2012 23:47, Zac Medico wrote:
>> It's more about what we're _not_ doing that what we're doing.
>
> Clearly something must have changed in udev 181 to make
> /usr-without-initramfs not work anymore, and someone must have done
> something to ma
On 15 March 2012 00:45, Zac Medico wrote:
> You're pointing your finger at udev, but the udev change is just a
> symptom of a more general shift away from supporting the "/ is a
> self-contained boot disk that is independent of /usr" use case.
OK, so there are multiple instances of people not not
On 03/14/2012 05:36 PM, David Leverton wrote:
> On 14 March 2012 23:47, Zac Medico wrote:
>> It's more about what we're _not_ doing that what we're doing.
>
> Clearly something must have changed in udev 181 to make
> /usr-without-initramfs not work anymore, and someone must have done
> something
On 14 March 2012 23:47, Zac Medico wrote:
> It's more about what we're _not_ doing that what we're doing.
Clearly something must have changed in udev 181 to make
/usr-without-initramfs not work anymore, and someone must have done
something to make that change happen, unless udev has aquired the
a
On 14 March 2012 23:44, Greg KH wrote:
> Oh, and somehow "consensus" will work? No, sorry, it will not.
No, logical analysis will, as I said in the rest of my post which you
conveniently ignored - either we conclude with evidence that there are
no issues, which should settle the matter for reaso
On Wed, Mar 14, 2012 at 07:58:23PM -0400, Richard Yao wrote:
> On 03/14/12 19:44, Greg KH wrote:
> > Now, to get back to what I said before, I'm done with this thread, it's
> > going nowhere, and it seems I'm just making it worse, my apologies. For
> > penance, I'll adopt the next abandoned packag
On 03/14/12 19:44, Greg KH wrote:
> Now, to get back to what I said before, I'm done with this thread, it's
> going nowhere, and it seems I'm just making it worse, my apologies. For
> penance, I'll adopt the next abandoned package someone throws at me, any
> suggestions?
Bug #360513 needs work. S
On 03/14/12 19:37, Greg KH wrote:
>> Portage provides use with the ability to do abstractions that other
>> distributions cannot do, such as permitting people to merge
>> /usr{bin,lib{32,64,},sbin} into /.
>
> Sure, but that doesn't mean that the packages that are being merged will
> actually work
On 03/14/2012 04:21 PM, David Leverton wrote:
> On 14 March 2012 22:51, Greg KH wrote:
>> Oh, that's simple, separate-/usr-without-initramfs will not work and
>> will not be supported :)
>
> See, it's this "we're doing it this way because we know best and we
> say so" that upsets people.
It's mo
On Wed, Mar 14, 2012 at 11:21:44PM +, David Leverton wrote:
> On 14 March 2012 22:51, Greg KH wrote:
> > Oh, that's simple, separate-/usr-without-initramfs will not work and
> > will not be supported :)
>
> See, it's this "we're doing it this way because we know best and we
> say so" that ups
On Wed, Mar 14, 2012 at 07:27:07PM -0400, Richard Yao wrote:
> >> 3. Why not let the users choose where these directories go and support
> >> both locations?
> >
> > Because a plethera of options is a sure way to make sure that half of
> > them don't work over the long run.
> >
> > We aren't Debi
On 03/14/12 18:49, Greg KH wrote:
> On Wed, Mar 14, 2012 at 06:39:05PM -0400, Richard Yao wrote:
>> With that said, I have a few questions:
>>
>> 1. Why does no one mention the enterprise use case at all?
>
> It has been pointed out before, why constantly repeat ourselves.
Simple. No one has docu
On 14 March 2012 22:51, Greg KH wrote:
> Oh, that's simple, separate-/usr-without-initramfs will not work and
> will not be supported :)
See, it's this "we're doing it this way because we know best and we
say so" that upsets people. I'm trying to encourage everyone to get
to the core reasons for
On Wed, Mar 14, 2012 at 10:14:54PM +, David Leverton wrote:
> On 14 March 2012 21:04, Greg KH wrote:
> > Haveing a separate /usr is wonderful, and once we finish moving /sbin/
> > and /bin/ into /usr/ it makes even more sense. See the /usr page at
> > fedora for all of the great reasons why t
On Wed, Mar 14, 2012 at 06:39:05PM -0400, Richard Yao wrote:
> Is this that page?
>
> http://fedoraproject.org/wiki/Features/UsrMove
>
> That refers to the systemd website on freedesktop.org.
>
> http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge
Yes.
> With that said, I ha
On 03/14/12 17:04, Greg KH wrote:
> On Wed, Mar 14, 2012 at 07:57:52PM +, David Leverton wrote:
>> Would anyone else like to continue with their own favourite
>> separate-/usr reason?
>
> Haveing a separate /usr is wonderful, and once we finish moving /sbin/
> and /bin/ into /usr/ it makes eve
On 14 March 2012 21:04, Greg KH wrote:
> Haveing a separate /usr is wonderful, and once we finish moving /sbin/
> and /bin/ into /usr/ it makes even more sense. See the /usr page at
> fedora for all of the great reasons why this is good.
My point was examine, in detail, whether separate-/usr-wit
On 03/14/12 16:55, Zac Medico wrote:
> On 03/14/2012 01:03 PM, Richard Yao wrote:
>> I do not have a separate /usr partition, however I agree with Joshua
>> Kinard's stance regarding the /usr move. The point of having a separate
>> /usr was to enable UNIX to exceed the space constraints that a 1.5M
On Wed, Mar 14, 2012 at 07:57:52PM +, David Leverton wrote:
> Would anyone else like to continue with their own favourite
> separate-/usr reason?
Haveing a separate /usr is wonderful, and once we finish moving /sbin/
and /bin/ into /usr/ it makes even more sense. See the /usr page at
fedora f
On Wed, Mar 14, 2012 at 03:59:56PM +, Ciaran McCreesh wrote:
> On Wed, 14 Mar 2012 08:22:09 -0700
> Greg KH wrote:
> > The people doing the work today do understand them, by virtue of
> > doing the work involved, which gives them the say in how it is done.
> > That's how open source works, why
On 03/14/2012 01:03 PM, Richard Yao wrote:
> On 03/14/12 14:56, Zac Medico wrote:
>> On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
>>> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
>>> wrote:
Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
nice to have a minimal rec
On Wed, Mar 14, 2012 at 08:04:31AM -0700, Greg KH wrote
> On Wed, Mar 14, 2012 at 10:51:44AM -0400, Philip Webb wrote:
> > 120314 Greg KH wrote:
> > > if you have /usr on a different filesystem today, with no initrd,
> > > your machine could be broken and you don't even know it.
> >
> > Whatever d
On 15 March 2012 07:48, Duncan <1i5t5.dun...@cox.net> wrote:
> It does, especially when it's literally the case, including a /usr/etc
> bind-mounted on a tmpfs-based rootfs, that by login time, all that's
> visible of rootfs is mountpoints, nothing else, and /usr literally IS the
> "unified system
On 03/14/12 14:56, Zac Medico wrote:
> On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
>> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
>> wrote:
>>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
>>> nice to have a minimal recovery env in case mounting fails, etc, etc,
>>> et
On 14 March 2012 18:56, Zac Medico wrote:
> Whatever the arguments may be, the whole discussion boils down to the
> fact that the only people who seem to have a "problem" are those that
> have a separate /usr partition and simultaneously refuse to use an
> initramfs.
I wonder if it might help to
On Wed, 14 Mar 2012 12:58:26 -0500
Matthew Summers wrote:
> __Everyone__ is already using an initramfs, therefore there are no
> initramfs-less systems anymore (it may just be empty).
I happen to understand you're not attempting to start a flame war here,
but it may not obvious to everyone.
On 03/14/2012 12:14 PM, Michael Orlitzky wrote:
> On 03/14/12 14:56, Zac Medico wrote:
>> On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
>>> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
>>> wrote:
Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
nice to have a minima
On 03/14/12 14:56, Zac Medico wrote:
> On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
>> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
>> wrote:
>>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
>>> nice to have a minimal recovery env in case mounting fails, etc, etc,
>>> et
On 03/14/2012 11:36 AM, Maxim Kammerer wrote:
> On Wed, Mar 14, 2012 at 19:58, Matthew Summers
> wrote:
>> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
>> nice to have a minimal recovery env in case mounting fails, etc, etc,
>> etc.
>
> There is nothing bad about initramfs
Zac Medico posted on Wed, 14 Mar 2012 10:52:48 -0700 as excerpted:
> On 03/14/2012 05:00 AM, James Cloos wrote:
>>> "MS" == Marc Schiffbauer writes:
>>
>> MS> IIRC usr = unified system resources (not an abbrev. for "user")
>> Before sysv created /home, bsd used /usr for user dirs.
> Anyway
On Wed, Mar 14, 2012 at 19:58, Matthew Summers
wrote:
> __Everyone__ is already using an initramfs, therefore there are no
> initramfs-less systems anymore (it may just be empty).
I suggest that you take a look at CONFIG_BLK_DEV_INITRD.
> Why is an in-kernel initramfs so bad anyway? I am baffled
On Wed, 14 Mar 2012 12:58:26 -0500
Matthew Summers wrote:
> Why is an in-kernel initramfs so bad anyway? I am baffled. Its quite
> nice to have a minimal recovery env in case mounting fails, etc, etc,
> etc.
Because the initramfs is just replacing what / used to be, and it's
even less well handle
On Wed, Mar 14, 2012 at 1:29 PM, Zac Medico wrote:
> On 03/14/2012 10:11 AM, Maxim Kammerer wrote:
>> What's wrong with:
>> * having an "early mounts" list file
>> * having an "early modules" list file
>> * init system in early boot (e.g., OpenRC in init.sh) loading "early
>> modules" and mo
On Wed, Mar 14, 2012 at 12:29 PM, Zac Medico wrote:
> On 03/14/2012 10:11 AM, Maxim Kammerer wrote:
>> What's wrong with:
>> * having an "early mounts" list file
>> * having an "early modules" list file
>> * init system in early boot (e.g., OpenRC in init.sh) loading "early
>> modules" and m
On 03/14/2012 10:11 AM, Maxim Kammerer wrote:
> What's wrong with:
> * having an "early mounts" list file
> * having an "early modules" list file
> * init system in early boot (e.g., OpenRC in init.sh) loading "early
> modules" and mounting "early mounts" from /etc/fstab
You're assuming that
On Wed, Mar 14, 2012 at 17:22, Greg KH wrote:
> As for "fixing this", see the oft-linked webpage as to why it can't be
> fixed easily, if at all, and honestly, I don't think it needs to be
> fixed.
What's wrong with:
* having an "early mounts" list file
* having an "early modules" list file
On Wed, Mar 14, 2012 at 10:22 AM, Greg KH wrote:
> On Wed, Mar 14, 2012 at 03:08:27PM +, Ciaran McCreesh wrote:
>> On Wed, 14 Mar 2012 08:04:31 -0700
>> Greg KH wrote:
>> > Not always, no, it isn't obvious that something didn't start up
>> > correctly, or that it didn't fully load properly.
On Wed, 14 Mar 2012 08:22:09 -0700
Greg KH wrote:
> The people doing the work today do understand them, by virtue of
> doing the work involved, which gives them the say in how it is done.
> That's how open source works, why is this ever a surprise to people?
The problem is that when a small numbe
On Wed, Mar 14, 2012 at 03:08:27PM +, Ciaran McCreesh wrote:
> On Wed, 14 Mar 2012 08:04:31 -0700
> Greg KH wrote:
> > Not always, no, it isn't obvious that something didn't start up
> > correctly, or that it didn't fully load properly. Some programs later
> > on recover and handle things bet
On Wed, 14 Mar 2012 08:04:31 -0700
Greg KH wrote:
> Not always, no, it isn't obvious that something didn't start up
> correctly, or that it didn't fully load properly. Some programs later
> on recover and handle things better.
So why not work on fixing those things, since they're clearly symptom
On Wed, Mar 14, 2012 at 10:51:44AM -0400, Philip Webb wrote:
> 120314 Greg KH wrote:
> > if you have /usr on a different filesystem today, with no initrd,
> > your machine could be broken and you don't even know it.
>
> Whatever do you mean ? -- if it were truly broken,
> it wouldn't perform in so
120314 Greg KH wrote:
> if you have /usr on a different filesystem today, with no initrd,
> your machine could be broken and you don't even know it.
Whatever do you mean ? -- if it were truly broken,
it wouldn't perform in some important & obvious respect.
Do you mean "insecure" ? -- if so, what i
On Wed, Mar 14, 2012 at 08:40:46AM -0400, Joshua Kinard wrote:
> I chose to stick with Gentoo as my distro of choice because I didn't like
> the way Red Hat did things years ago. As well as a few other nitpicks I
> have. It bugs me to no end that, despite running a fairly vanilla setup on
> a sou
On 03/14/2012 04:39, Duncan wrote:
>
> THAT is why they're moving /bin, /sbin and /lib to /usr rather than the
> other direction. rootfs will be ONLY a mountpoint, with even /etc/ being
> bind-mounted from /usr/etc, and all system data unified on /usr,
> including /etc.
>
> Viewed from that
Joshua Kinard posted on Tue, 13 Mar 2012 20:16:10 -0400 as excerpted:
> On 03/13/2012 07:54, James Broadhead wrote:
>
>> I believe that the Art of Unix Programming* says that /usr was the
>> result of the original UNIX 4MB hard disk becoming full, and that they
>> chose /usr to mount a second one
91 matches
Mail list logo
