Little spelling error
I hope this is the right mailing list for reporting spelling errors. I'm currently following LFS v6.4. in chap. 5.21 The paragraph: "This parameter bypasses the search for mktime in configure and uses the version in glibc. The is necessary due to a change in gcc that has not been incorporated into this package yet. " Should be:"This parameter bypasses the search for mktime in configure and uses the version in glibc. _This_ is necessary due to a change in gcc that has not been incorporated into this package yet. " Also, in the same chapter (5.21) the paragraph saying "Compilation is now complete. As discussed earlier..." should be after the "make" command, not before. Marc -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Missing operand in kernel installation doc
Hi, I've discovered another very small error in the kernel installation doc (chapter 8.3, in LFS 6.4). The line: "If the kernel source tree is going to be retained, run chown -R 0:0 on the linux-2.6.27.4 directory to ensure all files are owned by user root. " Should be: "If the kernel source tree is going to be retained, run chown -R 0:0 * on the linux-2.6.27.4 directory to ensure all files are owned by user root. " The "*" operand is missing. Cheers, Marc -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Missing operand in kernel installation doc
On Thursday 04 December 2008 16:59:47 Bruce Dubbs wrote: > Marc Ferland wrote: > > Hi, > > > > I've discovered another very small error in the kernel installation doc > > (chapter 8.3, in LFS 6.4). > > > > The line: > > "If the kernel source tree is going to be retained, run chown -R 0:0 on > > the linux-2.6.27.4 directory to ensure all files are owned by user root. > > " > > > > Should be: > > "If the kernel source tree is going to be retained, run chown -R 0:0 * on > > the linux-2.6.27.4 directory to ensure all files are owned by user root. > > " > > > > The "*" operand is missing. > > That's really not an error. If it were in a highlighted section, it would > be a problem, but in this case, we are saying what to do, but not *exactly* > how to do it. The command may be 'chown -R 0:0 /usr/src/linux-2.6.27.4' > and that would be good too. > >-- Bruce Ooops! My mistake, sorry. Marc -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Grub instructions
Hi, The last instruction of the grub setup states that you should use: grub-setup to update the MBR. Running this on my system yields to: root:~# grub-setup No device is specified. Try ``grub-setup --help'' for more information. So I think the instruction should instead be: grub-setup "(hdn)" where n is the hard-drive number returned by the previous grub-mkdevicemap command. There's also a small typo in: If you tested the GRUB configuration as specified above, re-enter the chroot envronment. Should have been: If you tested the GRUB configuration as specified above, re-enter the chroot environment. Regards, Marc -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Grub instructions
Here's the content of my /boot/grub/device.map (hd0) /dev/sda (hd1) /dev/sdb Marc -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
network script
Hi, >From what I've read in the LFS book and some testing, I noticed that each >network interface that has the ONBOOT flag set to anything else than "yes" >will not be brought up (neither on boot or by manually issuing a "network >restart" command. Correct me if I'm wrong, but this flag seems have 2 distinct use case, you can check it to verify if the interface should be brought up during boot _and_ if it is "enabled" in the system. This also means that you cannot have an interface set to "no" and bring it up manually later. You'll first have to set the flag to "yes", call "network restart" and then set it back to "no". >From the network init script, it also seems like the "IN_BOOT" variable is >always true... Am I missing something here ? Regards, Marc -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: network script
At Fri, 18 Dec 2009 13:44:06 -0600, Bruce Dubbs wrote: > > Marc Ferland wrote: > > Hi, > > > >> From what I've read in the LFS book and some testing, I noticed > >> that each network interface that has the ONBOOT flag set to > >> anything else than "yes" will not be brought up (neither on boot or > >> by manually issuing a "network restart" command. > > > > Correct me if I'm wrong, but this flag seems have 2 distinct use > > case, you can check it to verify if the interface should be brought > > up during boot _and_ if it is "enabled" in the system. > > > > This also means that you cannot have an interface set to "no" and > > bring it up manually later. You'll first have to set the flag to > > "yes", call "network restart" and then set it back to "no". > > > >> From the network init script, it also seems like the "IN_BOOT" > >> variable is always true... > > Did you try e.g. `/etc/sysconfig/network-devices/ifup eth0' > > There probably should be a symlink in /sbin to ifup and ifdown. > > IN_BOOT is set in /etc/rc.d/init.d/network but that is for the entire > network, not an individual interface. Aaaah, of course! Putting a symlink in ifup and ifdown would indeed simplify things. Thanks, Marc -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Boot messages
Hi, I work on an embedded device that uses LFS. I recently added a farily basic initramfs image (using busybox) to correctly handle UUID stuff on the kernel command line and also to display a nice boot logo. The logo is displayed correctly during kernel booting (I used the "quiet" option on the kernel cmd line). But when I switch to the real rootfs and start /sbin/init I see all the messages from the different init.d services. Is there a way to remove these messages? Maybe by redirecting them in a log file? Regards, Marc -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Boot messages
At Mon, 28 Dec 2009 17:29:22 -0600,
DJ Lucas wrote:
>
> On 12/28/2009 03:33 PM, Marc Ferland wrote:
> > The logo is displayed correctly during kernel booting (I used the "quiet"
> > option on the kernel cmd line). But when I switch to the real rootfs and
> > start /sbin/init I see all the messages from the different init.d services.
> >
> > Is there a way to remove these messages? Maybe by redirecting them in a
> > log file?
> >
> >
> Not a built-in way in the scripts, however, take a look at the runlevel
> control script (/etc/rc.d/init.d/rc) and maybe you could redirect it to
> null there. If you want logging, the root filesystem is not writable in
> sysinit until after the 6th script (mountfs) has ran, so I'm not sure
> exactly how to deal with it in your setup. I kinda doubt that the
> initramfs can be abused, but maybe. Take a look at the rc script in the
> contrib directory for the LSB-V3 bootscripts (warning: I never finished
> them so they might be ugly to read...also the entire set was broken
> because of changes to make them not distro specific which I also hadn't
> bothered to finish...really I will). A tempfs is mounted first thing to
> enable boot logging, but you need to take into account the entire script
> as I put in a couple of simple tricks (which escape me ATM) to get the
> time correct for the log files, and then a dump and then switch to real
> log files after sysinit finishes.
>
Great! Only a couple of messages left!
Like you said, I replaced the line that says:
${i} start
with
${i} start &> /dev/null
Thanks,
Marc
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Boot messages
At Mon, 28 Dec 2009 17:29:22 -0600,
DJ Lucas wrote:
>
> On 12/28/2009 03:33 PM, Marc Ferland wrote:
> > The logo is displayed correctly during kernel booting (I used the "quiet"
> > option on the kernel cmd line). But when I switch to the real rootfs and
> > start /sbin/init I see all the messages from the different init.d services.
> >
> > Is there a way to remove these messages? Maybe by redirecting them in a
> > log file?
> >
> >
> Not a built-in way in the scripts, however, take a look at the runlevel
> control script (/etc/rc.d/init.d/rc) and maybe you could redirect it to
> null there. If you want logging, the root filesystem is not writable in
> sysinit until after the 6th script (mountfs) has ran, so I'm not sure
> exactly how to deal with it in your setup. I kinda doubt that the
> initramfs can be abused, but maybe. Take a look at the rc script in the
> contrib directory for the LSB-V3 bootscripts (warning: I never finished
> them so they might be ugly to read...also the entire set was broken
> because of changes to make them not distro specific which I also hadn't
> bothered to finish...really I will). A tempfs is mounted first thing to
> enable boot logging, but you need to take into account the entire script
> as I put in a couple of simple tricks (which escape me ATM) to get the
> time correct for the log files, and then a dump and then switch to real
> log files after sysinit finishes.
>
Great! Only a couple of messages left!
Like you said, I replaced the line that says:
${i} start
with
${i} start &> /dev/null
Thanks,
Marc
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
VCS for LFS
Hi, I've been using LFS to create a specialized linux distribution at work. Everything is going as planned except that keeping track of all changes going into the distribution is nearly impossible. I often make changes to configuration files, I add new libraries, remove unneeded stuff, etc. I tought of maybe using SVN, but it doesn't really support the metadata associated with each file (only support the eXecutable flag if I remember correctly). So I'm currently using a combination of tar and rsync to keep an history of all versions. It works but I have to do a lot of things manually and I can't really diff between versions etc. Any of you had this problem before? If so how did you solve it? Regards, Marc -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: VCS for LFS
At Tue, 26 Jan 2010 19:39:12 -0600, Bruce Dubbs wrote: > > Marc Ferland wrote: > > > I've been using LFS to create a specialized linux distribution at > > work. Everything is going as planned except that keeping track of all > > changes going into the distribution is nearly impossible. > > Yes, the real work of a distribution for multiple systems is keeping > changes synchronized by something like tar.gz, .rpm, .deb, etc. > > > I often make changes to configuration files, I add new libraries, > > remove unneeded stuff, etc. > > > > I tought of maybe using SVN, but it doesn't really support the > > metadata associated with each file (only support the eXecutable flag > > if I remember correctly). > > > > So I'm currently using a combination of tar and rsync to keep an history > > of all versions. It works but I have to do a lot of things > > manually and I can't really diff between versions etc. > > > > Any of you had this problem before? If so how did you solve it? > > I have used svn for some configuration files. What metadata do you want > to support that isn't supported by svn? > By metadata I mean file ownership (user:group),permissions (just like the --preserve-permissions option in tar), time, date, etc. If these could be preserved/versioned by the VCS it would simplify part of what I do. This maybe look more like a versioned file system or something. I see there are a couple of scripts floating on the net to support part of this in svn. Regards, Marc -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: VCS for LFS
At Wed, 27 Jan 2010 09:07:16 -0500, Marc Ferland wrote: > > At Tue, 26 Jan 2010 19:39:12 -0600, > Bruce Dubbs wrote: > > > > Marc Ferland wrote: > > > > > I've been using LFS to create a specialized linux distribution at > > > work. Everything is going as planned except that keeping track of all > > > changes going into the distribution is nearly impossible. > > > > Yes, the real work of a distribution for multiple systems is keeping > > changes synchronized by something like tar.gz, .rpm, .deb, etc. > > > > > I often make changes to configuration files, I add new libraries, > > > remove unneeded stuff, etc. > > > > > > I tought of maybe using SVN, but it doesn't really support the > > > metadata associated with each file (only support the eXecutable flag > > > if I remember correctly). > > > > > > So I'm currently using a combination of tar and rsync to keep an history > > > of all versions. It works but I have to do a lot of things > > > manually and I can't really diff between versions etc. > > > > > > Any of you had this problem before? If so how did you solve it? > > > > I have used svn for some configuration files. What metadata do you want > > to support that isn't supported by svn? > > > > By metadata I mean file ownership (user:group),permissions (just > like the --preserve-permissions option in tar), time, date, etc. If > these could be preserved/versioned by the VCS it would simplify part > of what I do. > > This maybe look more like a versioned file system or something. I see > there are a couple of scripts floating on the net to support part of > this in svn. > A bit more googling revealed this project: http://david.hardeman.nu/software.php#metastore Looks like what I've been searching for! Marc -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
