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 User

 
 
LinkBack Thread Tools
 
Old 03-29-2012, 02:16 AM
Dale
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

Neil Bothwick wrote:

> It's not a blackbox, unlike a kernel or any other binary, it is a simple
> cpio archive that you can unpack and inspect. If you want total control,
> build your own, it is not rocket science.
>
>


<cough cough> You sure about that? I have tried building one, then
building it inside the kernel then using dracut. Still got issues. If
not rocket science, what other degree does a person need? ROFL

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-29-2012, 02:39 AM
Dale
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

Canek Peláez Valdés wrote:
> On Wed, Mar 28, 2012 at 7:53 PM, Dale <rdalek1967@gmail.com> wrote:
>> Alan Mackenzie wrote:
>>
>>> Incidentally, dracut says it won't work on a kernel without modules. I
>>> don't know if it's true or not.
>>>
>>
>> Oh really? I don't use modules and I am the one having issues with not
>> being able to su to root from a user. I wonder if that is related
>> somehow. o_O
>
> I don't use modules either (except scsi_wait_scan.ko; you cannot get
> rid of that one), I use dracut, and I can su just fine.
>
> Dale, can you please post the dracut comand you used to create your
> initramfs? Also, the DRACUT_MODULES you have defined, and the contents
> of /etc/dracut.conf?
>
> Not being able to su sounds incredible weird.
>
> Regards.


Here is one:

root@fireball / # cat /etc/dracut.conf


# Sample dracut config file





logfile=/var/log/dracut.log


fileloglvl=6





# Exact list of dracut modules to use. Modules not listed here are not
going

# to be included. If you only want to add some optional modules use


# add_dracutmodules option instead.


#dracutmodules+=""





# Dracut modules to omit


#omit_dracutmodules+=""



# Dracut modules to add to the default
#add_dracutmodules+="lvm fstab-sys usrmount"

# additional kernel modules to the default
#add_drivers+=""

# list of kernel filesystem modules to be included in the generic initramfs
filesystems+="ext2 reiserfs ext3"

# build initrd only to boot current hardware
#hostonly="yes"
#

# install local /etc/mdadm.conf
mdadmconf="yes"

# install local /etc/lvm/lvm.conf
lvmconf="yes"

# A list of fsck tools to install. If it's not specified, module's hardcoded
# default is used, currently: "umount mount /sbin/fsck* xfs_db xfs_check
# xfs_repair e2fsck jfs_fsck reiserfsck btrfsck". The installation is
# opportunistic, so non-existing tools are just ignored.
#fscks=""

# inhibit installation of any fsck tools
#nofscks="yes"
root@fireball / #

++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++

The command I use is:

dracut /boot/initramfs-<kernel version here>

I name each one according to kernel versions. I try to keep a few back
up kernels in case one gets borked or something. It makes cleaning
easier if I know which files belong to what. Anyway.

I also looked back at the log for the last build. The only thing I
found that may resemble a error would be it skipping file systems that I
don't have installed or built into the kernel, in other words, things I
don't use to begin with. I didn't see it complain about anything
missing or broken.

I agree it is weird that su to root doesn't work. I have not been able
to find anything related with SP, read as Google replacement search tool
www.startpage.com since Google got nosey. lol From what I have read,
it shouldn't matter but I can boot with the init thingy and it fails
everytime. When I boot without the init thingy, it works fine. Weird
is a good word to describe it.

I noticed dracut just got updated. I have dracut-017-r3 installed now.

I may stick a small drive in my old rig, x86, and try to figure this
mess out on it. Maybe try putting /usr and /var on LVM and really make
a mess of things. lol

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-29-2012, 05:08 AM
Canek Peláez Valdés
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

On Wed, Mar 28, 2012 at 8:39 PM, Dale <rdalek1967@gmail.com> wrote:
> Canek Peláez Valdés wrote:
>> On Wed, Mar 28, 2012 at 7:53 PM, Dale <rdalek1967@gmail.com> wrote:
>>> Alan Mackenzie wrote:
>>>
>>>> Incidentally, dracut says it won't work on a kernel without modules. *I
>>>> don't know if it's true or not.
>>>>
>>>
>>> Oh really? *I don't use modules and I am the one having issues with not
>>> being able to su to root from a user. *I wonder if that is related
>>> somehow. *o_O
>>
>> I don't use modules either (except scsi_wait_scan.ko; you cannot get
>> rid of that one), I use dracut, and I can su just fine.
>>
>> Dale, can you please post the dracut comand you used to create your
>> initramfs? Also, the DRACUT_MODULES you have defined, and the contents
>> of /etc/dracut.conf?
>>
>> Not being able to su sounds incredible weird.
>>
>> Regards.
>
>
> Here is one:
>
> root@fireball / # cat /etc/dracut.conf
>
>
> # Sample dracut config file
>
>
>
>
>
> logfile=/var/log/dracut.log
>
>
> fileloglvl=6
>
>
>
>
>
> # Exact list of dracut modules to use. *Modules not listed here are not
> going
>
> # to be included. *If you only want to add some optional modules use
>
>
> # add_dracutmodules option instead.
>
>
> #dracutmodules+=""
>
>
>
>
>
> # Dracut modules to omit
>
>
> #omit_dracutmodules+=""
>
>
>
> # Dracut modules to add to the default
> #add_dracutmodules+="lvm fstab-sys usrmount"
>
> # additional kernel modules to the default
> #add_drivers+=""
>
> # list of kernel filesystem modules to be included in the generic initramfs
> filesystems+="ext2 reiserfs ext3"
>
> # build initrd only to boot current hardware
> #hostonly="yes"
> #
>
> # install local /etc/mdadm.conf
> mdadmconf="yes"
>
> # install local /etc/lvm/lvm.conf
> lvmconf="yes"
>
> # A list of fsck tools to install. If it's not specified, module's hardcoded
> # default is used, currently: "umount mount /sbin/fsck* xfs_db xfs_check
> # xfs_repair e2fsck jfs_fsck reiserfsck btrfsck". The installation is
> # opportunistic, so non-existing tools are just ignored.
> #fscks=""
>
> # inhibit installation of any fsck tools
> #nofscks="yes"
> root@fireball / #
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++ +++++++++
>
> The command I use is:
>
> dracut /boot/initramfs-<kernel version here>
>
> I name each one according to kernel versions. *I try to keep a few back
> up kernels in case one gets borked or something. *It makes cleaning
> easier if I know which files belong to what. *Anyway.
>
> I also looked back at the log for the last build. *The only thing I
> found that may resemble a error would be it skipping file systems that I
> don't have installed or built into the kernel, in other words, things I
> don't use to begin with. *I didn't see it complain about anything
> missing or broken.
>
> I agree it is weird that su to root doesn't work. *I have not been able
> to find anything related with SP, read as Google replacement search tool
> www.startpage.com since Google got nosey. *lol *From what I have read,
> it shouldn't matter but I can boot with the init thingy and it fails
> everytime. *When I boot without the init thingy, it works fine. *Weird
> is a good word to describe it.
>
> I noticed dracut just got updated. *I have dracut-017-r3 installed now.
>
> I may stick a small drive in my old rig, x86, and try to figure this
> mess out on it. *Maybe try putting /usr and /var on LVM and really make
> a mess of things. *lol

Can you try doing

dracut -H /boot/initramfs-<kernel version here>

??

The man page from dracut says that -H is for the "current host"
instead of a "generic host". Maybe the "generic host" configuration is
messing up something with su that your actual host configuration
needs.

I use -H. As I have ben saying, my initramfs it's pretty up in sync
with my normal system.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México
 
Old 03-29-2012, 08:52 AM
Neil Bothwick
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

On Wed, 28 Mar 2012 21:16:30 -0500, Dale wrote:

> > It's not a blackbox, unlike a kernel or any other binary, it is a
> > simple cpio archive that you can unpack and inspect. If you want
> > total control, build your own, it is not rocket science.

> <cough cough> You sure about that? I have tried building one, then
> building it inside the kernel then using dracut. Still got issues. If
> not rocket science, what other degree does a person need? ROFL

A degree in reading wiki pages help :P


--
Neil Bothwick

The facts, although interesting, are irrelevant.
 
Old 03-29-2012, 04:35 PM
Neil Bothwick
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

On Thu, 29 Mar 2012 15:56:28 +0000, Alan Mackenzie wrote:

> > Well, for one, the initramfs solution is not generally considered
> > "ugly" except by a select vocal few who object to it on vague,
> > unarticulated grounds.
>
> I'll articulate a few. (i) The initramfs involves having two copies of
> lots of software around.

Lots? For most people busybox is enough! If you want encrypted
filesystems on LVM over RAID that rises to a total of four executables.

> (ii) What's more, these two copies are often
> different, one being built with static libraries, the other with dynamic
> ones. (iii) This situation is not (as far as I know) yet handled by
> Portage, which means in building such software statically, you've got to
> save the dynamic version somewhere else whilst you're doing it.

That's wrong. For example, LVM builds dynamic executable plus the
lvm.static file for use in the initramfs.

> (iv)
> The initramfs requires a potentially long script to make it work.

Mount /proc, /sys and /dev.
Mount root
Unmount /proc, /sys and /dev.
switch_root

> I think that qualifies the initramfs solution as ugly.

Only if you build the initramfs with USE="fud".

> I think I have the elegant solution: that would be for the kernel to be
> able to mount several partitions at system initialisation rather than
> just the root partition. With this, all the issues we've been
> discussing simply wouldn't arise.

That's an excellent idea.

> I accept that this solution will never happen. Sadly.

It's already happened here. My kernel mounts / and /usr thanks to the
inbuilt initramfs


--
Neil Bothwick

I just bought a microwave fireplace... You can spend an evening in
front of it in only eight minutes...
 
Old 03-29-2012, 05:13 PM
Michael Mol
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

On Thu, Mar 29, 2012 at 12:35 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Thu, 29 Mar 2012 15:56:28 +0000, Alan Mackenzie wrote:
>
>> > Well, for one, the initramfs solution is not generally considered
>> > "ugly" except by a select vocal few who object to it on vague,
>> > unarticulated grounds.
>>
>> I'll articulate a few. *(i) The initramfs involves having two copies of
>> lots of software around.
>
> Lots? For most people busybox is enough! If you want encrypted
> filesystems on LVM over RAID that rises to a total of four executables.

And anything they might conceivably link to. Not everything supports
static linking.

Don't forget boot-time X-based animation, too. That's an
extraordinarily common feature of mainstream desktop distributions.
And there will be other things, I'm sure.

>> (ii) What's more, these two copies are often
>> different, one being built with static libraries, the other with dynamic
>> ones. *(iii) This situation is not (as far as I know) yet handled by
>> Portage, which means in building such software statically, you've got to
>> save the dynamic version somewhere else whilst you're doing it.
>
> That's wrong. For example, LVM builds dynamic executable plus the
> lvm.static file for use in the initramfs.

That's exactly what Alan just noted in (ii), but perhaps portage
handles (iii) in the case of LVM.

>> (iv)
>> The initramfs requires a potentially long script to make it work.
>
> Mount /proc, /sys and /dev.
> Mount root
> Unmount /proc, /sys and /dev.
> switch_root

Things look much simpler when you abstract away the details. You still
have to manage lvm, mdraid and whatever else is necessary for mounting
things. That's where 'potentially long' came from, I expect.

>> I think that qualifies the initramfs solution as ugly.
>
> Only if you build the initramfs with USE="fud".

FUD: "Fear, uncertainty and doubt"

In short, three things which are important to rationally examine and
deal with on a case-by-case basis.

Fear of risk is healthy when trying to maintain something.

Uncertainty is expected when you first launch into some brave, new
world, and it's necessary to to learn things well enough to be able to
rule out uncertain conditions. That's an intrinsic part of systemic
stability.

Doubt is another word for risk analysis. What are the chances this
will fail, versus the chance that that will fail? What's the cost of
each of these failures.

--
:wq
 
Old 03-29-2012, 06:04 PM
Neil Bothwick
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

On Thu, 29 Mar 2012 17:29:11 +0000, Alan Mackenzie wrote:

> > It's already happened here. My kernel mounts / and /usr thanks to the
> > inbuilt initramfs
>
> That's exactly what I didn't mean, and I think you might have been aware
> of that.

Maybe, but it does fit your description.

> What I did mean was being able to mount subsequent partitions by giving
> kernel parameters in the boot loader configuration file. Something like
> "mount=8,3:/usr" for mount /dev/sda3 /usr.
>
> This would avoid the need to spend any effort whatsoever on building an
> initramfs, yet /usr would be mounted early in boot.

That sounds like a simple and elegant idea, and the kernel already
contains the code to mount filesystems. However, it doesn't handle
dm-crypt or LVM and putting all that in the kernel could be more complex
than putting the initramfs to do it in the kernel. However, if it could
be made to work , it would be a neat approach.


--
Neil Bothwick

Master of all I survey (at the moment, empty pizza boxes)
 
Old 03-29-2012, 06:11 PM
Neil Bothwick
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

On Thu, 29 Mar 2012 13:13:40 -0400, Michael Mol wrote:

> On Thu, Mar 29, 2012 at 12:35 PM, Neil Bothwick <neil@digimed.co.uk>
> wrote:

> >> I'll articulate a few. *(i) The initramfs involves having two copies
> >> of lots of software around.
> >
> > Lots? For most people busybox is enough! If you want encrypted
> > filesystems on LVM over RAID that rises to a total of four
> > executables.
>
> And anything they might conceivably link to. Not everything supports
> static linking.

Those four all have static version, there are no libraries in my
initramfs.

> Don't forget boot-time X-based animation, too. That's an
> extraordinarily common feature of mainstream desktop distributions.
> And there will be other things, I'm sure.

I don't get involved with those, but I'd hope something intended to be
run so early would have minimal dependencies, if any.

> >> (ii) What's more, these two copies are often
> >> different, one being built with static libraries, the other with
> >> dynamic ones. *(iii) This situation is not (as far as I know) yet
> >> handled by Portage, which means in building such software
> >> statically, you've got to save the dynamic version somewhere else
> >> whilst you're doing it.
> >
> > That's wrong. For example, LVM builds dynamic executable plus the
> > lvm.static file for use in the initramfs.
>
> That's exactly what Alan just noted in (ii), but perhaps portage
> handles (iii) in the case of LVM.

Exactly, there are static and dynamic files, all handled by portage.

> >> (iv)
> >> The initramfs requires a potentially long script to make it work.
> >
> > Mount /proc, /sys and /dev.
> > Mount root
> > Unmount /proc, /sys and /dev.
> > switch_root
>
> Things look much simpler when you abstract away the details. You still
> have to manage lvm, mdraid and whatever else is necessary for mounting
> things. That's where 'potentially long' came from, I expect.
>
> >> I think that qualifies the initramfs solution as ugly.
> >
> > Only if you build the initramfs with USE="fud".
>
> FUD: "Fear, uncertainty and doubt"
>
> In short, three things which are important to rationally examine and
> deal with on a case-by-case basis.

Yes, ideally before you start spreading them instead of vague handwaving
about initramfs being ugly and using "lots of files" (four only counts at
lots when applied to wives).



--
Neil Bothwick

Loose bits sink chips.
 
Old 03-29-2012, 06:35 PM
Michael Mol
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

On Thu, Mar 29, 2012 at 2:11 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Thu, 29 Mar 2012 13:13:40 -0400, Michael Mol wrote:
>
>> On Thu, Mar 29, 2012 at 12:35 PM, Neil Bothwick <neil@digimed.co.uk>
>> wrote:
>
>> >> I'll articulate a few. *(i) The initramfs involves having two copies
>> >> of lots of software around.
>> >
>> > Lots? For most people busybox is enough! If you want encrypted
>> > filesystems on LVM over RAID that rises to a total of four
>> > executables.
>>
>> And anything they might conceivably link to. Not everything supports
>> static linking.
>
> Those four all have static version, there are no libraries in my
> initramfs.

Which is good.

>
>> Don't forget boot-time X-based animation, too. That's an
>> extraordinarily common feature of mainstream desktop distributions.
>> And there will be other things, I'm sure.
>
> I don't get involved with those, but I'd hope something intended to be
> run so early would have minimal dependencies, if any.

There's a pretty firm distinction between what things get used for,
and what they're intended for. The udev developers presumably were
reacting to this when they decided to support an "anything goes"
policy regarding plugscript behavior.

And while I'm generally the kind of person to find unintended (but
perfectly compatible with their spec) uses for things, I don't figure
on being one to do so in my init sequence. That said, someone else
will. That's been a long tradition in open source software and hacker
culture.

In short, depending on things only being used when they're intended to
be used, in the circumstances they're intended to be used in, is
sticking one's head into the sand. Workarounds will always arise to
break such expectations and assumptions.

>
>> >> (ii) What's more, these two copies are often
>> >> different, one being built with static libraries, the other with
>> >> dynamic ones. *(iii) This situation is not (as far as I know) yet
>> >> handled by Portage, which means in building such software
>> >> statically, you've got to save the dynamic version somewhere else
>> >> whilst you're doing it.
>> >
>> > That's wrong. For example, LVM builds dynamic executable plus the
>> > lvm.static file for use in the initramfs.
>>
>> That's exactly what Alan just noted in (ii), but perhaps portage
>> handles (iii) in the case of LVM.
>
> Exactly, there are static and dynamic files, all handled by portage.
>
>> >> (iv)
>> >> The initramfs requires a potentially long script to make it work.
>> >
>> > Mount /proc, /sys and /dev.
>> > Mount root
>> > Unmount /proc, /sys and /dev.
>> > switch_root
>>
>> Things look much simpler when you abstract away the details. You still
>> have to manage lvm, mdraid and whatever else is necessary for mounting
>> things. That's where 'potentially long' came from, I expect.
>>
>> >> I think that qualifies the initramfs solution as ugly.
>> >
>> > Only if you build the initramfs with USE="fud".
>>
>> FUD: "Fear, uncertainty and doubt"
>>
>> In short, three things which are important to rationally examine and
>> deal with on a case-by-case basis.
>
> Yes, ideally before you start spreading them instead of vague handwaving
> about initramfs being ugly and using "lots of files" (four only counts at
> lots when applied to wives).

Fine. NFS clients. Samba clients. Crypto. SSHFS. NTFS-3g. Security
auditing. Virtualization tools. Perl, python or whatever is necessary
to handle some case which required scripting. X. Graphics loading
libraries. Cupsd, because some graphics library required by a
bootsplash expressed a dependency on cairo, which expressed a
dependency on something else, which expressed a dependency on cups.

Perhaps crypto required a crypto daemon to be loaded, which required a
smartcard, or required auth from a serial port or network connection.
Perhaps an accurate clock is needed. Or perhaps a network policy
demands that a machine be authorized to boot, so an LDAP client is
required.

It's easy to imagine entirely plausible circumstances which would
bloat initramfs size and maintenance. At some point in time, these
various things would normally be the simplest and most straightforward
way to reach a quick end to some problem or another for some poor guy
stuck in a private hell. And this initramfs crap increases the amount
of work he has to do to solve his unique case.

--
:wq
 
Old 03-29-2012, 08:15 PM
Dale
 
Default After /usr conflation: why not copy booting software to /sbin rather than initramfs?

Canek Peláez Valdés wrote:

> Can you try doing
>
> dracut -H /boot/initramfs-<kernel version here>
>
> ??
>
> The man page from dracut says that -H is for the "current host"
> instead of a "generic host". Maybe the "generic host" configuration is
> messing up something with su that your actual host configuration
> needs.
>
> I use -H. As I have ben saying, my initramfs it's pretty up in sync
> with my normal system.
>
> Regards.


Notice, I make the distinction between Console and Konsole by making the
first letter capitalized. It kind of gets confusing. :/

I had to reboot so I made a new init thingy with the -H switch. It
works in Console but nothing root works in KDE. I get the same error.
Heck, Konsole won't even try to come up much less ask for my password.
Krusader asks for password and says that su is not in the path. This is
similar to what I got when I was in a Console too.

So, boot without init thingy, everything works fine. Boot with the init
thingy, I can't access things in KDE as root. All I do is reboot. I
don't change or edit anything other than selecting a different entry in
grub.

I use Konsole when I emerge and such as that. I use Krusader, since
Konqueror developed a bug, to edit config files. I don't care to switch
to a Console to emerge something or edit a config file. This is not
going to work for me long term.

Also, keep in mind, I boot the EXACT same kernel whether I use the init
thingy or not. All I do is remove the stuff the init thingy needs to
work.

Go figure.

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"
 

Thread Tools




All times are GMT. The time now is 07:33 AM.

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