[lfs-dev] LFS- SVN-20140323 6.62. Eudev-1.5.3
There is an error in the following:
Create some directories now that are needed for tests, but will also be
used as a part of installation:
mkdir -pv /lib/{firmware,udev/devices/pts}
mkdir -pv /lib/firmware -- This is not needed as
directory is created by above
mkdir -pv /lib/udev/rules.d
mkdir -pv Create some directories now that are needed for tests, but
will also be used as a part of installation:
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
[lfs-dev] pkgconfig and *.pc files
I see that pkgconfig has been removed from LFS and BLFS Can the *.pc files be removed from /usr/lib/pkgconfig or are they still needed? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] chattr and lsattr
On 03/20/2014 08:41 PM, Bruce Dubbs wrote: I've noticed that our instructions for e2fsprogs put chattr and lsattr into /usr/bin. Shouldn't these be in /bin? -- Bruce If you follow Filesystem Hierarchy Standard version 2.3 they are not in placed into /bin. I have not found them in that document so it looks to me that /usr/bin is ok. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] LFS-7.5 5.6. Linux-3.13.3 API Headers
Why is the installation of the headers in the book like this make INSTALL_HDR_PATH=dest headers_install cp -rv dest/include/* /tools/include instead of make INSTALL_HDR_PATH=/tools/include headers_install ?? Would the latter be just the same or am I missing something here? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS-7.5 5.6. Linux-3.13.3 API Headers
On 03/02/2014 09:22 AM, thomas wrote: Am Sonntag, den 02.03.2014, 08:36 -0500 schrieb baho utot: Why is the installation of the headers in the book like this make INSTALL_HDR_PATH=dest headers_install cp -rv dest/include/* /tools/include instead of make INSTALL_HDR_PATH=/tools/include headers_install if at all, than: make INSTALL_HDR_PATH=/tools headers_install as the include dir is created in the INSTALL_HDR_PATH. ?? Would the latter be just the same or am I missing something here? If I remember right, at least in previous versions of the kernel sources the target directory had been cleared before the headers were written. That would be no good for the /tools/include dir but meaningless for the newly created dest dir. So when first installing to a dummy-dir and than copy over, no loss of files happens. OK thanks -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS-7.5 5.6. Linux-3.13.3 API Headers
On 03/02/2014 10:13 AM, William Harrington wrote: On Mar 2, 2014, at 8:22 AM, thomas wrote: If I remember right, at least in previous versions of the kernel sources the target directory had been cleared before the headers were written. That would be no good for the /tools/include dir but meaningless for the newly created dest dir. So when first installing to a dummy-dir and than copy over, no loss of files happens. Seeing how the kernel headers are installed after gcc pass1 and binutils pass1 in ch5, then that is a problem since /tools/include is populated. If you install the kernel headers right at the beginning, then it wouldn't be a problem as /tools/include wouldn't exist at that time. Final system kernel headers install wouldn't be a problem as /usr/ include isn't populated. Sincerely, William Harrington I am working on Chapter 5, so I will only comment on that as that is all I have info for right now. Chapter 5.4 binutils doesn't put any include files into /tools/include, places include files into x86_64-lfs-linux-gnu/lib Chapter 5.5 gcc places an empty directory into /tools so that /tools/inculde exists at this point but it is empty. Chapter 5.6 linux api headers is next but since the /tools/include directory is empty at this point there is nothing to over write. So installing the linux API headers into /tools/nclude should overwrite nothing. Is this correct? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] xz instructions from chapter 6
On 12/29/2013 05:54 AM, akhiezer wrote: Date: Sun, 29 Dec 2013 10:15:22 +0100 From: Pierre Labastie pierre.labas...@neuf.fr To: LFS Developers Mailinglist lfs-dev@linuxfromscratch.org Subject: Re: [lfs-dev] xz instructions from chapter 6 Le 28/12/2013 22:20, Bruce Dubbs a écrit : Aleksey Rybalkin wrote: Hi. xz instructions from chapter 6 leave broken symlink /usr/bin/lzcat which points to xz but /usr/bin/xz does not exist since it was moved to /bin I suppose lzcat should be moved to /bin too. That's right. I've got it in my queue to update svn. I suppose an errata entry is appropriate. -- Bruce Why an erratum? For 7.4, all the executables were installed in /usr/bin anyway. I think they're saying that '/usr/bin/lzcat - xz' becomes a dangling symlnk after 'mv /usr/bin/xz /bin/xz' ? rgds, akh Not in 7.4 the executables are all in /usr/bin none are moved -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Yikes perl-5.18.0-libc-1.patch missing
Ok who swiped the patch ;) Any one know where this took off to? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Yikes perl-5.18.0-libc-1.patch missing
On 08/13/2013 12:42 PM, Bruce Dubbs wrote: Baho Utot wrote: Ok who swiped the patch ;) Any one know where this took off to? perl-5.18.1-libc-1.patch is the same. -rw-rw-r-- 1 1611 Mar 16 perl-5.16.3-libc-1.patch lrwxrwxrwx 124 May 28 perl-5.18.0-libc-1.patch - perl-5.16.3-libc-1.patch lrwxrwxrwx 124 Aug 13 perl-5.18.1-libc-1.patch - perl-5.16.3-libc-1.patch And *all* the lfs perl patches are at http://www.linuxfromscratch.org/patches/downloads/perl/ -- Bruce Should the wget-list file point to that location for all of the patches instead of lfs.org/svn/whatever -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Raspberry Pi
On 05/31/2013 07:33 PM, Aleksandar Kuktin wrote: On Sat, 01 Jun 2013 00:39:25 +0200 Armin K. kre...@email.com wrote: On 06/01/2013 12:27 AM, Bruce Dubbs wrote: [snip] Is there any interest in LFS for the Pi? -- Bruce Yes, absolutely. However, think as much as I can, I can not think of anything to DO with the Pi. And, in general, I don't buy things if I can't think of at least one thing to do with them before I buy them. One could make a DNS server and maybe a smtp/imap server. I mean, I *could* browse the Web with it, or write programs with it, or play games on it, or play games with it, but I can do all those things with my current computer. And I ain't letting go of it before it dies a glorious number-crunching death. Maybe I can make it as a permanently-online computer, sort of like a personal persisten emissary to the Internet, but that would require an inbound link. See, that just might work. If I can convince the rest of the household to permanently open port 80 (or whatever) on the router, maybe I *can* make a persistance-server. But I will then somehow have to solve the dynamic-IP problem. Not a problem, it is easy to over come the dynamic ip issue. I have done that for about 20 years. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Raspberry Pi
On 05/31/2013 08:21 PM, Aleksandar Kuktin wrote: On Fri, 31 May 2013 19:36:14 -0400 Baho Utot baho-u...@columbus.rr.com wrote: On 05/31/2013 07:33 PM, Aleksandar Kuktin wrote: [snip] See, that just might work. If I can convince the rest of the household to permanently open port 80 (or whatever) on the router, maybe I *can* make a persistance-server. But I will then somehow have to solve the dynamic-IP problem. Not a problem, it is easy to over come the dynamic ip issue. I have done that for about 20 years. Without using the DNS. :) There are ways to do your own DNS or you can use a dynamic DNS service. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Script to check package versions
On 05/15/2013 03:56 PM, Bruce Dubbs wrote:
William Harrington wrote:
On May 15, 2013, at 12:12 PM, Bruce Dubbs wrote:
Not quite. I just put that out as an example of fetching via
svn/ftp/http and some examples of using regex expressions.
The changes are not great, but the edited diff below shows the relevant
changes. Mostly regex additions/changes.
Excellent. Thanks for the info. I'm planning on adding checks for my
current server build for packages I have installed. The script will give
me a great base to start from.
I decided to increase my apache/php/mysql knowledge and created
databases for LFS or CLFS builds and I have the package name, version,
configure options, and notes (I use for the installation instructions as
well). I have it to where I can edit add or delete entries. As I
update versions I update the configure and notes if required.
So each build I have a database and build order using mysql. A bit
overkill, but it is a good project!
Yes, I 'd say it was a bit of overkill, but if it gives you some DB
experience then it's good.
You might want to like into https://mariadb.org/. mysql is being
impacted by Oracle in some not-helpful ways.
Personally, I have some simple bash scripts that log each package as
it's built in a simple file. E.g:
$ head packages-SVN-20121218.log
Tue Dec 18 21:28:30 GMT 2012 /usr/src/bc/bc-1.06.95.tar.bz2
Tue Dec 18 21:30:01 GMT 2012 /usr/src/lsb-release/lsb-release-1.4.tar.gz
Tue Dec 18 21:41:49 GMT 2012 /usr/src/sudo/sudo-1.8.6p3.tar.gz
Tue Dec 18 21:46:39 GMT 2012 /usr/src/openssl/openssl-1.0.1c.tar.gz
Tue Dec 18 21:48:28 GMT 2012 /usr/src/openssh/openssh-6.1p1.tar.gz
Wed Dec 19 00:09:11 GMT 2012 /usr/src/alsa/alsa-lib/alsa-lib-1.0.26.tar.bz2
Wed Dec 19 00:16:23 GMT 2012
/usr/src/alsa/alsa-utils/alsa-utils-1.0.26.tar.bz2
Wed Dec 19 00:49:10 GMT 2012 /usr/src/cdparanoia/cdparanoia-III-10.2.src.tgz
Wed Dec 19 04:08:34 GMT 2012 /usr/src/which/which-2.20.tar.gz
Wed Dec 19 04:26:50 GMT 2012 /usr/src/yasm/yasm-1.2.0.tar.gz
All my sources are in /usr/src and I just create a new Makefile for each
revision for example I have:
bc-1.06.log
bc-1.06.95.log
bc-1.06.95.tar.bz2
bc-1.06.log
bc-1.06.tar.gz
make-bc-1.06
make-bc-1.06.95
If I want to build a new version, I copy make-bc-1.06.95 make-bc-1.xx.xx
and edit the contents, most of which is boilerplate. Usually only a few
commands or a version need to be updated:
$ cat make-bc-1.06.95
#!/bin/bash
source /usr/src/stats
###
# Installing bc
DIR=`pwd`
PROGRAM=bc-1.06.95
LOG=$DIR/$PROGRAM.log
TITLE=$PROGRAM
TIMEFORMAT=$TIMEFMT $TITLE
BUILDDIR=/tmp/bc
rm -f $LOG
rm -rf $BUILDDIR
mkdir $BUILDDIR
cd $BUILDDIR
before=`df -k /tmp | grep / | sed -e s/ \{2,\}/ /g | cut -d' ' -f3`
tar -xf $DIR/$PROGRAM.tar.?z* || exit 1
cd $PROGRAM
{ time \
{
echo Making $TITLE
date
./configure --prefix=/usr --with-readline
make
#echo quit | ./bc/bc -l Test/checklib.b
$SUDO make install
}
} 21 | tee -a $LOG
You can change
} 21 | tee -a $LOG
to
} | tee -a $LOG
the | does the same thing as 21
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
[lfs-dev] Trivial spelling error SVN-20130511
In the change log: [bdubbs] - Upgrade to gettest-0.18.2.1. Fixes #3298. It should be gettext -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] udev-202
I have the following files installed when building udev-202 /usr/share/gtk-doc/html/udev/api-index-full.html /usr/share/gtk-doc/html/udev/ch01.html /usr/share/gtk-doc/html/udev/home.png /usr/share/gtk-doc/html/udev/index.html /usr/share/gtk-doc/html/udev/index.sgml /usr/share/gtk-doc/html/udev/left.png /usr/share/gtk-doc/html/udev/libudev-udev-device.html /usr/share/gtk-doc/html/udev/libudev-udev-enumerate.html /usr/share/gtk-doc/html/udev/libudev-udev-hwdb.html /usr/share/gtk-doc/html/udev/libudev-udev-list.html /usr/share/gtk-doc/html/udev/libudev-udev-monitor.html /usr/share/gtk-doc/html/udev/libudev-udev-queue.html /usr/share/gtk-doc/html/udev/libudev-udev-util.html /usr/share/gtk-doc/html/udev/libudev-udev.html /usr/share/gtk-doc/html/udev/libudev.devhelp2 /usr/share/gtk-doc/html/udev/right.png /usr/share/gtk-doc/html/udev/style.css /usr/share/gtk-doc/html/udev/up.png Should not the directory be /usr/share/udev-202/html and not /usr/share/gtk-doc/html ? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Udev-lfs-198-3?
On 04/01/2013 09:49 AM, Matt Burgess wrote: On Mon, 2013-04-01 at 09:35 -0400, Baho Utot wrote: This is in the Change log for the the SVN book that I just rendered [matthew] - Upgrade to Udev-lfs-198-3 to fix issues with libdrm installation in BLFS. Thanks to Nico P for the report, and to Armin for the fix. In this section has 6.61. Udev-199 (Extracted from systemd-199) has the information for building tar -xvf ../udev-lfs-199-2.tar.bz2 What's up? Nothing, I don't think :-) Systemd was upgraded to 199 on 2013-03-28, which required a similar version bump in udev-lfs to 199-1. That was missing some man pages, which broke the build, so Bruce uploaded udev-lfs-199-2.tar.bz2. Regards, Matt. Ok I think I have it straight...well maybe -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] 6.17. GCC-4.8.0
Confused again :) Is the following still required with this --disable-install-libiberty switch? from the book... Workaround a bug so that GCC doesn't install libiberty.a, which is already provided by Binutils: sed -i 's/install_to_$(INSTALL_DEST) //' libiberty/Makefile.in or does just using the switch fix the problem and the sed isn't needed? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] 6.17. GCC-4.8.0
On 04/01/2013 11:45 AM, Matt Burgess wrote: On Mon, 2013-04-01 at 10:16 -0400, Baho Utot wrote: Confused again :) Is the following still required with this --disable-install-libiberty switch? from the book... Workaround a bug so that GCC doesn't install libiberty.a, which is already provided by Binutils: sed -i 's/install_to_$(INSTALL_DEST) //' libiberty/Makefile.in or does just using the switch fix the problem and the sed isn't needed? See the relevant changelog entry (from 2013-03-29). In short, --disable-install-libiberty is buggy: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780 Regards, Matt. OK..., but would it not have been better to not use the switch until it worked as the sed does the same thing? I am now just waiting so I can build April fools version of LFS, looks like I'll need to build both books tomorrow ;) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] $100 for helping me understand/fix this
On 11/19/2012 08:29 PM, William Harrington wrote: On Nov 19, 2012, at 5:37 PM, Paige Thompson wrote: https://github.com/paigeadele/erraticOS/blob/master/usr/src/binutils-build/config.log I just need to understand why these files are being linked this way and what I need to do to fix it: erratic@erratic-MacPro ~/erraticOS/tools/lib $ ldd libc.so.6 /home/erratic/erraticOS/tools/lib/ld-linux-x86-64.so.2 = /lib64/ld-linux-x86-64.so.2 (0x7f9036a27000) linux-vdso.so.1 = (0x7fff8cff3000) erratic@erratic-MacPro ~/erraticOS/tools/lib $ here is the script: https://github.com/paigeadele/erraticOS/blob/master/usr/src/chef/cookbooks/erraticOS/recipes/toolchain-solo.rb the first link is where it is breaking (binutils-pass-2) You have got to be freaking kidding me. No one else ever respond to this guy's posts. Let me explain something. If you are going to use scripts, then can't get LFS to build. Maybe you are in over your head. The frist problem is, you are using scripts, which you don't know how to troubleshoot. Give me the money! And I don't know why you'd want to reinvent the wheel to build LFS it's already done in ALFS. Are people psycho? Sincerely, William Harrington I made my own scripts and I didn't use ALFSI guess that makes me psycho ;) I also use a package manager so I guess I am beyond repair. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] OT: Re: How to install Systemd-193 on LFS
On 10/03/2012 09:23 PM, Ken Moffat wrote: On Wed, Oct 03, 2012 at 07:52:14PM -0400, Baho Utot wrote: Actually it goes much farther for me. It isn't just this package or that package but a general direction of linux seems to going down hill ( in my opinion) faster that a snowball headed for hell. Everyone seems to want something new just for the sake of something new. Don't care if it is needed or works, just give me something new. Suse, Fedora, arch and oracle linux, just not able to work for me. Things that where just simple are now complex and I can not trust the result. For example take my BLFS scripts that I work on on a desktop machine (x86-64), then transfer to a usb drive to compile/test on a i686. I copy them using cp -vaur BLFS /media/usb. Then I move the usb to the i686 machine and nothing was copied/updated. cp -a is equivalent to cp -dR --preserve=all according to the current info page. Certainly I just use cp -av to copy things (but, I use rsync for backups - very slow the first time, much quicker on subsequent updates). I wonder if -u is the problem : (sorry about the reformatting when I paste it) `-u' `--update' Do not copy a non-directory that has an existing destination with the same or newer modification time. If time stamps are being preserved, the comparison is to the source time stamp truncated to the resolutions of the destination file system and of the system calls used to update time stamps; this avoids duplicate work if several `cp -pu' commands are executed with the same source and destination. If `--preserve=links' is also specified (like with `cp -au' for example), that will take precedence. Consequently, depending on the order that files are processed from the source, newer files in the destination may be replaced, to mirror hard links in the source. Alternatively, it might be a filesystem issue. When I'm away from home, I tend to back things up onto vfat usb sticks - that is a stupid filesystem, so I put everything in a compressed tarball and then just copy the tarball, rather than expecting everything in a copied directory tree to work out fine. Occasionally, I use ext2 on sticks (and certainly ext2/3/4 on usb drives), but cheap solid-state storage doesn't like being written to - often the directory area for vfat is special, other places are more fragile. The file system is ext3 the same as on each box. Rsync is not an option as only the desktop machine has it at this time. cp -av doesn't work either, the copy never happens but the result in the term shows every thing copied and worked without any error or text saying nothing really happened. BTW I am not concerned with wearing out the sub drive as I have many of the available for use. I don't think that building BLFS will wear one out but if it does I have that covered. Another example is a file with 777 perms and a cat shows you nothing, you know that the file is not empty ( you put things in it) but cat or less shows nothing. Everybody has the perms to look at the file but go ahead and try to list and it shows you nothing. When you finally get the thing working by digging in to it you find that you lose 30 minutes to some user name nonsense. Maybe some security option in the kernel - I don't know, I try to avoid files with 777 perms. Any package-specifics you wish to share on this issue ? ĸen The perms are for/in my build system to prevent user problems of transfering from one system to another. I use pacman to build the system with and the perms in the final package are correct and not 777. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] OT: Re: How to install Systemd-193 on LFS
On 10/04/2012 08:15 AM, Matthew Burgess wrote: On Thu, 04 Oct 2012 08:09:50 -0400, Baho Utot baho-u...@columbus.rr.com wrote: The file system is ext3 the same as on each box. Rsync is not an option as only the desktop machine has it at this time. cp -av doesn't work either, the copy never happens but the result in the term shows every thing copied and worked without any error or text saying nothing really happened. You're not pulling the USB drive out before a sync() call has managed to be made are you? What happens if you call 'sync' after your 'cp -av' command, then inspect it? (disclaimer: this is just a wild hunch, 'cp' may itself call sync(2), I've no idea). Ta, Matt. No I do a sync in the term after the copy and then wait for kde to umount -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] OT: Re: How to install Systemd-193 on LFS
On 10/03/2012 12:18 PM, Henrik /KaarPoSoft wrote: [putolin] I am sorry to see this discussion turning into - If AAA succeed in moving linux to BBB I am moving to *BSD - XXX is a solution trying desperately to find a problem - The whole thing reminds me of a patient with cancer - godzilla mode on / In my opinion, the great thing is, that you can do what you want with OpenSource (within limits of licenses, but that is another topic). Depending on you, your users, and your usecase, you can select whatever combination of OpenSource software you find matching your requirements. If you like the good old UNIX the Berkeley way with a bit of ATT thrown in, go for *BSD. If you like the Linus way with a gnu thrown in, go for a linux distro. If you like something else, and no distro is just right for you, just brew your own system, pulling in the upstream packages you want. I have servers with FreeBSD, because that is a perfect match for my server requirements. I had desktops and laptops with Ubuntu. When they upgraded into something too futuristic for me, I changed to LinuxMint. When that gave me too little flexibility, I changed to LFS+BLFS. When that gave me too little reproducability, I rolled my own distro. The world is full of OpenSource - please do not flame it; embrace it and use it! /Henrik Actually it goes much farther for me. It isn't just this package or that package but a general direction of linux seems to going down hill ( in my opinion) faster that a snowball headed for hell. Everyone seems to want something new just for the sake of something new. Don't care if it is needed or works, just give me something new. Suse, Fedora, arch and oracle linux, just not able to work for me. Things that where just simple are now complex and I can not trust the result. For example take my BLFS scripts that I work on on a desktop machine (x86-64), then transfer to a usb drive to compile/test on a i686. I copy them using cp -vaur BLFS /media/usb. Then I move the usb to the i686 machine and nothing was copied/updated. What the hell I saw it copied in the xterm and it didn't error. Why does the usb drive have all tha old files and none of the corrected or newer files. Should not cp -vaur be trusted to work, it is caused by cgroups and other protections added to the kernel as well as some utils. It looks like it copied the files but it did not really copy them but the xterm shows that it worked as in the old days. How can you trust a system that shows you the command worked, but it really did not, you the user can not tell,did it work or not, all you see is that it succeeded when it nothing really happened. At least throw some kind or error so the user knows it did not work. Another example is a file with 777 perms and a cat shows you nothing, you know that the file is not empty ( you put things in it) but cat or less shows nothing. Everybody has the perms to look at the file but go ahead and try to list and it shows you nothing. When you finally get the thing working by digging in to it you find that you lose 30 minutes to some user name nonsense. This is really my last attempt with linux ( as I am creating my own distro ). If this doesn't work I am going to something else. Either something BSD or windows. I just want some thing that works and can be trusted. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] OT: Re: How to install Systemd-193 on LFS
On 10/02/2012 10:14 AM, Chris W. wrote: Hello, I wanted to better understand the inner workings of systemd. Just having finished a LFS install on a test server, I thought LFS 7.2 might be a good basis for this. My goal was to eventually replace SysVinit completely with systemd. I fully expected lots of things to break, but was pleasantly surprised, that getting systemd to work was not all that hard. I started out with a guide from Lemon Lime which he posted on this list a year ago. Because LFS 7.2 is using a customized non-standard installation of Systemd/Udevd, additional steps were required. Systemd has matured quite a bit since last year and more distributions are using it, among them Arch Linux. Having lots of unit files available from other distributions, makes the switch a lot easier. So what I have everything working on my test server with a Plone CMS installed and find the built-in monitoring and logging capabilities of systemd quite remarkable. Bootup and shutdown times are considerably faster than with SysVinit. The following guide was put together as I documented the steps I took, and is intended help others to get started with systemd. I have put it in a similar format as instructions in the BLFS book to make it easier to apply. I hope you'll find this guide helpful and would welcome your comments and suggestions. Ugh, If Lennart and redhat succeed in moving linux to systemd I am moving to *BSD. I have talked to many BSD developers ( there was a linux fest on saturday here) and they plan on sticking to a scripts base init system. I am currently looking at their udev replacement/work alike. Systemd is a solution trying desperately to find a problem. From my vantage point systemd is a windows solution to a non existent problem/issue. What are the problems with sysvinit? If it isn't broke don't fixit! -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] OT: Re: How to install Systemd-193 on LFS
On 10/02/2012 12:39 PM, Bruce Dubbs wrote: Baho Utot wrote: If Lennart and redhat succeed in moving linux to systemd I am moving to *BSD. I have talked to many BSD developers ( there was a linux fest on saturday here) and they plan on sticking to a scripts base init system. I am currently looking at their udev replacement/work alike. Systemd is a solution trying desperately to find a problem. From my vantage point systemd is a windows solution to a non existent problem/issue. What are the problems with sysvinit? If it isn't broke don't fixit! I think your comments are a bit too strong, although I generally agree with the sentiment. I do think that LFS users should have the instructions available to try it out and make their own judgements. Yes there rules their system. OTOH godzilla mode on Look out Tokyo I am just getting aggravated with the direction of linux with the cgroups etc. Heck you can copy a set of files to a usb and back and now you have no perms to do anything with the files any more. going to sudo -i in the term won't help you one wit. You still can't do anything with the files. You can do a ls and they are there but you can open them in vi, kwrite etc or run them if the are executable. Even cat and less shows you nothing. cp -vaur don't work correctly any more, cp -vaur your files to a usb and it says it worked but when you look at the files they are the same old ones! rsync -var some files to a usb and let it complete then sudo rsync -var the same files ( up arrow add sudo to front of line ) and now the perms are all messed up. This is brought on by changes in the kernel. Dealing these new additions I just might break out my old redhat 6.0-6.2 ( no not RHEL ) if I thought it would run on this quad core. I just don't think the 2.0 kernel would work. I guess I could run it in windows in vbox! This Fedora 17 is just @#$%^ !! I'll be glad when I get LFS/BLFS built to KDE so I can ditch distros. I am still in the process of looking at pcBSD, if this nonsense keeps up (in/with/about linux) I'll abandon ship and start building BSD from scratch. I want a unix like system like the old days that just works. The nice thing about LFS, is that you don't need to install systemd. You can continue to use sysvinit or upstart or some other method. The real issue, in my opinion, is that systemd is a correction for using an initrd and building virtually every driver as a kernel module. These are needed for large distros and adds a little flexibility that a few users need, but slows things down for everybody. Just making an experienced user's guess, I think that a kernel with almost all drivers built as modules needs to search for the appropriate module when a device is initialized. systemd then fires off the appropriate boot script when found and parallelizes this device initialization issue. If you don't use modules, then you don't need all this. My experience with a very vanilla initrd is that it about doubles my init time (about 8 seconds to 16 seconds) even without modules. It goes beyond kernel modules, systemd will respawn daemons that have stopped/failed. Opps slap me silly they are not daemons they are services now. It will only start a daemon/process/service if it is needed by some package on demand, so much for you if you would like it started at boot. The log file is binary and not just a text file so if something barfs you need to boot to something that has the systemd utils on the to read the log file to what happened. Also on the horizon is software packages are starting to change there startup away from sysvinit scripts or scripts in general. You can see this with Arch linux. The whole thing reminds me of a patient with cancer (supporting all devices and boot partition methods). The doctor gives chemo (initrd) and then gives other drugs (systemd) to overcome the side effects of the chemo. Actually It is worst than that...It's flesh eating bacteria over 90% of your body and gobbling fast! For big distros, I don't see how this is avoidable, but for LFS and similar systems, we are cancer free and don't need drugs. Just some data: On my 7 year old P6, the boot time from mountvirtfs through network device initialization, ntpd, dbus, sshd, and fcron, takes 6-7 seconds (2 seconds of that are udev). Not that it matters. I haven't rebooted since May 3rd. My newer Core 2 is slightly faster (5 seconds, still 2 seconds for udev). -- Bruce I don't really care about boot up or shut down time... I care about the speed/ease of use while I am USING the computer. After all I want to USE it not boot it every 5 mins and watch. I always thought the my system boots faster that your system as lame. I would care if sysvinit took 5 minutes, and systemd took 5 secsthat is if the system just works without pissing me off due to this non sense. godzilla mode off Ah feel better now ;) -- http
Re: [lfs-dev] OT: Re: How to install Systemd-193 on LFS
On 10/02/2012 06:35 PM, Bruce Dubbs wrote: Baho Utot wrote: I am just getting aggravated with the direction of linux with the cgroups etc. # CONFIG_CGROUPS is not set Lucky you. Until I get a LFS/BLFS desktop running I am stuck with cgroups I'll be glad when I get LFS/BLFS built to KDE so I can ditch distros. Try xfce. The build is faster and it seems to run cleanly without a lot of unwanted bells and whistles. I ran it before, it's just the setting up that involved. It goes beyond kernel modules, systemd will respawn daemons that have stopped/failed. Opps slap me silly they are not daemons they are services now. It will only start a daemon/process/service if it is needed by some package on demand, so much for you if you would like it started at boot. xinetd resurrected. That stuff is needed if you want to trigger 100 processes for the ignorant user and don't want them all, but the big distro wants to be able to offer them. Yes I use xinetd to start leafnode on a server The log file is binary and not just a text file so if something barfs you need to boot to something that has the systemd utils on the to read the log file to what happened. I agree that that is, shall we say, short sighted. Of course there are a few files hanging around for a long time that do the same thing. For example wtmp, btmp. Yes but you really don't need to look at them most of the time Also on the horizon is software packages are starting to change there startup away from sysvinit scripts or scripts in general. You can see this with Arch linux. That's why we have LFS. That's why I building it ;) My way with a package manager ;) I don't really care about boot up or shut down time... I care about the speed/ease of use while I am USING the computer. The boot time is just one excuse being used to justify systemd. I agree with your observations. Ah feel better now ;) I'm glad. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] RFC Combining /usr with root directories
On 10/02/2012 07:42 PM, Bruce Dubbs wrote:
I am wondering about making a change to LFS to combine some of the root
directories and /usr. Looking at the sizes on a fairly complete system:
22M /lib
4.9M/bin
7.6M/sbin
1.4G/usr/lib
300M/usr/bin
15M /usr/sbin
It seems like the space needed for /usr is really not that much.
(Disclaimer: I have multiple versions of gnome, kde, qt, jdk, and xorg
on /opt that takes about 11 G)
What I was thinking about doing was changing Section 6.5 - Creating
Directories from
mkdir -pv /{bin,boot,etc/{opt,sysconfig},home,lib,mnt,opt,run}
mkdir -pv /{media/{floppy,cdrom},sbin,srv,var}
to
mkdir -pv /{boot,etc/{opt,sysconfig},home,mnt,opt,run}
mkdir -pv /{media/{floppy,cdrom},srv,var}
... (create /usr hierarchy)
ln -sv /usr/bin /bin
ln -sv /usr/lib /lib
ln -sv /usr/sbin /sbin
case $(uname -m) in
x86_64) ln -sv /usr/lib /lib64 ln -sv lib /usr/lib64 ;;
esac
As far as I can tell, everything should work as before, but we can
remove some of the things we do to move files and libraries from /usr to
/. The restriction, of course, is that /usr must be a part of the
rootfs, but a recommended size for that could be 20G and not really
affect anything.
-
While I'm at it, should we remove *.la files in the libraries:
find /usr/lib -name \*.la -delete
We can add that to Section 6.64 - Stripping Again. What I've found is
that I get a lot of warning messages and sometimes failures when
packages try to use the .la files, but just removing them seems to fix
things up without causing other problems.
Opinions?
-- Bruce
I have seen this in other distros as well but what is the bottom line?
Does this fix anything and what does it solve?
Is it really good or just change for change sake?
IMHO
It doesn't really do anything for me one way or another. I can keep it
split up or merged all together as I usually have /usr on the root
partition.
I heard though the grape vine that developers are moving out of /bin
/sbin /lib to /usr any way.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: [lfs-dev] LFS SVN-20120916
On 09/26/2012 09:19 PM, Fernando de Oliveira wrote: $ cat /media/LFS72/etc/lfs-release SVN-20120916 Built almost each package twice: with DESTDIR (I think only one did not support some kind of DESTDIR) and without. [putolin] I cannot remember anymore, but think that one of 6.57.Sysklogd-1.5 6.58.Sysvinit-2.88dsf does not accept DESTDIR. Both of those have a problem with DESTDIR for sysklogd I use: make BINDIR=$pkgdir/sbin prefix=$pkgdir install -j1 for sysvinit: make ROOT=$pkgdir -C src install -j1 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS SVN-20120916
On 09/27/2012 12:16 PM, Fernando de Oliveira wrote: Em 27-09-2012 09:33, Baho Utot escreveu: On 09/26/2012 09:19 PM, Fernando de Oliveira wrote: $ cat /media/LFS72/etc/lfs-release SVN-20120916 Built almost each package twice: with DESTDIR (I think only one did not support some kind of DESTDIR) and without. [putolin] I cannot remember anymore, but think that one of 6.57.Sysklogd-1.5 6.58.Sysvinit-2.88dsf does not accept DESTDIR. Both of those have a problem with DESTDIR for sysklogd I use: make BINDIR=$pkgdir/sbin prefix=$pkgdir install -j1 for sysvinit: make ROOT=$pkgdir -C src install -j1 Thanks, Baho. Yes, both had problem, but I (only) succeeded to solve in one of them, as I remember. If you have any more trouble with packages using DESTDIR just let me know as I am using a package manager and it uses DESTDIR or a work around. I should be able to help you with that. I have all the package from LFS-7.2 working with DESTDIR and I am just starting BLFS which I am on the security section. Just started it today. I also have a full file list of all the stuff each package installs and where it installs to, if that is of any use/value to anyone. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] FYI: Network bread crumbs
I have just completed a LFS-7.0 build and I had some problems booting. When I was going through the boot scripts I noticed that there are some consistences with the book that is carry forward to the svn book. In this section at the end I stills refers to /etc/sysconfig/network-devices/ifconfig.eth0/ivp4. Should be /etc/sysconfig/ifconfig.eth0 I believe. 6.3.3. Deploying LFS on Multiple Systems One of the advantages of an LFS system is that there are no files that depend on the position of files on a disk system. Cloning an LFS build to another computer with an architecture similar to the base system is as simple as using tar on the LFS partition that contains the root directory (about 250MB uncompressed for a base LFS build), copying that file via network transfer or CD-ROM to the new system and expanding it. From that point, a few configuration files will have to be changed. Configuration files that may need to be updated include: /etc/hosts, /etc/fstab, /etc/passwd, /etc/group, /etc/shadow, /etc/ld.so.conf, /etc/scsi_id.config, /etc/sysconfig/network and /etc/sysconfig/network-devices/ifconfig.eth0/ipv4. I haven't found the error any where else but a grep maybe in order;) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] FYI: udev Gentoo fork
FYI It appears that Gentoo has forked udev http://forums.gentoo.org/viewtopic-p-7125718.html They want to produce a standalone udev Maybe you folks are interested? -- Ineptocracy (in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] FYI: udev Gentoo fork
On 08/28/2012 11:10 AM, Bruce Dubbs wrote: Baho Utot wrote: FYI It appears that Gentoo has forked udev http://forums.gentoo.org/viewtopic-p-7125718.html They want to produce a standalone udev Maybe you folks are interested? It is worth watching. Our technique of using a custom Makefile is probably a little easier to maintain. -- Bruce True If gentoo succeeds then you have just another package configure;make;make install ;) -- Ineptocracy (in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] FYI: udev Gentoo fork
On 08/28/2012 12:03 PM, Bruce Dubbs wrote: Baho Utot wrote: On 08/28/2012 11:10 AM, Bruce Dubbs wrote: If gentoo succeeds then you have just another package configure;make;make install ;) I've always thought that configure (autotools) is overkill for linux only packages, The kernel doesn't use it. Why should systemd/udev or util-linux? It's not as if those packages will run under Solaris or AIX. -- Bruce What about BSD? -- Ineptocracy (in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] FYI: udev Gentoo fork
On 08/28/2012 01:08 PM, Bruce Dubbs wrote: Baho Utot wrote: On 08/28/2012 12:03 PM, Bruce Dubbs wrote: Baho Utot wrote: On 08/28/2012 11:10 AM, Bruce Dubbs wrote: If gentoo succeeds then you have just another package configure;make;make install ;) I've always thought that configure (autotools) is overkill for linux only packages, The kernel doesn't use it. Why should systemd/udev or util-linux? It's not as if those packages will run under Solaris or AIX. What about BSD? Does BSD use udev, systemd, or util-linux? AFAIK, those packages rely on /sys and /proc. I don't know if BSD supports those file systems or not. -- Bruce I don't know either but there is a man page that does say it works with bsd. -- Ineptocracy (in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] FYI: udev Gentoo fork
On 08/28/2012 04:57 PM, Bruce Dubbs wrote: Baho Utot wrote: On 08/28/2012 01:08 PM, Bruce Dubbs wrote: Baho Utot wrote: On 08/28/2012 12:03 PM, Bruce Dubbs wrote: Baho Utot wrote: On 08/28/2012 11:10 AM, Bruce Dubbs wrote: If gentoo succeeds then you have just another package configure;make;make install ;) I've always thought that configure (autotools) is overkill for linux only packages, The kernel doesn't use it. Why should systemd/udev or util-linux? It's not as if those packages will run under Solaris or AIX. What about BSD? Does BSD use udev, systemd, or util-linux? AFAIK, those packages rely on /sys and /proc. I don't know if BSD supports those file systems or not. I don't know either but there is a man page that does say it works with bsd. Which man page? -- Bruce I found it by google bsd udev -- Ineptocracy (in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] FYI: udev Gentoo fork
On 08/28/2012 05:26 PM, Bruce Dubbs wrote: Baho Utot wrote: On 08/28/2012 04:57 PM, Bruce Dubbs wrote: Baho Utot wrote: On 08/28/2012 01:08 PM, Bruce Dubbs wrote: Baho Utot wrote: On 08/28/2012 12:03 PM, Bruce Dubbs wrote: Baho Utot wrote: On 08/28/2012 11:10 AM, Bruce Dubbs wrote: If gentoo succeeds then you have just another package configure;make;make install ;) I've always thought that configure (autotools) is overkill for linux only packages, The kernel doesn't use it. Why should systemd/udev or util-linux? It's not as if those packages will run under Solaris or AIX. What about BSD? Does BSD use udev, systemd, or util-linux? AFAIK, those packages rely on /sys and /proc. I don't know if BSD supports those file systems or not. I don't know either but there is a man page that does say it works with bsd. Which man page? I found it by google bsd udev I found this: Posted by Lennart at Mon Aug 23 17:46:50 2010 Matthew, systemd is Linux-only. We have no plans to support niche kernels. That'd would severely limit our technical options and hold Linux back unnecessarily. If Debian cares about those kernels, it's on them to provide support for it. Note however, that Upstart doesn't work on those other kernels either and similar to us has little interest in supporting it. Note that nothing stops Debian to ship systemd on Linux by default and provide SysV compatibility scripts for the other OSes. Now that udev is a part of systemd, I'd say that udev is also linux only. -- Bruce I can't disagee with that. All thou I hope the gentoo udev fork goes well -- Ineptocracy (in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] FYI: man-db LFS-7.1-rc1
I have this enabled in this --with-db=gdbm maybe add it to this package, since gdbm is used in the base system? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] FYI: man-db LFS-7.1-rc1
On 08/28/2012 06:05 PM, Bruce Dubbs wrote: Baho Utot wrote: I have this enabled in this --with-db=gdbm maybe add it to this package, since gdbm is used in the base system? It's the default: checking gdbm.h usability... yes checking gdbm.h presence... yes checking for gdbm.h... yes checking for gdbm_fetch in -lgdbm... yes checking for gdbm_exists... yes ... configure: default DBLIBS = -lgdbm If this was a change, it would not be appropriate for the current target which is in a package freeze and where we only want to change instructions if there are significant problems. Text issues are more likely to be updated before release. -- Bruce Ok thanks -- Ineptocracy (in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] FYI: mountpoint
I am building LFS-7.0 but this may also be true of the latest LFS I have found that mountpoint and its man page is in util-linux and sysvinit packages. I know that the way LFS installs packages the sysvinit package would over write the util-linux but. Which should really be kept? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] FYI: mountpoint
On 08/28/2012 06:30 PM, Armin K. wrote: On 08/29/2012 12:28 AM, Baho Utot wrote: I am building LFS-7.0 but this may also be true of the latest LFS I have found that mountpoint and its man page is in util-linux and sysvinit packages. I know that the way LFS installs packages the sysvinit package would over write the util-linux but. Which should really be kept? http://www.linuxfromscratch.org/lfs/view/stable/chapter06/sysvinit.html http://www.linuxfromscratch.org/lfs/view/development/chapter06/sysvinit.html 7.1 and latest SVN contain instructions to remove the program from sysvinit. I am not sure about LFS 7.0. I don't think mountpoint was there in LFS 7.0 version of util-linux. It is both present in LFS-7.0. My package manager caught it otherwise I would not have found this issue. OK I will need to rebuild util-linux and sysvinit as I removed the util-linux one Thanks -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] FYI: mountpoint
On 08/28/2012 06:39 PM, Ken Moffat wrote: On Tue, Aug 28, 2012 at 06:28:11PM -0400, Baho Utot wrote: I am building LFS-7.0 but this may also be true of the latest LFS I have found that mountpoint and its man page is in util-linux and sysvinit packages. I know that the way LFS installs packages the sysvinit package would over write the util-linux but. Which should really be kept? On my current system (7.2-rc), both mountpoint and the manpage are from util-linux. We are currently removing it from sysvinit with a sed: sed -i -e 's/utmpdump wall/utmpdump/' \ -e '/= mountpoint/d' \ -e 's/mountpoint.1 wall.1//' src/Makefile No idea when we started doing that, but if it was overwriting in 7.0 it's fixed now. ĸen Ok thanks -- Ineptocracy (in-ep-toc’-ra-cy) – a system of government where the least capable to lead are elected by the least capable of producing, and where the members of society least likely to sustain themselves or succeed, are rewarded with goods and services paid for by the confiscated wealth of a diminishing number of producers. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS SVN and Systemd Report
On 06/01/2012 01:13 PM, Armin K. wrote: [putolin] Ah yes ... Some apps use those for loading modules. For example, cyrus-sasl is one of those, but I've patched it not to use them, but the .so ones directly. Among those is mpg123 which also uses .la files by default but they can be overwritten by configure switch. Possibly the sane does that too ... Haven't had time to check. I am following Debian and they announced removal of those ... Archlinux has removed them too. On my Arch linux boxen ImageMagick-6.7.6, libgphoto2, libarchive, libcanberra and libneon has .la files For example see http://www.archlinux.org/packages/extra/x86_64/neon/ click view file list. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Once more: Package Management
On 05/20/2012 07:09 PM, Ken Moffat wrote: [putolin] The more I think about this, the less happy I am. Point 2 doesn't really help editing BLFS as far as I can see (upgrading a package usually needs several builds - typically, for me, a first to see if it actually works when I use it, then others to get nice clean measurements, check what is in the DESTDIR (or INSTALLROOT), and review options for the optional dependencies and any testsuite. OK, for a few packages I will build them without being able to confirm that they still work (e.g. mutt in the recent tagging), but in general the absence of required dependencies is the least of the issues - and anyway, sometimes the dependencies need to be upgraded. Then there is the question of dependencies - in BLFS we don't normally tell people how to use optional deps. Sometimes they are picked up automatically, but many times you have to pass a switch to get them used. The instructions in BLFS are hopefully correct, but Just use the dependencies that are required that's in the book. You as a user/builder can add any additional one you would like. they don't suit everyone. I'm also wary of standard workflows - my own LFS build is different enough (nothing updated in /sources, because that is an nfs mount on my systems, and with efforts to remove many of the static libraries) that I expect pain. And that's just for LFS. For BLFS, I suspect this sort of change will actually increase my workload and therefore reduce my contributions. Rationale: (B)LFS-style development by hand becomes a huge undertaking. BLFS _is_ a huge undertaking - and it's a difficult beast to maintain. In order to create a stable reference page in BLFS an editor has to have spent the time to build all of LFS, tweak it, go through current BLFS, manually install dependency packages and then carefully document the package he builds. No two developers are guaranteed to have the same environment, either, so accuracy and stability becomes an issue. Indeed. For BLFS, I'm typically now building on both the last LFS release, and also on a more recent svn version to make sure that when I say it builds and works with 7.1 it does, and to detect if any change in a newer LFS package has broken something along the way (nothing recent, but I can remember pain in a package from a grep update: something to do with manpages in a docbook package, I think, which only bit me some time later because I hadn't been building whichever package it was, and also problems caused by newer kernel headers). pacman package management also has a set of tools to check the resulting package for corectness based upon LSB. It will also detect permission problems and RPATH issues. The intention is good, but I'm not at all convinced that the plan will help. Also, can I really trust whoever is permitted to edit a book (I'm assuming that part of the aim is to get more people editing in BLFS ?) to have an uncompromised system, and to not want to upload compromised binaries ? For the xml in the book, and for patches, we can look at what is being changed. For a binary, how do we know what was done to it ? Distros have build machines with restricted access and some degree of security. Is LFS going to need signed binaries and a ring of trust ? One doesn't need to fetch a binary, just the PKGBUILD file and then you can build it If I upload an unsigned binary package, the only way you can verify it is by following the build instructions and seeing if you get the same result. I gave up 'farce' testing (seeing if binaries were the same after an LFS system built itself) because there were too many inexplicable differences, probably caused by randomisation of addresses. Posts in the last few months have suggested that this problem is no longer present, but don't understimate the difficulties of trying to see if my binary build matches yours using the same instructions and the same versions of everything. ĸen I have placed my build of LFS 6.8 using Arch linux pacman package manager onto github. The URL: github.com/baho-utot/LFS-pacman Have a look at it if you like. I don't follow the recent comments at all. Pacman packeage manager has some great features that makes rooling your own easier. For example if I get the PKGBUILD for a package that is in BLFS from someone then I am not duplicating my effort and I have a mecanisim that gives me a package that will work. Package management is also learned so why not include something in the book? I see using pacman package management as a plus. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Once more: Package Management
On 05/19/2012 09:26 AM, Jeremy Huntwork wrote: I've been holding back bringing this up on-list for a while because I intended to do the bulk of the work and then present a working system to the community for comment and review. I still intend to do that, but given some recent discussions, I think the time is right to bring this up and see where it goes. (Sorry for the cross posting, but since it involves both projects, I wanted to make sure all saw it - if possible, please reply on lfs-dev.) Proposal: 1. Adjust LFS/BLFS to auto-generate build recipes for individual packages that a packaging tool can use to create binary packages with meta information included such as dependency tracking. 2. Store 'official' copies of those binary packages in a developer package repository so that when developing (primarily BLFS) a dev can automatically pull and install into a build environment the dependencies he needs to build and create an individual package. 3. Create a standard workflow and tools whereby a developer can accomplish #2 and edit the book accordingly in an efficient, reliable way. Rationale: (B)LFS-style development by hand becomes a huge undertaking. BLFS _is_ a huge undertaking - and it's a difficult beast to maintain. In order to create a stable reference page in BLFS an editor has to have spent the time to build all of LFS, tweak it, go through current BLFS, manually install dependency packages and then carefully document the package he builds. No two developers are guaranteed to have the same environment, either, so accuracy and stability becomes an issue. The same is true of the LiveCD project, and is the main reason why it sits dead today. It is difficult to maintain when there are no packaged binaries to draw from and the entire thing is a scripted source build. Let me just say now that because (B)LFS is primarily (and probably should always be) about educating, I don't think we should require end-users to use package management. Mainly the proposal is intended to assist in development. However, if we have taken the time to incorporate PM in our dev workflow, we can make the option of building via PM tools available to readers if they wish to use it for themselves and build their own package repository. Details: (The following details assume pacman is the package manager chosen, but it could conceivably be another, such as rpm5.) 1. The end of LFS chapter 5 is modified to (optionally) build the packaging tool and any dependencies it has. 2. LFS chapter 6 is modified so that for each package a build recipe (e.g. PKGBUILD file) is generated from the book's source. A reader is given the option of carrying out the build manually or via the packaging tool. 3. LFS devs create official copies of the binary packages and install them to a semi-public package repository 4. BLFS is modified to also generate build recipes (PKGBUILD files) from its source 5. As BLFS devs work on individual packages, they can use the defined workflow and tools to generate a chroot environment with only the packages they need for build-time dependencies - they can then both produce a binary version of the package as well as document what they've done, the end product being a BLFS page which will generate/correspond to the PKGBUILD file. 6. BLFS dev updates the BLFS binary package repository with the 'official' package and other devs can now draw from and use those when working on their respective package. There are, I'm sure, both positives and negatives to this proposal, and I'd like to hear everyone's thoughts. I intended to do all the development in the jh branch, but if there are more parties interested in helping this development, then I'm also open to sharing the workload and perhaps creating an environment where this can be done together. JH I have in the past worked on LFS-6.8 and have a completed pacman build for it. I wanted to build a desktop system from LFS/BLFS but it was too much work for me. I have not gone further because BLFS is a beast as you say. I completed a server using LFS/BLFS that handles mail web and news services. Sharing the work using pacman would be great, maybe we can exchange notes? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS-8.0
On Sunday 29 January 2012 10:46:19 pm Bruce Dubbs wrote: Sigh. http://www.phoronix.com/scan.php?page=news_itempx=MTA0OTY http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge -- Bruce I believe LFS is now working in this direction Myth #8: The /usr merge will break my old installation which has /usr on a separate partition. Fact: This is perfectly well supported, and one of the reasons we are actually doing this is to make placing /usr of a separate partition more thorough. What changes is simply that you need to boot with an initrd that mounts /usr before jumping into the root file system. Most distributions rely on initrds anyway, so effectively little changes. What where you saying about initramfs not being needed ;^) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS-8.0
On Monday 30 January 2012 12:35:54 pm Bruce Dubbs wrote: Baho Utot wrote: On Sunday 29 January 2012 10:46:19 pm Bruce Dubbs wrote: Sigh. http://www.phoronix.com/scan.php?page=news_itempx=MTA0OTY http://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge -- Bruce I believe LFS is now working in this direction Not yet. Myth #8: The /usr merge will break my old installation which has /usr on a separate partition. Fact: This is perfectly well supported, and one of the reasons we are actually doing this is to make placing /usr of a separate partition more thorough. What changes is simply that you need to boot with an initrd that mounts /usr before jumping into the root file system. Most distributions rely on initrds anyway, so effectively little changes. and we disable those that don't like it. OK What where you saying about initramfs not being needed ;^) I have been thinking about this quite a bit. I believe upstream has lost it's way. One of the principles of Unix was always to keep things simple. The reason that we have a separate /bin /sbin /lib is so that other partitions can be mounted without all the overhead in /usr. Now that same capability is, for some reason, being moved to initramfs where there is a duplication of packages, and a large decrease in transparency and and an associated increase in complexity. Yes I agree. This is the biggest reason I am moving from other distros to LFS. I like what LFS is. I like the old unix ways. This split package and dependency _HELL_ is not good. The only thing that I would like see added to LFS is lvm/raid/encrypted root systems and maybe KVM. I think everything is the more or less covered. Why? Just because something can be done, doesn't mean that it should be done. No it means it _shouldn't_ be done ;) systemd is another instance of the same symptom. Instead of a few relatively simple scripts and a very simple init, we have a large opaque monstrosity. I see nothing of value in systemd. All this seems to be a product of we are in charge, we'll do what we want attitude. Just make the changes and everybody will follow. We are going away from community and towards an oligopoly to the ruin of open source. -- Bruce I think this concept is one of all/most the old farts are moving on...to be taken over by the youngens who are now thinking that they are the masters when thye haven't a clue for history. I will take the ways of unix from the 70's, It is that way for many _good_ reasons. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS-8.0
On Monday 30 January 2012 06:26:52 pm Gerard Beekmans wrote: I think this concept is one of all/most the old farts are moving on...to be taken over by the youngens who are now thinking that they are the masters when thye haven't a clue for history. I will take the ways of unix from the 70's, It is that way for many _good_ reasons. Yes, you're right, certain things from the 70s were like that for many good reasons but some of them have become bad reasons as technology has evolved. What follows is a devil's advocate point of view in an attempt to keep an open mind and consider all sides equally. 40 years ago hardware and software were extremely limited compared to today's standards. If we never changed anything, we'd still be on 8-bit systems today with little RAM and HDD. A lot of people disliked the recent 64-bit change as well. In some ways it was a royal headache to deal with. Now we all but live breathe it and are (mostly?) happy for 64-bit architectures because it allows us to address a lot more RAM and HDD. All that additional RAM and HDD allows us to virtualize systems on just about any system and save a lot of money. LFS development is faster cheaper this way. 10 years ago it wasn't as easy of efficient having multiple computers around my desk so I could test instructions on one machine while writing the book on another. There is a fine line between following a tried, tested true method with philosophies such as why break what wasn't broken in the first place and being at the far end of that spectrum called stuck in the past. Change is sometimes painful but not all change is ultimately bad. Just don't fall into change for the sake of change. I think it's important for everybody to at least keep an open mind. Another example is that nobody wants the Internet of the old days back when 2400 baud and slower modems were around. It wasn't necessarily broken; it worked fine, just slow. Now we have GigE Internet readily available. Progress comes at the price of adopting paradigm shifts and letting go of old and outdated ways. When we arrive on the other side, we sometimes are better off for it. Now a lot of people wouldn't dream of going back to a simpler time of 2400 baud, 8-bit computers and a couple of kilobyte of RAM. Sometimes simpler times are also the thing that hold you back from beneficial improvements. Ah yes I would like to go back to those days. As for systemd specifically, I have to agree it feels messy and less than ideal. I wouldn't be overly happy if I were to be forced into using it. Some of its benefits do make sense even if the implementation is rough around the edges. I'm trying to at least see past that and keep an open mind for the time being. Perhaps its final implementation down the road won't be so bad. If nothing else, it's something new to play with. Whether it makes it into the LFS book is a whole different matter. There are valid plus sides to the merging /usr debate. I can't remember if this was mentioned on the freedesktop.org page linked by Bruce. If everything OS provided is together in one top level directory, it would make a lot of things simply more elegant. Backups being one of them. Lookup the bumblebee fiasco on google, The bumble devs had a line rm -rf /usr /libwhat ever in a install script so you installed the app and your /usr was gone. Do you really want everything in /usr? I don't, I mess up more that I straighten up ;) Sure, all those separate mount points existed for a number of very good reasons. Those reasons evolved over the decades and maybe we're truly coming to a point where they can be considered obsolete. One of those reasons was due to hard drive capacity problems. There wasn't always enough room to store all of /, /usr, /var, /tmp, /home and others on the same drive when all you had was 100-300 MB per physical drive. Having a few tools in /bin and /sbin was by some considered a work-around/hack so you could boot a mini system with enough tools to repair bring up all the other partitions into a full system that may have spanned half a dozen drives. Now that we don't have that hard drive size problem and more intelligent file systems that are harder and harder to corrupt, do we still need to stick with those work-arounds? The work-arounds have become common practice and we've adopted them as the only true way of doing things. But they were considered work-arounds by some, and eventually a work-around is removed when the original issue no longer exists or has been fixed by other means. I still like the filesystem as it is now. I don't see all the pain/problems that folks say it is causing. Nowadays with multi-TB size drives space at least is no longer a concern. There were other good reasons to have separate partitions. For example, if /home filled up it wouldn't necessarily crash the system as /var wouldn't fill up. Subsystems such as email would
Re: [lfs-dev] LFS-8.0
On Monday 30 January 2012 07:40:11 pm Gerard Beekmans wrote: Just don't fall into change for the sake of change. Good point. Lookup the bumblebee fiasco on google, The bumble devs had a line rm -rf /usr /libwhat ever in a install script so you installed the app and your /usr was gone. Do you really want everything in /usr? A typo is a typo. Say you wanted everything in /usr/local/lib/googlestuff A typo could easily be rm -rf / usr/local/lib/googlestuff - I've made that mistake once in my life. It doesn't matter where you put stuff in the end. It won't be safe from a typo. If the filsystem was mounted ro you would be safe. My point was if everything is in /usr would it not be harder to correct the typo? If the filesystems are split up you can some what protect against the typo things. I mount things as ro and only have the things I need to change mounted rw. Saved me a number of times it did. Also I use lvm snapshots so if I did hose root I can restore it without too mch of a problem. Everybody can purse the change if that is what they want, just leave enough of the old for me. That's why when change happens slowly it's often better. It gives everybody a sense of being able to keep up and not feel the rug is pulled out from under them every 6 months. There are days I like pulling the rub out from under me just so learn something new. Other days I'd like things to stay the same so I can take a breather once in a while and not be out of date within a few months. Gerard -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] systemd
On Wednesday 25 January 2012 01:23:01 pm Bruce Dubbs wrote: I'm sure that systemd solves a problem for 1% of users, but for 99%, it's not needed. I recently installed Fedora 16 on a virtual system with exactly one partition. The listing below is what I got for a simple 'mount' command. I am against adding systemd to LFS. -- Bruce +1 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] LFS Direction
On Thursday 12 January 2012 04:32:49 pm Bruce Dubbs wrote: I'd like to discuss the direction of LFS with respect to where upstream developers appear to be going. Currently we use sysvinit and udev as the basis of bringing up LFS. We do not use an initd/initramfs or systemd. LFS now provides a good, solid, and relatively simple way of bringing up a single system. It does not directly support any of these more complex methods. The question is: should LFS add these capabilities? If we did decide to implement the capability for an initramfs and/or systemd, I think we might need a whole new chapter in the book. One of the major purposes of LFS is to explain how the packages in Linux fit together. If we don't add things like an initramfs to the book, we will probably need to limit what our users can do. For instance, we will probably need to require that /usr cannot be on a partition separate from /. In the era of TB hard disks, that is probably not a big deal. It's hard to find a thumb drive smaller than 16GB any more. Many organizations give them away as promotional items. Any changes we decide to make do not need to be done right away. We are What do you think? -- Bruce From a users/possible future contributor: I would like to see an initramfs supporting lvm/raid/encrypted root filesystem. Even if the user has to hack on it to get anything past lvm. Lvm is nice on the large hard drives. The hint from Bryan is a good start to provide an initramfs. Encrypted root filesystems is good for security as in if some one pinches your computer or you lose it somehow you are not giving up any of your sensitive information. As far as systemd...whats wrong with the present system? I am in process of building LFS/BLFS + lvm + trinity. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] lvm hint
On Wednesday 04 January 2012 11:40:59 pm Bryan Kadzban wrote: Now that I have access to SVN again, let me throw together a 1.0.1 tarball and upload it, with the recent changes I've made. (This does include at least hackish support for /run.) That would have a better chance of working than 1.0 would. There. It's in the same directory as the -1.0 tarball on lfs.org. I have a LFS-6.8 version installed on a laptop, the install is on partition /dev/sda8. I installed your tarball and then lvm2. I fixed up the config file and put it into /etc. Created a LVM partition and formated and rsynced the entire LFS-6.8 build to the lvm partition. The LFS was on /dev/sda8 and I called the other lvm-root I changed the fstab (in the lvm-root) to point the / to /dev/mapper/lvm-root I then did mkinitramfs -k 2.6.37, then added an entry into menu.lst. The grub line is kernel /linux-lfs-6.8 root=/dev/mapper/lvm-root ro initrd /initramfs.cpio.gz I did the above from memory so it may not be right but on the laptop it is correct. When booted the kernel panics can't find mapper/lvm-root When I remove the root=/dev/mapper/lvm-root from the grub menu entry it boots the /dev/sda8 successfully. I built the initramfs from the /dev/sda8 partition install. I would have built it from the lvm-root but I didn't know how to do that as I could not boot it just yet. Is there something I am doing wrong? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] lvm hint
On 01/03/2012 10:20 PM, Bryan Kadzban wrote:
On Tue, Jan 03, 2012 at 05:36:18PM -0500, Baho Utot wrote:
On 01/03/2012 03:44 PM, Ren? GARCIA wrote:
Hi,
I am using LFS 7.0 with LVM2/ext4 for all partitions excepted /boot
which is a primary partition using ext4.
I haven't followed the Bryan Kadzban hint.
What I needed :
- LVM2 2.02.88
- device-mapper 1.02.28
- dracut-013
- some minor modifications in LFS init scripts (to properly remount
/dev/pty when initramfs already did it)
In my configuration, /usr and / are on the same partition. It make
things much more easy when executing the first init scripts.
My main grub entry is :
menuentry LFS7.0 on LVM2 {
insmod ext2
set root=(hd0,1)
linux /vmlinuz root=LABEL=root-fs ro
initrd /initramfs.img
}
/boot is on the 1st primary partition of the first disk
vmlinuz and initramfs.img are symbolic links to kernel and initramfs
files in /boot
initramfs is generated using dracut
While installing I've been using a second hard drive for testing LVM2.
All volumes are using ext4 filesystem with labels to identify them.
I labelled my root filesystem root-fs. As it is part of a LVM2 group,
the generated dracut script will enable all LVM2 groups to find it. If
it's not part of a LVM2 group you can still add grub the option
rd_LVM_VG=yourVGname to the linux line to enable a specific LVM2 group
when in initramfs.
I'm sorry but I don't have a step by step hint to give you. I needed
many reboots to manage LFS7 to run on LVM2.
Regards,
Ren?
Le 03/01/2012 21:50, Baho Utot a ?crit :
Is the lvm hint by Bryan Kadzban still viable/relavent?
It works with current kernels. (Well, as of 2.6.39 anyway. That's
getting less and less current as time passes. :-( ) I have not had
time to upgrade the kernel to see if it's still working though, and
upgrading udev is always a hit-or-miss proposition due to its
development practices (the developers think you should upgrade your
kernel before udev, and they also lump the glibc kernel headers in with
that; this is pretty much impossible in any running system though).
I have also not tried to upgrade cryptsetup beyond 1.0.2 or so, or LVM
beyond whatever version is in the current hint.
I *have* had time to add a few things to the lfs-initramfs package,
though I don't remember if I released a newer tarball or not. SVN is
what I'm using on my own system (rootfs on LVM on dm-crypt, so
everything except RAID).
In somewhat more general terms: You definitely need some kind of
initramfs to put your rootfs on LVM. Whether you use a prepackaged
initramfs builder like dracut (those were always either too magical or
too generic for me, or both, which is why I wrote my own), or the one
referred to in the hint, or one you write yourself, doesn't really
matter.
I would like to boot LFS installed to a lvm partition.
I have a 2 TB drive that I use and it is currently booting Arch linux on lvm.
I would like to convert to use LFS/BLFS. I would like to get away from Arch
now because of the bloat and the crazy split packages. Just try to build
the base packages. LFS/BLFS suits me just fine and I like the way it is
being developed. I am going to use LFS/BLFS with Trinity.
I will need to boot into lfs install in a lvm partition. So any advice will be
greatly apreciated.
I could boot LFS on a regular partition and use lvm for everything else but
that doesn't really fit how I want to use linux.
Thank you for all your hard work.
I will look at dracut thanks
I may need help with the init scripts as that is not one of my good points.
That's one of the reasons I really don't like many of the premade
initramfs packages: they all assume you want a /dev from the initramfs
to also be used by the final system. But that means you need all the
user/group resolution handling to be up and running when the initramfs
runs, and (especially for a NIS/YP/whatever system) that's not really
always feasible.
So the one that I built explicitly works with the standard LFS
bootscripts; it kills off udevd, unmounts the tmpfs, etc., after the
rootfs is mounted and before it hands off control to /sbin/init. Then
the standard bootscripts can do their thing: remount /dev, retrigger all
the events, use the standard user/group resolution, etc., etc. (You
also don't need to copy every single udev rule, or udev helper script,
into the initramfs. If they're missing, nothing cares, as long as they
aren't needed to find the rootfs.)
I find a compartmentalized setup works a *lot* better (where the
bootscripts don't depend on any particular initramfs, and the initramfs
doesn't do something that the bootscripts are required to fix later,
either).
Thanks for the reply.
I am not looking for something too complicated, All I need is to be able
to boot into lvm with minimal trouble.
Will your system work with LFS7.0 or just 6.8?
I am going to build a system and I can go either way.
--
http://linuxfromscratch.org
[lfs-dev] lvm hint
Is the lvm hint by Bryan Kadzban still viable/relavent? I would like to boot LFS installed to a lvm partition. I have a 2 TB drive that I use and it is currently booting Arch linux on lvm. I would like to convert to use LFS/BLFS. I would like to get away from Arch now because of the bloat and the crazy split packages. Just try to build the base packages. LFS/BLFS suits me just fine and I like the way it is being developed. I am going to use LFS/BLFS with Trinity. I will need to boot into lfs install in a lvm partition. So any advice will be greatly apreciated. I could boot LFS on a regular partition and use lvm for everything else but that doesn't really fit how I want to use linux. Thank you for all your hard work. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] lvm hint
On 01/03/2012 03:44 PM, René GARCIA wrote:
Hi,
I am using LFS 7.0 with LVM2/ext4 for all partitions excepted /boot
which is a primary partition using ext4.
I haven't followed the Bryan Kadzban hint.
What I needed :
- LVM2 2.02.88
- device-mapper 1.02.28
- dracut-013
- some minor modifications in LFS init scripts (to properly remount
/dev/pty when initramfs already did it)
In my configuration, /usr and / are on the same partition. It make
things much more easy when executing the first init scripts.
My main grub entry is :
menuentry LFS7.0 on LVM2 {
insmod ext2
set root=(hd0,1)
linux /vmlinuz root=LABEL=root-fs ro
initrd /initramfs.img
}
/boot is on the 1st primary partition of the first disk
vmlinuz and initramfs.img are symbolic links to kernel and initramfs
files in /boot
initramfs is generated using dracut
While installing I've been using a second hard drive for testing LVM2.
All volumes are using ext4 filesystem with labels to identify them.
I labelled my root filesystem root-fs. As it is part of a LVM2 group,
the generated dracut script will enable all LVM2 groups to find it. If
it's not part of a LVM2 group you can still add grub the option
rd_LVM_VG=yourVGname to the linux line to enable a specific LVM2 group
when in initramfs.
I'm sorry but I don't have a step by step hint to give you. I needed
many reboots to manage LFS7 to run on LVM2.
Regards,
René
Le 03/01/2012 21:50, Baho Utot a écrit :
Is the lvm hint by Bryan Kadzban still viable/relavent?
I would like to boot LFS installed to a lvm partition.
I have a 2 TB drive that I use and it is currently booting Arch linux on lvm.
I would like to convert to use LFS/BLFS. I would like to get away from Arch
now because of the bloat and the crazy split packages. Just try to build
the base packages. LFS/BLFS suits me just fine and I like the way it is
being developed. I am going to use LFS/BLFS with Trinity.
I will need to boot into lfs install in a lvm partition. So any advice will
be
greatly apreciated.
I could boot LFS on a regular partition and use lvm for everything else but
that doesn't really fit how I want to use linux.
Thank you for all your hard work.
I will look at dracut thanks
I may need help with the init scripts as that is not one of my good points.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Glibc vulnerability . . . implications for LFS?
On 10/26/10 22:44, Bruce Dubbs wrote: Drew Ames wrote: Now I have another question. How do I make the patch in the link above into a .patch file that I can apply? Do I fill out the Submitted By, Date, Initial Package Version, Upstream Status, Origin, and Description, at the top, paste in the information from the link starting at the line with the diff command, and then give it all a .patch extension? You need an original and a modified version: diff -u modified orig name.patch Then edit the patch to add the other info at the top. The 'orig' and 'modified' are generally the package top level directory as in: orig: file.c modified: file.c -- Bruce Here's a helper #!/bin/sh # $Knoppix: localtools/usr/local/bin/mkpatch,v 1.2 2007-01-10 19:35:05 # bsd Exp $ # # mkpatch -- creates unified patch files for diff in given 2 files and, # or directories, also cares which one is newer :) # # see also diff(1) and patch(1) # prog=`basename $0` if [ $# -lt 2 ]; then echo Invalid argc $# 12 echo usage: $prog filename1 filename2 12 exit 1 fi if [ $1 -nt $2 ]; then new=$1 old=$2 else new=$2 old=$1 fi patch=`basename $new`.patch LC_ALL=C TZ=UTC0 diff -Naur $old $new $patch -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Why isn't dpkg included in the LFS book
On 10/26/10 12:03, Michael Schmidt wrote: Hi everybody! I was wondering: one of the things that gives me a headache when installing LFS, is that there is no generic package management system that you can use to install the basic system software (Chapter 6). I know, that the point of lfs is to built everything from scratch, but that not necessarily conflicts with dpkg, the only thing you would have to explain, is how a deb package is built from scratch eg. a hint would do the trick, then you could use dpkg to install all the packages in chapter 6. I know that dpkg is very light weight, and it should be no problem to include it at the beginning of chapter 6 (If you install the package without dselect). Just curious to get feedback, as of why this isn't a good idea. Greetings Michael It is left as challenge/exercise to your new found/gained experience. BTW I use arch linux pacman for package management, dpkg gives me heart burn. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
