Re: Grub 2
Bruce Dubbs wrote: > taipan67 wrote: > >> Bruce Dubbs wrote: >> >>> taipan67 wrote: >>> >>> >>> >>>> Well, if you consider that when installing & configuring grub1 you are >>>> currently obliged to use the term 'root' in *five* different contexts, >>>> they're actually getting better... ;) >>>> >>>> >>> Really? I only know of one. Can you expand on your comment? >>> >>> -- Bruce >>> >>> >> Okay, the grub-shell uses 'root' to tell grub on which partition to find >> it's stage-files... >> >> Then in /boot/grub/menu.lst, the term is used first to tell grub on >> which partition to find the kernel, then again on the kernel-line to >> define the partition on which the linux-filesystem is rooted (at '/' aka >> 'root')... >> >> All of which must be done as the root-user... >> >> Is that five or only four? I hope i wasn't exaggerating & slandering >> grub's good name. >> >> Apologies if the above expansion is confusing - then again, that's kinda >> the point, innit? :) >> > > No apologies necessary. To me that is two: one to tell grub where the > base of things is and the other to tell the kernel where the root > partition is located. > > I didn't think about the 2nd. > > -- Bruce > Ah, but "the base of things" isn't necessarily the same for all invocations of 'root (hd?,?)' - this is illustrated in chapter 8.4 of the lfs-book when adding a menu.lst entry for the host (or any other bootable) system. How about we drop my inclusion of the username & settle on *three* different contexts (just to be pedantic)? taipan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Grub 2
Bruce Dubbs wrote: > taipan67 wrote: > > >> Well, if you consider that when installing & configuring grub1 you are >> currently obliged to use the term 'root' in *five* different contexts, >> they're actually getting better... ;) >> > > Really? I only know of one. Can you expand on your comment? > > -- Bruce > Okay, the grub-shell uses 'root' to tell grub on which partition to find it's stage-files... Then in /boot/grub/menu.lst, the term is used first to tell grub on which partition to find the kernel, then again on the kernel-line to define the partition on which the linux-filesystem is rooted (at '/' aka 'root')... All of which must be done as the root-user... Is that five or only four? I hope i wasn't exaggerating & slandering grub's good name. Apologies if the above expansion is confusing - then again, that's kinda the point, innit? :) taipan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Grub 2
Bruce Dubbs wrote: > Alexander E. Patrakov wrote: > > >> Note, however, that this is not the same type of module as "insmod" and >> "lsmod" Grub2 commands refer to. Grub2 has its own modules for loading >> Linux kernels, loading FreeBSD kernels, support for filesystems, and so >> on. Obviously, not all of them are used in the typical "boot a kernel >> from ext3 partition" scenario - but this is not a valid reason to call >> Grub2 bloated, since the old Grub1 has all this functionality always >> built statically into stage2. >> > > Overloading the meaning of lsmod and rmmod does not seem to me to be a > good idea. I would think something like lsgmod (ls grub module) or even > lsext (ls extention) would be better. Using the same term for different > things is a recipe for confusing users. > > -- Bruce > > > Well, if you consider that when installing & configuring grub1 you are currently obliged to use the term 'root' in *five* different contexts, they're actually getting better... ;) I know this is no help to the discussion, it's just a pet peeve that i felt compelled to air. taipan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Choosing appropriate keymaps and fonts
Matthew Burgess wrote: > Hi, > > How does one go about choosing the correct keymaps and fonts for their > system? I've read over chapter07/console.html several times but still have a > couple of questions. > > What I'm trying to do is configure a system to have a UK keymap and have a > UTF-8 capable console. > > This is what i have at the moment to achieve the same objective :- UNICODE="1" KEYMAP="uk" KEYMAP_CORRECTIONS="euro2 windowkeys" LEGACY_CHARSET="iso-8859-15" FONT="LatArCyrHeb-16" The 'euro2' thing still doesn't generate a Euro symbol, so that needs work. I also chose iso-8859-15 instead of iso-8859-1 in the hope of getting said Euro-symbol... Ken Moffat has composed a 'uk-utf8' keymap, but the download link doesn't seem to work - Ken, is there any chance of another attempt to make this available? > Similarly, for fonts, how do I determine which ones are UTF-8 capable and > what flags I need to pass to setfont, via the FONT variable, so that it will > display correctly? > > Thanks, > > Matt. > > As Alexander said, fonts with a 'psfu' suffix are supposed to be unicode-compatible. Hope that helps, taipan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
taipan67 wrote: > Bryan Kadzban wrote: > >> I'm going to tentatively vote -1 for package management in LFS -- that >> is, unless it doesn't break my current package management setup >> (pkg-user hint FTW!). If the changes don't break the pkg-user hint, >> then I'd say +1; it's worth a shot at least. DESTDIR=$dest on all the >> packages, for instance, shouldn't hurt if $dest is empty. >> >> >> > Obviously $dest must be "chgrp install && chmod 1775" in such a case... > > taipan > Actually, the sticky bit isn't really necessary, since the package-user would be doing "rm -r $dest/*" after relocating the files to the live system, thus leaving it empty. Also, & still slightly OT (sorry), i've been using "strip --strip-unneeded" instead of "strip --strip-all" on the binaries in $dest, as 'man strip' says something about 'relocation symbols' - i don't understand it entirely, but figured better safe than sorry, plus it's what portage does... taipan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Jeremy Huntwork wrote: > What I do like about it is that it adds a useful feature (for some), > offers flexibility, and offers areas for greater education. It could be > argued that by inspecting the contents of DESTDIR after they run the > make install command there is additional opportunity for builders to get > familiar with what exactly is going to be installed. > > -- > JH > That's precisely what i'd hoped to say in my initial post in this thread, when i said that the use of $DESTDIR wouldn't detract from the book's educational objectives - on the contrary, it would more likely be an enhancement. Thank you, Jeremy, for your superior eloquence. ;-) taipan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
Bryan Kadzban wrote: > I'm going to tentatively vote -1 for package management in LFS -- that > is, unless it doesn't break my current package management setup > (pkg-user hint FTW!). If the changes don't break the pkg-user hint, > then I'd say +1; it's worth a shot at least. DESTDIR=$dest on all the > packages, for instance, shouldn't hurt if $dest is empty. > > Obviously $dest must be "chgrp install && chmod 1775" in such a case, but beyond that i found it actually _improved_ on the pkgusr method - it even negates one or two of the gremlins mentioned in the hint, & allows for additional install-dir's to be correctly created when needed, like during X-installation. There are a couple of packages in LFS that don't play nice with $DESTDIR (i think 'shadow' was one), but hopefully more adept minds than mine would be able to resolve those issues, if this proposal goes forward... taipan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: An idea for a new development model
lists wrote:
> Jeremy Huntwork wrote:
>
>> On Wed, Aug 15, 2007 at 07:37:12AM -0500, Randy McMurchy wrote:
>>
>>> I'll go on record as -1.
>>>
>> I'm not going to push to get this into LFS. If the vast majority of
>> those with a voice here are for PM in LFS, great. If not, great. :)
>>
>>
>>> I feel we should mention it, provide links to the various alternatives,
>>> and drive on. We are not a distribution. We are a book that shows how
>>> to compile Linux from scratch. Let's don't forget that.
>>>
>> Understandable. Of course, it could be argued that part of what makes a
>> Linux system is package management. It is after all part of the LSB.
>>
>
> The real reason that package managers are a bad thing, the bloated
> "requirements" of the meta packages in them. grab yourself a current
> debian install, and install KDE on it, minimal KDE without the kdeedu,
> games, development, pim package groups. you can't, Debian made the KDE
> meta package require 100% of all optional KDE software to install the
> base KDE.
> Debian did the same type of bloat with the Gnome meta package
> requirements, put way to much as absolutely required.
>
>
This last observation is one of the main reasons i've been using Gentoo
for 4 years - you don't even have to install all of 'kdebase' if you
don't want to, much less the other meta-packages. However, their PM,
Portage, must require an absolutely colossal amount of maintenance (&
i'm just talking about the ebuild-tree, never mind the package-manager
itself), so a similar system for {,B}LFS would almost certainly be
impractical...
During my only LFS-build thus far i used a combination of the pkgusr &
fakeroot hints, & found the use of $DESTDIR to be particularly
educational, as well as practical, so if the book were to encourage it's
use more in future, i don't think that would detract from it's original
goal of being a learning tool.
I also whole-heartedly agree with Alan's earlier comment - "The
unfortunate consequence of LFS is that it also teaches the user how
great a lean/mean Linux system can be (and most would want it to stay
that way if it *was* a distribution). I would hazard a guess that most
people who grok LFS would love to use it for their everyday distro."
Perhaps the existing book-section on package-management could be
embellished to the effect that "These are some of the most popular
options, of which we ourselves use in development of our
LiveCD project" - not so much a stipulation as an endorsement...
Subsequent to listening to an ArchLinux advocate, & looking at Greg's
DIY project, i'm thinking of using 'pacman' on my own system, but i'm in
no rush so i'll be holding off for now & following this thread with
interest to see where the consensus leads...
taipan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: LiveCD Users
Jeremy Huntwork wrote:
> William Harrington wrote:
>
>> I think it'd be a good idea to post this to all the mailing lists
>> than just this one.
>>
>
> Well, I did lfs-dev, lfs-chat, and livecd. You think there's bound to be
> more users not covered on the other lists?
>
> --
> JH
>
>
>
I haven't used a LiveCD, so can't offer any feedback i'm afraid, but i
thought i'd suggest that posting to the lfs-support list strikes me as
the place most likely to draw attention (i'm only currently registered
on {,b}lfs-dev & -support)...
hth, taipan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: suggest 'make -j2' for SMP machines?
Mohan wrote: > I've actually seen some improvement on compile times running Athlons > and such as well with -j2... I suspect it fills time the compiler spends > waiting for this or that read, or write, or something. There are > certainly a lot of packages I've run into that have trouble with > parallelization, though. Not that it's much of a problem to just start > the compile again without -j2. > > I've only just completed my 1st LFS build, having come from 3 years on Gentoo, where the '-j' flag is one of the standard options. Their recommendation (listed in /etc/make.conf.example) is to set it to "the number of cpu's plus one", which for my AthlonXP meant '-j2'... ...I completely forgot it's existence during this LFS build, & without it i'm almost positive that my compile-times were faster (toolchain packages more than twice as fast). So now i'm thinking that Gentoo's recommendation is somewhat innacurate, & would be better worded as "set -j to the number of cpu-cores" or some such, having no personal experience of such a configuration, but agreeing with the theories set forth in this thread... -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Shadow Maintenance (was Re: download location for shadow down since a while ?)
Greg Schafer wrote: > Mark Rosenstand wrote: > > >> On Mon, 2007-05-14 at 08:02 -0700, Dan Nicholson wrote: >> >>> On 5/14/07, Jens Stroebel <[EMAIL PROTECTED]> wrote: >>> I've been trying for some time now to get the shadow-4.0.18.1 source from ftp://ftp.pld.org.pl/software/shadow/shadow-4.0.18.1.tar.bz2 ; the site is not resolvable, though. >>> Yeah, that's about the least reliable server on the internet :) You >>> can just use a mirror for now. >>> >> It's _unresolvable_ and has been so for several months. I don't think >> it's coming back. >> >> pld.org.pl redirects to pld-linux.org, and the latest version of shadow >> at their FTP site is 4.0.3. >> >> I haven't gotten any traffic from their mailing list since Feb 1, which >> was the maintainer telling that he was busy with his new job. >> > > AFAICT shadow is dead. The maintainer has a history of.. um, shall we say, > being difficult. This is evidenced by a FAQ on the PLD site: > > http://www.pld-linux.org/FAQ#head-8d1d084c78d30202351371109aa23ef2350f8c0f > > In the following bug report there is mention of Debian possibly taking > over maintenance: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=423956 > > I sure hope they do.. > > Regards > Greg > I'm on my 1st LFS install at the moment, & when the Shadow link wouldn't resolve, i grabbed the tarball from one of the Gentoo mirrors - every package that they support is stored in the 'distfiles' sub-directory. Only version 4.0.18.1 is currently available, though... ...Incidentally, the 'useradd_fix-2.patch' broke useradd, which i discovered because i'm following the 'pkgusr' hint. The 'fix-1.patch' solved the problem. When my install is complete, i'll try to determine why the later patch gave me trouble & post any findings here... -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: IPRoute2-2.6.20-070313 man-page glitch
Dan Nicholson wrote: > On 5/23/07, taipan67 <[EMAIL PROTECTED]> wrote: > >> The IPRoute2-2.6.20-070313 tarball contains :- man/man8/tc-bfifo.8 & >> man/man8/tc-pfifo.8, the latter being a symlink to the former. >> >> Makefile installs both, then overwrites them with symlinks to >> tc-pbfifo.8, which doesn't exist. >> >> My solution is to :- >> >> rm man/man8/tc-pfifo.8 && mv man/man8/tc-bfifo.8 man/man8/tc-pbfifo.8 >> >> ...prior to 'make SBINDIR=/sbin install' (this should probably be done >> upstream as a permanent fix, if it hasn't already). >> > > Thanks for the report. I noticed this a couple months ago, but haven't > gotten into the book yet. > > http://linuxfromscratch.org/pipermail/lfs-dev/2007-March/059166.html > > -- > Dan > Thanks Dan - a search from the LFS homepage didn't highlight your earlier entry, so sorry for the duplicate (more search-practice required, maybe). I chose my solution in preference to changing the Makefile basically because the man-page shipped with the tarball, tc-bfifo.8, still has 'pbfifo 8' in it's opening text, so i assumed it was a term still supported. Then again, it's also dated January 2002, so perhaps it has been dropped, in which case removing the 2 symlinking instructions from the Makefile (& upstream editing their man-page) would be the way to go. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
IPRoute2-2.6.20-070313 man-page glitch
The IPRoute2-2.6.20-070313 tarball contains :- man/man8/tc-bfifo.8 & man/man8/tc-pfifo.8, the latter being a symlink to the former. Makefile installs both, then overwrites them with symlinks to tc-pbfifo.8, which doesn't exist. My solution is to :- rm man/man8/tc-pfifo.8 && mv man/man8/tc-bfifo.8 man/man8/tc-pbfifo.8 ...prior to 'make SBINDIR=/sbin install' (this should probably be done upstream as a permanent fix, if it hasn't already). This is my first lfs-install (svn-20070514), & my first post to the lists, so if this should've been sent to the lfs-book list, i apologise & would appreciate any constructive correction available. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
