On 07/30/12 08:10, lynn pecked at the keyboard and wrote:

On 30/07/12 12:33, cagsm wrote:

...

On Mon, Jul 30, 2012 at 12:23 PM, lynn wrote:

...

In 12.1 I just type 3 at the prompt. In 12.2 I don't seem to have the opportunity to type 3 anywhere.

grub2, and that makes it necessary to go into the editor like interface of grub2 during pre-boot time

Ahhgghh. that hurt;-) L x

So much for making things _more_ user friendly, *not*. Seems the programmers forgot about KISS. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2012/07/30 15:05 (GMT+0200) Stephan Barth composed:

Ken Schneider wrote:

...

So much for making things _more_ user friendly, *not*. Seems the programmers forgot about KISS.

They didn't forget about KISS, since they made several things easier to use and I like most of GRUB2.

Granted I've not used it much, because on first exposures (via *buntu) I found too little similarity and less convenience, definitely not easier to use, KISS missing.

However, it seems there is a new fashion in the F/OSS scene to make some things better with a rewrite and leave out well-proven features :-/

For sure, except for the "new" part. KDE4 was started when, 5 years ago? 6? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Mmm, so, how do I boot to a text console in 12.2? Must I learn emacs to be able to do it? Has anyone succeeded? Could anyone tell me how to do it? Thanks, L x -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Aug 1, 2012 at 11:59 AM, Larry Finger wrote:

Do you mean to run level 3? If so, then add a 3 to the boot options line for Grub legacy. If Grub2, then see http://www.if-not-true-then-false.com/2012/howto-change-runlevel-on-grub2/ for a tutorial on how to edit the boot parameters when starting. You add the "3" to the "linux" line.

runlevel 3 doesn't give you a pure text console. I don't know what the OP means, text console = tty, or text console = no graphics mode. If it's the latter, you get it with vga=<n> with <n> a non-graphic[0] mode. [0] http://en.wikipedia.org/wiki/VESA_BIOS_Extensions#Modes_defined_by_VESA -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Aug 1, 2012 at 7:26 PM, Felix Miata wrote:

vga= only works when KMS not active. When booting verbose (e.g. splash=verbose, as opposed to silent, in which case I don't know what happens, since I never boot with silent on cmdline) with vga= on cmdline but not video=, vga= will be active only briefly, until KMS kicks in, after which KMS will choose a mode based upon EDID. If you want ttys to do what vga= did pre-KMS, you need e.g. video=1152x864@60, or whatever your own preferred mode is. Since 11.3 all my kernel lines include both vga= and video=, except on a few machines with video chips lacking KMS support.

Ah, yes, you're right. You need nomodeset too. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Mon, Jul 30, 2012 at 7:33 AM, cagsm wrote:

in opensuse 12.2 the default bootloader probably changed for everybody to grub2 (version 2), and that makes it necessary to go into the editor like interface of grub2 during pre-boot time and add your commandline kernel switch parameters there, which can also be added temporarily for just the following boot attempt if I am not mistaken. ctrl+x or F10 or whatever the help text says in there inside grub2 boots your added changed parameters then.

it seems a bit more complex or complicated in comparison to grub1 times. consult the manpages or websites. good luck.

grub1 also made you go into edit mode by default. I'm not sure whether it's an opensuse-specific patch or a config thing, but opensuse is the only grub-based distro I know that lets you change the kernel command line so easily. I liked it in fact, it makes phone troubleshooting with inexperienced users a lot easier (they don't have to press their way through unwieldly menus). Anyway, if it's an opensuse patch, I'd bet they didn't have time to port it to grub2 yet. If it isn't... I'd suggest they do :-) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Felix Miata wrote:

This amounts to a feature loss, so a bug would be the appropriate way to react, if one hasn't already been filed. As long as Grub Legacy is available, I won't be using Grub 2, making me an inappropriate person to file such a bug.

---- Why don't people use LILO? It's interface is still the same and it still works... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 2012/08/01 13:08 (GMT-0700) Linda Walsh composed:

Felix Miata wrote:

...

This amounts to a feature loss, so a bug would be the appropriate way to react, if one hasn't already been filed. As long as Grub Legacy is available, I won't be using Grub 2, making me an inappropriate person to file such a bug.

Why don't people use LILO?

It's interface is still the same and it still works...

I can't answer for others. As for me WRT Grub Legacy: 1-Because of Lilo, I avoided Linux until I discovered distros that used Grub and defaulted to it. 2-Kernel/initrd changes require "running" lilo before a reboot can use them. 3-Grub shell allows to manually boot from the Grub shell, crucially handy if menu.lst is missing or otherwise problematic. 4-Interactive editing of initrd & kernel cmdline. 5-Chainloads NTLDR, IBM BM (at least in theory), other Grubs, & even Lilo. 6-Easily configurable & installable even though booted to another OS or media. 7-Needs no files in /etc to be able to function or configure. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wednesday 2012-08-01 22:08, Linda Walsh wrote:

Felix Miata wrote:

...

This amounts to a feature loss, so a bug would be the appropriate way to react, if one hasn't already been filed. As long as Grub Legacy is available, I won't be using Grub 2, making me an inappropriate person to file such a bug.

---- Why don't people use LILO?

Because they hate having to run it whenever they add a new kernel? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 16/08/12 02:52, Linda Walsh wrote:

Jan Engelhardt wrote:

...

On Wednesday 2012-08-01 22:08, Linda Walsh wrote:

...

Felix Miata wrote:

...

This amounts to a feature loss, so a bug would be the appropriate way to react, if one hasn't already been filed. As long as Grub Legacy is available, I won't be using Grub 2, making me an inappropriate person to file such a bug.

---

Why don't people use LILO?

Because they hate having to run it whenever they add a new kernel?

And you are saying no suse-config needs to be done to add a new kernel to a grub menu when one is added?

Isn't the running of such part of the install?

Wouldn't running lilo be part of the install if it was similarly supported?

I don't know if this is pertinent as I haven't been following the complete thread. I build and deploy vanilla kernels mainly to test for problems with VirtualBox and the NVidia driver. I simply run the following script -- different disk ID's as appropriate to the particular system -- before rebooting to build the drivers. Much less work to do than editing /etc/menu.lst for grub1. --------------------------------------- Cut ------------------------------------------------------------ #!/bin/sh cp arch/x86/boot/bzImage /boot/vmlinuz-$1;cp System.map /boot/System.map-$1 rm /boot/System.map;ln -s /boot/System.map-$1 /boot/System.map cp .config /boot/config-$1 cd /boot; mkinitrd -k vmlinuz-$1 -i initrd-$1 -M /boot/System.map -d /dev/disk/by-id/ata-WDC_WD20EARS-07MVWB0_WD-WCAZA4270277-part1 grub2-mkconfig -o /boot/grub2/grub.cfg ------------------------------------- Cut ---------------------------------------------------------------- Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 20/08/12 21:36, Linda Walsh wrote:

Sid Boyce wrote:

...

#!/bin/sh cp arch/x86/boot/bzImage /boot/vmlinuz-$1;cp System.map /boot/System.map-$1 rm /boot/System.map;ln -s /boot/System.map-$1 /boot/System.map cp .config /boot/config-$1 cd /boot; mkinitrd -k vmlinuz-$1 -i initrd-$1 -M /boot/System.map -d /dev/disk/by-id/ata-WDC_WD20EARS-07MVWB0_WD-WCAZA4270277-part1 grub2-mkconfig -o /boot/grub2/grub.cfg ------------------------------------- Cut

---

---Same here... cept I'm lazier.. I don't type in the version -- just 'm' or no 'm' to install modules as well as kernel...

----------------------- #!/bin/sh -xe # v6 - allow for alphabetics in extra version (2011/08) # v5 - convert to 2.6.XX/3.X.x (2nd) name-forming convention (2008/12; RCS'ed) # v4 - convert to 2.6 name-forming convention # v3 - add parameter check to run modules_install export arch="${ARCH:-""}" if [ -z "${arch:-""}" ] ; then arch="$(/bin/uname -i)" ; fi shopt -s expand_aliases alias sed="sed -r" maj=$(grep "^VERSION = " Makefile|sed 's/.*[ ]([0-9]+)/\1/ ') min=$(grep "^PATCHLEVEL = " Makefile|sed 's/.*[ ]([0-9]+)/\1/ ') dot=$(grep "^SUBLEVEL = " Makefile|sed 's/.*[ ]([0-9]+)/\1/ ') patch=$(grep "^EXTRAVERSION = " Makefile|sed 's/.*[ ]([-\.0-9a-zA-Z]+)/\1/ ') if [ -e .config ]; then local=$(grep "CONFIG_LOCALVERSION=" .config |sed 's/^[A-Z_]+="(.*)"/\1/ ') fi KERN="$maj.$min.$dot$patch$local" echo "Kernel = $KERN" set -x cp ./arch/$arch/boot/bzImage /boot/vmlinuz-$KERN cp System.map /boot/System.map-$KERN test -e /boot/System.map && rm /boot/System.map # a fail ends script due to -e ln -s /boot/System.map-$KERN /boot/System.map unset ROOT /sbin/lilo if [ "$1" == "" ]; then echo Modules not installed else echo installing modules... make modules_install fi OK, another way to skin the cat. I use a different script to take care of building the kernel and installing modules. When the build completes successfully, this script takes care of setting everything up for a reboot. Regards Sid.

-- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Senior Staff Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt wrote:

On Thursday 2012-08-16 03:52, Linda Walsh wrote:

...

...

...

Why don't people use LILO? Because they hate having to run it whenever they add a new kernel? And you are saying no suse-config needs to be done to add a new kernel to a grub menu when one is added?

A kernel does not strictly have to be added to the menu for grub to be able to boot it.

...

Isn't the running of such part of the install? Wouldn't running lilo be part of the install if it was similarly supported?

Think outside rpm for a change. The less steps in the install, the more likely to be successful.

Now you are talking probabilities. I don't use rpm to install my kernel. I don't have to run an Install script written in perl. I run a make and use a couple of lines of shell script. Which is more reliable? A couple of lines of shell or a few hundred perl in an updating perl dist? Those few lines of shell have no dependencies. Any method suse supports has more. You want to talk reliability and probabilities? I'd wager my kernel install has considerably fewer steps as it simply copies the kernel, maps and modules into place. No packages to extract. So....we agree...thew fewer steps in the install the more likely to be successful. I forget things all the time. If it was complicated, I would screw it up! -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt wrote:

If you start to throw in shell scripts, then certainly, perl-Bootloader is a lot more reliable, because in contrast to your shellage, is tested by more than just one person.

---- Au contrare. depending on /bin/sh, is alot less code to depend on than perl which has had numerous incompatible changes over the past 10-15 years. /bin/sh has been far more stable.

But since I was talking about *hand* installing kernels without automation, ...

--- Hand installing, like where you enter 1's and 0's with dip switches on the front of a panel? or do you have single commands that copy entire files? Where did you get the image? did you enter the binary by hand or did you run a script? "By Hand"??.. who, who does any kernel remaking more than 1-2 times doesn't do something to aid in install -- other wise they'd be wasting time. The script was more reliable than anything I could type in. No typo's, no misspellings, knows the right versions without me even thinking about it. That is my idea of a hand install. I write helper scripts to save my hands from over use -- but it was all still done by my hands.

well since you have gone off-topic there

Not really, we were discussing relative merits of lilo/grub because grub (or grub2) turns off the boot console by default in text mode -- and doesn't seem to use the built-in text modes of the BIOS/graphics chip, **to the point**, that many people earlier in the discussion didn't know what was meant by text mode nor know that the text mode of a frame buffer wasn't really text mode. Those people are sufficiently separated from the low-level HW functionality as to already be unaware of its abilities. and what they have given up to use various conveniences. PC-boot computers have been the main staple of booting for the past 40 years -- UEFI compat while on schedule to supplant that is far from universal. UEFI compat more closely parallels grub boot in that its almost a miniature OS in the BIOS, but as you move up in level, it's easier to lose control of the low-level details -- like being able to easily boot a kernel at will -- suse is buying into a future where machines will have to have secure boot disabled or not to boot at all. Further partitioning the world. Simply removing 'text mode' a root symptom of booting with one loader vs. the other. So they would seem to be interrelated. Point being if suse supported at least 2 ways of doing boot lilo/elilo for simplicity and grub/grub2 for those who like to call themselves power users the point would be moot. At the level of the average desktop user -- they won't care much which is used as long as it boots. Only us development types get into this level of arcane disagreement.... -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Dominique Leuenberger a.k.a DimStar wrote:

Well, as you have such great scripts and the all-around testing experience:

Why don't you just package your script up, submit it to Factory and change the integration part of Yast / Bootloader config to use your scripts that does everything and more, just without error?

If I thought I could write something I would find acceptable for submission, I would, but my standards are such that that I rarely think my code would be worthwhile for others. The code I write that is reliable enough is usually too specific -- i.e. it's reliable because the specification for how it needs to perform is sufficiently narrow that it can do the task well. I'm very aware of the issues in supporting complex software. While software complexity rises geometrically, if one is lucky, testing doesn't shrink -- I say lucky, as testing needs to rise in proportion to complexity. But usually, the contrary happens, and major companies release product and call it Beta quality -- and that's become the standard.

THEN, and ONLY then, when NOBODY has any issues with your solution, can you make claims that your solution is so much superior to the existing perl-bootloader soltution.

I make no claim of superiority. The discussion was centered on the problem of having to call lilo as part of a kernel install. I and others pointed out that that by using a script (including post-install scripts in rpm), one can do just about anything one needs to support their installation. Someone posted their script that worked with grub for a 'hand install' (one could argue about that definition endlessly when it somes to the fact that it's all done in electrons). As for perl-bootloader vs. my kernel installer? well I make no claims of superiority, but on my system, mine works, and perl-bootloader doesn't. So, I don't really care if it is better -- it first has to work before better is even considered. When the suse-boot-installer USED to work -- it took ~3 minutes to run, most of which was spent building a RAM disk image that I don't boot from. vs. my script ... that installs kernel + modules in <1 minute. Used to be about 20-30 seconds, but kernel images have gotten a bit bigger and lilo makes a map of every sector of every kernel image. My script broke when lilo broke for a few months and suse no longer supported it... fortunately the lilo maintainer was already on it (kernel got too big) for certain sector maps... Other than that... it's worked fine for ~8+ years. But I make no claims about general usefulness, nor have I tried to make it general. It's not worth the effort. However, if even if it was slow -- the fact that it works make it better for my situation than something that doesn't. Nothing personal, but I prefer running to not? ;-) -l

Think about more complexity than what your system offers...

Point being: openSUSE is the distribution produced by the openSUSE community. SUSE happens to be an important 'player' in this community, but does not have the overall responsibility... when oh WHEN will people understand that SUSE is NOT delivering openSUSE as a unit...

Dominique

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Jan Engelhardt wrote:

Think outside rpm for a change. The less steps in the install, the more likely to be successful.

Actually just thought about it -- When I auto-update my packages, new kernels are often installed as well -- the suse way. They are completely ignored. They fail to replace my current kernel (which is good for me. I suppose it is bad, but I've come to expect and somewhat rely on the fact that installing a suse kernel will have no effect on my boot process... That's how reliable the suse boot install is. I DO have my /etc/sysconfig/bootload configed for the correct loader... Its just that the code your boot installer relies on to insert it's new kernel into a bootable position in the updated system has been broken for several releases. So you want to talk chances of your install being successful or reliability? Let's not -- then I'd have to worry that it might get it right and I might have to actually do something about it. That bug was the thing that kicked me back from using grub which I used for a while (it was documented in one of the references I posted yesturday about XFS support being hosed due to grub. Another grub bug -- I changed my boot partition. so new grub installs were into the new place, but boot kept using the old boot partition (which thankfully I hadn't wiped yet). Switching back to lilo solved both problems. It did its updates to the partition I was actually going to boot from -- not the one that grub kept seeing as my boot disk. So "think outside grub for a change" (especially it's boot paradigm. It reliably doesn't work in various situations. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Philipp Thomas wrote:

On Thu, 16 Aug 2012 06:23:43 -0700, Linda Walsh wrote:

...

That's how reliable the suse boot install is.

I do get the impression that you like to alienate people!

Not really -- I'm just resigned to it because people usually assume the wrong things or misquote me. Like you, below.

You deliberately bypass the distribution and still expect things to work the distribution way?

I bypass how the kernel boots. That's not bypassing the distribution.

I'm hundred percent sure you'ld have loudly complained if the installation of a distribution kernel had changed your boot setup.

You be of equal percentage wrong as it has changed my setup before and when it did I was aware of what it did and what the effects were and what I needed to do about it (if anything). It's being caught be surprises .. like the OS NOT boot'ing when control was handed over to the distribution after 12.1 upgrd -- due to systemd being subb'ed in for the init scripts and the upgrade didn't handle upgrading all the old scripts and/or the old scripts didn't work with systemd. Either way, Kernel still came up, and as soon as I reinstalled init.d the distribution way -- from it's rpm and got rid of systemd, it worked.

Philipp

-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org