Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Wed, Jan 23, 2013 at 08:06:48PM +0100, Felix Kuperjans wrote: Mike Gilbert: On Wed, Jan 23, 2013 at 1:29 PM, Felix Kuperjans fe...@desaster-games.com wrote: Samuli Suominen wrote: please review this news item, seems we need one after all Hello Samuli, /dev/root is no longer available in this udev version, so people who put this in their /etc/fstab might end up with an unbootable system. I suggest including in the news item, that /dev/root must be replaced with the actual root device or LABEL=..., UUID=... and the like in /etc/fstab. fstab is not consulted for mounting the root filesystem, so it doesn't really matter what you have in there. Either the kernel mounts it based on the kernel command line, or your initramfs mounts it based on whatever your /init programs does. Well, *if* a line with /dev/root is present in /etc/fstab, the system does not boot up properly (tested it right now). I always though such a line in /etc/fstab is needed so that fsck is run on the root filesystem... That was an example in the fstab in the stages, but the handbook always told you to replace /dev/root with the reference to the specific root device. William pgpWHehg7YGMy.pgp Description: PGP signature
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen ssuomi...@gentoo.org wrote: please review this news item, seems we need one after all Here's a crazy idea: can we patch our kernel to let make oldconfig default CONFIG_DEVTMPFS to true? Or better yet, request that this is changed upstream? Also, after installing udev-197, are there any negative consequences to just downgrading to -171 again? Cheers, Dirkjan
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Fri, Jan 25, 2013 at 4:19 AM, Dirkjan Ochtman d...@gentoo.org wrote: On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen ssuomi...@gentoo.org wrote: please review this news item, seems we need one after all Here's a crazy idea: can we patch our kernel to let make oldconfig default CONFIG_DEVTMPFS to true? Or better yet, request that this is changed upstream? I could see making that the default if there is no .config file present and a new one is being created, and perhaps upstream would support that since udev is popular. However, make oldconfig is usually used when you have a .config file and you just want to update it. In that case I don't think we should be changing settings - what if a user doesn't want this set? They'd have to remember to manually unset it every single time they compile a new kernel, as we'd be helpfully changing it back. Not everybody uses udev. Somebody already brought this up, but the main thing users need is notice for changes like this, and warnings. By all means mention in the warnings that their systems will be unbootable. And by all means let's cut down on spurious elog traffic otherwise. Oh, here's another thought - when elog traffic gets sent out as email can the subject line be changed based on the most serious message in the log? That is, can a log-only email be distinguished from one that has a warning in it? Rich
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Fri, Jan 25, 2013 at 12:59 PM, Rich Freeman ri...@gentoo.org wrote: I could see making that the default if there is no .config file present and a new one is being created, and perhaps upstream would support that since udev is popular. However, make oldconfig is usually used when you have a .config file and you just want to update it. In that case I don't think we should be changing settings - what if a user doesn't want this set? They'd have to remember to manually unset it every single time they compile a new kernel, as we'd be helpfully changing it back. Ah yeah, I mistakenly assumed that DEVTMPFS was a relatively new option. Cheers, Dirkjan
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 25/01/13 04:19 AM, Dirkjan Ochtman wrote: On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen ssuomi...@gentoo.org wrote: Also, after installing udev-197, are there any negative consequences to just downgrading to -171 again? Depends on whether or not you rebuilt the rdeps -- udev-197 provides libudev.so.1 while udev-171 provides libudev.so.0 , so there's breakage on stuffs like lvm2 and other ebuilds that link to libudev -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlECk+IACgkQ2ugaI38ACPDiPQEArL3Abb2QWi+/uM31+2Nr2wmY GnNGk0ScrqjMA0YuH5gBAI2y8hnzVP/99GwqlwRBnfOav/IftQMSEDzwkKIJhLi4 =EUug -END PGP SIGNATURE-
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Fri, Jan 25, 2013 at 3:17 PM, Ian Stakenvicius a...@gentoo.org wrote: Depends on whether or not you rebuilt the rdeps -- udev-197 provides libudev.so.1 while udev-171 provides libudev.so.0 , so there's breakage on stuffs like lvm2 and other ebuilds that link to libudev Even so, I could downgrade and revdep-rebuild after that, and it should Just Work, right? IIRC, I had nothing rebuilt by revdep-rebuilt after merging udev-197, so maybe this is not an issue for me. Maybe you could add a note about this to the news item? Cheers, Dirkjan
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On 25/01/2013 15:23, Dirkjan Ochtman wrote: Even so, I could downgrade and revdep-rebuild after that, and it should Just Work, right? Yes and no — you're safer if you get rid of the .so.1 first then revdep-rebuild (if you're using preserved-libs). I know there should be support for ldconfig NOT to re-create the links to the highest library by default for .so files, but I wouldn't bet on it as I've seen other things causing ldconfig to run and overwrite them outside Portage. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On 01/23/13 19:29, Felix Kuperjans wrote: Samuli Suominen wrote: please review this news item, seems we need one after all /dev/root is no longer available in this udev version, so people who put this in their /etc/fstab might end up with an unbootable system. I suggest including in the news item, that /dev/root must be replaced with the actual root device or LABEL=..., UUID=... and the like in /etc/fstab. I've recently upgraded some server from kernel-2.6.28 to kernel-3.5.7 and encountered that the root-device was renamed from /dev/cciss/c0d0p1 to /dev/sda1 due to some kernel driver change (took me a while to find out). I'm not using genkernel or any initramfs, nor do I have separate /usr. The only way I've found to keep the system bootable with both kernels (for the upgrade process until the new kernel config was good enough) was to replace /dev/cciss/c0d0p1 by /dev/root in /etc/fstab. How would this be done when there is no /dev/root any more? So yes, please include the /dev/root drop (at least) in the news item. /haubi/
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Thu, Jan 24, 2013 at 5:02 AM, Michael Haubenwallner ha...@gentoo.org wrote: The only way I've found to keep the system bootable with both kernels (for the upgrade process until the new kernel config was good enough) was to replace /dev/cciss/c0d0p1 by /dev/root in /etc/fstab. How would this be done when there is no /dev/root any more? I would think that you could just use LABEL=, UUID=, or /dev/disk/by-uuid/foo. Those device names only work on the kernel boot line if you're using an initramfs, but I suspect that they'd work fine in fstab regardless. Situations like this of course are one of the reasons initramfs is so popular - they can be far smarter about finding the root filesystem. Disclaimer: I'm using an initramfs, so I can't vouch for what happens without one. Rich
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23/01/13 05:21 PM, Pacho Ramos wrote: El mié, 23-01-2013 a las 23:45 +0200, Samuli Suominen escribió: On 23/01/13 23:21, Pacho Ramos wrote: El mié, 23-01-2013 a las 15:14 +0200, Samuli Suominen escribió: please review this news item, seems we need one after all Why don't you drop ~ from: CONFIG_CHECK=~DEVTMPFS to ensure people really changes it in their kernel and prevent breakage? That won't work because the host you run the package isn't necessarily same as the one you are building it on The build host doesn't need DEVTMPFS And couldn't that be done at install time? I mean, you can build and package new udev but installation will die if udev is going to be installed on a system without DEVTMPFS There's too many variables, though -- firstly, /usr/src/linux/.config may not match /proc/config.gz. And even if both are checked there's nothing to say that the next boot is going to use a kernel that matches either one. Realistically, what udev needs is something at runtime to report the error and temporarily bypass the requirement, because this really is a runtime issue instead of something that can be properly controlled or contained at build/install time. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iF4EAREIAAYFAlEBVgIACgkQ2ugaI38ACPBzfQD/ZAE4UHgQJ3zB9wuVkCcPAhXS 21C+7k+mjS2YSg8BgqcA/0iv12JreFnvmybX2H8a/g8BBKm30+Xbt1+bGC+rijYN =qA5Y -END PGP SIGNATURE-
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On 01/24/13 05:02, Michael Haubenwallner wrote: I've recently upgraded some server from kernel-2.6.28 to kernel-3.5.7 and encountered that the root-device was renamed from /dev/cciss/c0d0p1 to /dev/sda1 due to some kernel driver change (took me a while to find out). I'm not using genkernel or any initramfs, nor do I have separate /usr. The only way I've found to keep the system bootable with both kernels (for the upgrade process until the new kernel config was good enough) was to replace /dev/cciss/c0d0p1 by /dev/root in /etc/fstab. How would this be done when there is no /dev/root any more? These are the Compaq SmartArray controllers (usually found in HP Proliants). They used to have their own block driver, but these days they're just grouped with the rest of the SCSI drives. The old driver: Block Devices - BLK_CPQ_CISS_DA The new one is under, SCSI device support - SCSI low-level drivers - SCSI_HPSA This driver supports HP Smart Array Controllers (circa 2009). It is a SCSI alternative to the cciss driver, which is a block driver. Anyone wishing to use HP Smart Array controllers who would prefer the devices be presented to linux as SCSI devices, rather than as generic block devices should say Y here. The HPSA driver does *not* work on older Proliants, so I can only assume that HPSA is receiving active maintenance while the old block driver is not. Nevertheless, if the block driver worked for you in an old kernel, you could simply disable HPSA on the new one. When the time comes that you need to boot two newish kernels, you can re-enable HPSA and update fstab to use the new name.
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On 01/24/13 16:49, Michael Orlitzky wrote: On 01/24/13 05:02, Michael Haubenwallner wrote: I've recently upgraded some server from kernel-2.6.28 to kernel-3.5.7 and encountered that the root-device was renamed from /dev/cciss/c0d0p1 to /dev/sda1 due to some kernel driver change (took me a while to find out). I'm not using genkernel or any initramfs, nor do I have separate /usr. The only way I've found to keep the system bootable with both kernels (for the upgrade process until the new kernel config was good enough) was to replace /dev/cciss/c0d0p1 by /dev/root in /etc/fstab. How would this be done when there is no /dev/root any more? These are the Compaq SmartArray controllers (usually found in HP Proliants). They used to have their own block driver, but these days they're just grouped with the rest of the SCSI drives. Yep, this is a HP DL380 G6, and lspci says: 04:00.0 RAID bus controller: Hewlett-Packard Company Smart Array G6 controllers (rev 01) The old driver: Block Devices - BLK_CPQ_CISS_DA The new one is under, SCSI device support - SCSI low-level drivers - SCSI_HPSA The HPSA driver does *not* work on older Proliants, so I can only assume that HPSA is receiving active maintenance while the old block driver is not. Nevertheless, if the block driver worked for you in an old kernel, you could simply disable HPSA on the new one. Well, I'm pretty sure to have started with BLK_CPQ_CISS_DA=y in the new kernel config, but this driver doesn't seem to feel responsible for that controller any more - or what else could have make me wonder where /dev/cciss/* has gone? Finally I went along [1] to identify SCSI_HPSA as the correct driver. [1] http://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/ch08s02.html When the time comes that you need to boot two newish kernels, you can re-enable HPSA and update fstab to use the new name. So this didn't work out IIRC - but I won't retest that now. For the curious: $ cat /sys/bus/pci/devices/\:04\:00.0/vendor 0x103c $ cat /sys/bus/pci/devices/\:04\:00.0/device 0x323a /haubi/
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On 24/01/2013 20:19, Michael Haubenwallner wrote: Yep, this is a HP DL380 G6, and lspci says: 04:00.0 RAID bus controller: Hewlett-Packard Company Smart Array G6 controllers (rev 01) Hrm just for reference, I've got a number of G6s and they all work fine with the old cciss — although they do work better with HPSA. It's the same RAID bus controller there. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen ssuomi...@gentoo.org wrote: please review this news item, seems we need one after all +1, this would have been useful.
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On 23 January 2013 13:32, Dirkjan Ochtman d...@gentoo.org wrote: On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen ssuomi...@gentoo.org wrote: please review this news item, seems we need one after all +1, this would have been useful. Looks ok but as the news item says, it's a bit too late ... -- Regards, Markos Chandras / Gentoo Linux Developer / Key ID: B4AFF2C2
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On 23/01/13 15:34, Markos Chandras wrote: On 23 January 2013 13:32, Dirkjan Ochtman d...@gentoo.org wrote: On Wed, Jan 23, 2013 at 2:14 PM, Samuli Suominen ssuomi...@gentoo.org wrote: please review this news item, seems we need one after all +1, this would have been useful. Looks ok but as the news item says, it's a bit too late ... not for everyone, not everyone upgrades this often, and it's usually the servers that get updated last
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Wed, Jan 23, 2013 at 8:41 AM, Samuli Suominen ssuomi...@gentoo.org wrote: not for everyone, not everyone upgrades this often, and it's usually the servers that get updated last Agreed, but best to get this out ASAP. Only question - display-if-installed is set to . Would it make sense to make it 198 instead? Does a new install 5 years from now really need to see this? If sent out in advance I'd make it 197, but if we want to catch anybody who hasn't rebooted yet or who might have missed a detail 198 would handle that. Rich
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
130123 Samuli Suominen wrote: please review this news item, seems we need one after all ... - The need of CONFIG_DEVTMPFS=y in the kernel; need to verify the fstype for possible /dev line in /etc/fstab is devtmpfs (and not, for example, tmpfs) ... I have 2 such lines : tmpfs /tmptmpfs defaults,noatime,mode=1777 0 0 none /dev/shmtmpfs defaults 0 0 Are either or both involved ? -- if so, what to do ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On 23/01/2013 15:02, Philip Webb wrote: - The need of CONFIG_DEVTMPFS=y in the kernel; need to verify the fstype for possible /dev line in /etc/fstab is devtmpfs (and not, for example, tmpfs) ... I have 2 such lines : tmpfs /tmptmpfs defaults,noatime,mode=1777 0 0 none/dev/shmtmpfs defaults 0 0 Are either or both involved ? -- if so, what to do ? None are involved. The second column would read /dev if it was involved. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On 23/01/13 15:44, Rich Freeman wrote: On Wed, Jan 23, 2013 at 8:41 AM, Samuli Suominen ssuomi...@gentoo.org wrote: not for everyone, not everyone upgrades this often, and it's usually the servers that get updated last Agreed, but best to get this out ASAP. Only question - display-if-installed is set to . Would it make sense to make it 198 instead? Does a new install 5 years from now really need to see this? If sent out in advance I'd make it 197, but if we want to catch anybody who hasn't rebooted yet or who might have missed a detail 198 would handle that. Rich Right, I've used 198 and pushed the item now I welcome anyone to edit it if it needs editing, just do it
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Wed, Jan 23, 2013 at 9:05 AM, Diego Elio Pettenò flamee...@flameeyes.eu wrote: None are involved. The second column would read /dev if it was involved. The news item doesn't mention what to do if there is no line to mount /dev. I don't see one in my fstab, and I simply followed the handbook (as it was written ~2001), and all announced migration documents since. I can't imagine I'm the only one... System seems to work fine, so I'm not sure how essential that line is. The fact that I'm using an initramfs might also have an effect. Rich
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On 23/01/2013 16:04, Rich Freeman wrote: System seems to work fine, so I'm not sure how essential that line is. The fact that I'm using an initramfs might also have an effect. AFAICT if you do NOT have a /dev entry you're the best off because the init script will mount it for you. I think the same is true of /sys and /proc. -- Diego Elio Pettenò — Flameeyes flamee...@flameeyes.eu — http://blog.flameeyes.eu/
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
Hi, On 01/23/2013 04:04 PM, Rich Freeman wrote: System seems to work fine, so I'm not sure how essential that line is. The fact that I'm using an initramfs might also have an effect. I'd strongly suggest using CONFIG_DEVTMPFS_MOUNT=y. and stop worring about udev/openrc. udev/openrc stopped re-mounting /dev that last year. Michael -- Michael Weber Gentoo Developer web: https://xmw.de/ mailto: Michael Weber x...@gentoo.org
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
Samuli Suominen wrote: please review this news item, seems we need one after all Hello Samuli, /dev/root is no longer available in this udev version, so people who put this in their /etc/fstab might end up with an unbootable system. I suggest including in the news item, that /dev/root must be replaced with the actual root device or LABEL=..., UUID=... and the like in /etc/fstab. Regards, Felix
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Wed, Jan 23, 2013 at 1:29 PM, Felix Kuperjans fe...@desaster-games.com wrote: Samuli Suominen wrote: please review this news item, seems we need one after all Hello Samuli, /dev/root is no longer available in this udev version, so people who put this in their /etc/fstab might end up with an unbootable system. I suggest including in the news item, that /dev/root must be replaced with the actual root device or LABEL=..., UUID=... and the like in /etc/fstab. fstab is not consulted for mounting the root filesystem, so it doesn't really matter what you have in there. Either the kernel mounts it based on the kernel command line, or your initramfs mounts it based on whatever your /init programs does.
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Wed, Jan 23, 2013 at 1:42 PM, Mike Gilbert flop...@gentoo.org wrote: fstab is not consulted for mounting the root filesystem, so it doesn't really matter what you have in there. Either the kernel mounts it based on the kernel command line, or your initramfs mounts it based on whatever your /init programs does. Keep in mind that for some implementations whatever your /init programs does includes checking fstab. When I switched to dracut I discovered this when the system would not boot - my fstab had the wrong filesystem type for the root (it dated back to the ext2 days)... Rich
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Wed, Jan 23, 2013 at 1:52 PM, Rich Freeman ri...@gentoo.org wrote: On Wed, Jan 23, 2013 at 1:42 PM, Mike Gilbert flop...@gentoo.org wrote: fstab is not consulted for mounting the root filesystem, so it doesn't really matter what you have in there. Either the kernel mounts it based on the kernel command line, or your initramfs mounts it based on whatever your /init programs does. Keep in mind that for some implementations whatever your /init programs does includes checking fstab. When I switched to dracut I discovered this when the system would not boot - my fstab had the wrong filesystem type for the root (it dated back to the ext2 days)... Ah, good to know. I'm used to dealing with my little homegrown initramfs, where I parse root from the kernel command line in /init. genkernel does the same thing.
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
Mike Gilbert: On Wed, Jan 23, 2013 at 1:29 PM, Felix Kuperjans fe...@desaster-games.com wrote: Samuli Suominen wrote: please review this news item, seems we need one after all Hello Samuli, /dev/root is no longer available in this udev version, so people who put this in their /etc/fstab might end up with an unbootable system. I suggest including in the news item, that /dev/root must be replaced with the actual root device or LABEL=..., UUID=... and the like in /etc/fstab. fstab is not consulted for mounting the root filesystem, so it doesn't really matter what you have in there. Either the kernel mounts it based on the kernel command line, or your initramfs mounts it based on whatever your /init programs does. Well, *if* a line with /dev/root is present in /etc/fstab, the system does not boot up properly (tested it right now). I always though such a line in /etc/fstab is needed so that fsck is run on the root filesystem... Removing the line completely boots up fine, but the filesystem has not been fscked on boot. Regards, Felix
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On Wed, Jan 23, 2013 at 1:56 PM, Mike Gilbert flop...@gentoo.org wrote: Ah, good to know. I'm used to dealing with my little homegrown initramfs, where I parse root from the kernel command line in /init. genkernel does the same thing. Yeah, dracut generally does the right thing but that generally assumes that things like fstab are correct. It still uses the root= option (I'm not sure if it can work without it - I believe it does snapshot the fstab at time of creation). My understanding is that dracut actually remounts root a few times as it moves along, starting with the kernel command line, then after setting up mounts in fstab.sys (which is how you handle a separate /usr), and finally based on the contents of fstab (which it can't read until it actually has root mounted). When it is done the root filesystem is mounted using all options in /etc/fstab, which is probably a good thing. That said, it hasn't been without bugs. I think they're mostly fixed at this point, but I haven't tried removing all of my workarounds (mainly around the fact that it wasn't auto-assembling my raid unless I hardcoded an mdadm -As in a script). The best thing about dracut though is that it is pretty powerful, with modules/hooks/etc. When it wasn't quite working right for me I just added my own module to it. It also has the side-benefit of working well even when mdadm decides to renumber all my md minor device numbers (tends to happen when booting for CD or whatever - probably because I'm using older metadata for some of the arrays). Rich
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
El mié, 23-01-2013 a las 15:14 +0200, Samuli Suominen escribió: please review this news item, seems we need one after all Why don't you drop ~ from: CONFIG_CHECK=~DEVTMPFS to ensure people really changes it in their kernel and prevent breakage? signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On 23/01/13 23:21, Pacho Ramos wrote: El mié, 23-01-2013 a las 15:14 +0200, Samuli Suominen escribió: please review this news item, seems we need one after all Why don't you drop ~ from: CONFIG_CHECK=~DEVTMPFS to ensure people really changes it in their kernel and prevent breakage? That won't work because the host you run the package isn't necessarily same as the one you are building it on The build host doesn't need DEVTMPFS
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
Are you sure? I have CONFIG_DEVTMPFS_MOUNT disabled, latest stable udev (197-r3) and openrc (0.11.8), and no /dev line in my fstab, yet my /dev is still a devtmpfs with a proper set of device nodes. Chris On Wed, 23 Jan 2013 17:03:15 +0100 Michael Weber x...@gentoo.org wrote: Hi, On 01/23/2013 04:04 PM, Rich Freeman wrote: System seems to work fine, so I'm not sure how essential that line is. The fact that I'm using an initramfs might also have an effect. I'd strongly suggest using CONFIG_DEVTMPFS_MOUNT=y. and stop worring about udev/openrc. udev/openrc stopped re-mounting /dev that last year. Michael
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
El mié, 23-01-2013 a las 23:45 +0200, Samuli Suominen escribió: On 23/01/13 23:21, Pacho Ramos wrote: El mié, 23-01-2013 a las 15:14 +0200, Samuli Suominen escribió: please review this news item, seems we need one after all Why don't you drop ~ from: CONFIG_CHECK=~DEVTMPFS to ensure people really changes it in their kernel and prevent breakage? That won't work because the host you run the package isn't necessarily same as the one you are building it on The build host doesn't need DEVTMPFS And couldn't that be done at install time? I mean, you can build and package new udev but installation will die if udev is going to be installed on a system without DEVTMPFS signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
2013/1/23 Pacho Ramos pa...@gentoo.org El mié, 23-01-2013 a las 23:45 +0200, Samuli Suominen escribió: On 23/01/13 23:21, Pacho Ramos wrote: El mié, 23-01-2013 a las 15:14 +0200, Samuli Suominen escribió: please review this news item, seems we need one after all Why don't you drop ~ from: CONFIG_CHECK=~DEVTMPFS to ensure people really changes it in their kernel and prevent breakage? That won't work because the host you run the package isn't necessarily same as the one you are building it on The build host doesn't need DEVTMPFS And couldn't that be done at install time? I mean, you can build and package new udev but installation will die if udev is going to be installed on a system without DEVTMPFS Pacho, see the message from robbat2 titled RFC: CONFIG_CHECK_FATAL, making CONFIG_CHECKS fatal by default
Re: [gentoo-dev] news item for udev 197-r3 upgrade (yes, I know, it's late)
On 23/01/13 21:06, Felix Kuperjans wrote: Mike Gilbert: On Wed, Jan 23, 2013 at 1:29 PM, Felix Kuperjans fe...@desaster-games.com wrote: Samuli Suominen wrote: please review this news item, seems we need one after all Hello Samuli, /dev/root is no longer available in this udev version, so people who put this in their /etc/fstab might end up with an unbootable system. I suggest including in the news item, that /dev/root must be replaced with the actual root device or LABEL=..., UUID=... and the like in /etc/fstab. fstab is not consulted for mounting the root filesystem, so it doesn't really matter what you have in there. Either the kernel mounts it based on the kernel command line, or your initramfs mounts it based on whatever your /init programs does. Well, *if* a line with /dev/root is present in /etc/fstab, the system does not boot up properly (tested it right now). I always though such a line in /etc/fstab is needed so that fsck is run on the root filesystem... Removing the line completely boots up fine, but the filesystem has not been fscked on boot. I don't think we ever instructed users for adding such line... if we did, I'll eat my words. So, I don't think it's necessary to instruct them away from it either, never seen such fstab line. Maybe I'm too naive. - Samuli
