Bryan J. Smith wrote: > 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).
I turned that offer down before Kara Pritchard had the job. I know a headache when I see one. > > 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 but you need more flexibility than that. > 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. ;) I know. I deal with redboot and more daily. > > 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. ;) no, just pointing out the difference between a program that runs _after_ boot and one that allows you to boot what you want, how you want (or even at all). Beats flipping switches to boot. > > 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. No, and not redboot, NFS booting, or silo, etc., either. > > Please don't draw lines in the sand. Besides, I can draw them longer > than you (among others longer than I as well ;). I very seldom do, but this is one I need to. If LILO is not tested in some regard in LPIC-1, it won't be taught. If it's not taught, that LPIC level becomes L-0 for me. > > 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. ;) No? If you say so. I have a hard time setting up a boot loader in a vacuum though. What would you boot with it? Ether? > > 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. I thought we were talking about LPIC-1 level knowledge here. > > 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. Well, I didn't know about grub-reboot (and not having grub on a single system had to google it). The documentation I could find was not something that would make me want to try to use it. No mention anywhere of labels. I have little time to spend re-researching every program I don't use on a weekly basis. > > 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. Glad you have time to hover over your e-mail. I just got to this. It was 3 pages off the bottom of the screen last nite. Only got to the bottom this a.m. (I do need to sleep sometime, and I spent way too much time last nite trying to make a system do something for a client he needs a much bigger system for and not reading e-mails). > > 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? I said it solved failover "better"? I said it solved some problems easier, that's for sure. In 1997 when GRUB came out and Caldera ran with it, I used it (very shortly). Since then, I've relooked it perhaps 3 times. I am extremely pragmatic in my choice of software. First, I look at what actually works. When I needed to deploy a number of geographically diverse servers, I looked at reboots. I couldn't at the time (2001) choose beforehand a non-default kernel. LILO won. I looked at both again (not sure what year) when I deployed software RAID-1 on a number of systems. Among the questions I ask: can it do what I need it to? can ANYONE (jr admin) maintain it once it's set up? IF GRUB can _now_ do these things, great (but too late). Am I _now_ going to change all my servers? No. Will I re-evaluate the next time I have a major shift in disk structure? Yes. But that's not today, or when LPIC decides on a whim to rip out something I need tested. > > 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. Wish you'd make up your mind. I don't need in depth knowledge of any boot loader. But for the two x86 disk boot loaders, I need at least one question so the information (at a basic level) is taught. Not tested, not taught. But now you're saying test it in LPIC-1. Above you say no. Below you say it's dropped below your statistically significant level for testing. Can you please decide? > > 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%). Not asking to. > > 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. Even if it's only identification, it will have to be taught. Most of the posters want NO LILO tested at all. > > 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. I sure wish I could figure out what your stance is. > > 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. I don't need an jr admin to explain to me _how_ booting works, just identify the boot program (grub/lilo) and be able to know how to ensure when it's lilo that it will boot. Run lilo and get "fatal error" -- fine, now call me or another senior admin. Don't run lilo and can't boot? Know to try the old kernel first (and how to get it to show up). I don't ask much, but I do ask basics. NFS booting, redboot (I use it on all the embedded systems, mostly arm and mips based), that's definitely LPIC 2 or even 3. > > 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. Exactly. I have way too many systems to maintain to have non-standard stuff. Every system I can make "standard" is. Makes everything, from monitoring to upgrading to maintaining simpler. Every system that is non-standard costs me time -- time I don't have to hover over my e-mails, etc. That even makes errors, when they occur, pretty standard fare, be they boot errors, etc. I also can't change every system every 6 months. A good number of systems I deployed in 2001 are still deployed although they've all had their hardware changed out and more than once, it's still the original install (I love rsync), just continued upgrades. > > 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 work on non-PC systems, but don't expect LPIC-1 to understand it. Taking a lesson from BIOS writers, they refer to disks (mostly) as a: or c:, etc. Why? Understanding. Basic recognition. While this thread looked at these things, most folks don't understand interrupts. Looked at another way: you have brakes, gas, clutch in your car (or at least two of the three). If someone comes to give you lessons and tells you to "hit the frenos", do you understand him? Perhaps. I still find software that uses non-standard terms to be confusing to newbies and more stuff to keep in your head. Unnecessary. Software should do that for me. I know what lilo "hides" and I'm thankful for it. Makes my job easier, especially when it comes to showing someone else the basics. After spending precious time explaining devices, I don't need to start over because software can't do simple translations for me. > > 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." Include LILO or no in LPIC-1 is the question. I've supported LPIC since day one since I need a way to evaluate if someone can do a job or not. I make no assumptions about optional software, mysql/postgres, myriad web servers, mail servers, etc. The test should obviously include some general info on mail, web, sql, but I don't expect specific, detailed knowledge at that level, just how to stay out of trouble and recognize some basic things. I need to know if the individual can work from a command line and do basic tasks -- upgrading a kernel and rebooting is a basic task to me. If an admin can't take a running server and upgrade the kernel and reboot (regardless of whether it is running lilo or grub), and the "certification" hasn't tested that, then that cert does me no good as evaluation criteria. > > > 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. I have a client that insists on Gentoo. That's fine. But because it costs me a premium on my time to maintain it, they get charged a premium price. Gentoo is a fun toy, as is Linux from scratch. But to maintain those systems is, for me, way to time consuming. > > 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." > > > First, let me check to see if anyone else has posted since your post (as it's been more than 5 hours). Then, back to an asterisk installation that's on a system that doesn't have enough CPU to handle what this client wants to do (and he wonders why audio is broken up at high call volumes). Don't get me started on folks who want to use desktop systems as servers. *Sigh.* Ciao, David A. Bandel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ lpi-examdev mailing list [email protected] http://list.lpi.org/cgi-bin/mailman/listinfo/lpi-examdev
