patch-2.6.tar.gz has gone missing
lfs trunk on 2009 11 19 Under All Packages, patch-2.6.tar.gz has gone missing wget -c ftp://alpha.gnu.org/gnu/diffutils/patch-2.6.tar.gz --14:45:10-- ftp://alpha.gnu.org/gnu/diffutils/patch-2.6.tar.gz => `patch-2.6.tar.gz' Resolving alpha.gnu.org... 140.186.70.21 Connecting to alpha.gnu.org|140.186.70.21|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done.==> PWD ... done. ==> TYPE I ... done. ==> CWD /gnu/diffutils ... done. ==> PASV ... done.==> RETR patch-2.6.tar.gz ... No such file `patch-2.6.tar.gz'. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: patch-2.6.tar.gz has gone missing
On 11/19/09, Uwe Düffert wrote: > try ftp://ftp.gnu.org/gnu/patch/patch-2.6.tar.gz OK With that, I got a different md5sum than 5729b1430ba6c2216e0f3eb18f213c81 in the book. md5sum patch-2.6.tar.gz bc71d33c35004db3768465bcaf9ed23c patch-2.6.tar.gz -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: patch-2.6.tar.gz has gone missing
On 11/19/09, Matthew Burgess wrote: > The book switched over to using the .tar.bz2 file. Could you check the > md5sum matches that please? OK that matches. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: suggestion: add wget
On 12/23/09, ALIP BUDIANTO wrote: > The LFS team may just install wget without the deps but also tell a I didn't think wget or even ftp would work before getting internet connection, which for me, requires installing dhcpcd. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: klogd and System.map
On 2/18/10, Bruce Dubbs wrote: > My understanding is that klogd reads the symbols to translate kernel > oops to symbols. I think I saw that the kernel is now doing that > internally. In that case, there is no need for klogd to read System.map > at all. That is what Linus said in reply to an email: On Sat, 7 Nov 2009, linux fan wrote: > > "[PATCH] init/version.c: Define version_string only if" > causes sysklogd to report "Cannot find map" But isn't that what we _want_. If we have CONFIG_KALLSYMS, then we do _not_ want sysklogd to try to interpret kernel addresses, because the kernel will do that itself. So the sysklogd "Cannot find map" warning is a feature, not a bug. I think. Linus -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: klogd and System.map
On 2/18/10, Bruce Dubbs wrote: > I saw that when I was researching last night. I don't think it is a > feature. It implies something is wrong. When something is right in > Linux/Unix, the application should stay silent. I fussed a lot over this and the warning happen in ksym.c in sysklogd sources. I tried rival rsyslog which many distros ran to, but saw no clear advantage. It remains a mystery to me whether sysklogd actually looses any functionality due to this. It still prints all the panic stuff when it happens. But it is frustrating that apparently neither Linus or sysklogd maintainer cares. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: klogd and System.map
On 2/19/10, Bruce Dubbs wrote: > My first choice right now is the script with the unconditional -x as a > second choice. It seems script effectively does unconditional -x because it greps for Version_ which is what they removed which triggered this whole business. Does -x cause loss of information reported when needed? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Kernel 2.6.32.9 with fix BUG at fs/ext3/super.c
Looks like Kernel 2.6.32.9 is with fix fo BUG at fs/ext3/super.c in kernel/futex.c that glibc's test suite was known to trigger. http://marc.info/?l=linux-kernel&m=126428261230399&w=2 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: kernel and gcc-4.5
On 5/13/10, Bruce Dubbs wrote: > Curious. My next step will be to go back and rebuild everything. > Could there be a difference in gcc-4.5 with respect to which glibc was in service at the time it was built that contibutes to "it works for them and not for you"? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Just for fun
On 5/15/10, Bruce Dubbs wrote: > I added a new image to the lfs home page. > > http://www.linuxfromscratch.org/ > I don't know why, but the critter on the left really bothers me. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Migrating Expat to LFS
On 5/25/10, Bryan Kadzban wrote: > [snip] >> Until such time as a package that an LFS system requires cannot >> itself function without parsing XML, then there's seemingly no need >> for utiliites that handle XML to be in the LFS system. > [snip] > to suppress the failure ourselves, let's do it, and note that rebuilding > the package when libxml2/expat is available will enable extra > functionality. Or something like that. > > Yes, I think something like that. I'll throw another hat into this ring. I just don't like the idea of a package moving from BLFS to LFS and back again next time. I think if it moves, it stays. The best LFS is as straightforward and consistent as possible for all. It should also be as consistent as possible from release to release. The extra functionalities should really be in BLFS and LFS could contain an appendix with information (perhaps instruction pages or reference to BLFS) for adding these functionalities for those who want to build them while building LFS. The actual package in question might just refer to the section in that appendix. Let's not forget that shadow is in BLFS because someone might want to implement PAM or CrackLib. Most will not want to be bothered with these under current thinking. But for those that do, they might be afforded an opportunity to build them along with LFS. I don't know how many want PAM or Glade, but why not spare those that don't, and provide a reference to info for those that do. If not having it throws a test error, then provie some way to handle that if possible. Especially if it is safe to just say "ignore this test error". On the other hand, if expat (or libxml) needs to be in LFS, then that is where it needs to be, and no harm done. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
On 6/30/10, Andrew Benton wrote: > > But it won't boot very far. The kernel won't be able to mount its root > partition unless you manually edit the grub.cfg or compile the kernel > with an initramfs > It needs to be tested if it will boot based on the search line when the linux line omits the "root=/dev/sdax" parameter. In some cases, but not always, grub and linux can boot to the desired partition when the "root=/dev/sdax" parameter is absent. It won't boot if the fstab specifies "/dev/sdax" that is the wrong partition. However, with "LABEL=" it can work. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
On 6/30/10, Sebastian Plotz wrote:
> "The search lines are only meaningful for LFS systems if a separate boot
> partition and a LABEL or UUID entry for this partition in /etc/fstab is
> used."
>
It booted me and mounted /dev/sdd10
With this in grub.cfg
=
menuentry "GNU/Linux, with Linux 2.6.33 (search only)" {
insmod ext2
search --no-floppy --fs-uuid --set 11b62acd-ee91-43f7-a619-c4b5cb5fa5e7
linux /boot/vmlinux-2.6.33
}
With this in fstab
==
# Begin /etc/fstab
# file system mount-point type options dump fsck
#order
#/dev/sdd10 /ext3 defaults1 1
UUID=11b62acd-ee91-43f7-a619-c4b5cb5fa5e7 /ext3
defaults1 1
/dev/sdd8 swap swap pri=1 0 0
proc /procproc defaults0 0
sysfs /sys sysfs defaults0 0
devpts /dev/pts devpts gid=4,mode=620 0 0
tmpfs /dev/shm tmpfs defaults0 0
# End /etc/fstab
/boot is on the root partition
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
On 6/30/10, Stuart Stegall wrote: > ro is also unnecessary since around 2.2.x (I don't swear to that, it > could have been 2.1.x or 0.99.) The kernel is read-only by default. Confirmed. I requested a forced fsck by placing empty file with touch /forcefsck I booted as previously with no "ro" parameter and the fsck was performed. Also, I wonder ... since grub2 can search uuid, then if Linus can be convinced that this indeed works and is useful, maybe someday the kernel will do it. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
On 6/30/10, Bruce Dubbs wrote:
>
> The Linux kernel generally needs to be told what it's root partition is.
> To the best of my knowledge, it understands root=/dev/ and
> root=LABEL=label-name.
I so wished that to be true that I grasped at straws, but kernel won't
understand
root=LABEL=label-name any better than root=UUID=bla-bla-bla without initrd.
However, there is a somewhat cool thing which worked:
menuentry "GNU/Linux, with Linux 2.6.33 (label)" {
insmod ext2
search --no-floppy --label --set LFS-6-6
linux /boot/vmlinux-2.6.33
}
where LFS-6-6 is the e2label of the partition in question.
And fstab can have:
LABEL=LFS-6-6 / ext3 defaults1 1
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
On 6/30/10, Bruce Dubbs wrote: > This is a catch-22. udev populates /dev which is needed to determine > partitions. The only alternative is to do raw device searches and the > number of different device types and filesystems on those devices makes > this really prohibitive. GRUB does it, but that's not the kernel's job. Fine. Some day, some genius is going to figure out that making linux booting better is ok. At any rate, grub2 search line is not totally useless, and that is nice to know. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
On 7/1/10, splotz90 wrote: > Ok, so we say "The search lines are only meaningful for LFS systems if a > separate boot partition is used." ? A separate boot partition is not a necessity for using search. I works for me with boot as a subdirectory on the root / partition. I don't know how generally useful search is, but I was pleased to learn how it works rather than being told by the book that it is useless. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
On 6/30/10, Bruce Dubbs wrote: > > I'll ask the question again. How is search useful in an LFS environment > where we don't have initrd available? > By using search, one can entirely avoid using the grub drive and partition notation. e.g., (hd0,1) I alone find that potentially useful. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
On 7/1/10, Andrew Benton wrote:
> Why would we say that? You've not shown any meaningful use for the
> search lines on an LFS system.
Rather than stating "The search lines are not meaningful ...",
this exercise has revealed that the next 2 lines are equivalent in their effect:
search --no-floppy --fs-uuid --set 11b62acd-ee91-43f7-a619-c4b5cb5fa5e7
set root=UUID=11b62acd-ee91-43f7-a619-c4b5cb5fa5e7
and either of the above 2 lines supercede a line like this:
set root=(hd4,10)
whichever one occurs last.
So I found that I can have it like this if I choose:
menuentry "GNU/Linux, with Linux 2.6.33 (UUID)" {
insmod ext2
set root=UUID=11b62acd-ee91-43f7-a619-c4b5cb5fa5e7
linux /boot/vmlinux-2.6.33
}
In the LFS spirit of learning how linux works, I found learning
something about how the esoteric grub2 works to be meaningful. Anyone
is welcome to disagree.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
On 7/1/10, linux fan wrote: > something about how the esoteric grub2 works to be meaningful. Anyone > is welcome to disagree. > An alternative language might be that: The search line is not required on a typical LFS system. It could optionally be noted that there is an alternative to the use of grub's (drive,partition) notation on the root= line which is suggested by this scriptlet: read -e -p "Partition (/dev/sdXY): " p && tune2fs -l $p | grep UUID | sed -e "s/Filesystem \(UUID\):\s*/root=\1=/" -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
On 7/1/10, Sebastian Plotz wrote: > If the LFS-User has moved the /boot partition (NOT / partition), the > system will still boot (with help of the search line). > My understanding (from experimentation and documentation) is that the UUID is specifically generated for a specific file system. You would need to use dd or similar utility to move the filesystem to a different partition if you wished to preserve the UUID. If that is the case, it may do what was claimed. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
FYI
-
For grub-1.98 !!!
-
http://ubuntuforums.org/showthread.php?t=1195275
describes a way to save the last chosen boot option to default
Involved is /etc/default/grub file which must be user created:
==
cat > /etc/default/grub << EOF
# If you change this file, run 'update-grub' afterwards to update
# /boot/grub/grub.cfg.
GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
#GRUB_HIDDEN_TIMEOUT=0
#GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TIMEOUT=10
#GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
#GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"
GRUB_CMDLINE_LINUX=""
# Uncomment to disable graphical terminal (grub-pc only)
#GRUB_TERMINAL=console
# The resolution used on graphical terminal
# note that you can use only modes which your graphic card supports via VBE
# you can see them in real GRUB with the command `vbeinfo'
#GRUB_GFXMODE=640x480
# Uncomment if you don't want GRUB to pass "root=UUID=xxx" parameter to Linux
#GRUB_DISABLE_LINUX_UUID=true
# Uncomment to disable generation of recovery mode menu entries
GRUB_DISABLE_LINUX_RECOVERY="true"
# Uncomment to get a beep at grub start
#GRUB_INIT_TUNE="480 440 1"
EOF
There is no silly update-grub command, so use grub-mkconfig to update.
For grub-1.98, there is broken build
http://www.mail-archive.com/grub-de...@gnu.org/msg15254.html
One solution that worked is to NOT build in a separate build directory.
E.g., instead of:
mkdir build
cd build
../configure --bla-bla-bla
make
Do:
./configure --bla-bla-bla
make
Grub-1.98 puts 3 lines in a common area which can (should?) be removed
in the individual "menuentry" blocks:
insmod ext2
set root='([drive],[partition])'
search --bla-bla-bla
Since the search is redundant of set root, it is not necessary.
Since the silly 'echo Loading linux ...' will scroll off almost
immediately it is not necessary.
The resulting grub.cfg I got (after removing redundant and silly) was:
=
#
# DO NOT EDIT THIS FILE
#
# It is automatically generated by /usr/sbin/grub-mkconfig using templates
# from /etc/grub.d and settings from /etc/default/grub
#
### BEGIN /etc/grub.d/00_header ###
if [ -s $prefix/grubenv ]; then
load_env
fi
set default="${saved_entry}"
if [ ${prev_saved_entry} ]; then
set saved_entry=${prev_saved_entry}
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z ${boot_once} ]; then
saved_entry=${chosen}
save_env saved_entry
fi
}
insmod ext2
set root='(hd4,10)'
search --no-floppy --fs-uuid --set 11b62acd-ee91-43f7-a619-c4b5cb5fa5e7
set locale_dir=($root)/boot/grub/locale
set lang=en
insmod gettext
set timeout=10
### END /etc/grub.d/00_header ###
### BEGIN /etc/grub.d/10_linux ###
menuentry "GNU/Linux, with Linux 2.6.33.5" --class gnu-linux --class
gnu --class os {
savedefault
linux /boot/vmlinux-2.6.33.5 root=/dev/sdd10 ro
}
menuentry "GNU/Linux, with Linux 2.6.33" --class gnu-linux --class gnu
--class os {
savedefault
linux /boot/vmlinux-2.6.33 root=/dev/sdd10 ro
}
menuentry "GNU/Linux, with Linux 2.6.32.8" --class gnu-linux --class
gnu --class os {
savedefault
linux /boot/vmlinux-2.6.32.8 root=/dev/sdd10 ro
}
### END /etc/grub.d/10_linux ###
### BEGIN /etc/grub.d/30_os-prober ###
### END /etc/grub.d/30_os-prober ###
### BEGIN /etc/grub.d/40_custom ###
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
### END /etc/grub.d/40_custom ###
=
This has some variance with what is in lfs/dev for grub-1.98.
Those --class businesses are probably silly.
I (think) used this sequence which produced a good result:
* create /etc/default/grub
* grub-install --grub-setup=/bin/true /dev/sdd
* grub-mkconfig -o /boot/grub/grub.cfg
I rebooted and chose menuentry "GNU/Linux, with Linux 2.6.33"
and (amongst other grub garbage) /boot/grub/grubenv contained:
saved_entry=GNU/Linux, with Linux 2.6.33
On subsequent reboot, this was the default.
The lfs/dev updated language involving search looks sensible.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
On 7/2/10, Bruce Dubbs wrote: >> ./configure --bla-bla-bla >> make > > Try to do a simple ls in the grub top level directory after a build if > you don't use a separate build directory. There are 2400 files, many of Not saying that is the right way. Just that it succeeded and I didn't see or understand a better solution. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
FYI A possible search usefulness: Or, other search methods to deduce the root filesystem for the kernel's "root=" parameter, or where the kernel is. * Suppose that the grub directory is a subdirectory of boot * Suppose that the boot directory is a subdirectory of root / * Suppose that the kernel name is vmlinux-2.6.33 and it is located in boot * This search command will find which (grub syntax) partitions contain that file: search -n -f /boot/vmlinux-2.6.33 * The result may show a list if it exist on multiple partitions as: (hd2,9) (hd4,10) * You may be clever and deduce that (hd4,10) is what you want. * You may find out which (kernel syntax) that drive is with: cat (hd4,10)/boot/grub/device.map * Cat may return information such as: (fd0) /dev/fd0 (hd0) /dev/hda (hd1) /dev/sda (hd2) /dev/sdb (hd3) /dev/sdc (hd4) /dev/sdd * It can then be deduced that the (kernel syntax) root partition is: /dev/sdd10 * So the linux line can have the parameter: root=/dev/sdd10 * The full linux line can then be: linux (hd4,10)/boot/vmlinux-2.6.33 root=/dev/sdd10 * boot * If boot is on a separate partition, omit the "/boot" component when searching for the partition that holds the kernel. * If boot is on a separate partition, you might also search for a distinct filename, that is known to be on the system's root / filesystem, in order to determine the "root=" parameter. At least it can narrow down the choices. This can be useful when struggling to boot from the grub2 command line while struggling to producing a working grub.cfg. I have struggled many times and I always appreciate the existence of a tool that can help sort things out. Search is not limited to searching for UUID. What I might be trying to say is that grub2 has a command that can operate like the grub legacy command "find" and the name of that command is "search". To find what partition(s) a filename exist on, the search command is useful: search -n -f filename In long-param-notation that is: search --no-floppy --file=filename Thus it is technically incorrect to imply that "[ ... the search ...] command only sets an internal GRUB variable used to find the kernel image. It might be more precise to say something like: * The above search lines set the GRUB variable "root" by searching --fs-uuid, which is not considered standard practice for LFS systems. The above set root commands are sufficient to establish the GRUB variable "root". Just reporting the discovery. But, whatever you think. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Management and such (Was RE: Website)
DJ Lucas wrote: > > Berkeley DB could be done easily enough I think. Flat text files allow processing via command line tools such as grep, sed, awk, perl, bash, etcetera. Does a DB require an esoteric API that can get in someone's way? > > if everything were properly accounted for, > prior to installation Choice in LFS seems to thwart the possibility of an existing list of files which means that everything cannot (easily) be accounted for prior to pressing ENTER. I use a find-before and a find-after and then process the diff with awk which enables me to detect whether a file was new or modified. It only serves as a reality check before I start deleting (uninstall). By the way, I put the md5sum in the list which enables detection of files that were modified, hopefully by me, hopefully on purpose. It also enables detection of files that were not deleted (if uninstalled) due to me being "chicken" to delete files in /etc or otherwise. I wouldn't want to be without my installation logs. I even use them to make a tarballs before uninstalling in case I change my mind. Files in "DESTDIR" are not the only files that will be "installed". There are those installs which perform operations over potentially pre-existing (random) files. Ex: daemon user/groups, additions to a conf file, info, gconf, etc. It is those things to look out for in the fakeroot hint which have scared me. Kevin Buckley wrote: > > find / -newer SOME_TIMESTAMP_FILE -ls > > where SOME_TIMESTAMP_FILE is touched after every package install > would seem to do all that one wants. Thousands of files may change between installs, especially in BLFS. A system is not always built in twenty minutes from start to finish. I ponder Slackware, how similar a slackbuild script seems to LFS. The biggest difference is that LFS is "Your system, Your rules", not theirs. I applaud discussions of hooks that can be (opionally) used to manage packages, such as DESTDIR and file logging. If it miraculously evolves to a near-package-manager, or even helpful notes, that would be wonderful. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Package Management and such (Was RE: Website)
On 8/2/10, Ken Moffat wrote:
before uninstalling in case I change my mind.
>
> Cool. You've obviously been bitten in the past. Based on my script
> that runs through my audio, video, and photo files every week to
> check if md5s exist, and generate them where they don't, I imagine
> this will add a significant amount of time to every install ?
>
md5sum does add some seconds, but a few minutes vs. compile time
usually doesn't seem too bad. Not all sure how useful it is.
I was dreaming of some way to get a list and detect files new vs.
modified and can only look in what would be destdir, but here is some
little program. It is in perl due to some difficulties getting a
manageble date format plus optional md5. Not saying it's great, just
dreaming.
... If they only would come up with a patch for "make install" to
produce a file list ...
#!/usr/bin/perl
# explanation:
# perldoc "mystat" # assuming name is mystat
# or read at end
use Digest::MD5;
$do_md5 = "n";
for $arg (@ARGV) {
# spent lt 5 minutes on params...
$do_md5 = "y" if ($arg =~ /^[-]{1,}md5/);
$destdir = $arg if ($arg !~ /^-/);
}
die "No destdir" if (length($destdir) == 0);
$cmd = "find $destdir";
if (open(CMD, "$cmd |")) {
while () {
chomp;
if ($_ !~ /^$destdir$/) {
$filespec = $_;
$filespec =~ s...@^$destdir/@@;
push(@filespecs, $filespec);
}
}
}
for $filespec (sort(@filespecs)) { # sort was an afterthought
$ret = &get_stat("${destdir}/${filespec}");
$ret =~ s...@^$destdir/@@;
@pre_x = lstat("/${filespec}");
if (scalar @pre_x == 0) {
$ret = "+ " . $ret;
}
else {
$ret = "! " . $ret;
}
print "$ret\n";
}
sub get_stat() {
my ($n) = @_;
my @s = lstat($n);
my $t = "";
my $mm = "";
my @unam = ();
my @gnam = ();
my $ret = "";
my $md5sum = "";
if (scalar @s == 0) {
return $ret;
}
if ( -f _ ) { $t = "f" }
elsif ( -l _ ) { $t = "l" }
elsif ( -d _ ) { $t = "d" }
elsif ( -b _ ) { $t = "b" }
elsif ( -c _ ) { $t = "c" }
elsif ( -p _ ) { $t = "p" }
elsif ( -S _ ) { $t = "s" }
else { $t = "?" }
@unam = getpwuid($s[4]);
@gnam = getgrgid($s[5]);
$mm = $s[2] & 0;
# ($dev,$ino,$mode,$nlink,$uid,$gid,$rdev,$size,
# $atime,$mtime,$ctime,$blksize,$blocks)
$ret = sprintf "%s %s %s %s %o %s %s", $n, $s[7], $t, $s[10], $mm,
$unam[0], $gnam[0];
if (($do_md5 eq "y") && ($t eq "f")) {
$md5sum = &do_md5($n);
if ($md5sum ne "") {
$ret .= " " . $md5sum;
}
}
return $ret;
}
sub do_md5() {
my ($fil) = @_;
my $md5 = "";
if (open(FILE, $fil)) {
binmode(FILE);
$md5 = Digest::MD5->new->addfile(*FILE)->hexdigest;
close(FILE);
}
return $md5;
}
__END__
=pod
=head1 NAME
mystat
=head1 SYNOPSIS
mystat $destdir
=head1 DESCRIPTION
stat files in destdir and detect pre-existing
+ denotes new file
! denotes pre-existing file
maybe add md5sum with parameter --md5
File list fields
newness name size type ctime mode user group md5
=head1 example
export destd=foo &&
find {$destd,/tfoo} &&
echo "" &&
./mystat $destd
foo
foo/big
foo/big/foo
foo/you
foo/bar
foo/tfoo
foo/tfoo/ufu
/tfoo
/tfoo/ufu
+ big 4096 d 1280737263 775 jhalfs jhalfs
+ big/foo 4 f 1280782110 664 jhalfs jhalfs
+ you 4 f 1280737152 664 jhalfs jhalfs
+ bar 4 f 1280737160 664 jhalfs jhalfs
! tfoo 4096 d 1280783341 775 jhalfs jhalfs
! tfoo/ufu 8 f 1280783341 664 jhalfs jhalfs
=cut
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Honing package users: some build notes. . . and problems.
On 9/2/10, Drew Ames wrote: > # Finally, enter the chroot environment: > chroot "$LFS" /tools/bin/env -i \ > HOME=/root TERM="$TERM" PS1='\u:\w\$ ' \ > PATH=/bin:/usr/bin:/sbin:/usr/sbin:/tools/bin \ > /tools/bin/bash --login +h > I would read "6.62. Cleaning Up" regarding the chroot command *after* ch6. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: LFS-build-notes
On 10/7/10, Bruce Dubbs wrote: > For some reason I can't figure out, Drew Ames' post is being marked as > spam when it isn't. This is his post: > - Hmmm, well you posted it without it being spam. One silly thought: Diff the spam post with this post and the only difference should (will) be the header and the footer. One more silly thought: Maybe the spam killer thinks (or at that moment was thinking) there is something particularly interesting about that account. -- 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, 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 > There is dpkg hint in hints http://www.linuxfromscratch.org/hints/read.html -- 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, Drew Ames wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 10/26/2010 01:26 AM, DJ Lucas wrote: >> >>> That patch is now also available, in LFS format, from >>> > http://www.linuxfromscratch.org/patches/downloads/glibc/glibc-2.12.1-origin_fix-1.patch. >>> >>> Apply using the usual 'patch -Np1 -i ../glibc-2.12.1-origin_fix-1.patch'. >>> >>> Regards, >>> >>> Matt. >>> >> >> Additional part. Haven't tested. >> >> http://sourceware.org/ml/libc-hacker/2010-10/msg00010.html >> >> Makes LD_AUDIT behave same as LD_PRELOAD. >> > Gentlemen, > > Thanks for the lengthy replies and testing in response to my initial > question. > > 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? > > Thanks, > > - -Drew > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.10 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkzHhnkACgkQ7ZZ4z2wRxN2RLACeJNB8/YKj4K0x9q6Hf1Bk+nj2 > AaIAn0jFdJbmvnuhDTgdKQEHzSXvzj5x > =PrC1 > -END PGP SIGNATURE- > > -- > http://linuxfromscratch.org/mailman/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page > IIf one meant howto make http://sourceware.org/ml/libc-hacker/2010-10/msg00010.html into a patch, it must be reliably copied without space damage by some means. Perhaps on that link, could click "raw text", then select all, CTRL-C, somehow paste CTRL-V, or some kind of nonsense. I think the entire email, if not space damaged, can be a patch, and patch is smart enough to know what to do. But I am really not sure. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
