Re: [Mageia-dev] Issues with dracut
'Twas brillig, and David W. Hodgins at 03/02/12 08:04 did gyre and gimble: On Tue, 17 Jan 2012 07:22:30 -0500, Colin Guthrie mag...@colin.guthr.ie wrote: Are things working OK for you now with dracut or is it still busted? Just to clarify why I think the problem is happening on single core systems. On a multi-core system, the bash and udevd processes will be running on different cores. When the script executes the udev settle command, it continues to execute, so the loop checking to see if udev is done finds it isn't, so it then looks for/runs the initqueue jobs. On a single core system, the bash script waits for the settle command to finish, so then finds it's done, and exits without even trying to run the initqueue jobs. The patch in my prior message is effectively changing the script from udev done or jobs done to udev done and jobs done. Hmm, actually thinking about this more, I'm not 100% sure I agree with this argument. The number of cores should be irrelevant here as the program itself should be dealing with things synchronously anyway. I'm wondering if it's more of an issue relating to the fact that it's not specifically waiting for the LVM device to be ready. I guess your / is either not on LVM or is in a different Volume Group? In my tests it worked, but perhaps the dual core machine is simply that bit faster (and it's speed, not #cores that is important)? In the file parse-lvm.sh, it does a for loop and has a wait_for_dev call. This function will put stuff into the initqueue that should prevent the exiting of the loop until that device exists... for dev in $(getargs rd.lvm.vg rd_LVM_VG=) $(getargs rd.lvm.lv rd_LVM_LV=); do wait_for_dev /dev/$dev done Now according to the man page, these options are only meant to be used to restrict what devices are activated so they shouldn't be needed per-se. But it brings an important point... there does not appear to be any wait_for_dev calls for the usrmount module So nothing is going to be waiting for the device to exist. If it takes a little while to come up it could lead to your error. And herein we have chicken and egg... we don't know where /usr is (i.e. which /dev/foo) until we mount / (as we have to read /etc/fstab). But by the time we've mounted /, we've already exited this loop and thus cannot re-enter the loop to wait for more devices. Tricky, and certainly something I'll discuss with Harald this weekend. He does have a separate branch that deals with usr mounting in a more holistic way (i.e. it handles /usr/bin being a separate mount if that floats your boat!), but I've not looked at this for a while to see if he's progressed any with it. All in all, it's perhaps just the fact that the first call to udevadm settle is skipped due to there being nothing in your initqueue/finished/ folder? You can check via passing rd.break=initqueue and looking in the folder. If so, then all that should be needed to get this into shape is to put a dummy file in there as part of the 98usrmount module, have that file delete itself and return and error code, thus causing check_finished() to return non zero and thus the call to udevsettle will be reached. If this is NOT the issue, then it should just be a timing thing plain and simple. To confirm, this you should simply be able to pass rd.break=pre-pivot to the command line, wait a little while and then just type exit to continue the boot process. This extra time should be sufficient for udev to see the LVM stuff and for the mount command to succeed (I hope!) Sorry for the long reply. You will likely have to poke in the dracut code to understand everything I'm saying, but it looks like you're doing that happily already :D Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Issues with dracut
On Tue, 17 Jan 2012 07:22:30 -0500, Colin Guthrie mag...@colin.guthr.ie wrote: Are things working OK for you now with dracut or is it still busted? I've finally figured out why it wasn't working for my system. Two separate problems. First, /dev/$volumegroup/$logicalvolume symlinks are no longer created. My fstab had ... /dev/91/usr /usr ext4 defaults,relatime,user_xattr 1 2 which used to work, but /dev/91/usr is not created when the lvm scan is run. /dev/mapper/91-usr is created, but not /dev/91/usr. Second, on my single core system, the loop to process the things found by udev only ran while :; do check_finished break at which point it ended the loop, without trying to run the initqueue jobs. I've attached a patch to fix the init script. Would you prefer I open a new bug report for this? Regards, Dave Hodgins init.patch Description: Binary data
Re: [Mageia-dev] Issues with dracut
'Twas brillig, and David W. Hodgins at 19/12/11 21:48 did gyre and gimble: On Sun, 18 Dec 2011 17:22:46 -0500, Colin Guthrie mag...@colin.guthr.ie wrote: Can you run the attached? It works. It identifies /usr as being on 252:9, which is on 8:12, which has the fs_type LVM2_member. Regards, Dave Hodgins Sorry, missed the reply... if this attachment worked, then the main code should work for you too Are things working OK for you now with dracut or is it still busted? Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Issues with dracut
On Sun, 18 Dec 2011 17:22:46 -0500, Colin Guthrie mag...@colin.guthr.ie wrote: Can you run the attached? It works. It identifies /usr as being on 252:9, which is on 8:12, which has the fs_type LVM2_member. Regards, Dave Hodgins
Re: [Mageia-dev] Issues with dracut
On Sat, 17 Dec 2011 22:00:51 -0500, Colin Guthrie mag...@colin.guthr.ie wrote: The shell script you'll need to tweak is /usr/lib/dracut/modules.d/90lvm/module-setup.sh. That is the problem. In that module, it finds /usr on dev/block/252:9, and the call to get_fs_type correctly returns the file system type as ext4, but the module-setup.sh is looking for LVM2_member which will never be returned for a mounted file system. I don't see how it could be working on your system. Regards, Dave Hodgins
Re: [Mageia-dev] Issues with dracut
'Twas brillig, and David W. Hodgins at 18/12/11 21:28 did gyre and gimble: On Sat, 17 Dec 2011 22:00:51 -0500, Colin Guthrie mag...@colin.guthr.ie wrote: The shell script you'll need to tweak is /usr/lib/dracut/modules.d/90lvm/module-setup.sh. That is the problem. In that module, it finds /usr on dev/block/252:9, and the call to get_fs_type correctly returns the file system type as ext4, but the module-setup.sh is looking for LVM2_member which will never be returned for a mounted file system. I don't see how it could be working on your system. For me my /usr is found on dev/block/252:0... So I guess this is the problem. Can you run the attached? It produces: Checking / via 8:1 Checking /usr via 252:0 _needed=1 0 for me. My df output: /dev/mapper/vg0-1 ... /usr Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ test-lvm.sh Description: application/shellscript
Re: [Mageia-dev] Issues with dracut
On Fri, 16 Dec 2011 09:11:48 -0500, Colin Guthrie mag...@colin.guthr.ie wrote: I'll have a look and if I cannot come up with something better, I'll just give up and force grep to be installed :D With the current versions of dracut and lvm, lvm is failing to load due to libncursesw.so.5 not loading. I've solved it on my system for now, by copying # ll /usr/lib/libncursesw.so.* lrwxrwxrwx 1 root root 18 Jul 1 13:41 /usr/lib/libncursesw.so.5 - libncursesw.so.5.9* -rwxr-xr-x 1 root root 369968 Jul 1 04:01 /usr/lib/libncursesw.so.5.9* to /lib, running ldconfig and adding install_items+=(/lib/libncursesw.so.5.9 /lib/libncursesw.so.5) to /etc/dracut.conf. Regards, Dave Hodgins
Re: [Mageia-dev] Issues with dracut
'Twas brillig, and David W. Hodgins at 17/12/11 20:00 did gyre and gimble: On Fri, 16 Dec 2011 09:11:48 -0500, Colin Guthrie mag...@colin.guthr.ie wrote: I'll have a look and if I cannot come up with something better, I'll just give up and force grep to be installed :D With the current versions of dracut and lvm, lvm is failing to load due to libncursesw.so.5 not loading. This is strange. I've got LVM on my system and it works fine :s Dracut should install all dynamic libs needed by apps. Which app needs this library specifically? I've solved it on my system for now, by copying # ll /usr/lib/libncursesw.so.* lrwxrwxrwx 1 root root 18 Jul 1 13:41 /usr/lib/libncursesw.so.5 - libncursesw.so.5.9* -rwxr-xr-x 1 root root 369968 Jul 1 04:01 /usr/lib/libncursesw.so.5.9* to /lib, running ldconfig and adding install_items+=(/lib/libncursesw.so.5.9 /lib/libncursesw.so.5) to /etc/dracut.conf. Cool, good to know it works with tweaks... now to make it automatic. What is strange is that my initrd contains: [root@jimmy ~]# lsinitrd| grep libnc lrwxrwxrwx 1 root root 18 Dec 17 10:41 usr/lib64/libncursesw.so.5 - libncursesw.so.5.9 -rwxr-xr-x 1 root root 399664 Jul 1 09:00 usr/lib64/libncursesw.so.5.9 lrwxrwxrwx 1 root root 18 Dec 17 10:41 usr/lib64/libncursesw.so - libncursesw.so.5.9 So I've got the necessary lib... I wonder if this is a side effect of me having lib64ncursesw-devel-5.9-2.mga2 installed (i.e. the dev package)? Perhaps it's someone the key to including the right lib? Perhaps you can test by installing the 32 bit devel package and seeing if the lib is then included automatically? FWIW, dracut is crazy easy to hack on so if you can have a play with it, I'll happily review and merge your patch into our package and push it upstream if needed. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Issues with dracut
'Twas brillig, and Colin Guthrie at 17/12/11 20:21 did gyre and gimble: So I've got the necessary lib... I wonder if this is a side effect of me having lib64ncursesw-devel-5.9-2.mga2 installed (i.e. the dev package)? Perhaps it's someone the key to including the right lib? Perhaps you can test by installing the 32 bit devel package and seeing if the lib is then included automatically? I tried removing the devel pkg and I still got it... I guess it might be a 32-bit issue? If you just checkout the dracut source package (plus our patches) you can run it in tree with ./dracut -l -H -f foo.img and inspect with lsinitrd foo.img, so if you can have a fiddle that would be great. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Issues with dracut
On Sat, 17 Dec 2011 15:21:14 -0500, Colin Guthrie mag...@colin.guthr.ie wrote: Dracut should install all dynamic libs needed by apps. Which app needs this library specifically? When I tried to boot after running dracut with the default config, I was dropped to a shell, with the non-lvm root mounted. I then tried running /sbin/lvm vgchange -a y --ignorelockingfailure, and it failed due to the missing libncursesw.so.5 module. Now that I think about it, a bit more, I think I had already been chrooted into the root, so since /usr hadn't been mounted, of course the module could not be accessed. Something else must have gone wrong before the chroot, that I didn't see. So I've got the necessary lib... I wonder if this is a side effect of me having lib64ncursesw-devel-5.9-2.mga2 installed (i.e. the dev package)? Perhaps it's someone the key to including the right lib? Perhaps you can test by installing the 32 bit devel package and seeing if the lib is then included automatically? I'll test that, and report back. Regards, Dave Hodgins
Re: [Mageia-dev] Issues with dracut
On Sat, 17 Dec 2011 15:21:14 -0500, Colin Guthrie mag...@colin.guthr.ie wrote: Dracut should install all dynamic libs needed by apps. Which app needs this library specifically? Do you have /usr on a logical volume? I've figured out now, that /lib/dracut/hooks/pre-pivot/50mount-usr.sh is failing, as lvm has not yet been activated. Later, I'm dropped to a shell, after the switch to the new root, and since /usr hasn't been mounted, any commands that try to load /usr/lib/libncursesw.so.5 such as lvm, grep, or less, will fail. When I've copied /usr/lib/libncursesw.so.5* to /lib and run ldconfig, it still fails in 50mount-usr, but succeeds later, after the root switch. The dm-mod module loading, and the lvm vgchange -ay --sysinit command should be run before looking for the root file system, as it too could be on a logical volume. Regards, Dave Hodgins
Re: [Mageia-dev] Issues with dracut
'Twas brillig, and David W. Hodgins at 18/12/11 00:04 did gyre and gimble: On Sat, 17 Dec 2011 15:21:14 -0500, Colin Guthrie mag...@colin.guthr.ie wrote: Dracut should install all dynamic libs needed by apps. Which app needs this library specifically? When I tried to boot after running dracut with the default config, I was dropped to a shell, with the non-lvm root mounted. I then tried running /sbin/lvm vgchange -a y --ignorelockingfailure, and it failed due to the missing libncursesw.so.5 module. Now that I think about it, a bit more, I think I had already been chrooted into the root, so since /usr hadn't been mounted, of course the module could not be accessed. Something else must have gone wrong before the chroot, that I didn't see. Ahhh interesting. Could have been a filesystem check error. What filesystem do you have on your /usr ? (obviously on top of the lvm layer). Did typing mount /usr just work? After that (and typing exit) does everything work as expected? Do you have /usr on a logical volume? In my test VM yes, I had / on ext4 and /usr on LVM also with ext4. I've figured out now, that /lib/dracut/hooks/pre-pivot/50mount-usr.sh is failing, as lvm has not yet been activated. That's strange, as lvm should be activated by then. Was the lvm module included in your ramfs? The latest version should detect LVM on the /usr partition, but it's perhaps not full proof (I only tested it in my test vm when I wrote it). Later, I'm dropped to a shell, after the switch to the new root, and since /usr hasn't been mounted, any commands that try to load /usr/lib/libncursesw.so.5 such as lvm, grep, or less, will fail. When I've copied /usr/lib/libncursesw.so.5* to /lib and run ldconfig, it still fails in 50mount-usr, but succeeds later, after the root switch. The dm-mod module loading, and the lvm vgchange -ay --sysinit command should be run before looking for the root file system, as it too could be on a logical volume. They all should be (and are for me). I suspect the missing link is that the lvm module is not being included in your ramfs... If we can work out why it would be great. The shell script you'll need to tweak is /usr/lib/dracut/modules.d/90lvm/module-setup.sh. The code is fairly easy to follow and you can probably hack out the bits to make it a simple runable script to see if you can work out why lvm is not being included. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Issues with dracut
On 16.12.2011 14:35, Colin Guthrie wrote: Hiya, 'Twas brillig, and JA Magallon at 16/12/11 12:06 did gyre and gimble: After those couple previous thread it looks like move to dracut is ongoing, so I decided to try it. Good! This is exactly the kind of feedback we need! I found a couple problems: - dracut inists on loading nouveau driver. With mknitrd, just booting with nokmsboot works. Booting with a dracut generated initrd ignores that. I think it is plymouth that forces it, even if I added 'blacklist nouveau' in a .conf file in modprobe.d: dracut -f: I'll include it but if it's blacklisted, it shouldn't ultimately be used in the ramfs even if it's included. That said, it's clearly inefficient to include it if it is blacklisted so we should try and fix that. Anssi, could this be your code to detect the h/w that causes it to bypass any blacklist checks (not sure if there are actually any blacklist checks when building the initrd... not relaly looked at it much) There is no check. I think the nokmsboot parameter is not working in dracut because the udev rule that interprets it uses the grep command and that is not currently included in the ramdisk. I could hack it in easy enough, but we should maybe see if a more minimal method of detecting it in the commandline is possible. Ah, my dracut initramfs from last month has it, but maybe it has changed since then... Feel free to change the udev rule to use a more minimal method :) -- Anssi Hannula
Re: [Mageia-dev] Issues with dracut
'Twas brillig, and Anssi Hannula at 16/12/11 12:58 did gyre and gimble: On 16.12.2011 14:35, Colin Guthrie wrote: Hiya, 'Twas brillig, and JA Magallon at 16/12/11 12:06 did gyre and gimble: After those couple previous thread it looks like move to dracut is ongoing, so I decided to try it. Good! This is exactly the kind of feedback we need! I found a couple problems: - dracut inists on loading nouveau driver. With mknitrd, just booting with nokmsboot works. Booting with a dracut generated initrd ignores that. I think it is plymouth that forces it, even if I added 'blacklist nouveau' in a .conf file in modprobe.d: dracut -f: I'll include it but if it's blacklisted, it shouldn't ultimately be used in the ramfs even if it's included. That said, it's clearly inefficient to include it if it is blacklisted so we should try and fix that. Anssi, could this be your code to detect the h/w that causes it to bypass any blacklist checks (not sure if there are actually any blacklist checks when building the initrd... not relaly looked at it much) There is no check. OK, so that's fine I think, just a slightly bigger initramfs than is 100% needed but such is life. I wonder, does the modprobe -R stuff process blacklists... it would be kinda nice if a side effect of improving the hostonly mode was to not include blacklisted modules... :D I think the nokmsboot parameter is not working in dracut because the udev rule that interprets it uses the grep command and that is not currently included in the ramdisk. I could hack it in easy enough, but we should maybe see if a more minimal method of detecting it in the commandline is possible. Ah, my dracut initramfs from last month has it, but maybe it has changed since then... I suspect it's a side effect of: ./modules.d/00bootchart/module-setup.sh:inst /bin/grep i.e. if you have bootchart installed, then you get grep and thus other things work too. Feel free to change the udev rule to use a more minimal method :) I'll have a look and if I cannot come up with something better, I'll just give up and force grep to be installed :D Cheers Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Issues with dracut
'Twas brillig, and JA Magallon at 16/12/11 22:52 did gyre and gimble: On Fri, 16 Dec 2011 12:35:22 + Colin Guthrie mag...@colin.guthr.ie wrote: Hiya, 'Twas brillig, and JA Magallon at 16/12/11 12:06 did gyre and gimble: After those couple previous thread it looks like move to dracut is ongoing, so I decided to try it. Good! This is exactly the kind of feedback we need! I found a couple problems: - dracut inists on loading nouveau driver. With mknitrd, just booting with nokmsboot works. Booting with a dracut generated initrd ignores that. I think it is plymouth that forces it, even if I added 'blacklist nouveau' in a .conf file in modprobe.d: dracut -f: I'll include it but if it's blacklisted, it shouldn't ultimately be used in the ramfs even if it's included. That said, it's clearly inefficient to include it if it is blacklisted so we should try and fix that. Anssi, could this be your code to detect the h/w that causes it to bypass any blacklist checks (not sure if there are actually any blacklist checks when building the initrd... not relaly looked at it much)รง Clue... Let's state all my findings. As 'nokmsboot' was ignored, i remembered CentOS where the nvidia installer achived the same blacklisting nouveau. I added the blacklist in /etc/modprobe.d/display-driver.conf, which is a symlink to /etc/nvidia-current/modprobe.conf. It didn't work. After the fiasco with symlinks in systemd, i tried creting a new file. And it worked. So there is something strange with symlinked files... That's interesting... The code in question: ./modules.d/90kernel-modules/module-setup.sh:for i in $(find /etc/modprobe.d/ -type f -name '*.conf'); do So it only finds files. If I change find to find -L this should fix up this problem (when the files are installed, links are dereferenced so that won't be a problem). This should avoid any such similar problems. Also I believe it's pointless to go into any subfolders here, so adding also a -maxdepth 1 should cut down on unnecessary includes. - initrd from dracut fails to detect one of my drives, and booting stops: OK, this is more interesting. ... I found the problem: lsscsi: werewolf:~/dr# cat lsscsi* [0:0:0:0]diskATA ST3250310AS 3.AA /dev/sda [1:0:0:0]diskATA WDC WD3200AVJS-6 12.0 /dev/sdb [2:0:0:0]diskATA ST3320620AS 3.AA /dev/sdc [3:0:0:0]diskATA ST3500418AS CC38 /dev/sdh [5:0:0:0]cd/dvd HL-DT-ST DVDRAM GH22NS50 TN01 /dev/sr0 [6:0:0:0]diskGeneric USB CF Reader 0.00 /dev/sdd [6:0:0:1]diskGeneric USB SD Reader 0.00 /dev/sde [6:0:0:2]diskGeneric USB MS Reader 0.00 /dev/sdf [6:0:0:3]diskGeneric USB SM Reader 0.00 /dev/sdg The disk has been renamed as sdh I changed the mounting points from devices to labels and all worked fine. This will probably not be an issue with standard install, using UUIDs, but the real problem is that drive name asssignment is even more random (well, interlaced ;)). Hmm, interesting. Not quite sure why it's doing that but as it's using udev rather than any manual driver loading, it's likely a more predicable system overall in the long term. Col -- Colin Guthrie colin(at)mageia.org http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Issues with dracut
'Twas brillig, and JA Magallon at 16/12/11 23:08 did gyre and gimble:
On Fri, 16 Dec 2011 12:35:22 +
Colin Guthrie mag...@colin.guthr.ie wrote:
Hiya,
'Twas brillig, and JA Magallon at 16/12/11 12:06 did gyre and gimble:
After those couple previous thread it looks like move to dracut is
ongoing, so I decided to try it.
Good! This is exactly the kind of feedback we need!
I found a couple problems:
- dracut inists on loading nouveau driver. With mknitrd, just booting with
nokmsboot
works. Booting with a dracut generated initrd ignores that. I think it is
plymouth
that forces it, even if I added 'blacklist nouveau' in a .conf file in
modprobe.d:
dracut -f:
I'll include it but if it's blacklisted, it shouldn't ultimately be used
in the ramfs even if it's included. That said, it's clearly inefficient
to include it if it is blacklisted so we should try and fix that. Anssi,
could this be your code to detect the h/w that causes it to bypass any
blacklist checks (not sure if there are actually any blacklist checks
when building the initrd... not relaly looked at it much)
I think the nokmsboot parameter is not working in dracut because the
udev rule that interprets it uses the grep command and that is not
currently included in the ramdisk. I could hack it in easy enough, but
we should maybe see if a more minimal method of detecting it in the
commandline is possible.
If its is (d)ash:
CMDLINE=$(cat /proc/cmdline)
case ${CMDLINE} in
* nokmsboot *)
echo YES
;;
esac
if if uses bash:
CMDLINE=$(cat /proc/cmdline)
if [[ ${CMDLINE} == * nokmsboot * ]]
then
echo YES
fi
Well it's in a udev rule so it's not 100% predictable what it's using.
I'll have a wee look just now.
Col
--
Colin Guthrie
colin(at)mageia.org
http://colin.guthr.ie/
Day Job:
Tribalogic Limited http://www.tribalogic.net/
Open Source:
Mageia Contributor http://www.mageia.org/
PulseAudio Hacker http://www.pulseaudio.org/
Trac Hacker http://trac.edgewall.org/
Re: [Mageia-dev] Issues with dracut
On Sat, Dec 17, 2011 at 12:08:36AM +0100, JA Magallon wrote:
If its is (d)ash:
CMDLINE=$(cat /proc/cmdline)
Or save two fork+execs this way, on dash or bash:
read CMDLINE /proc/cmdline
case ${CMDLINE} in
* nokmsboot *)
echo YES
;;
esac
if if uses bash:
CMDLINE=$(cat /proc/cmdline)
if [[ ${CMDLINE} == * nokmsboot * ]]
then
echo YES
fi
Dan
