Re: [lfs-dev] LFS Chapter 7
Am 21.04.2014 23:46, schrieb Bruce Dubbs: I have reorganized and rewritten Chapter 7. I'd appreciate feedback. Thanks. -- Bruce It looks really good. I have only three minor things to mention: 1) Unfortunately some (in my opinion) interesting documentation got lost: - |description of /etc/init.d/mountvirtfs| - description of |/etc/rc.d/init.d/udev (it triggers coldplug, |unsets the uevent handler from the default of |/sbin/hotplug) - the configfile |/etc/sysconfig/udev_retry is not mentioned anymore (associated with the *udevadm info --attribute-walk device command) Would it be meaningful to include this documentation again somewhere? 2) The is a typo in paragraph 7.5.2. Configuring the Network Interface Card at boot (systemd): configuartion -- configuration 3) It may should be mentioned that it is necessary to run systemctl disable ifupdown@eth0 before the procedure described under 7.5.3. Configuring the Network Interface Card for systemd-networkd can be used. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Use systemd to configure network interfaces
I copied the example from http://www.freedesktop.org/software/systemd/man/systemd.link.html. Here is the full example: [Match] MACAddress=12:34:56:78:9a:bc Driver=brcmsmac Path=pci-:02:00.0-* Type=wlan Virtualization=no Host=my-laptop Architecture=x86-64 [Link] Name=wireless0 MTUBytes=1450 BitsPerSecond=10M WakeOnLan=magic MACAddress=cb:a9:87:65:43:21 ...still appears to be matching by MAC? Or am I misunderstanding, and the [Link] section doesn't control which name is assigned to which interface In this example we have two MACAdress lines. The first line (in the [Match] section) is for matching the interface by MAC. The second line (in the [Link] section) is for altering the MAC of the interface (MAC spoofing). That's not exactly the question I was asking, but maybe I'm missing something. Sorry, my fault. I think the easiest solution would be to have no Name= line in the config file. Did I get it right now? With the config file you have above, and a static IP set, does systemd issue a SIOCSIFNAME ioctl against a socket FD? If so, what string is in the ifr_newname char array? Actually I don't know how systemd is accomplishing this task (I would have to read the sources first). But I guess that if_newname = wireless0 (if systemd uses SIOCSIFNAME ioctl). And either way, what ip addr add v.w.x.y/z dev XX would systemd run to add the fixed IP to the interface? (Or if it adds the address itself via netlink, then (a) why doesn't it use standard tools to do configuration, (b) does it actually support multiple addresses per interface like ip does, and (c) what name does it dereference to an ifindex for the ifa_index arg to the netlink message that it sends to add the address?) I can't give an answer for (a) and (c). But I can say that systemd supports multiple adresses per interface. The description of the Address= line says: This option may be specified more than once. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Use systemd to configure network interfaces
What about using systemd to bring up the network interfaces? There was already a discussion about this topic before: https://www.mail-archive.com/lfs-dev@linuxfromscratch.org/msg19837.html The systemd version wouldn't need the LFS-Network-Scripts anymore. The main book could use both the scripts (if booted by Sysvinit) and .link and .network files (if booted by systemd). Here are some useful links: http://coreos.com/blog/intro-to-systemd-networkd/ http://www.freedesktop.org/software/systemd/man/systemd.link.html http://www.freedesktop.org/software/systemd/man/systemd.network.html Any thoughts? Kind regards Sebastian -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Use systemd to configure network interfaces
Am 14.04.2014 21:52, schrieb Bruce Dubbs: I've thought about it, but my experience with systemd is limited. Do you have specific instructions I can test with LFS? -- Bruce Ok, I'll try to give a starting point. 1.) First of all we need to create a .link file (for example 15-eth0.link) in /usr/lib/systemd/network: [Match] MACAddress=12:34:56:78:9a:bc [Link] Name=eth0 This assignes the name eth0 to the interface with the MAC address 12:34:56:78:9a:bc. The file name is important: if there would be a second file (for example 10-eth1.link) with Name=eth1instead of Name=eth0 the interface would get the name eth1. 2.) The second step would be to create .network files (for example 10-eth0-static.network) in /usr/lib/systemd/network. These files are read by systemd-networkd. This service is started by default in multi-user.target (http://www.phoronix.com/scan.php?page=news_itempx=MTYxMTI). Otherwise the service can be enabled with systemctl start systemd-networkd I took the example configuration from the LFS book: [Match] Name=eth0 [Network] Address=192.168.1.2/24 Gateway=192.168.1.1 This configuration assigns the ip address and the gateway to the interface eth0. It is also possible to use DHCP and other things (see http://www.freedesktop.org/software/systemd/man/systemd.network.html). I hope this helps a bit. I'm open to discuss further details. Kind regards. Sebastian -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] Use systemd to configure network interfaces
Am 15.04.2014 05:37, schrieb Bryan Kadzban: Why the duplication? If I create a file named 10-eth1.link and it has Name=eth0 in it, what interface name is created when the address matches? (Wouldn't it be better to have *one* source of truth for renames like this?) It would create the interface eth0. Yes, it is better to have one source. It was just an example to show that the first matching file applies. So the final setup depends on the file naming. Also, does it work to match NICs by device path instead of MAC address, e.g. because I'm in some random virtualization environment where that works, or because I'm a server that gets new NICs when they fail? (That works in the setup I've put together, where the NIC alias gets dereferenced by the ifup script, and so a NIC can have many aliases of arbitrary length. Still haven't gotten time to commit that to contrib/ though. :-/ ) Yes. Have a look at |Path=pci-:02:00.0-*:| |[Match] Driver=brcmsmac Path=pci-:02:00.0-* Type=wlan Virtualization=no Host=my-laptop Architecture=x86-64 [Link] Name=wireless0 MTUBytes=1450 BitsPerSecond=10M WakeOnLan=magic MACAddress=cb:a9:87:65:43:21| Also also, is there a way to make systemd *not* do the rename at all, and simply configure whatever device happens to show up that matches the Match section? This is how I have the ifup patch working above (nothing on the system cares if a NIC gets renamed from one boot to the next, because the config is attached to something more permanent, either the MAC or path), and it works really well to avoid the renaming. The file |/etc/udev/rules.d/80-net-setup-link.rules is responsible| for renaming. So it can be disabled with: |ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules See: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ | -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: [lfs-dev] systemd ifup get run before systemd rename interface sometimes.
Am 08.04.2014 16:40, schrieb xinglp: $ journalctl -b|grep enp Apr 08 22:37:25 vm1 ifup[123]: Adding IPv4 address 192.168.3.1 to the enp4s0 interface...Cannot find device enp4s0 Apr 08 22:37:26 vm1 systemd-udevd[173]: renamed network interface eth0 to enp4s0 So it won't startup network. Wouldn't it be the easiest way to let systemd configure the network interfaces? http://coreos.com/blog/intro-to-systemd-networkd/ http://www.freedesktop.org/software/systemd/man/systemd.link.html http://www.freedesktop.org/software/systemd/man/systemd.network.html -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Drop Coreutils Internationalization Fixes Patch
I just want to ask if it is still necessary to ship the Coreutils Internationalization Fixes Patch with the book. It was rejected by the upstream maintainers and is possibly the reason for problems (the book says this). Kind regards Sebastian -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Minimal Linux Bootloader
I wrote a tiny linux bootloader (without a stage 2) which is able to boot a single kernel image. Because of the size limit (446 byte) there is no support for a menu and there is no support to load an initial ramdisk. Now I need some help to find possibly hidden bugs. I would be glad if someone (who is interested in it) plays around with it. The source file is available at http://sebastian-plotz.blogspot.de. Any comments and hints are desired. I'm not sure if this bootloader is also useful for the book because GRUB is much more powerful and well tested. Thank you. Sebastian Plotz -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
[lfs-dev] Check-Package
I just saw that the Check-Package is missing on the Rationale for Packages in the Book-page. Best Regards Sebastian -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Glibc GCC Build Fix Patch
Just a question: Is the Glibc GCC Build Fix Patch still required for GCC 4.6.0? I have to say that I didn't test anything. Thank you! Regards Sebastian -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
6.8-rc1: minor fixups
I found two minor things ... 1. The upgrades to newer versions of IPRoute2 and Readline are not mentioned on the What's new page. 2. The description of grub-mkrescue in 6.44. GRUB-1.98 should may be updated to Make a bootable image of GRUB suitable for a floppy disk or a CD. Regards Sebastian -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Kernel and glibc headers
Hello, this doesn't directly belongs to LFS but maybe somebody can answer my question. Is there a difference between using the header files from the kernel (for example /usr/include/linux/inotify.h) or the header files from glibc (/usr/include/sys/inotify.h)? Sebastian -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Kernel and glibc headers
Ok, thank you! Best regards Am Dienstag, den 11.01.2011, 14:35 -0600 schrieb Bruce Dubbs: Yes. The kernel headers include definitions for the kernel only. Don't use the kernel headers for applications or utilities. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Ticket 2722 (Mistake on the linux console page)
Am 18.08.2010 07:22, schrieb Sebastian Plotz: Am 18.08.2010 00:34, schrieb Bruce Dubbs: Sebastian Plotz wrote: Am Dienstag, den 17.08.2010, 15:55 -0500 schrieb Bruce Dubbs: Hmm. What charset am I using? I guess that's the basic charset of ANSI C (see http://openbook.galileocomputing.de/c_von_a_bis_z/003_c_grundlagen_001.htm#mj6cc85534f12d7e0868b75171de8d087e). The prototype of printf: int printf(const char * restrict format, ... ); And it uses a char pointer (not a wchar_t pointer). If you want to print a wchar_t, you have to do the following: wchar_t ch = L'Z'; print(%lc, ch); That's my point. A standard C program doesn't normally use utf-8. The programmer has to go out of his way to use it. The whole issue of the console configuration has to do with running applications on the console, not X or ssh based. How much do people do that any more? I'd say very few. That's not to say that we shouldn't try to get the information about consoles right. We should. However the consequences of getting it wrong are probably not significant. -- Bruce I'm note sure, but I think that the LANG variable influences the encoding of the output. So we should enable unicode mode if we're using de_DE.UTF-8 and for de...@euro we should leave the unicode mode disabled (and -m 8859-15 needs to be specified). I think Ubuntu uses the unicode mode and sets the LANG variable to de_DE.UTF-8 (in a german installation). But I'm not shure, if this is true (it needs to be verified). Simple programs like your example will still work in unicode mode (because UTF-8 is ASCII compatible). Seems to be true ... See http://www.cl.cam.ac.uk/~mgk25/unicode.html#c -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Ticket 2722 (Mistake on the linux console page)
Am Dienstag, den 17.08.2010, 11:53 -0600 schrieb Matthew Burgess: Hi all, The only remaining ticket for LFS-6.7 is 2722, although I'm not sure quite what needs to be done to resolve it. That ticket points to the kernel's unicode.txt document to show that the linux console is always uses unicode, but also quotes setfont(8): If the console is in utf8 mode (see unicode_start(1)) Why the If there? Has setfont(8) just not been updated since the kernel changed, or is it because kbd is not Linux specific? Or have I just misunderstood the docs? If the console is always in unicode, why do our bootscripts call `kbd_mode -u` to set the console mode? I think I understand the proposed changes to the examples, but I'd prefer it if someone could prepare a patch in case I screw them up (given my last few commits, that's entirely possible!). And if that patch also contains the changes to the descriptive text too, that may make it easier for me to understand what's going on. Thanks, Matt. Here is my understanding of that: If we're NOT in unicode mode (this is the default) the kernel assumes that the applications are using legacy charsets (for example 8859-15) for their output. But now, there's a problem: This output needs to be converted into unicode values (because most fonts are using unicode for the mapping). This translation table can be set with the -m option of setfont. After this translation, the correct character can be displayed on the screen. If the application expects input from the keyboard, it will always receive the lower 8 bits from the keymap. I know, that's a bit confusing (because the application actually won't receive 8859-15 values, if the keymap is loaded with unicode). If we're in unicode mode, the kernel assumes that the applications are producing UTF8 encoded output. So there's no need to translate something. The keymap is normally loaded with unicode values by kdb (see http://gunnarwrobel.de/wiki/Linux-and-the-keyboard.html). That's why I said the linux console always uses unicode. I think it can be loaded with legacy charsets (but only legacy keymaps without a chaset definition will do that). I hope that I understood all these things in the right way. I would suggest the following for the book (I'm sure that it can be written in a better way): If programs without UTF-8 support should be used, the kernel needs a table to translate the output of the program into unicode. This translation table can be set with -m parameter. It should be set to the same charset, that is used by the application. If all applications are supporting UTF-8, the console can be set into unicode mode (UNICODE=1). In this case, there is no need to specifiy a translation table. I don't know a meaningful example for LEGACY_CHARSET, because all keymaps I've seen are using unicode or the are defining the correct charset. Same for KEYMAP_CORRECTIONS. I don't know a meaningful example. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Ticket 2722 (Mistake on the linux console page)
Am Dienstag, den 17.08.2010, 21:10 +0200 schrieb Sebastian Plotz: I think it can be loaded with legacy charsets (but only legacy keymaps without a chaset definition will do that). I thing that's wrong. If I didn't misunderstood the man pages of keymaps and dumpkeys, kbd will always load the keymap with unicode values. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Ticket 2722 (Mistake on the linux console page)
Am Dienstag, den 17.08.2010, 13:37 -0600 schrieb Matthew Burgess: In order to provide the best guidance to our audience, how would a reader determine if a program supports UTF-8 or not? One possibility could be watching the source: If wchar_t (instead of char) is used, it is likely that the application supports UTF-8. But I think that this isn't a good solution for the book. I guess all packages in the book are supporting UTF-8 now. So can we assume that the user will never use programs with legacy charsets? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Ticket 2722 (Mistake on the linux console page)
Am Dienstag, den 17.08.2010, 15:55 -0500 schrieb Bruce Dubbs: Hmm. What charset am I using? I guess that's the basic charset of ANSI C (see http://openbook.galileocomputing.de/c_von_a_bis_z/003_c_grundlagen_001.htm#mj6cc85534f12d7e0868b75171de8d087e). The prototype of printf: int printf(const char * restrict format, ... ); And it uses a char pointer (not a wchar_t pointer). If you want to print a wchar_t, you have to do the following: wchar_t ch = L'Z'; print(%lc, ch); -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
glibc-2.12.1-gcc_fix-1.patch doesn't exist
http://www.linuxfromscratch.org/patches/lfs/development/glibc-2.12.1-gcc_fix-1.patch is broken. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
GRUB 2 requires gettext
make install will fail (some .mo files couldn't be found), if you are compiling GRUB 2 without an installed gettext. And that's what I tried to do ;-) You've possibly overlooked this, Bruce. See http://wiki.linuxfromscratch.org/lfs/attachment/ticket/2716/patch-dependencies_NEW.patch ... -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Broken link on GRUB page
Am 18.07.2010 21:44, schrieb Bruce Dubbs: Sebastian Plotz wrote: I know that this doesn't directly belongs to LFS ... But I just want to note that the Linux From Scratch GRUB2 Build Instructions link on the GRUB documentation page (http://www.gnu.org/software/grub/grub-documentation.en.html) is broken ... And Bruce maintains this site ... Works for me. ;) -- Bruce Hmm ... curious ;-) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: GRUB 2 requires gettext
Am Montag, den 19.07.2010, 10:39 -0500 schrieb Bruce Dubbs: Sebastian Plotz wrote: make install will fail (some .mo files couldn't be found), if you are compiling GRUB 2 without an installed gettext. And that's what I tried to do ;-) You've possibly overlooked this, Bruce. See http://wiki.linuxfromscratch.org/lfs/attachment/ticket/2716/patch-dependencies_NEW.patch ... If you look at the ticket, you'll see that I fixed it yesterday. We install gettext 2 packages before grub. What's you issue? -- Bruce Gettext is not listed as a dependency of GRUB on the dependencies page ... I've included gettext in my patch to fix that ... -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Broken link on GRUB page
I know that this doesn't directly belongs to LFS ... But I just want to note that the Linux From Scratch GRUB2 Build Instructions link on the GRUB documentation page (http://www.gnu.org/software/grub/grub-documentation.en.html) is broken ... And Bruce maintains this site ... -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
Am Freitag, den 02.07.2010, 13:38 +0200 schrieb splotz90: Am 01.07.2010 22:29, schrieb Andrew Benton: Which partition will grub choose? I have found some additional information about that: http://www.linuxquestions.org/questions/linux-software-2/how-does-grub2-find-the-grub-cfg-file-794560/ The grub-setup command seems to add an information where to find the grub.cfg right after the MBR. Sebastian I did some testing in a virtual machine (if someone is interested in it): Here are my partitions: /dev/sda1 -- Ubuntu 10.04 (with /boot on it) /dev/sda2 -- swap /dev/sda3 -- empty ext4 partition First I've mounted /dev/sda3 over /boot and installed the GRUB files on it: mount /dev/sda3 /boot grub-install --grub-setup=/bin/true /dev/sda After that I've mounted /dev/sda3 under /media and copied the existing grub.cfg: umount /dev/sda3 mount /dev/sda3 /media/sda3 cp /boot/grub/grub.cfg /media/sda3/grub I removed the Memtest menu entry's from the grub.cfg on /dev/sda3 (now, there is a difference between both files). Finally: grub-setup -r \(hd0,3\) /dev/sda But after a reboot: error: file not found grub rescue So I reinstalled GRUB with help of the Ubuntu CD. After rebooting my system I tried this: mount /dev/sda3 /boot grub-setup -r \(hd0,3\) /dev/sda And I got grub.cfg from /dev/sda3! :-) So I think that grub-setup writes the following information to a place right after the MBR: - on which partition grub.cfg can be found - in which folder grub.cfg can be found (/grub or /boot/grub) If I want my old grub.cfg from /dev/sda1, I just need to reinstall GRUB with: grub-setup -r \(hd0,1\) /dev/sda -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Sysklogd -- syslog-ng?
Are there any arguments against using rsyslog in LFS? You may say Sysklogd does it's job. So why changing something? ... But then we could say GRUB Legacy does it's job. So why upgrading to GRUB 2?, too. In my opinion, LFS should be a modern and up-to-date distribution. But the code of Sysklogd is not maintained anymore. If we're deciding to use rsyslog, this may help a bit: http://cross-lfs.org/view/svn/x86/final-system/rsyslog.html ... Another good solution might be dropping out Sysklogd and using syslogd from the Inetutils package instead. This implemenation can process kernel messages, too. And we just need to keep one daemon running. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Sysvinit -- Upstart?
Am 06.07.2010 23:28, schrieb Andrew Benton: On 06/07/10 18:50, Sebastian Plotz wrote: I just want to start a discussion, if it would be meaningful to replace Sysvinit with Upstart ... Reading through the README in the upstart source, it depends on libnih, nih-dbus-tool and D-BUS so it would mean adding 3 extra packages into LFS. Andy Yes, this is an good argument against using Upstart in LFS. Here are the requirements of systemd: Linux kernel = 2.6.30 (with autofs4, devtmpfs, cgroups) libudev = 151 libcgroup = 0.35 vala = 0.80 gtk+ = 2.20 dbus = 1.2.24 So I think BLFS would be a better place for it. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Sysvinit -- Upstart?
Am 07.07.2010 01:03, schrieb Ken Moffat: Well, if you have a watch with a second hand or a seconds display, you can try building two systems (for *your* definition of how much or how little is contained within a system, in particular what services are started). Then, try booting each of them several times and take an average. Yes, I know that only resolves to about 1 second, and a stop-watch would be better, but I think it will give enough information for an early stage review. I think that I'm going to test things like that next time. You also get to find out if there are oddities about how the new dependencies are built (e.g. do they have to pull in a shed load of other packages that we don't build). http://linuxfromscratch.org/pipermail/lfs-dev/2010-July/064012.html You are the person suggesting a change. I'm trying to persuade you to do the leg work and produce figures to explain why it is beneficial. Generally, saying almost everyone else does it now is not an adequate reason to persuade LFS to change. Ok, I'll try to explain the most important things about Upstart ... 1. Every task is a job (one separate file per job): An example job (jobname is sethostname; jobname is set by the filename): start on startup exec hostname -b -F /etc/hostname 2. The jobs will be executed when an event occurs. In my example it is the event startup (which is always the first event; produced by Upstart itself). The next job that depends on my job can use start on stopped hostname in the first line. 3. Jobs that doesn't depend on each other can be executed simultaneous (and this will save boot time). 4. Jobs will only be executed if they are really needed: If there's no network connection, NTP will never be started (for example). 5. What if, when starting a daemon or executing a program fails? This can be checked with something like stopped hostname ok or stopped hostname failed. See http://upstart.ubuntu.com/wiki/JobFailedEvent for more information. You talk about replacing the current bootscripts with event based jobs. I have no idea what this means. At the moment, if I add in a new package to my own builds which needs something started in certain runlevels, I take the template and edit it. If we were using these event based jobs, what would I have to know when starting a new service ? This may all be as clear as day to you, but to some of us here you might as well be speaking in gibberish because we don't understand the practical changes. You'll have to create a new job (if it is not already included in the package itself). An example: start on network_up /usr/local/apache/bin/httpd -f /usr/local/apache/conf/httpd.conf And this is much shorter than the init script of apache. Maintenance of the main part of the LFS bootscripts doesn't seem to be required very often, in fact looking at the current and previous releases (ignoring contrib/) it's only udev that needed changes. But, since I've no idea how these event based jobs would look, it's hard for me to say that you are either right or wrong. Further - at the moment I can, if I wish, start in a particular run level, but you say that run levels will disappear. There is only one dyed in the wool run level that particularly matters (I assume you can still reboot and shut down in the normal ways) - run level 1 or single user mode. Do your alternative method(s) continue to support that ? That depends on the job definitions. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Sysvinit -- Upstart?
Here's the last mail again (this mail is more readable). Am 07.07.2010 01:03, schrieb Ken Moffat: Well, if you have a watch with a second hand or a seconds display, you can try building two systems (for *your* definition of how much or how little is contained within a system, in particular what services are started). Then, try booting each of them several times and take an average. Yes, I know that only resolves to about 1 second, and a stop-watch would be better, but I think it will give enough information for an early stage review. I think that I'm going to test things like that next time. You also get to find out if there are oddities about how the new dependencies are built (e.g. do they have to pull in a shed load of other packages that we don't build). http://linuxfromscratch.org/pipermail/lfs-dev/2010-July/064012.html You are the person suggesting a change. I'm trying to persuade you to do the leg work and produce figures to explain why it is beneficial. Generally, saying almost everyone else does it now is not an adequate reason to persuade LFS to change. Ok, I'll try to explain the most important things about Upstart ... 1. Every task is a job (one separate file per job): An example job (jobname is sethostname; jobname is set by the filename): start on startup exec hostname -b -F /etc/hostname 2. The jobs will be executed when an event occurs. In my example it is the event startup (which is always the first event; produced by Upstart itself). The next job that depends on my job can use start on stopped hostname in the first line. 3. Jobs that doesn't depend on each other can be executed simultaneous (and this will save boot time). 4. Jobs will only be executed if they are really needed: If there's no network connection, NTP will never be started (for example). 5. What if, when starting a daemon or executing a program fails? This can be checked with something like stopped hostname ok or stopped hostname failed. See http://upstart.ubuntu.com/wiki/JobFailedEvent for more information. You talk about replacing the current bootscripts with event based jobs. I have no idea what this means. At the moment, if I add in a new package to my own builds which needs something started in certain runlevels, I take the template and edit it. If we were using these event based jobs, what would I have to know when starting a new service ? This may all be as clear as day to you, but to some of us here you might as well be speaking in gibberish because we don't understand the practical changes. You'll have to create a new job (if it is not already included in the package itself). An example: start on network_up /usr/local/apache/bin/httpd -f /usr/local/apache/conf/httpd.conf And this is much shorter than the init script of apache. Further - at the moment I can, if I wish, start in a particular run level, but you say that run levels will disappear. There is only one dyed in the wool run level that particularly matters (I assume you can still reboot and shut down in the normal ways) - run level 1 or single user mode. Do your alternative method(s) continue to support that ? That depends on the job definitions. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Sysvinit -- Upstart?
Am 07.07.2010 11:24, schrieb Sebastian Plotz: The next job that depends on my job can use start on stopped hostname in the first line. start on stopped hostname --- start on stopped sethostname -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Sysvinit -- Upstart?
I just want to start a discussion, if it would be meaningful to replace Sysvinit with Upstart ... Here are some points for discussion: 1. The bootscripts can still be used (like Ubuntu did). 2. The LFS user will learn something about old techniques (runlevels) and new techniques (event based booting) at the same time. 3. Upstart is more modern than Sysvinit (and it is under active development). 4. Some distributions already use upstart (Ubuntu, Fedora) or will use it in future (openSUSE, Debian). What are you thinking about that? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Sysklogd -- syslog-ng?
What about changing from Sysklogd to syslog-ng? - syslog-ng is under active development - sysklogd is quiet old (last version released in 2007) - we just need to run one daemon (instead of syslogd and klogd) -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Sysvinit -- Upstart?
Am Dienstag, den 06.07.2010, 14:09 -0400 schrieb Robert Xu: But that requires SysVinit tools. Did you mean halt, init, runlevel, shutdown, telinit, ...? They are all included in Upstart, too. Upstart is compatible with Sysvinit. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Sysvinit -- Upstart?
Am Dienstag, den 06.07.2010, 13:38 -0500 schrieb Stuart Stegall: On Tue, Jul 6, 2010 at 12:50 PM, Sebastian Plotz sebastian-pl...@web.de wrote: I just want to start a discussion, if it would be meaningful to replace Sysvinit with Upstart ... Here are some points for discussion: 1. The bootscripts can still be used (like Ubuntu did). 2. The LFS user will learn something about old techniques (runlevels) and new techniques (event based booting) at the same time. 3. Upstart is more modern than Sysvinit (and it is under active development). 4. Some distributions already use upstart (Ubuntu, Fedora) or will use it in future (openSUSE, Debian). What are you thinking about that? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page Fedora is dropping upstart for systemd. openSUSE is waiting on FC14 and how well systemd works before proceeding with upstart/systemd. There's also a ITP for systemd in Debian, and who knows where that might go. Systemd seamlessly supports SysVinit scripts and new event based scripts. Fedora Commentary: https://fedoraproject.org/wiki/Features/systemd Systemd Homepage: http://www.freedesktop.org/wiki/Software/systemd Yes, I think it would be meaningful, if we would do the same as the openSUSE community (waiting until systemd becomes stable and usable). -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Sysvinit -- Upstart?
Am Dienstag, den 06.07.2010, 20:39 +0100 schrieb Ken Moffat: On 6 July 2010 18:50, Sebastian Plotz sebastian-pl...@web.de wrote: I just want to start a discussion, if it would be meaningful to replace Sysvinit with Upstart ... Here are some points for discussion: 1. The bootscripts can still be used (like Ubuntu did). 2. The LFS user will learn something about old techniques (runlevels) and new techniques (event based booting) at the same time. 3. Upstart is more modern than Sysvinit (and it is under active development). 4. Some distributions already use upstart (Ubuntu, Fedora) or will use it in future (openSUSE, Debian). What are you thinking about that? Changing things *for the sake of changing them* when we don't have to just causes work. I don't see any concrete advantages listed (either for upstart, or for the alternatives listed by others). From memory, I think the reason ubuntu moved from sysvinit was to speed up their boot process. Last time I used ubuntu (admittedly a long time ago), my impression was that their boot process was excessively complex, and in some ways I would actually describe it as wrong (like debian, run a graphical login on all runlevels for desktops). I also recall that they switched to dash, which I regard as an *inadequate* shell, to improve their boot times. Do I think the LFS/BLFS desktop boot could be quicker ? Of course. In my case, I get a delay of several seconds while ntp starts up. But so far, I've managed to live with that and I know that it *doesn't* need a completely revised method of booting to address it. I might be misjudging you, but so far your post comes across as ooh, upstart is newer and shinier. ISTR those were the motivations behind kde4 - and for those of us who build from source on bare metal, that turned into a disaster (total bloat). I suggest that you identify *what* you think can be done better during the boot process, then go off and try different method(s) - if any of them provides a significant benefit, come back and explain why you think the change is worthwhile - if the aim is to speed up the boot, timings will be useful. In my case, the slowest part of booting my desktop machines is waiting for the bios to present me with the grub boot screen, then the ntp delay I mentioned. From memory, I think that saving 5 seconds in the whole process is actually neither here nor there, but people have different views. ĸen -- After tragedy, and farce, OMG poneys! Yes of course, saving boot time is an important point of Upstart. But I think that the system actually won't boot faster if we're using the old bootscripts (I don't know any timings). My idea was, that we're using the scripts for an unspecified time. After that, they may be replaced with event based jobs. Another point is, that the event based jobs are shorter than the scripts. So I think that they are easier to maintain. -- please correct me, if I'm wrong -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
Am Donnerstag, den 01.07.2010, 15:05 +0100 schrieb Andrew Benton: Why would we say that? You've not shown any meaningful use for the search lines on an LFS system. Andy I did ... 1. The search command is only useful if we're using a separate /boot partition. 2. With help of the search line, GRUB can find the /boot partition (NOT / partition), even if the device of the /boot partition has changed (for example /dev/sda3 -- /dev/sda2). Or in other words: With help of the search line, GRUB can find the kernel (and initrd, if used), even if the device of the /boot partition has changed (for example /dev/sda3 -- /dev/sda2). 3. This means: If the LFS-User changes the device of the /boot partition (NOT / partition), the system will still boot (with help of the search line). -- and this IS meaningful, I think ... 4. If the device of the root partition has changed the boot process will fail (the kernel won't be able to mount the root partition). -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
Am Donnerstag, den 01.07.2010, 15:03 +0100 schrieb Andrew Benton: I think your first problem would be that if you move your /boot partition grub will not be able to find any of it's files and you will need to find a CD/USB stick to boot from to fix your now broken system. The fact that the bootscripts fail to mount the /boot partition is a small problem in comparison. Andy In this early stage, GRUB is able to read a file system. The fs driver is placed direct after the MBR. GRUB has to probe every partition to find a grub.cfg ... So I think moving the /boot partition is not a problem. Please correct me, if I'm wrong ... -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
Am Donnerstag, den 01.07.2010, 18:52 +0200 schrieb Sebastian Plotz: If the LFS-User changes the device of the /boot partition (NOT / partition), the system will still boot (with help of the search line). I should better say: If the LFS-User has moved the /boot partition (NOT / partition), the system will still boot (with help of the search line). -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
Am Mittwoch, den 30.06.2010, 13:44 +0100 schrieb Andrew Benton: But it won't boot very far. The kernel won't be able to mount its root partition unless you manually edit the grub.cfg or compile the kernel with an initramfs Andy Yes, and it will work if you're using a separate boot partition ... This means: GRUB can find the kernel (and the initrd, if used) when the device of the boot partition has changed. After that, the kernel can mount the root partition (the device of the root partition must not be changed). But it's important that a UUID will be used for the boot partition in /etc/fstab. So we can say in the book: The search lines are only meaningful if your are using a separate boot partition and a UUID entry for this partition in /etc/fstab. ... or we simply remove this sentence from the book. Sebastian -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
Am Mittwoch, den 30.06.2010, 19:41 +0200 schrieb Sebastian Plotz: Am Mittwoch, den 30.06.2010, 13:44 +0100 schrieb Andrew Benton: But it won't boot very far. The kernel won't be able to mount its root partition unless you manually edit the grub.cfg or compile the kernel with an initramfs Andy Yes, and it will work if you're using a separate boot partition ... This means: GRUB can find the kernel (and the initrd, if used) when the device of the boot partition has changed. After that, the kernel can mount the root partition (the device of the root partition must not be changed). But it's important that a UUID will be used for the boot partition in /etc/fstab. So we can say in the book: The search lines are only meaningful if your are using a separate boot partition and a UUID entry for this partition in /etc/fstab. ... or we simply remove this sentence from the book. Sebastian Small update: The search lines are only meaningful for LFS systems if a separate boot partition and a LABEL or UUID entry for this partition in /etc/fstab is used. Sebastian -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Explanation about grub's search command in chapter 8.4 of lfs book is wrong
Am Mittwoch, den 30.06.2010, 15:20 -0400 schrieb linux fan:
It booted me and mounted /dev/sdd10
With this in grub.cfg
=
menuentry GNU/Linux, with Linux 2.6.33 (search only) {
insmod ext2
search --no-floppy --fs-uuid --set
11b62acd-ee91-43f7-a619-c4b5cb5fa5e7
linux /boot/vmlinux-2.6.33
}
With this in fstab
==
# Begin /etc/fstab
# file system mount-point type options dump fsck
#order
#/dev/sdd10 /ext3 defaults1 1
UUID=11b62acd-ee91-43f7-a619-c4b5cb5fa5e7 /ext3
defaults1 1
/dev/sdd8 swap swap pri=1 0 0
proc /procproc defaults0 0
sysfs /sys sysfs defaults0 0
devpts /dev/pts devpts gid=4,mode=620 0 0
tmpfs /dev/shm tmpfs defaults0 0
# End /etc/fstab
/boot is on the root partition
If the root parameter (in the linux command) is omitted, then the kernel
will use the partition it was compiled on.
So if you have compiled the kernel on /dev/sda1, the kernel will try to
mount /dev/sda1 as root partition (only if the root-parameter is
omitted).
I think this will work in some cases (but you can't rely on it): Some
LFS-Users may compile the kernel on /dev/sda2 and want to use /dev/sda1
as their root partition.
Please correct me, if I'm wrong ...
Sebastian
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
