Why initramfs stops although root device is mountable and ready to use
Boker Everybody, I recently experienced a strange problem: The system is based on Ubuntu kernel 2.6.28 which I compiled and built initramfs for it provided with a driver for ide disk (pata_via.ko) grub should boot this system from the root=/dev/sda1 The boot process stops on a famous message waiting for a root file system. But then it enters the busybox prompt and I see that /dev/sda1 is indeed exist, I can mount it and access files. I do not understand this : root device is ready, but boot process is stuck ?? Thanks, Lev ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Last Meeting (Programming Red Flags) Summary + What's Next forTelFOSS?
On Monday 06 July 2009 20:33:33 Dov Grobgeld wrote: I just reread the article Why the KDE project switched from scons to CMakehttp://lwn.net/Articles/188693/and compared it to my needs: Well, Offer was also referring to some threads on the KDE mailing lists (which I haven't read either). - Support compilation over a fixed number of platforms: Linux, Linux cross compilation for Windows, Windows mingw, Windows MS compiler, CMake supports all of those except perhaps Linux-cross-compile-for-Windows which I'm not sure about. It may exist or may not, but I'm not sure. CMake can also generate proper Microsoft Developer Studio projects. Solaris. - Complete control over compiler flags for different platforms for release and debug mode. CMake gives you that. I was able to override the C_FLAGS variable, etc. - No need to run configure since the code either relies on the cross platform glib infrastructure or ifdef's. I don't understand that point. - A number of autogenerated h- and c-files through either perl or python scripts. You can easily use custom commands or invoke external executables or scripts with CMake. Naturally, this would mean the people building your program will need to have perl, python or whatever installed, but it's probably not a deal breaker. The last of these options is probably the reason I dropped CMake from my consideration list. E.g. the following code that I have in my scons files is difficult to translate: def file2c(env, target, source): out = open(str(target[0]), wb) inp = open(str(source[0]), rb) for line in inp.readlines(): line = line.rstrip() line = re.sub(, , line) line = re.sub(\\\, \\\, line) line = ''+line+'\\n\n' out.write(line) out.close() inp.close() You can put this in a script and call it from CMake or create a custom target for it. You may also opt to write it in pure-CMake, but it's not absolutely necessary. Regards, Shlomi Fish env.Command(menu-top-xml.i, menu-top.xml, file2c) I.e. the dependency is resolved through a python function that is defined within the makefile. I think that scons is the only system that kind of code. Whether it is sane is a different question... Regards, Dov 2009/7/6 Offer Kaye offer.k...@gmail.com 2009/7/6 Dov Grobgeld : I have switched to scons a couple of years back and couldn't be happier. I read some of the threads of the KDE developers detailing how/why the moved from Autotools to CMake. It seems at first that actually SCons was the preferred contender, but when they looked into it more deeply they ran into trouble - apparently it was not mature enough and lacked all the features required for a project of the size and complexity of KDE4. Still it's probably good enough for less complex projects :) -- Offer Kaye -- - Shlomi Fish http://www.shlomifish.org/ Humanity - Parody of Modern Life - http://xrl.us/bkeut God gave us two eyes and ten fingers so we will type five times as much as we read. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Why initramfs stops although root device is mountable and ready to use
Lev Olshvang wrote: Boker Everybody, I recently experienced a strange problem: The system is based on Ubuntu kernel 2.6.28 which I compiled and built initramfs for it provided with a driver for ide disk (pata_via.ko) grub should boot this system from the root=/dev/sda1 The boot process stops on a famous message waiting for a root file system. But then it enters the busybox prompt and I see that /dev/sda1 is indeed exist, I can mount it and access files. I do not understand this : root device is ready, but boot process is stuck ?? Simple: You either use an initramfs, and if so your initramfs should mount the real root file system itself using switch_root() or you don't use an initramfs and let the kernel mount it (but then you need the driver compiled into the kernel). Gilad -- Gilad Ben-Yossef Chief Coffee Drinker CTO Codefidence Ltd. Web: http://codefidence.com Cell: +972-52-8260388 Tel: +972-8-9316883 ext. 201 Fax: +972-8-9316884 Email: gi...@codefidence.com Check out our Open Source technology and training blog - http://tuxology.net Now the world has gone to bed Darkness won't engulf my head I can see by infra-red How I hate the night. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Why initramfs stops although root device is mountable and ready to use
Gilad Ben-Yossef wrote: I do not understand this : root device is ready, but boot process is stuck ?? Simple: You either use an initramfs, and if so your initramfs should mount the real root file system itself using switch_root() or you don't use an initramfs and let the kernel mount it (but then you need the driver compiled into the kernel). Gilad As a nitpicking, if you are using initrd, there is a mode of operation where the initrd (linuxrc script) loads the kernel module, but the kernel does the actual mounting. I'm not sure it's still available in modern kernels. Initrd can also work similarly to initramfs (typically using pivot_root, though, and not switch_root). More to the point, however, I believe Lev is using an initramfs generated by his distribution, which begs the question why didn't the init script on it mount the file system and run switch_root? Lev, from the prompt you get, can you do cat /init and paste here what appears there? Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Why initramfs stops although root device is mountable and ready to use
Shachar Shemesh wrote: Gilad Ben-Yossef wrote: I do not understand this : root device is ready, but boot process is stuck ?? Simple: You either use an initramfs, and if so your initramfs should mount the real root file system itself using switch_root() or you don't use an initramfs and let the kernel mount it (but then you need the driver compiled into the kernel). Gilad As a nitpicking, if you are using initrd, there is a mode of operation where the initrd (linuxrc script) loads the kernel module, but the kernel does the actual mounting. I Yes, but initramfs does not support it AFAIK and I wouldn't recommend anyone to use initrd in favour of initramfs for any system with 2.6 kernel. Gilad -- Gilad Ben-Yossef Chief Coffee Drinker CTO Codefidence Ltd. Web: http://codefidence.com Cell: +972-52-8260388 Tel: +972-8-9316883 ext. 201 Fax: +972-8-9316884 Email: gi...@codefidence.com Check out our Open Source technology and training blog - http://tuxology.net Now the world has gone to bed Darkness won't engulf my head I can see by infra-red How I hate the night. ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Why initramfs stops although root device is mountable and ready to use
Gilad Ben-Yossef wrote: Shachar Shemesh wrote: Gilad Ben-Yossef wrote: I do not understand this : root device is ready, but boot process is stuck ?? Simple: You either use an initramfs, and if so your initramfs should mount the real root file system itself using switch_root() or you don't use an initramfs and let the kernel mount it (but then you need the driver compiled into the kernel). Gilad As a nitpicking, if you are using initrd, there is a mode of operation where the initrd (linuxrc script) loads the kernel module, but the kernel does the actual mounting. I Yes, but initramfs does not support it AFAIK and I wouldn't recommend anyone to use initrd in favour of initramfs for any system with 2.6 kernel. I think it's the other way around - if you exit from your linuxrc when running from initramfs, it'll continue on with standard boot sequence, while ending linuxrc in initrd will panic the kernel with Trying to kill PID 1 error. -- Ilya A. Volynets-Evenbakh http://www.total-knowledge.com ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
Re: Why initramfs stops although root device is mountable and ready to use
Ilya A. Volynets-Evenbakh wrote: I think it's the other way around - if you exit from your linuxrc when running from initramfs, it'll continue on with standard boot sequence, while ending linuxrc in initrd will panic the kernel with Trying to kill PID 1 error. An initramfs exists for any 2.6 kernel. Sometimes it's just a very small one. The way the kernel decides whether to execute it is to check for a */init* file in it. If it finds one, it runs it. If not, it does not. As such, if you have a /linuxrc file in your initramfs, and it simply exists at the end, all that will happen is that the kernel will not find a /init and will skip running anything from the initramfs at all. In that sense you might be said to be right that if your linuxrc exists, the normal boot sequence will continue. The history goes something like this: Originally, the drivers for the root file system had to be compiled into the kernel. This was very difficult, if not impossible, for distribution kernels, as the list of potential drivers included, well, everything, and the kernels were just too big. Then the idea of initrd came - we compile the drivers only for the ram disk and the initrd file system (typically, cramfs) into the kernel. The initrd loads the relevant drivers into the kernel and quits, restoring the original boot sequence. Then someone pointed out that, sometimes, an initrd is all you need. The convention then arose to pass boot=/dev/ram0 to the kernel, which tells it that the initrd stage is the last one. It then became common to put the real boot= option on the kernel command line, but then, from initrd, to load the values for /dev/ram0 into the proc entry for the boot device from linuxrc, manually mount the real root file system, make it the root file system using pivot_root, and exec init from there. Then, for 2.6, people figured that if this is what you normally do anyways, there is no point in carrying around the drivers for the ram disk and cramfs (compiled into the kernel, which means it cannot be unloaded). Instead, use the much lighter tmpfs file system, and use a cpio archive for the actual files. The tmpfs file system was made mandatory, whether initramfs was used or not, and so you couldn't move it from the root (only mount on top of it). This means you cannot use pivot_root, and switch_root was invented. While at it, the legacy boot sequence was removed. Assuming, as Gilad seems to, that we leave initrd is out of the discussion, your options are either run an initramfs and perform the entire root mounting from the /init script there, or compile the root file system drivers into the kernel and let the kernel mount them using the boot= kernel option. Shachar -- Shachar Shemesh Lingnu Open Source Consulting Ltd. http://www.lingnu.com ___ Linux-il mailing list Linux-il@cs.huji.ac.il http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il
