David A. Bandel wrote: > If it is the default on _one_ distro, that's enough.
Not it is _not_. That utterly _fails_ the "litmus test" for _any_ certification program, unless the certification program is purposely geared towards only that distribution (or a tower of distributions that all agree on something). Please, please understand the real considerations that LPI has to make. If not, then you should argue to have Matt's job. They are pretty damn big shoes to fill to get things done (I surely do not want it). Until then, please understand why LPI doesn't include and test everything, although they do try to match objectives into things. From: "David A. Bandel" <[EMAIL PROTECTED]> > Apples and oranges. Fact is, I can boot and even run a server without > X. One _can_ boot a system without LILO or GRUB for that matter. Heck, why don't we talk virtualization while we're at it? Seriously, there's a lot of apples, a lot of oranges, a lot of applesauce and a crapload of orange juice out there. ;) From: "David A. Bandel" <[EMAIL PROTECTED]> > In fact, why anyone would put X on a server is beyond me. X [Server] or X programs? I think you're mixing applesauce with your OJ again. ;) From: "David A. Bandel" <[EMAIL PROTECTED]> > But server or desktop, you have to boot it. Many packages have > alternatives. I still run sendmail. I don't care if you test on it or > not -- or BIND, etc. Because I can always change the mail|dns|web|etc > server. Once booted, I can do what I like. Gotta boot first, though. Then let's just throw the whole freak'n Anvin suite of SYSLinux, ISOLinux, PXELinux, et al. in there! Dude, seriously, I could make the same "line in the sand" as you did on LILO when it comes to PXELinux and ISOLinux, given today's Linux boot support details and commonality. Please don't draw lines in the sand. Besides, I can draw them longer than you (among others longer than I as well ;). From: "David A. Bandel" <[EMAIL PROTECTED]> > Let's make this REAL simple. > You have an OS. You need to boot it. You set up the bootloader in THAT > OS, NOT IN A VACUUM. You don't set up a bootloader on a multiboot > system in every OS, just one. Let's make this *REAL* simple ... this has *NOTHING* to do with your point or LILO at all. ;) From: "David A. Bandel" <[EMAIL PROTECTED]> > Ok, so I have a system in front of me (this is not a make believe > system, but one I actually installed -- poor choice, but it was provided > by a client): > 2 IDE hard drives, 2 SATA drives, on IDE CDROM. I connected the two IDE > drives as masters on the two IDE channels, w/ the CDROM as slave on IDE0. > Not relevant for GRUB, but make the SATA drives md0 and the IDEs md1. > OK, which is hd0? The one you map BIOS Disk 80h (GRUB label "hd0") to. GRUB has *0* difference than LILO, you *CAN*ALSO* map in GRUB. No offense, but just because you are ignorant of GRUB's mapping options doesn't mean they do not exist. I saw you repeatedly state things in your earlier posts and I rolled my eyes. I see this far too often. If and when people do that because of something I post, I quickly go try to minimize my ignorance as fast as I can on something. It still doesn't replace or "make up for" the experience other have with something, but it does let me mitigate the damage I do to my own name as far as being a Subject Matter Expert (SME) on Linux. The key to being a SME on Linux is to know when you're not knowledegable with something. Yes, you know LILO. But you clearly do *NOT* know GRUB. That means anything you talk about with regards to not only GRUB, but even more generic concepts on boot loaders, is going to either be incorrect or from a narrower foci than others who have experience with both. Again, don't take the "ignorant" word to be an insult. I consider myself wholly ignorant on many web services, because I got out of the focus back in 1995-1996 (when everyone started doing it). I can name several others regarding myself as well. David A. Bandel wrote: > Thank you LILO, boot=/dev/md0, root=/dev/md0, raid-extra-boot=mbr-only. > Will ensure the BIOS looks to the SATA for boot (usually a choice of > SATA or IDE boot in the BIOS). Have you seen LILO dork up a multi-disk setup? I have! Got help you when it's anything but what LILO expects. LILO automagically only understand basic, "whole disk" type setups. I don't create those in many cases. ;) Again, and no offense, but just because you are ignorant of GRUB's mapping options doesn't mean they do not exist. E.g., Fedora/Red Hat system ... $ cat /boot/grub/device.map # this device map was generated by anaconda (hd0) /dev/sda (hd1) /dev/sdb There *ARE* BIOS and device mappings in GRUB. They *DO* work for many devices, including multi-device. There *IS* further work on LVM support as well (GRUB2), which is an available option now in leading edge distros. Please do _not_ be ignorant when arguing for/against something. Learn to recognize when you are not experienced with a tool. Learn to step back and take are not to assume what something does or does not do. That will prevent you from looking ignorant when you say something does not exist. I posted early today (18:00 GMT) *NOT* "singling out" anyone. I had *HOPED* that would get people to stop and think, so I would *NOT* have to "cross" anyone on their ignorance. Unfortunately, you posted many hours later. David A. Bandel wrote: > Which drive is hd0? There is no such thing. There _is_ 16-bit PC BIOS Interrupt 13h Disk Services, "Fixed Disk 80h." But that's PC specific. GRUB uses the hd# nomenclature to be non-PC BIOS (shall we get into even EFI on the PC?). But on the PC, that means "Fixed Disk 80h" is "first hard drive," so hd0 for GRUB. More pragmatic, it's mask out the bit of the upper byte, and you have your fixed disk number -- *EXACTLY* how the 16-bit PC BIOS' Interrupt 13h Disk Services were designed (the bitmask is used for fixed disks). The next # is then BIOS Disk 81h, etc..., so hd1. Etc... GRUB also has mappings for other. LILO just "hides" some of this from you. It does *NOT* solve the multi-disk issues and fail-over any "better" than GRUB. Furthermore, there is a "false sense" of "resolution" in how LILO breaks down md0 into something. In other words, you _still_ have to "know what you're doing" when you deal with multi-disk, let alone LVM, etc... What level do you want to take LPIC-1 to? Again, I wish you would have read my first post, before I started bottom-posting. Do *NOT* comment on GRUB if you are not experienced with it enough to know many, many basic things. ;) > Fortunately with LILO, I can use drive designations we can agree on. I > have NO IDEA where GRUB will write the MBR (and neither do you, *YES*I*DO*! Again, please don't substitute ignorance for lack of capability. *BOTH* GRUB (yes, v1) and LILO have mapping options. Just because you don't understand GRUB's doesn't mean they don't exist. Please go away and come back when you learn GRUB. No offense, but you cannot make any arguments for/against it with your limited exposure. I do *NOT* say this to be rude, but to honestly say ... "dude, you're exposing your lack of exposure, and telling us capabilities don't exist in it when they, in fact, do." From: Jorge Armando Medina <[EMAIL PROTECTED]> > Sometimes I have to go and fix or manage a customers server, for example, a > customer with 2000 slackware servers asked to another consulting company to > help them fix a issue with a raid controler, the "professional" could not > solve the problem because he didnt know lilo, he didnt know about the configs > and that he needs to execute grub after modify lilo.conf, this "professional" > messed up the sistem. There are plenty of "professional" sysadmins that are "junior level" that don't know jack. There are RHCEs that don't know jack as well. How does including LILO do anything to guarantee this in LPIC-1, other than taking away from other objectives? I *DO* strongly believe that LILO *SHOULD* continue to be included in the LPI 100/200 level objectives. *BUT* it should be the lesser consideration for exams questions and study, and noted as such. This is not because I "don't believe in it" (even I still use it), but out of sheer popularity. Furthermore, Slackware may still be popular, but it's not inside what I regularly refer to as the "3 Sigma" inclusion zone -- basic 1-2-3 sigma percentages here. That means well under 1% of professionals will utilize it. We cannot go off and go after 4+ Sigma concepts, technologies, etc... It's hard enough going outside 2 Sigma (~96%). From: Jorge Armando Medina <[EMAIL PROTECTED]> > Lilo is very important, I do have customers with mandrake servers, they cant > upgrade, they use lilo, they have a lot of slackware servers, If you remove > lilo from the objetives I really wont hire a LPI Professional who doesnt know > how to solve basic boot problems. Then that's _their_ choice. LPI is _not_ designed to represent a distro (or even set of distro's) implementations, but a common denominator of many. If that is not enough, then Mandrake, Slackware and others _should_ do what Canonical has done with Ubuntu (and SuSE before their purchase by Novell) -- create their own 100 supplemental examination. MJang wrote: > Let me just add that LILO is - also - in the upcoming objectives for > the 202 exam (objective 213.1). So it is possible to remove LILO from > the LPIC-1 objectives without removing LILO from the LPI curriculum. This is what I love about Matt and the rest of the LPI gang, volunteers, etc... They have a lot -- and I mean a *LOT* -- of legacy in the program they are still working to redesign and reposition. They are making many things more relevant, more generic to more distros, but still very focused on examining professionals. As I said in my first post, I agree that many of these concepts are "advanced" when you start talking about how boot loaders work, where LILO differs, etc... Stuff that isn't even remotely a consideration for LPIC-1. I stated that LILO should be left at a basic level for LPIC-1, possibly identification only, and said it's more "advanced" to get into the differences and the boot concepts that ultimately will be involved. GRUB is what Debian, Fedora and SUSE and related/based distros ship by default. It's what 3 Sigmas are going to be exposing professionals to as a result. I use LILO, but it's not a LPIC-1 concept. MJang wrote: > And the arguments I see so far in favor of LILO are based on > situations which would require the skills of a more advanced > Linux administrator. It's actually more of the "GRUB v. LILO" and requirements that require an "advanced" administrator, and not so much LILO itself. The default is GRUB on so much now, it's hard to consider LILO as a "default" boot-loader to cover, other than in identification, for LPIC-1. To discuss LILO, therefore, becomes one of "GRUB v. LILO" and results in, "here's where LILO must be used" or "here's where LILO makes things easier." Over Five (5) years ago, it was LILO, that was virtually the default everywhere. That made this consideration more of an issue, because LILO could be considered a "default" and, therefore, not needing "advanced" discussion. But starting five (5) years ago, that started to change. Now today, it's a no-brainer, GRUB is the default in the 3 Sigma of distros. Pretty much kills it for LPIC-1 consideration, other than identification. MJang wrote: > OTOH, I suspect that the first answer many admins would have w/r/t > the GRUB boot problems described would be a LiveCD/DVD distro like > Knoppix. And I'd smack the hell out of them too. ;) Best way to dork up a LVM or MD setup -- or any storage for that matter -- is to boot another kernel/distro than the one that is utilizing it. Especially LVM when it comes to Fedora-based distros, where the newer LVM2/DM features are not often in stock 2.6 distros. It's much better now in latter kernels, but back in the early 2.6 days ... sigh. Happens regularly with ReiserFS and, to a far lesser extent, XFS as well. In general, you want to boot the "Live" media of your distro, not some "all-in-one" Live distro. Simone Piccardi wrote: > Once booted you can just change the also the bootloader. It's just I > did many time ago on all the server still using LILO I had. I suppose > is what you do when you find GRUB. The problem is that some people just want it to be one option, and one option from the get-go -- _their_ default option. ;) Simone Piccardi wrote: > Just look on the device.map file, and this is needed to be just the > first time on install (of GRUB), you'll find all the data there. Actually, the "device.map" file/path is actually more specific to a lineage of distros. Other distros use other filenames, for mapping, configuration, etc... But the configuration is the same, agreed. But yeah, the second I read that the first time, I was like, "okay, this guy hasn't used GRUB much at all." Then he did it again, some 5 or so hours after my post (note my post timestamp is GMT ;) that I hoped would be a "wake up call." Sigh, guess not. Ignorance is _never_ a good bases for people to make viewpoints from, much less, what quickly boils down to, eccentric arguments. Sorry, but that's the truth here. Even I use LILO, and many other loaders, have had to use U-boot way too many times for crap (don't get me started), and I don't expect more than GRUB knowledge. Because when you start visiting LILO and other concepts, you're getting in deeper than virtually _everyone_ I know of (sans Ian and a few others here) can deal with. I'll take 10 professionals out of any LUG, 10 very experienced Linux users in corporate environments, and I'll completely stump them on boot-time issues. And I can bring their systems back from the dead from them too. Without any data loss. In fact, that's the problem. A lot of people will "eventually get it," but they can dork up their system doing it. Simone Piccardi wrote: > It's not extinct, but looking its on its web site everything seems > stopped the 19-Feb-2007. There are many considerations, including GRUB v2 developments, the coming end of the 16-bit PC BIOS era (which is none too soon), 2.2TB (2TiB) issues, etc... The absolute sector approach of LILO was good for many things in its day, but it's days are clearly limited because of countless issues. Many things GRUB v1 and, even more so, GRUB v2 addresses. Simone Piccardi wrote: > That's still an opinion, mostly based, it appears, on the fact that > you don't like the device naming... Which shows a clear PC-only mindset. As much as LPI is focused on PC, complaining about GRUB adopting a PC-like, but non-PC compatible/ alignable nomenclature is rather exposing one's ignorance more than anything. As I said before, that's never a good viewpoint for someone to have. I wish he wouldn't have kept going head-strong with it. I am ignorant of many, many things. But I try to keep my mouth shut or, at a bare minimum, realize I do not have anywhere to stand when people who are more experienced with *BOTH* what I use and have not used start disagreeing with me. It probably means I don't know what I'm talking about. But I have been known to cross my own ignorance more than once, although I usually stop by the 2nd e-mail and say, "okay, that's the 2nd person, I'm missing something here." Ian Shields wrote: > Portage is the default package system on at least one distro, > but LPI doesn't test it. Let alone Portage really comes at the "problem" from a more "source" level. So -- as I've mentioned before (among others) -- it's not really about including portage "in addition to" APT (DPKG) or YUM (RPM), but more as an "augmentation" to existing source/build coverage. Sometimes you have to "step back" and not focus so much on "inclusion" or "fair" (even ignoring installed systems, and making them all "even"), but "relevance" to a topic, under a "context" for the purpose of saying, "here is a professional that understands and can use the technologies in 2-3 sigma variations of system implementations." -- Bryan J Smith Professional, Technical Annoyance mailto:[EMAIL PROTECTED] http://www.linkedin.com/in/bjsmith ------------------------------------------------------------- Fission Power: An Inconvenient Solution _______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
