[opensuse-factory] 2 questions concerning a recent kernel and hostname
Group; 1. Over the past 15 years I have downloaded and compiled about every kernel basic and git from www.kernel.org and gotten them to work. I have changed the CPU to match this one and the default name using make menuconfig. I have tried over and over recently with no luck and openSuSE. Using oldconfig and /proc/config.gz as .config and make menuconfig. Both work just fine but mkinitrd fails - even though the modules are built and installed in /lib/modules/. Both openSuSE supplied kernel source and kernel.org kernels fail and have even cause this system to need reloading from scratch. 2. I have gone through all gyrations looking for why at a login I get no hostname but (none). And Apache2 complains about (none) at boot time. The happened before and was fixed in 11.4 one of alpha/beta versions but it is again broken -- 73 de Donn Washburn 307 Savoy Street Email:" n5xwb@comcast.net " Sugar Land, TX 77478 LL# 1.281.242.3256 Ham Callsign N5XWB HAMs : " n5xwb@arrl.net " VoIP via Skype:n5xwbg BMWMOA #:4146 Ambassador " http://counter.li.org " #279316 -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Donn Washburn wrote:
Group;
1. Over the past 15 years I have downloaded and compiled about every kernel basic and git from www.kernel.org and gotten them to work. I have changed the CPU to match this one and the default name using make menuconfig. I have tried over and over recently with no luck and openSuSE. Using oldconfig and /proc/config.gz as .config and make menuconfig. Both work just fine but mkinitrd fails - even though the modules are built and installed in /lib/modules/. Both openSuSE supplied kernel source and kernel.org kernels fail and have even cause this system to need reloading from scratch.
2. I have gone through all gyrations looking for why at a login I get no hostname but (none). And Apache2 complains about (none) at boot time. The happened before and was fixed in 11.4 one of alpha/beta versions but it is again broken
I had similar problems when I upgraded, I think it was to the 11 series (as I also build my own kernel from kernel.org configed for my hw)... It was when they switched to grub and putting everything on a RAMDISK to boot from and started thinking they could totally go with file-labels instead of /dev/sda3 -- including at boot.... I never was able to get it to work right with the suse framework, because, in order to give the illusion of booting by the 'name' of the partition, rather than using /dev/sda3, they basically have to boot a miniroot of sorts to read the labels, and that all has to be on the boot-ram disk. Once I switched back to lilo, (I use XFS BTW, for all my disks, including the boot disk -- have since maybe suse 7-8 timeframe). I did run into a problem in some of the recent kernels with the boot code not fitting in the boot area, but a new version of lilo has solved that now as well. I'm not saying it can't be done -- I needed my system working again ASAP, so I didn't have weeks to look at debugging the issue. It's frustrating too -- since if I don't use their grub setup, I can't get the suse kernels to load (suse hasn't kept up lilo and was actually claiming a bug in grub was the fault of xfs -- so they dropped support for xfs for a while...until some people vehemently pointed out the bug was in grub (modifying a live-mounted file system?! You've got to be kidding!!).... Anyway, Would be nice if they had the resources to make everything play nice together, but it's a matter of them using the tools they are most familiar with and not having the cycles to do everything. Doesn't mean I don't continue to put in my voice about problems, because a lilo boot of my kernel happens in 1/2-1/3 the time of a standard suse boot from grub. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Linda Walsh wrote:
I did run into a problem in some of the recent kernels with the boot code not fitting in the boot area, but a new version of lilo has solved that now as well.
FYI, I hit the same thing, and I'm now working on getting lilo 23.2 into Factory. -- Per Jessen, Zürich (15.7°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Le 18/06/2011 09:09, Per Jessen a écrit :
FYI, I hit the same thing, and I'm now working on getting lilo 23.2 into Factory.
did you try grub2? My server provider switched from lilo to grub2 recently (that said, I have no nidea why) jdd -- http://www.dodin.net http://pizzanetti.fr -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
jdd wrote:
Le 18/06/2011 09:09, Per Jessen a écrit :
FYI, I hit the same thing, and I'm now working on getting lilo 23.2 into Factory.
did you try grub2?
No, I use only lilo. Just a personal preference. -- Per Jessen, Zürich (15.1°C) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 18/06/11 06:25, Linda Walsh wrote:
Donn Washburn wrote:
Group;
1. Over the past 15 years I have downloaded and compiled about every kernel basic and git from www.kernel.org and gotten them to work. I have changed the CPU to match this one and the default name using make menuconfig. I have tried over and over recently with no luck and openSuSE. Using oldconfig and /proc/config.gz as .config and make menuconfig. Both work just fine but mkinitrd fails - even though the modules are built and installed in /lib/modules/. Both openSuSE supplied kernel source and kernel.org kernels fail and have even cause this system to need reloading from scratch.
2. I have gone through all gyrations looking for why at a login I get no hostname but (none). And Apache2 complains about (none) at boot time. The happened before and was fixed in 11.4 one of alpha/beta versions but it is again broken
I had similar problems when I upgraded, I think it was to the 11 series (as I also build my own kernel from kernel.org configed for my hw)...
It was when they switched to grub and putting everything on a RAMDISK to boot from and started thinking they could totally go with file-labels instead of /dev/sda3 -- including at boot....
I never was able to get it to work right with the suse framework, because, in order to give the illusion of booting by the 'name' of the partition, rather than using /dev/sda3, they basically have to boot a miniroot of sorts to read the labels, and that all has to be on the boot-ram disk. Once I switched back to lilo, (I use XFS BTW, for all my disks, including the boot disk -- have since maybe suse 7-8 timeframe).
I did run into a problem in some of the recent kernels with the boot code not fitting in the boot area, but a new version of lilo has solved that now as well.
I'm not saying it can't be done -- I needed my system working again ASAP, so I didn't have weeks to look at debugging the issue. It's frustrating too -- since if I don't use their grub setup, I can't get the suse kernels to load (suse hasn't kept up lilo and was actually claiming a bug in grub was the fault of xfs -- so they dropped support for xfs for a while...until some people vehemently pointed out the bug was in grub (modifying a live-mounted file system?! You've got to be kidding!!)....
Anyway, Would be nice if they had the resources to make everything play nice together, but it's a matter of them using the tools they are most familiar with and not having the cycles to do everything.
Doesn't mean I don't continue to put in my voice about problems, because a lilo boot of my kernel happens in 1/2-1/3 the time of a standard suse boot from grub.
The last kernel problems I had going back a few months was with XFS where modules were being zeroed out on boot sometimes, so I moved to ext4. Donn, can you show us some output, mkinitrd failing says absolutely zero about how it's failing. What filesystem are you using? The previous vanilla kernels all worked as does the current one built minutes ago. slipstream:/home/lancelot/ftp/may11 # uname -r 3.0.0-rc3-git7-smp slipstream:/home/lancelot/ftp/may11 # cat /proc/driver/nvidia/version NVRM version: NVIDIA UNIX x86_64 Kernel Module 275.09.07 Wed Jun 8 14:16:46 PDT 2011 GCC version: gcc version 4.6.0 20110607 [gcc-4_6-branch revision 174741] (SUSE Linux) slipstream:/home/lancelot/ftp/may11 # # lsmod|grep vbox vboxnetadp 13382 0 vboxnetflt 28693 0 vboxdrv 238789 2 vboxnetadp,vboxnetflt I also have all sorts of weird stuff attached and working - SDR transceiver (Software Defined Radio), Logic analyser, VNA (Virtual Network Analyser). # cat /proc/asound/cards 0 [SB ]: HDA-Intel - HDA ATI SB HDA ATI SB at 0xf7df8000 irq 16 1 [Live ]: EMU10K1 - SB Live! 5.1 [SB0060] SB Live! 5.1 [SB0060] (rev.7, serial:0x80611102) at 0xb880, irq 20 2 [DG8SAQI2C ]: USB-Audio - DG8SAQ-I2C www.obdev.at DG8SAQ-I2C at usb-0000:00:13.2-3.3, high speed # lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Bus 001 Device 003: ID 148f:2573 Ralink Technology, Corp. RT2501/RT2573 Wireless Adapter Bus 002 Device 002: ID 0409:005a NEC Corp. HighSpeed Hub Bus 002 Device 003: ID 050d:0307 Belkin Components Bus 006 Device 002: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 001 Device 004: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port Bus 001 Device 005: ID 16c0:0478 VOTI Bus 001 Device 006: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB Bus 002 Device 005: ID 047d:2043 Kensington Bus 002 Device 006: ID 16c0:05dc VOTI shared ID for use with libusb Bus 002 Device 007: ID 0402:5602 ALi Corp. M5602 Video Camera Controller Bus 002 Device 012: ID 046d:c404 Logitech, Inc. TrackMan Wheel Bus 002 Device 013: ID 068e:00f2 CH Products, Inc. Flight Sim Pedals Bus 002 Device 014: ID 068e:00ff CH Products, Inc. Flight Sim Yoke Bus 001 Device 007: ID 0925:3881 Lakeview Research # cat /etc/SuSE-release openSUSE 12.1 Milestone 1 (x86_64) VERSION = 12.1 CODENAME = Asparagus So here I am, fat dumb and happy with everything functioning 100%. 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 For additional commands, e-mail: opensuse-factory+help@opensuse.org
Sid Boyce wrote:
The last kernel problems I had going back a few months was with XFS where modules were being zeroed out on boot sometimes, so I moved to ext4.
ext4 is has options like 'write-through', that disallow buffering of large writes. If you have unreliable hardware, subject to crashes, it is probably a better choice. xfs was designed for servers that have UPS's -- if used with RAID, then with battery back-up on the RAID card as well, it wasn't designed for systems that could crash at any point.... You have to match the file system with your system's usage/reliability. My systems are all on UPS's, I think I had one XFS file corruption in the 10+ years I've been using it...but my systems are also usually on 24/7. On my largest array (a home server), I get max-read/write (large files) of 1GB/s read & write. What do you get with ext4? The file zeroing, BTW, was required for SGI's "Trusted Irix", as any object in the system must be zeroed out before being given to a user. Since XFS allows you to allocate space and THEN write to it -- if you allocate the space and you think you've written to it, but the kernel hasn't flushed it's buffers yet...(between xfs's delayed writes and kernel's buffering can be over 15 seconds or more (it is tunable...BTW to more often or less ... on a laptop setting it to 60 seconds can let the hard disk stay off for most of the time).... BUT....file 'meta' info (names creation, size) gets written immediately to the log...it's file 'data' that can be slower to flush (again, a tunable in /proc), but if you crash or lose power before your buffers are flushed, then the allocated space is ensured to be zeroed when the fs is mounted -- otherwise, you run into a security risk of being able to read someone else's data. It USED to be allowed to disable 'unwritten extent support' at mkfs time, but apparently it was considered too insecure. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 20/06/11 05:15, Linda Walsh wrote:
Sid Boyce wrote:
The last kernel problems I had going back a few months was with XFS where modules were being zeroed out on boot sometimes, so I moved to ext4.
ext4 is has options like 'write-through', that disallow buffering of large writes. If you have unreliable hardware, subject to crashes, it is probably a better choice.
After I went back to ext4 I saw a kernel patch for XFS. The symptoms weren't exactly the same but there had a fair similarity. The problem was with root on XFS on 2 systems. The same HD's are in the systems, mounted and used but not as root.
xfs was designed for servers that have UPS's -- if used with RAID, then with battery back-up on the RAID card as well, it wasn't designed for systems that could crash at any point....
You have to match the file system with your system's usage/reliability. My systems are all on UPS's, I think I had one XFS file corruption in the 10+ years I've been using it...but my systems are also usually on 24/7. On my largest array (a home server), I get max-read/write (large files) of 1GB/s read & write. What do you get with ext4?
All mine, except for 2 laptops are on UPS's. It was just on a series of vanilla kernels when the problems happened. I would build a kernel, check that the modules were OK "sync;sync;sync" and sometimes reboot next day or days later only to find most of them zero bytes. I could eventually get the modules to work by booting and doing "make modules_install" and rebooting.
The file zeroing, BTW, was required for SGI's "Trusted Irix", as any object in the system must be zeroed out before being given to a user. Since XFS allows you to allocate space and THEN write to it -- if you allocate the space and you think you've written to it, but the kernel hasn't flushed it's buffers yet...(between xfs's delayed writes and kernel's buffering can be over 15 seconds or more (it is tunable...BTW to more often or less ... on a laptop setting it to 60 seconds can let the hard disk stay off for most of the time)....
BUT....file 'meta' info (names creation, size) gets written immediately to the log...it's file 'data' that can be slower to flush (again, a tunable in /proc), but if you crash or lose power before your buffers are flushed, then the allocated space is ensured to be zeroed when the fs is mounted -- otherwise, you run into a security risk of being able to read someone else's data.
It USED to be allowed to disable 'unwritten extent support' at mkfs time, but apparently it was considered too insecure.
No crashes, no power loss - the UPS's see to that. I knew that so that's why I used sync after modules_install. The problem only came on with a 2.6.3x series of kernels, -rc and -rc-git. 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 For additional commands, e-mail: opensuse-factory+help@opensuse.org
On 06/20/2011 06:15 AM, Linda Walsh wrote:
ext4 is has options like 'write-through', that disallow buffering of large writes. If you have unreliable hardware, subject to crashes, it is probably a better choice.
I use xfs for my system, any compiling or such is performed on an ext4 partition because although xfs has survived power dips and failures that made my monitor turn blue and persistent bad sectors with no ill effects it's visibly slower on copy, decompress and delete operations. Ext4 hasn't been subjected to this on my system but an ext3 partition would have given me grey hairs. Don't write off xfs as far as crash recovery is concerned but it's slower which is most probably a trade off. JFYI there's an xfs defragmenter "xfs_fsr". Dave P -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (6)
-
Dave Plater -
Donn Washburn -
jdd -
Linda Walsh -
Per Jessen -
Sid Boyce