View previous topic :: View next topic |
Author |
Message |
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Tue Nov 08, 2011 6:32 pm Post subject: HOWTO: udev, sep /usr, no initramfs. eudev:3.1.5 rc:0.23.2 |
|
|
Tested against stable openrc: 0.23.2, eudev: 3.1.5 and udev-init-scripts: 32 - running with lvm2: 2.02.145-r2
Note: if you are upgrading udev or udev-init-scripts beware that (from udev-204 on), the ebuild silently adds udev to the sysinit runlevel. So before you reboot, make sure to run rc-update del udev sysinit or you will get what looks like dependency errors, with fsck (and udev) starting before lvm/localmount.
Same for udev-trigger.
Note to self: always check: rc-update show and scan across ;) Neither udev nor udev-trigger should be in sysinit; udev-trigger should be in boot (if we're not using an initramfs.)
Warning: If you are on lvm see the notes below.
As many of you will be aware, udev upstream has moved to requiring /usr mounted before it starts. Upstream (including kernel developers) advocates an initramfs across the board for Linux distributions, but definitely in the case where /usr is on a separate partition. This is not down to udev itself, but helper scripts for devices which often live in /usr or sometimes /var, and aiui the hardware database is also on /usr (i guess that bit is down to udev itself;)
This has caused some controversy on the gentoo-user and gentoo-dev mailing lists, as many of us are used to keeping /usr on a separate partition for security and backup purposes (other use-cases for a separate partition include mounting /usr over NFS, or a common partition for virtual machines) and don't want an initramfs, both for startup times and the additional maintenance task of recompiling it at every kernel upgrade/recompile (yes this could be scripted, but we don't see the need.) I've read several times that you can't use LVM on /usr etc without an initramfs, but this has never been an issue for several of us. (I don't have root on LVM, just most other partitions.)
Anyhow, leaving aside the arguments, Gentoo is about choice and in that spirit, I'd like to share the setup I've been using for the last 2 years (so I know it works;) to make udev start after localmount.
NB: Do not use this if you don't know what this is about, don't have /usr or /var on a separate partition, or need some device started by udev in order to mount local filesystems, or start your system (eg a bluetooth keyboard was given as an example on the dev mailing list.)
Having said that, it is simple enough to revert (comment line in /etc/rc.conf, and move udev-trigger to sysinit runlevel again,) so that could be done from a rescue shell (boot with init=/bin/sh and then edit file and run rc-update) or live disk [at worst-- if you can't get a shell] for setups that need udev to mount local drives.
As usual, you are responsible for your own system. This works for me and is easy enough to revert, but don't complain if you have an unusual setup and find you need to boot a live disk and chroot in to fix it (although you're welcome to ask for help, or share the experience. :) This is for people who know they have all the modules built-in the kernel to mount local filesystems, have a separate /usr and/or /var, and are happy with their current setups, apart from possible future issues with udev starting before localmount, and find the requirement for an initramfs sufficiently annoying to tweak their setups, and are willing to deal with keeping the lines in the initscripts during etc-updates.
Basically it consists of patches to 3 initscripts to support a new option initramfs which defaults to no/0.
We need a cross-initscript variable, which goes in /etc/rc.conf so it is active during dependency generation. cf: /lib/rc/sh/gendepends.sh
Config: /etc/rc.conf
Note: There is only one line with any content:
The rest is all instructions and comments on the setup. Code: | --- /etc/rc.conf
+++ /etc/rc.conf
@@ -104,6 +104,11 @@
# own fstypes to the following variable.
#extra_net_fs_list=""
+# UNSUPPORTED: Allow people with a separate /usr and /var to live without an
+# initramfs. NOTE you MUST use rc-update when changing this variable.
+# See EOF for explanation and rc-update setup. Default="YES"
+#initramfs=YES
+
##############################################################################
# SERVICE CONFIGURATION VARIABLES
# These variables are documented here, but should be configured in
@@ -248,3 +253,38 @@
# execute cgroup_cleanup with /etc/init.d/<service> cgroup_cleanup or
# rc-service <service> cgroup_cleanup.
# rc_cgroup_cleanup="NO"
+
+##############################################################################
+# SPLIT PARTITIONING WITHOUT INITRAMFS (UNSUPPORTED by systemd-udev)
+# Allow people with a separate /usr and /var to live without an initramfs.
+# The problem here is that udev helpers live in /usr and /var, so udev has
+# to start after they have been mounted.
+# To use udev, you MUST have CONFIG_DEVTMPFS set in kernel
+# If you are not using an initramfs (and are *sure* that you don't need one
+# NOR udev to mount /usr and /var) you can set initramfs="NO" to make
+# udev wait for localmount.
+# This also means localmount will umount /usr when it stops.
+# NB: you MUST first have applied the patches from:
+# http://forums.gentoo.org/viewtopic-t-901206.html
+
+## NOTE: to make this work you MUST:
+# rc-update del udev sysinit
+# rc-update del udev-trigger sysinit
+# rc-update add udev-trigger boot
+
+# If you are using LVM, you MUST use: /dev/mapper/vg-lv
+# in /etc/fstab, and not: /dev/vg/lv
+# - dash/hyphen/minus-sign '-' separates, not underscore '_'
+# CONFIG_DEVTMPFS_MOUNT is recommended for LVM.
+
+# If switching initramfs, you MUST also move udev-trigger
+# - udev will be started in the same level via 'need'
+
+# To reset to default (initramfs=YES):
+# rc-update del udev-trigger boot
+# rc-update add udev-trigger sysinit
+
+# To run without an initramfs(=NO) again:
+# rc-update del udev-trigger sysinit
+# rc-update add udev-trigger boot | Again: The only line of significance here is: which you have to change to "NO" (or "no" or 0) in order to use the new setup; this should be done after the changes to runlevels (and kernel first, if needed: --reboot before making any of the other changes) outlined in the comments.
Basically all you are doing is moving udev-trigger to boot, not sysinit, so it can start when udev has started, after localmount.
We remove udev from sysinit, so it gets pulled into whichever runlevel udev-trigger is in.
The other changes are to the init scripts for udev and udev-trigger, to support the new option, and to opentmpfiles-dev, to keep the sysinit dependencies correct. The only changes needed are to depend() functions.
/etc/init.d/udev: Code: | --- /etc/init.d/udev
+++ /etc/init.d/udev
depend()
{
need sysfs dev-mount
- before checkfs fsck
+ if yesno "${initramfs:-YES}";then
+ before checkfs fsck
+ else
+ need localmount
+ fi
keyword -lxc -systemd-nspawn -vserver
} | As you can see this just does the default setup, unless we're using the initramfs="no" option, when we should start after localmount to make sure /usr and /var etc are mounted.
/etc/init.d/udev-trigger: Code: | --- /etc/init.d/udev-trigger
+++ /etc/init.d/udev-trigger
@@ -10,7 +10,11 @@
depend()
{
need udev
- provide dev
+ if yesno "${initramfs:-YES}"; then
+ provide dev
+ else
+ before sysctl bootmisc net procfs logger termencoding urandom opentmpfiles-setup
+ fi
keyword -lxc -systemd-nspawn -vserver
}
| Again, the default setup, unless we're using the initramfs="no" option, when we start after udev (which is after localmount). The before line makes sure the pair start as soon as possible after localmount (immediately after, here.)
/etc/init.d/opentmpfiles-dev (always in sysinit): Code: | --- /etc/init.d/opentmpfiles-dev
+++ /etc/init.d/opentmpfiles-dev
@@ -7,8 +7,13 @@
depend()
{
provide tmpfiles-dev tmpfiles.dev
- use dev-mount
- before dev
+ if yesno "${initramfs:-YES}"; then
+ use dev-mount
+ before dev
+ else
+ need sysfs dev-mount
+ provide dev
+ fi
keyword -prefix -vserver
}
| Again default, or: this pulls in the same deps as udev in sysinit, and says that the initial devices provided by the kernel dev-mount = devfs (CONFIG_DEVTMPFS) are sufficient.
dev is usually provided by udev-trigger (which is no longer in sysinit) and used by fsck.
(We cannot patch devfs, as it provides dev-mount, and there are at least two "in-between" services, the other being kmod-static-nodes, also in sysinit, which does the setup for opentmpfiles-dev.)
We also need another, very minor, patch to /lib/rc/sh/init.sh to deal with the red error messages at startup: Code: | --- /lib/rc/sh/init.sh
+++ /lib/rc/sh/init.sh
@@ -12,13 +12,13 @@
fi
# check for md5sum, and probably /usr too
+got_md5sum=false
if command -v md5sum >/dev/null; then
got_md5sum=true
-else
+elif yesno "${initramfs:-YES}"; then
eerror "md5sum is missing, which suggests /usr is not mounted"
eerror "If you have separate /usr, it must be mounted by initramfs"
eerror "If not, you should check coreutils is installed correctly"
- got_md5sum=false
fi
# By default VServer already has /proc mounted, but OpenVZ does not! |
NOTE: If you are using lvm, you will need to use /dev/mapper/vg-lv in your /etc/fstab rather than /dev/vg/lv. The /dev/mapper/vg-lv links are made by the lvm vgscan, in our case at a time when udev is not running to make symlinks.
Note: Code: | /dev/vg/lv => vg-lv under: /dev/mapper | (ie with a hyphen.)
For >=sys-fs/lvm2-2.02.100 you'll need these set in /etc/lvm/lvm.conf:
Code: | sysfs_scan = 1
obtain_device_list_from_udev = 0
udev_sync = 1
udev_rules = 0 | The first, sysfs_scan is default; I mention it in case you have it set differently.
[Thanks to saellaven for working these out.]
CONFIG_DEVTMPFS_MOUNT is also useful, should you ever need to boot into a rescue shell. It means /dev will automatically be mounted by the kernel, which means the /dev/mapper links will be available however you start your machine, IME. While I've seen the links unavailable in sysinit (for 204 upgrade, when udev had been added back to sysinit by the ebuild) whenever I've booted into a rescue shell they have been present (presumably from the dm kernel module.) So you can usually get mount -a to work: if it's a dependency ordering issue, lvm will have already have activated the volumes, albeit too late for fsck; otherwise run: Code: | pvscan; vgscan --mknodes; vgchange --sysinit -a ly | to activate your local volumes.
--
So, if you're sure you don't need udev to mount your local drives, you can simply add the new option and change a couple of runlevels via rc-update to get udev to start after they've been mounted. This means full correct udev support, wherever the helper scripts or the hardware database live.
Note: you won't be able to use an encrypted rootfs, or rootfs on LVM, without an initramfs using this, but then you can't do either of those without an initramfs at all. Also, bear in mind that udev-181+ is not supposed to support booting without an initramfs, so be careful upgrading! Remember the note at the top about udev being added to sysinit, without notice.
Effectively, this is not so much a technical requirement as a distribution packaging issue, since all this happens in an initramfs in any case (or how else can it support lvm on /usr?) That's why the original technical specification given, was that "/usr and all file-systems where supporting scripts, binaries, plugins or libraries might live, be mounted and available before udev starts" (to summarise Greg K-H, in case I've not got the words exact.)
HTH,
steveL. _________________
creaker wrote: | systemd. It is a really ass pain |
update - "a most excellent portage wrapper"
#friendly-coders -- We're still here for you™ ;)
Last edited by steveL on Thu May 04, 2017 2:58 am; edited 25 times in total |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54578 Location: 56N 3W
|
Posted: Tue Nov 08, 2011 7:07 pm Post subject: |
|
|
/me watches this thread and will test later.
/me also watches the -dev ml for comments _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Tue Nov 08, 2011 7:58 pm Post subject: |
|
|
NeddySeagoon wrote: | /me watches this thread and will test later. |
Awesome :)
Quote: | /me also watches the -dev ml for comments |
Er, the user ML; I was hesitant about posting to dev, at very least until it's been tested by more people (and changes for unstable are worked out) and there seemed to be quite a few people on user ML who wanted an alternative. (The fake initscript thing was interesting in terms of showing something new, but seemed like a bit of a hack to me, as well as an unnecessary extra step; dependency tracking via the init system feels like the correct approach, since that is the issue-- udev needs localmount and for most of us localmount doesn't need udev, although in a generic system it might-- and an interesting area to explore as I'd never played with it.) |
|
Back to top |
|
|
netfab Veteran
Joined: 03 Mar 2005 Posts: 1957 Location: 127.0.0.1
|
Posted: Tue Nov 08, 2011 11:27 pm Post subject: |
|
|
Thank you, I will try this as soon as possible. Since a few weeks I'm using a minimal initramfs to mount /usr (this was mostly to learn how to build an initramfs and use it), but I'm not entirely satisfied with it.
Since a few days I thought about removing it, your topic is coming just in the nick of time |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54578 Location: 56N 3W
|
Posted: Tue Nov 08, 2011 11:46 pm Post subject: |
|
|
steveL,
I only have unstable/testing.
It will be the weekend before I can test as I can't afford to be without my main box until then.
Then its /boot on raid1, root on raid5 and everything else in LVM on raid5, with separate /usr and /var. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Wed Nov 09, 2011 1:48 am Post subject: |
|
|
No worries, Neddy; I look forward to hearing how you get on whenever you do get some time. I haven't used RAID (mdadm?) myself, so I don't know anything about it, but if you were able to get your machine booting without a ramdisk before (as many people appear to have been able to) then you should be fine.
As I said, resetting it is pretty easy; I kept switching back and forth when I was playing with the patches in August.
To turn it off, you just comment out the initramfs="no" line in /etc/conf.d/udev and run:
Code: | rc-update del udev-trigger boot
rc-update add udev-trigger sysinit |
..which only requires root fs.
netfab, glad it will be of use (hopefully;) Let us know how you get on.
edit: udev script split to udev (daemon) and udev-trigger (main, coldplug.)
Last edited by steveL on Sun Apr 09, 2017 9:22 pm; edited 1 time in total |
|
Back to top |
|
|
netfab Veteran
Joined: 03 Mar 2005 Posts: 1957 Location: 127.0.0.1
|
Posted: Wed Nov 09, 2011 12:14 pm Post subject: |
|
|
My system has nothing special, just a separate /usr, this seems to work fine.
Just a small typo, in /etc/conf.d/udev :
Quote: |
+# You MUST have CONFIG_DEV_TMPFS set in kernel OR (YMMV)
|
should be :
Quote: |
+# You MUST have CONFIG_DEVTMPFS set in kernel OR (YMMV)
|
Again, thank you |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Wed Nov 09, 2011 1:18 pm Post subject: |
|
|
netfab wrote: | My system has nothing special, just a separate /usr, this seems to work fine.
Just a small typo, in /etc/conf.d/udev |
Ah thanks netfab; I've edited the post to reflect that.
I also have CONFIG_DEVTMPFS_MOUNT which isn't needed, in that udev-mount mounts /dev as a tmpfs (devtmpfs if in /proc/filesystems which is what we want and configure) but it doesn't hurt, as udev-mount just einfo's that /dev is already mounted. If things change in the initscripts we can fall back on the kernel option (it might also be safer for more esoteric setups in that it's mounted straight after rootfs by the kernel itself.)
Quote: | Again, thank you 8) |
Thank you for testing and fixing the typo :-) |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54578 Location: 56N 3W
|
Posted: Wed Nov 09, 2011 11:09 pm Post subject: |
|
|
steveL,
I really don't want CONFIG_DEVTMPFS so I'll play with a cut down static /dev to get my raid sets assembled.
It might justwork for me anyway as my install is old enough to have come with a full static /dev from the stage3.
Users who have installed since May 2011, when baselayout2 was added to the stage3 will not have this static /dev
More news at the weekend. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sun Nov 13, 2011 8:45 pm Post subject: |
|
|
NeddySeagoon wrote: | Users who have installed since May 2011, when baselayout2 was added to the stage3 will not have this static /dev |
According to bug 368597 there was a problem with device nodes not being installed in stages for a few months. While it's not a full static /dev, users should now be getting ~250 static device nodes to fall back on; note that these are hidden once udev-mount has mounted a (dev)tmpfs on /dev (or indeed if kernel has CONFIG_DEVTMPFS_MOUNT set) (correct me if I'm wrong, as ever.) If you should be in that situation, comment 97 gives a good approach to recovering the standard setup for recovery situations.
The bug is useful reading for others looking at using static devices, who should consider MAKEDEV (from sys-apps/makedev but available on live CD) which can be used to make individual device nodes (eg MAKEDEV /dev/ttyS0) (add -S flag to see what it'll do first) as well as the traditional MAKEDEV generic (which would be run from within the target /dev.) MAKEDEV will take care of permissions and ownership, as well as device types, for you.
I'm not sure how static device nodes interact with udev; presumably it asks the kernel what devices are currently in use to populate its new /dev directory? |
|
Back to top |
|
|
keenblade Veteran
Joined: 03 Oct 2004 Posts: 1087
|
Posted: Wed Nov 16, 2011 1:19 am Post subject: |
|
|
My setup use partitions everywhere (/var /tmp /usr /home /var/portage /usr/src, etc). So, this means, I am in trouble. Although, I hate to use an initrid, before experimenting your method, I want to create an initrd.
I have never used or created it before, so I ask here, what is the current way of creating an initrd without genkernel for grub2? I don't want to create a big initrd, but only to enough to get over separete /var /usr problem.
There seems to be a new tool dracut which obsoletes the mkinitrd.
Will this work?
Code: |
dracut /boot/initrd-3.1.1-gentoo.img 3.1.1
|
Also what about kernel options that need to enable? only initramfs is enough to enable? Are there other packages needed to install?
Edit : Naming is important. Otherwise grub2-update cant find initrd. This seems to work:
Code: |
dracut /boot/initramfs-x86_64-3.1.1-gentoo.img 3.1.1-gentoo
|
_________________ Anyway it's all the same at the end...
Need help to get it working: "x-fi surround 5.1" |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Wed Nov 16, 2011 7:43 pm Post subject: |
|
|
Wow there's a nick I haven't seen in ages. Glad you're still about keenblade :)
keenblade wrote: | My setup use partitions everywhere (/var /tmp /usr /home /var/portage /usr/src, etc). So, this means, I am in trouble. |
Heh so do I, and don't worry you're not. Like you I've partitioned as much as I can, for differing file usage, stopping runaway processes running in a temp directory, and one I like is not allowing device nodes anywhere but root; unfortunately I found that stopped stuff working a while back, so /usr has lax permissions. You can't have 'noexec' on /var/tmp as scripts and built programs need to run from there during emerges.
Here's my fstab; it's easier to paste it than describe it and should prove to you that this setup works for complex partitioning schemes-- just not if you need services started, or scripts run, to mount root. Simply put, if you didn't need an initrd before, you won't now, and udev scripts will all start up properly, since the requisite filesystems are all there before it gets started.
Code: | /dev/sda2 none swap sw 0 0
/dev/sdb2 none swap sw 0 0
/dev/sda5 / ext3 noatime 1 1
/dev/sda1 /boot ext2 nodev,noexec,nosuid,noatime,sync 1 2
/dev/sdb9 /home ext3 nodev,nosuid,noatime 1 2
/dev/sdb5 /tmp ext2 nodev,noexec,nosuid,noatime 0 0
/dev/mapper/gent2-usr /usr ext3 noatime 0 2
/dev/mapper/var-gentoo /var ext3 nodev,nosuid,noatime 1 2
/dev/sdb8 /opt ext3 nodev,nosuid,noatime 0 0
/dev/mapper/gent2-local /usr/local ext3 noatime 1 2
/dev/mapper/gent2-portage /usr/portage ext3 nodev,noexec,nosuid,noatime 0 0
/dev/mapper/gent2-distfiles /usr/portage/distfiles ext3 nodev,noexec,nosuid,noatime 0 2
/dev/sdb7 /var/tmp ext2 nodev,nosuid,noatime 0 0
/dev/mapper/gent2-src /usr/src ext3 nodev,nosuid,noatime 0 0
/dev/cdrom /mnt/cdrom auto users,noauto,nosuid,nodev,noexec,ro 0 0
/dev/cdrom1 /mnt/cdrom2 auto users,noauto,nosuid,nodev,noexec,ro 0 0
/dev/fd0 /mnt/floppy auto users,noauto,nosuid,nodev,noexec 0 0
# NOTE: The next line is critical for boot!
proc /proc proc rw,nosuid,nodev,noexec 0 0
# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm
shm /dev/shm tmpfs nodev,nosuid,noexec 0 0
|
/dev/mapper/gent2 and /dev/mapper/var are LVM volume groups; I also have a debian group I no longer use anymore, as well as plenty of hard-disk space for when I get round to experimenting :) All of this was setup using the cfdisk, lvm tools etc, via the gent2 installer script we started a few years ago; it definitely needs some love. (I was out of action for quite a while and update needed the work first to get up to speed with emerge after such a long hiatus.)
Quote: | Although, I hate to use an initrid, before experimenting your method, I want to create an initrd. |
That's commendably sensible.
Unfortunately I've never used one since bad old days trying to compile a kernel in mandrake about a decade ago. Bear in mind that initrd is old style, initramfs is newer and supposed to be easier to handle. But then you appear to have got there already :)
Thanks for the tip; anything like this is welcome afaic. The more options people have, the better.
/me looks at Neddy for some info on setting up static dev ;)
(it's been mentioned on user ML as well; people are making mdev work again, and also playing with static /dev on vms.)
(Yeah I know I should have /boot read-only for security, but I figure if something malicious can write there, it can read and write anywhere, so my box would already be compromised.)
edit: Updated fstab listing to reflect usage with new lvm which relies on udev to create the /dev/vg/lv mapping of /dev/mapper/vg-lv.
Last edited by steveL on Mon Mar 19, 2012 7:03 am; edited 1 time in total |
|
Back to top |
|
|
keenblade Veteran
Joined: 03 Oct 2004 Posts: 1087
|
Posted: Thu Nov 17, 2011 4:24 am Post subject: |
|
|
Hi, steveL. It's a pleasure to see you, here, too. Thanks for the info you shared. I will try when I can afford time.
Btw, I see, your update script advanced wonderfully. That is really appreciated. Best way to update. I don't know what I would do, if you guys weren't here. _________________ Anyway it's all the same at the end...
Need help to get it working: "x-fi surround 5.1" |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Sat Nov 19, 2011 9:40 am Post subject: |
|
|
Thanks for your kind words, keenblade; they're much appreciated. :-) |
|
Back to top |
|
|
Txema l33t
Joined: 20 May 2008 Posts: 772 Location: Granada
|
Posted: Sun Mar 18, 2012 11:19 am Post subject: |
|
|
If i have this partition scheme, would i need to configure initramfs too?
/ --> sda5
/usr/src --> sda7
/usr/portage --> sda8 |
|
Back to top |
|
|
ppurka Advocate
Joined: 26 Dec 2004 Posts: 3256
|
Posted: Sun Mar 18, 2012 11:23 am Post subject: |
|
|
Txema wrote: | If i have this partition scheme, would i need to configure initramfs too?
/ --> sda5
/usr/src --> sda7
/usr/portage --> sda8 | No. You don't need an initramfs. Just make sure that your /boot contains a System.map file corresponding to the current kernel. _________________ emerge --quiet redefined | E17 vids: I, II | Now using kde5 | e is unstable :-/ |
|
Back to top |
|
|
Trog Dog Apprentice
Joined: 04 Aug 2007 Posts: 282
|
Posted: Sun Mar 18, 2012 3:20 pm Post subject: |
|
|
What are the patches for udev-171-r5? I applied the ones for 164 as best I could but gnome-terminal became unusable (don't know what else broke), luckily I was able to ssh into the box and revert the changes.
Additionally, will this workaround still be valid for udev 181? _________________ CIC1=CC=C(C2=N[C@@H](CC(OC(C)(C)C)=O)C3=NN=C(C)N3C4=C2C(C)=C(C)S4)C=C1 |
|
Back to top |
|
|
DaggyStyle Watchman
Joined: 22 Mar 2006 Posts: 5929
|
Posted: Sun Mar 18, 2012 8:58 pm Post subject: |
|
|
what is the gain in placing /usr in separate partition? _________________ Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein |
|
Back to top |
|
|
Ant P. Watchman
Joined: 18 Apr 2009 Posts: 6920
|
Posted: Sun Mar 18, 2012 9:59 pm Post subject: |
|
|
I just realised my home server has /var on its own partition... I don't really need hotplug on there, would it be easier for me to make the kernel non-modular and use devtmpfs on its own maybe?
edit: I've installed sys-fs/static-dev - a few things broke initially, but I fixed them all:
- /etc/init.d/udev* didn't get unmerged due to config-protect and all hell broke loose on the next reboot until I removed them by hand
- I needed to `rc-update add sysfs boot` since it no longer got autostarted
- I was using kexec, which no longer autodetected the root partition (no /dev/root symlink), so I had to set that manually to avoid kernel panics
- /dev/{ptmx,tty*,vcs*} need manually chown'ing to root:tty and chmod g+rw on vcs*. Paludis in particular complains if they aren't, other programs might too.
|
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Mon Mar 19, 2012 6:23 am Post subject: |
|
|
Sorry about delay responding, I was offline for a while. When I upgraded my machine after a couple of months, the whole thing broke ;) but it turned out to be due to a recent change in lvm2, since my LVM partitions were being mounted as eg /dev/gent/usr instead of /dev/mapper/gent2-usr, and lvm startup now expects the nodes to be made by udev. I had to use vgscan --mknodes when booting from a rescue shell, and couldn't quite integrate that into the lvm scripts (which iirc have the same option) so I switched back to initramfs=yes. Then X didn't work and it took me a while to realise I'd upgraded xorg-server so needed the drivers rebuilding. After that I didn't bother playing with it, though I realised I could just use the mapper device names instead of the udev-provided friendly names, so I switched my fstab to those to check they function, and got on with other work.
Trog Dog wrote: | What are the patches for udev-171-r5? I applied the ones for 164 as best I could but gnome-terminal became unusable (don't know what else broke), luckily I was able to ssh into the box and revert the changes. |
After the above saga, I've tested the updated patches in the first post, which I'm running on my machine now. The two major points are lvm usage as above (it simply won't work unless you use /dev/mapper/..) and additionally references to /etc/conf.d/udev were removed from the udev and udev-mount initscripts; that's not an issue for the former, as openrc sources it itself, but we need it to build the depend() info for udev-mount.
Curiously, on my machine, when I was testing the upgraded patches, not having the initramfs info in udev-mount didn't hurt, possibly as I already have CONFIG_DEVTMPFS_MOUNT, not sure.
Quote: | Additionally, will this workaround still be valid for udev 181? |
I don't know yet, but I'd plan for it not to be. There's a recent thread on dev ml about a news item for 181 hitting unstable tree, stating that udev will no longer support starting without an initramfs. It'd be a shame if they actively put in stuff that requires more than local drives being mounted, but I'd advise getting a basic initramfs built-in to your kernel that does support udev with the standard setup (initramfs=yes) before doing that upgrade, so you can switch to it before installing, or in case there are any other problems later.
I'd understand if you felt you might as well just chuck in the towel and switch to an initramfs. |
|
Back to top |
|
|
DaggyStyle Watchman
Joined: 22 Mar 2006 Posts: 5929
|
Posted: Mon Mar 19, 2012 6:35 am Post subject: |
|
|
Ant P. wrote: | I just realised my home server has /var on its own partition... I don't really need hotplug on there, would it be easier for me to make the kernel non-modular and use devtmpfs on its own maybe?
edit: I've installed sys-fs/static-dev - a few things broke initially, but I fixed them all:
- /etc/init.d/udev* didn't get unmerged due to config-protect and all hell broke loose on the next reboot until I removed them by hand
- I needed to `rc-update add sysfs boot` since it no longer got autostarted
- I was using kexec, which no longer autodetected the root partition (no /dev/root symlink), so I had to set that manually to avoid kernel panics
- /dev/{ptmx,tty*,vcs*} need manually chown'ing to root:tty and chmod g+rw on vcs*. Paludis in particular complains if they aren't, other programs might too.
|
wait, do I need initramfs if my /var is on a different partition? _________________ Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Mon Mar 19, 2012 6:44 am Post subject: |
|
|
Ant P. wrote: | I just realised my home server has /var on its own partition... I don't really need hotplug on there, would it be easier for me to make the kernel non-modular and use devtmpfs on its own maybe?
edit: I've installed sys-fs/static-dev - a few things broke initially, but I fixed them all:
- /etc/init.d/udev* didn't get unmerged due to config-protect and all hell broke loose on the next reboot until I removed them by hand
- I needed to `rc-update add sysfs boot` since it no longer got autostarted
- I was using kexec, which no longer autodetected the root partition (no /dev/root symlink), so I had to set that manually to avoid kernel panics
- /dev/{ptmx,tty*,vcs*} need manually chown'ing to root:tty and chmod g+rw on vcs*. Paludis in particular complains if they aren't, other programs might too.
|
Great info, Ant, and nicely done :)
One thing: maybe you should have sysfs in sysinit runlevel? I'm not sure how vital it being there is, but I know that's where it starts on a standard system, as udev is normally in sysinit and requires sysfs and udev-mount.
DaggyStyle wrote: | what is the gain in placing /usr in separate partition? |
As I said in the first post "many of us are used to keeping /usr on a separate partition for security and backup purposes (other use-cases for a separate partition include mounting /usr over NFS, or a common partition for virtual machines)." It's also easier to use lvm (and iirc other technologies like drive encryption and mdraid, though that may be less true nowadays if you have no initramfs) if you have a small-ish root and mount other partitions from lvm, which is my use-case. I also like to set different mount options on a partition basis; nodev, nosuid and noexec are the main security ones, though as you'll see from my fstab above, /usr and / have the same options. I certainly don't want /var, which is also required for some udev scripts, to have lax settings though.
But you don't have to use this to get separate partitions: you can do that with an initramfs, and have full support. I'm personally not happy at being told an initramfs is the rescue system that root used to be, at the same time as I'm told that I only need a small initramfs with at most a few hundred kilobytes in it, but I would recommend anyone new to partitioning to go the supported route. |
|
Back to top |
|
|
steveL Watchman
Joined: 13 Sep 2006 Posts: 5153 Location: The Peanut Gallery
|
Posted: Mon Mar 19, 2012 6:48 am Post subject: |
|
|
DaggyStyle wrote: | wait, do I need initramfs if my /var is on a different partition? |
Yup :)
Well, it needs to be mounted before udev starts (and pragmatically all standard mountpoints do, ie the equivalent of localmount.) |
|
Back to top |
|
|
DaggyStyle Watchman
Joined: 22 Mar 2006 Posts: 5929
|
Posted: Mon Mar 19, 2012 8:09 am Post subject: |
|
|
steveL wrote: | DaggyStyle wrote: | wait, do I need initramfs if my /var is on a different partition? |
Yup
Well, it needs to be mounted before udev starts (and pragmatically all standard mountpoints do, ie the equivalent of localmount.) |
imho this is completely stupid, is there any way to avoid this and still update udev
but if there is any relation to the news about the udev upgrade, than the msg was talking about /usr only, thus the gentoo devs got lazy and may cause unneeded serious computer breakage for users, this must be corrected at once and notify all that /var on separate mounts is affected too. _________________ Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein |
|
Back to top |
|
|
Trog Dog Apprentice
Joined: 04 Aug 2007 Posts: 282
|
Posted: Mon Mar 19, 2012 12:00 pm Post subject: |
|
|
steveL wrote: | After the above saga, I've tested the updated patches in the first post, which I'm running on my machine now. The two major points are lvm usage as above (it simply won't work unless you use /dev/mapper/..) and additionally references to /etc/conf.d/udev were removed from the udev and udev-mount initscripts; that's not an issue for the former, as openrc sources it itself, but we need it to build the depend() info for udev-mount.
Curiously, on my machine, when I was testing the upgraded patches, not having the initramfs info in udev-mount didn't hurt, possibly as I already have CONFIG_DEVTMPFS_MOUNT, not sure. |
Cheers Steve - I'll give it a shot on my boxes tonight.
Quote: |
Quote: | Additionally, will this workaround still be valid for udev 181? |
I don't know yet, but I'd plan for it not to be. There's a recent thread on dev ml about a news item for 181 hitting unstable tree, stating that udev will no longer support starting without an initramfs. It'd be a shame if they actively put in stuff that requires more than local drives being mounted, but I'd advise getting a basic initramfs built-in to your kernel that does support udev with the standard setup (initramfs=yes) before doing that upgrade, so you can switch to it before installing, or in case there are any other problems later.
I'd understand if you felt you might as well just chuck in the towel and switch to an initramfs. |
I'd be more likely to just stick /usr back on / than create an initramfs - it was only because the lvm guide recommended that /usr go on it's own partition that I now face this situation. _________________ CIC1=CC=C(C2=N[C@@H](CC(OC(C)(C)C)=O)C3=NN=C(C)N3C4=C2C(C)=C(C)S4)C=C1 |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|