Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?
On 2011-11-15 07:21, waltd...@waltdnes.org wrote: The purpose of this email is to ask adventurous people here to beta test my approach to a udev-less Gentoo. If we don't find any showstopper problems, we can think about requesting Gentoo developers to support an mdev-based profile. It would help the cause if a large number of testers can report that it works for them. The instructions for a udev-ectomy follow below. Thanks to Zac Medico and others on the Gentoo developers' list for their helpful hints and pointers on how to do this. I couldn't have figured this out by myself. I apologize for not having replied sooner. This sounds very interesting and I will try this out, when I can find the time to tinker. Thanks for doing this! Best regards Peter K
Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?
On Wed, Nov 16, 2011 at 07:52, Pandu Poluan pa...@poluan.info wrote: On Nov 16, 2011 3:21 AM, waltd...@waltdnes.org wrote: The more scenarios we can test, the better. mdev might shave a second or two off the VM's bootup time, versus udev. Okay, I have two staging VMs on XenServer and one on VMware. I'm going to report back what happens. If anything bad happens, *should* be an easy rollback to the previous snapshot. 1st Report: amd64-hardened on XenServer, PV-mode Booted okay. There's 1 (one) red asterisk but it booted so fast I can't see what that asterisk was about. `less /var/log/rc.log` did not show anything... ... but I realized that I can scroll up on XenServer console, so I saw that the asterisk said: * Error: fopen(/lib64/rc/init.d/rc.log) failed: No such file or directory Nothing serious though. I think it was because /lib64/rc/init.d got overlaid by rc-svcdir during boot, so rc.log disappeared. (Doing `mount -o bind / /mnt/rooot ls /mnt/rooot/lib64/rc/init.d` showed that rc.log existed in the non-overlaid /lib64/rc/init.d) /dev/xvdb* (which was not created statically in the non-overlaid /dev) appeared. /dev/xvdd appeared when I attached an ISO image to the VM. mount /dev/xvdd /mnt/cd worked. I could `ls /mnt/cd` and see the contents of the CD. Ejecting the ISO image made /dev/xvdd disappear (as it should). Networking is okay. The Xen virtual console (hvc0) works okay. `rc-update | grep dev` showed `udev-postmount` still part of default, so I did `rc-update del udev-postmount default` and rebooted, and all were still well (and still a glint of red asterisk). Unmerging udev went well. All in all, rebooting after switching to udev *seems* to be faster. Rgds, -- FdS Pandu E Poluan ~ IT Optimizer ~ • LOPSA Member #15248 • Blog : http://pepoluan.tumblr.com • Linked-In : http://id.linkedin.com/in/pepoluan
Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?
On Wed, Nov 16, 2011 at 07:52, Pandu Poluan pa...@poluan.info wrote: On Nov 16, 2011 3:21 AM, waltd...@waltdnes.org wrote: The more scenarios we can test, the better. mdev might shave a second or two off the VM's bootup time, versus udev. Okay, I have two staging VMs on XenServer and one on VMware. I'm going to report back what happens. If anything bad happens, *should* be an easy rollback to the previous snapshot. 2nd Report: amd64-hardened on VMware, using VMware PVSCSI for hard disk, but e1000 for network. Booted okay, and similar to the report on XenServer. But this time. I got 2 (two) red asterisks during boot. The 1st one seems to say Error ... read-only file system. The second starts with Warning temp file left behind ... (or something similar) `rc-update del udev-postmount default reboot` ... no problem. Unmerged udev reboot ... no problem. There. No problem with XenServer and/or VMware. Except for the 1 or 2 red asterisks during boot (which I'm not sure caused by udev--mdev switch or something else). I'll experiment with VirtualBox (on Windows) tomorrow. This might be much more interesting :-) Rgds, -- FdS Pandu E Poluan ~ IT Optimizer ~ • LOPSA Member #15248 • Blog : http://pepoluan.tumblr.com • Linked-In : http://id.linkedin.com/in/pepoluan
Re: CRTs and EDID (was: Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?
On Tue, Nov 15, 2011 at 09:53:47AM -0500, Michael Mol wrote Just an FYI, EDID blocks have been part of CRT tech since the mid to late 90s; it's the basis of plug play monitors. IIRC, the EDID block is transported via DDC, which is essentially I2C implemented on top of your VGA cable. I've got three EDID-supporting, 19 1600x1200 CRTs staring me in the face right now. https://plus.google.com/108080062547354628132/posts/ZLLw66eL4We Maybe X has learned how to read them without udev's help. The xorg logfile shows the EDID block, max/min horizontal/vertical scan rates, supported modes, etc. -- Walter Dnes waltd...@waltdnes.org
Re: CRTs and EDID (was: Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?
On 11/16/2011 06:20 PM, waltd...@waltdnes.org wrote: On Tue, Nov 15, 2011 at 09:53:47AM -0500, Michael Mol wrote Just an FYI, EDID blocks have been part of CRT tech since the mid to late 90s; it's the basis of plug play monitors. IIRC, the EDID block is transported via DDC, which is essentially I2C implemented on top of your VGA cable. I've got three EDID-supporting, 19 1600x1200 CRTs staring me in the face right now. https://plus.google.com/108080062547354628132/posts/ZLLw66eL4We Maybe X has learned how to read them without udev's help. The xorg logfile shows the EDID block, max/min horizontal/vertical scan rates, supported modes, etc. Xorg's been around since 2004, and udev since 2003, so it's possible that it's depended on udev for displays. It seems unlikely, though; I remember XFree86 4.x having EDID support, just prior to people migrating over to Xorg. It was a royal pain, actually; my Thinkpad 760XL's LVDA (I think it was LVDA. It wasn't a common laptop video connection yet) display didn't support EDID, and I never did manage to get any version of XFree86 newer than 3.3.6 working on it. Point is, Xorg autoconfiguration has worked find for *most* setups for almost a decade. At the very least, it's worked fine since the first graphical Knoppix and Ubuntu live CDs.
CRTs and EDID (was: Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?
On Tue, Nov 15, 2011 at 1:21 AM, waltd...@waltdnes.org wrote: Contrary to the FUD I've heard, X works just fine, thank you, without an xorg.conf. Modern flatscreens with EDID info are set up automatically. I suppose that old CRT monitors without EDID info might require xorg.conf, but that's exotic hardware nowadays. Just an FYI, EDID blocks have been part of CRT tech since the mid to late 90s; it's the basis of plug play monitors. IIRC, the EDID block is transported via DDC, which is essentially I2C implemented on top of your VGA cable. I've got three EDID-supporting, 19 1600x1200 CRTs staring me in the face right now. https://plus.google.com/108080062547354628132/posts/ZLLw66eL4We -- :wq
Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?
On Tue, 15 Nov 2011 14:44:58 +0700 Pandu Poluan pa...@poluan.info wrote: Create the file if it doesn't already exist. You now have a totally udev-free machine Sounds nice! However, my Gentoo systems are all virtual servers (DomU VMs on XenServer). So, the hardware devices are static. Will switching over to mdev give any benefits? I even am toying around with the idea of having a completely static /dev, but still can't find any guide/pointers yet. (Apologies if my email is OOT) A VM can be surprisingly useful for this. If you can emulate different hardware you can generate useful testing scenarios quickly. The tests won't be conclusive (emulated hardware is not the same thing as real hardware) but you *can* test to a standard. -- Alan McKinnnon alan.mckin...@gmail.com
Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?
On Tue, 2011-11-15 at 14:44 +0700, Pandu Poluan wrote: However, my Gentoo systems are all virtual servers (DomU VMs on XenServer). So, the hardware devices are static. Will switching over to mdev give any benefits? I even am toying around with the idea of having a completely static /dev, but still can't find any guide/pointers yet. I have a completely static /dev/ on my VMs.. I just disable the udev devfs services and create whatever device nodes needed manually.
Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?
On Nov 15, 2011 11:19 PM, Alan McKinnon alan.mckin...@gmail.com wrote: On Tue, 15 Nov 2011 14:44:58 +0700 Pandu Poluan pa...@poluan.info wrote: Create the file if it doesn't already exist. You now have a totally udev-free machine Sounds nice! However, my Gentoo systems are all virtual servers (DomU VMs on XenServer). So, the hardware devices are static. Will switching over to mdev give any benefits? I even am toying around with the idea of having a completely static /dev, but still can't find any guide/pointers yet. (Apologies if my email is OOT) A VM can be surprisingly useful for this. If you can emulate different hardware you can generate useful testing scenarios quickly. The tests won't be conclusive (emulated hardware is not the same thing as real hardware) but you *can* test to a standard. True. Unfortunately, I don't have 'exotic' hardware to test mdev against, and USB pass-through is not yet supported on XenServer 5.6 (which I'm using right now). I can try it inside VirtualBox on my Windows workstation though. Will that help? Rgds,
Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?
On Nov 15, 2011 11:43 PM, Albert W. Hopkins mar...@letterboxes.org wrote: On Tue, 2011-11-15 at 14:44 +0700, Pandu Poluan wrote: However, my Gentoo systems are all virtual servers (DomU VMs on XenServer). So, the hardware devices are static. Will switching over to mdev give any benefits? I even am toying around with the idea of having a completely static /dev, but still can't find any guide/pointers yet. I have a completely static /dev/ on my VMs.. I just disable the udev devfs services and create whatever device nodes needed manually. Ah, thanks! Now I have more confidence to experiment, knowing someone else have successfully went the static /dev road :-) Rgds,
Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?
On Tue, Nov 15, 2011 at 02:44:58PM +0700, Pandu Poluan wrote However, my Gentoo systems are all virtual servers (DomU VMs on XenServer). So, the hardware devices are static. Will switching over to mdev give any benefits? I even am toying around with the idea of having a completely static /dev, but still can't find any guide/pointers yet. (Apologies if my email is OOT) The more scenarios we can test, the better. mdev might shave a second or two off the VM's bootup time, versus udev. -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?
On Nov 16, 2011 3:21 AM, waltd...@waltdnes.org wrote: On Tue, Nov 15, 2011 at 02:44:58PM +0700, Pandu Poluan wrote However, my Gentoo systems are all virtual servers (DomU VMs on XenServer). So, the hardware devices are static. Will switching over to mdev give any benefits? I even am toying around with the idea of having a completely static /dev, but still can't find any guide/pointers yet. (Apologies if my email is OOT) The more scenarios we can test, the better. mdev might shave a second or two off the VM's bootup time, versus udev. Okay, I have two staging VMs on XenServer and one on VMware. I'm going to report back what happens. If anything bad happens, *should* be an easy rollback to the previous snapshot. Rgds,
Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?
Plus, I'm feeling adventurous and will experiment with VirtualBox also ;) Rgds, On Nov 16, 2011 7:52 AM, Pandu Poluan pa...@poluan.info wrote: On Nov 16, 2011 3:21 AM, waltd...@waltdnes.org wrote: On Tue, Nov 15, 2011 at 02:44:58PM +0700, Pandu Poluan wrote However, my Gentoo systems are all virtual servers (DomU VMs on XenServer). So, the hardware devices are static. Will switching over to mdev give any benefits? I even am toying around with the idea of having a completely static /dev, but still can't find any guide/pointers yet. (Apologies if my email is OOT) The more scenarios we can test, the better. mdev might shave a second or two off the VM's bootup time, versus udev. Okay, I have two staging VMs on XenServer and one on VMware. I'm going to report back what happens. If anything bad happens, *should* be an easy rollback to the previous snapshot. Rgds,
Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?
I'm using systemd as init. Currently there's no .service file for mdev. Hope someone on this list can provide one :-) On Wed, Nov 16, 2011 at 9:41 AM, Pandu Poluan pa...@poluan.info wrote: Plus, I'm feeling adventurous and will experiment with VirtualBox also ;) Rgds, On Nov 16, 2011 7:52 AM, Pandu Poluan pa...@poluan.info wrote: On Nov 16, 2011 3:21 AM, waltd...@waltdnes.org wrote: On Tue, Nov 15, 2011 at 02:44:58PM +0700, Pandu Poluan wrote However, my Gentoo systems are all virtual servers (DomU VMs on XenServer). So, the hardware devices are static. Will switching over to mdev give any benefits? I even am toying around with the idea of having a completely static /dev, but still can't find any guide/pointers yet. (Apologies if my email is OOT) The more scenarios we can test, the better. mdev might shave a second or two off the VM's bootup time, versus udev. Okay, I have two staging VMs on XenServer and one on VMware. I'm going to report back what happens. If anything bad happens, *should* be an easy rollback to the previous snapshot. Rgds,
[gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?
After a recent thread, about udev developers wanting /usr on the same partition as / (or else requiring initramfs), it was pretty obvious that 90%+ of the users here strongly disliked the idea. I went around asking on various lists if it was possible to run Gentoo without udev. After some research, and various unrelated delays, I've come up with a working Gentoo without udev. It turns out that busybox's mdev implementation is sufficient for my needs. I do the usual email, web surfing, including Youtube. I'm listening to Live365.com as I type this email, so Flash works just fine. Contrary to the FUD I've heard, X works just fine, thank you, without an xorg.conf. Modern flatscreens with EDID info are set up automatically. I suppose that old CRT monitors without EDID info might require xorg.conf, but that's exotic hardware nowadays. The only change I notice is somewhat faster bootup. The purpose of this email is to ask adventurous people here to beta test my approach to a udev-less Gentoo. If we don't find any showstopper problems, we can think about requesting Gentoo developers to support an mdev-based profile. It would help the cause if a large number of testers can report that it works for them. The instructions for a udev-ectomy follow below. Thanks to Zac Medico and others on the Gentoo developers' list for their helpful hints and pointers on how to do this. I couldn't have figured this out by myself. The usual warnings apply... * this is a beta * use a spare test machine * if you don't follow the instructions correctly, the result might be an unbootable linux * even if you do follow instructions, the result might be an unbootable linux 1) Set up your kernel to support and automount a devtmpfs filesystem at /dev * If you prefer to edit .config directly, set CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y * If you prefer make menuconfig, the route is as shown below. Note that the Autount devtmpfs... option won't appear until you enable Maintain a devtmpf... option. make menuconfig Device Drivers --- Generic Driver Options --- [*] Maintain a devtmpfs filesystem to mount at /dev [*] Automount devtmpfs at /dev, after the kernel mounted the rootfs Once you've made the changes, rebuild the kernel. 2) Set up for emerging busybox, there are 2 items to change A) It appears that there may be an mdev bug in older versions of busybox. To avoid that bug, keyword busybox-1.19.2 in /etc/portage/package.keywords E.g. if you're using 32-bit Gentoo on Intel, the incantation is... =sys-apps/busybox-1.19.2 ~x86 Change the ~x86 to reflect your architecture, etc. B) busybox requires the mdev flag in this situation. The static flag is probably also a good idea. In file /etc/portage/package.use add the line sys-apps/busybox static mdev Now, emerge busybox 3) In the bootloader append line, include init=/sbin/linuxrc where the file /sbin/linuxrc consists of *AT LEAST*... #!/sbin/busybox ash mount -t proc proc /proc mount -t sysfs sysfs /sys exec /sbin/init This should be enough for most users. If you have an unusual setup, you may need additional stuff in there. If you're using lilo remember to re-run lilo to implement the changes. 4) Remove udev from the services list, and replace it with mdev. Type the following 2 commands at the command line rc-update del udev sysinit rc-update add mdev sysinit 5) reboot to your new kernel. You're now running without using udev. 6) ***THIS STEP IS OPTIONAL*** This is only to alay any suspicion that udev is still in use. udev is pulled in by virtual/dev-manager, which in turn is pulled in by the kernel. * cd /usr/portage/virtual/dev-manager * Make a backup copy of dev-manager-0.ebuild * Edit dev-manager-0.ebuild to include sys-apps/busybox as one option in RDEPEND, like so... RDEPEND=|| ( sys-fs/udev sys-fs/devfsd sys-apps/busybox sys-fs/static-dev sys-freebsd/freebsd-sbin ) I had really wanted to use sys-apps/busybox[mdev], but an EAPI-0 ebuild can't handle that syntax. * execute the following 3 commands at the commandline ebuild dev-manager-0.ebuild digest emerge -1 dev-manager emerge --unmerge sys-fs/udev * In file /atc/portage/package.mask, append the line sys-fs/udev Create the file if it doesn't already exist. You now have a totally udev-free machine -- Walter Dnes waltd...@waltdnes.org
Re: [gentoo-user] Anybody want to beta test Gentoo with mdev instead of udev?
On Nov 15, 2011 1:24 PM, waltd...@waltdnes.org wrote: After a recent thread, about udev developers wanting /usr on the same partition as / (or else requiring initramfs), it was pretty obvious that 90%+ of the users here strongly disliked the idea. I went around asking on various lists if it was possible to run Gentoo without udev. After some research, and various unrelated delays, I've come up with a working Gentoo without udev. It turns out that busybox's mdev implementation is sufficient for my needs. I do the usual email, web surfing, including Youtube. I'm listening to Live365.com as I type this email, so Flash works just fine. Contrary to the FUD I've heard, X works just fine, thank you, without an xorg.conf. Modern flatscreens with EDID info are set up automatically. I suppose that old CRT monitors without EDID info might require xorg.conf, but that's exotic hardware nowadays. The only change I notice is somewhat faster bootup. The purpose of this email is to ask adventurous people here to beta test my approach to a udev-less Gentoo. If we don't find any showstopper problems, we can think about requesting Gentoo developers to support an mdev-based profile. It would help the cause if a large number of testers can report that it works for them. The instructions for a udev-ectomy follow below. Thanks to Zac Medico and others on the Gentoo developers' list for their helpful hints and pointers on how to do this. I couldn't have figured this out by myself. The usual warnings apply... * this is a beta * use a spare test machine * if you don't follow the instructions correctly, the result might be an unbootable linux * even if you do follow instructions, the result might be an unbootable linux 1) Set up your kernel to support and automount a devtmpfs filesystem at /dev * If you prefer to edit .config directly, set CONFIG_DEVTMPFS=y and CONFIG_DEVTMPFS_MOUNT=y * If you prefer make menuconfig, the route is as shown below. Note that the Autount devtmpfs... option won't appear until you enable Maintain a devtmpf... option. make menuconfig Device Drivers --- Generic Driver Options --- [*] Maintain a devtmpfs filesystem to mount at /dev [*] Automount devtmpfs at /dev, after the kernel mounted the rootfs Once you've made the changes, rebuild the kernel. 2) Set up for emerging busybox, there are 2 items to change A) It appears that there may be an mdev bug in older versions of busybox. To avoid that bug, keyword busybox-1.19.2 in /etc/portage/package.keywords E.g. if you're using 32-bit Gentoo on Intel, the incantation is... =sys-apps/busybox-1.19.2 ~x86 Change the ~x86 to reflect your architecture, etc. B) busybox requires the mdev flag in this situation. The static flag is probably also a good idea. In file /etc/portage/package.use add the line sys-apps/busybox static mdev Now, emerge busybox 3) In the bootloader append line, include init=/sbin/linuxrc where the file /sbin/linuxrc consists of *AT LEAST*... #!/sbin/busybox ash mount -t proc proc /proc mount -t sysfs sysfs /sys exec /sbin/init This should be enough for most users. If you have an unusual setup, you may need additional stuff in there. If you're using lilo remember to re-run lilo to implement the changes. 4) Remove udev from the services list, and replace it with mdev. Type the following 2 commands at the command line rc-update del udev sysinit rc-update add mdev sysinit 5) reboot to your new kernel. You're now running without using udev. 6) ***THIS STEP IS OPTIONAL*** This is only to alay any suspicion that udev is still in use. udev is pulled in by virtual/dev-manager, which in turn is pulled in by the kernel. * cd /usr/portage/virtual/dev-manager * Make a backup copy of dev-manager-0.ebuild * Edit dev-manager-0.ebuild to include sys-apps/busybox as one option in RDEPEND, like so... RDEPEND=|| ( sys-fs/udev sys-fs/devfsd sys-apps/busybox sys-fs/static-dev sys-freebsd/freebsd-sbin ) I had really wanted to use sys-apps/busybox[mdev], but an EAPI-0 ebuild can't handle that syntax. * execute the following 3 commands at the commandline ebuild dev-manager-0.ebuild digest emerge -1 dev-manager emerge --unmerge sys-fs/udev * In file /atc/portage/package.mask, append the line sys-fs/udev Create the file if it doesn't already exist. You now have a totally udev-free machine Sounds nice! However, my Gentoo systems are all virtual servers (DomU VMs on XenServer). So, the hardware devices are static. Will switching over to mdev give any benefits? I even am toying around with the idea of having a completely static /dev, but still can't find any guide/pointers yet. (Apologies if my email is OOT) Rgds,
