David W Noon wrote:
> On Thu, 29 Mar 2012 00:26:40 +0200, Alan McKinnon wrote about Re:
> [gentoo-user] InitRAMFS - boot expert sought:
>
>> On Wed, 28 Mar 2012 23:01:24 +0100
>> David W Noon <dwnoon@ntlworld.com> wrote:
> [snip]
>>> With the pending changes to udev scripts, you could well need /var
>>> -- and anything else -- before udev starts. So it is in the same
>>> category as /usr.
>>
>> Maybe, maybe not.
>>
>> However, no-one apart from you is even suggesting such a thing. For my
>> part I'm going to ignore that possibility and concentrate on those
>> things that are being seriously suggested.
>
> The Gentoo developers have been discussing just that. The reason is
> that many of the daemons that can be started by udev scripts require
> work files on /var, so we could well need /var mounted too.
Yep. I notice my LVM starts twice. It fails the first time because it
can't find files in /var then tries again later on after everything is
mounted, except the LVM stuff of course. So, this is most likely coming
and is one reason I am considering different options.
This is also another reason I want to get some sort of init thingy
working. I already have /var on its own regular partition but also want
/usr and /var on LVM. Right now, that could cause a problem since LVM
looks to have issues coming up without /var being mounted.
Luckily for me, I only have a data partition that contains video files
on LVM. It has nothing to do with the OS itself.
That is one reason this is causing me concerns. It's not just what is
already getting screwed up but also what is about to get screwed up that
makes it even worse.
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"
03-29-2012, 02:38 AM
Allan Gottlieb
InitRAMFS - boot expert sought
On Wed, Mar 28 2012, Alan McKinnon wrote:
> What you describe sounds ok, but I'd still hesitate to give a definite
> answer without a little more data.
>
> If you send over the output of
>
> df -h
> du -shx for each partition you have
> fdisk -l
> pvdisplay
> vgdisplay
> lvdisplay
>
> I'll be happy to go over the numbers and offer an opinion.
Wow. I get a detailed lvm recipe (with warnings) from wonko (thank you
very much) and from alan I get "an offer I can't refuse". Definitely a
good day!
ajglap gottlieb # for i in / /usr /local /var /tmp /opt /a; do du -shx $i; done
395M /
13G /usr
7.2G /local
313M /var
168M /tmp
147M /opt
16G /a
ajglap gottlieb # pvdisplay
--- Physical volume ---
PV Name /dev/sda7
VG Name vg
PV Size 100.01 GiB / not usable 2.50 MiB
Allocatable yes
PE Size 4.00 MiB
Total PE 25601
Free PE 2561
Allocated PE 23040
PV UUID NW7PkL-9uTd-FpVs-CBQ5-23uN-zXmP-S93rUr
ajglap gottlieb # vgdisplay
--- Volume group ---
VG Name vg
System ID
Format lvm2
Metadata Areas 1
Metadata Sequence No 9
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 6
Open LV 6
Max PV 0
Cur PV 1
Act PV 1
VG Size 100.00 GiB
PE Size 4.00 MiB
Total PE 25601
Alloc PE / Size 23040 / 90.00 GiB
Free PE / Size 2561 / 10.00 GiB
VG UUID Qu7Lml-xaZ6-RjDF-3Pu4-Q0im-aStB-AWKGwD
ajglap gottlieb # lvdisplay
--- Logical volume ---
LV Path /dev/vg/usr
LV Name usr
VG Name vg
LV UUID PsU87T-o3vy-k2wj-15wU-tOZk-2csz-1gmDwz
LV Write Access read/write
LV Creation host, time ,
LV Status available
# open 1
LV Size 20.00 GiB
Current LE 5120
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:0
--- Logical volume ---
LV Path /dev/vg/local
LV Name local
VG Name vg
LV UUID h05KfH-xF4U-A5ii-diWd-SZ4P-bWQD-U8Gly2
LV Write Access read/write
LV Creation host, time ,
LV Status available
# open 1
LV Size 10.00 GiB
Current LE 2560
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:1
--- Logical volume ---
LV Path /dev/vg/var
LV Name var
VG Name vg
LV UUID 860txl-vddH-nF5m-2cZz-6uco-eZ4v-IvSeh6
LV Write Access read/write
LV Creation host, time ,
LV Status available
# open 1
LV Size 15.00 GiB
Current LE 3840
Segments 2
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:2
--- Logical volume ---
LV Path /dev/vg/tmp
LV Name tmp
VG Name vg
LV UUID a2RKmz-If71-cF9p-QE3E-kjQO-sYW2-VopkEO
LV Write Access read/write
LV Creation host, time ,
LV Status available
# open 1
LV Size 5.00 GiB
Current LE 1280
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:3
--- Logical volume ---
LV Path /dev/vg/opt
LV Name opt
VG Name vg
LV UUID 0zUFgs-I0UE-j3ue-eVtY-9snn-noho-uDNOBk
LV Write Access read/write
LV Creation host, time ,
LV Status available
# open 1
LV Size 5.00 GiB
Current LE 1280
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:4
--- Logical volume ---
LV Path /dev/vg/a
LV Name a
VG Name vg
LV UUID QHqc9a-JLRy-01Oe-W61Y-SO1y-aPdJ-utDoqh
LV Write Access read/write
LV Creation host, time ,
LV Status available
# open 1
LV Size 35.00 GiB
Current LE 8960
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 254:5
03-29-2012, 08:28 AM
Alan McKinnon
InitRAMFS - boot expert sought
On Thu, 29 Mar 2012 00:20:04 +0100
David W Noon <dwnoon@ntlworld.com> wrote:
> On Thu, 29 Mar 2012 00:26:40 +0200, Alan McKinnon wrote about Re:
> [gentoo-user] InitRAMFS - boot expert sought:
>
> > On Wed, 28 Mar 2012 23:01:24 +0100
> > David W Noon <dwnoon@ntlworld.com> wrote:
> [snip]
> > > With the pending changes to udev scripts, you could well need /var
> > > -- and anything else -- before udev starts. So it is in the same
> > > category as /usr.
> >
> > Maybe, maybe not.
> >
> > However, no-one apart from you is even suggesting such a thing. For
> > my part I'm going to ignore that possibility and concentrate on
> > those things that are being seriously suggested.
>
> The Gentoo developers have been discussing just that. The reason is
> that many of the daemons that can be started by udev scripts require
> work files on /var, so we could well need /var mounted too.
Which begs the obvious question,
Why on earth is udev launching daemons in EARLY BOOT?
--
Alan McKinnnon
alan.mckinnon@gmail.com
03-29-2012, 08:43 AM
Allan Gottlieb
InitRAMFS - boot expert sought
I forgot one of the commands alan wanted to see. Here it is.
allan
ajglap gottlieb # fdisk -l
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders, total 976773168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x4f809fec
Device Boot Start End Blocks Id System
/dev/sda1 63 80324 40131 de Dell Utility
/dev/sda2 * 81920 30801919 15360000 7 HPFS/NTFS/exFAT
/dev/sda3 30801920 114667519 41932800 7 HPFS/NTFS/exFAT
/dev/sda4 114667520 976768064 431050272+ 5 Extended
/dev/sda5 114667583 125162414 5247416 83 Linux
/dev/sda6 125162478 146143304 10490413+ 82 Linux swap / Solaris
/dev/sda7 146143368 355871879 104864256 8e Linux LVM
/dev/sda8 355873928 460731527 52428800 83 Linux
Disk /dev/mapper/vg-a doesn't contain a valid partition table
03-29-2012, 09:02 AM
Neil Bothwick
InitRAMFS - boot expert sought
On Wed, 28 Mar 2012 22:21:11 -0400, Michael Mol wrote:
> There is so much BS being spewed around this topic, I'm genuinely
> disgusted. It's enough to lead me to suspect that Linux, as a
> platform, is *dying*.
It's not dying, it's evolving - with the associated growing pains. Of
course, that's not to say it couldn't evolve the way of the dodo.
> The "true UNIX way" is about KISS philosophy. Keep it Simple, Stupid.
> Keep things small, well-defined and modular. Break things into
> components, keep the components small and relatively well-defined.
That, IMO, is the problem with the current filesystem layout. The split
between / and /usr is anything but well-defined. Putting things in
different boxes based on their function is good practice. Doing it based
on some arbitrary size limit on the box is not.
It makes me think of Ubuntu's insistence on fitting their installer on a
single CD, even if it means omitting useful software or having the
installer sneakily download components in the background.
--
Neil Bothwick
Bugs are Sons of Glitches
03-29-2012, 12:01 PM
David W Noon
InitRAMFS - boot expert sought
On Thu, 29 Mar 2012 10:28:36 +0200, Alan McKinnon wrote about Re:
[gentoo-user] InitRAMFS - boot expert sought:
> On Thu, 29 Mar 2012 00:20:04 +0100
> David W Noon <dwnoon@ntlworld.com> wrote:
[snip]
> > The Gentoo developers have been discussing just that. The reason is
> > that many of the daemons that can be started by udev scripts require
> > work files on /var, so we could well need /var mounted too.
>
> Which begs the obvious question,
>
> Why on earth is udev launching daemons in EARLY BOOT?
Your guess is as good as mine!
At present, the first thing I see when udev starts is a failed attempt
to run /usr/sbin/alsactl to restore the audio levels on my sound card.
This occurs before localmount or any other services in the sysinit
run-level have been started. Just why anybody wants sound before the
disk volumes have been mounted baffles me; I guess people are just
desperate for the comforts of stereo. Perhaps my mind simply lacks the
sophistication to understand the design of udev.
I guess I'll just stick to my 80-column Hollerith cards. ... :-)
--
Regards,
Dave [RLU #314465]
================================================== ====================
dwnoon@ntlworld.com (David W Noon)
================================================== ====================
03-29-2012, 12:05 PM
Nicolas Sebrecht
InitRAMFS - boot expert sought
The 29/03/12, Alan McKinnon wrote:
> On Thu, 29 Mar 2012 00:20:04 +0100
> David W Noon <dwnoon@ntlworld.com> wrote:
> > The Gentoo developers have been discussing just that. The reason is
> > that many of the daemons that can be started by udev scripts require
> > work files on /var, so we could well need /var mounted too.
>
> Which begs the obvious question,
>
> Why on earth is udev launching daemons in EARLY BOOT?
udev launches nothing. udev scripts do. These scripts are not part of
udev.
--
Nicolas Sebrecht
03-29-2012, 01:00 PM
Neil Bothwick
InitRAMFS - boot expert sought
On Thu, 29 Mar 2012 14:05:30 +0200, Nicolas Sebrecht wrote:
> > Why on earth is udev launching daemons in EARLY BOOT?
>
> udev launches nothing. udev scripts do. These scripts are not part of
> udev.
That is true, but udev provides no control over when these scripts are
run. udev starts in early boot, because /some/ of its function is needed
then, and it then tries to run rules for all detected hardware. This is a
flaw in udev.
--
Neil Bothwick
In possession of a mind not merely twisted, but actually sprained.
03-29-2012, 01:59 PM
"J. Roeleveld"
InitRAMFS - boot expert sought
On Wed, March 28, 2012 12:49 am, Mark Knecht wrote:
<snipped>
> Do nothing. Just read, watch, learn but most important don't do
> updates. Just wait. Patience is a virtue!
I wonder how many threads we'll get with "I haven't updated my Gentoo for
over a year, how do I best do the upgrade?" from people following this
advice?
--
Joost
03-29-2012, 02:08 PM
Doug Hunley
InitRAMFS - boot expert sought
On Wed, Mar 28, 2012 at 19:20, David W Noon <dwnoon@ntlworld.com> wrote:
> On Thu, 29 Mar 2012 00:26:40 +0200, Alan McKinnon wrote about Re:
> [gentoo-user] InitRAMFS - boot expert sought:
>
>> On Wed, 28 Mar 2012 23:01:24 +0100
>> David W Noon <dwnoon@ntlworld.com> wrote:
> [snip]
>> > With the pending changes to udev scripts, you could well need /var
>> > -- and anything else -- before udev starts. *So it is in the same
>> > category as /usr.
>>
>> Maybe, maybe not.
>>
>> However, no-one apart from you is even suggesting such a thing. For my
>> part I'm going to ignore that possibility and concentrate on those
>> things that are being seriously suggested.
>
> The Gentoo developers have been discussing just that. *The reason is
> that many of the daemons that can be started by udev scripts require
> work files on /var, so we could well need /var mounted too.
But wait, that's what having /var/run being a link to /run was all
about. This problem is supposed to be *solved* already, damnit
--
Douglas J Hunley (doug.hunley@gmail.com)
Twitter: @hunleyd * * * * * * * * * * * * * * * * * * * * * * * Web:
douglasjhunley.com
G+: http://goo.gl/sajR3