| View previous topic :: View next topic |
| Author |
Message |
Odysseus
Apprentice
Joined: 23 Jun 2004
Posts: 250
Location: Miami, FL. I miss San Francisco!!!
|
 Posted: Wed Jan 23, 2013 10:44 pm Post subject: a devtmpfs fstab question |
 |
|
I'm a longtime Gentoo user(over 10 years), but I'm a truck driver not a programmer. I'm running ~amd64 on my laptop and also using baselayout-2.
This afternoon while updating my system I saw there an alert that there was a new news item to read.
The alert was titled "2013-01-23-udev-upgrade" and reads as follows: | Quote: | Title Upgrading udev from 171 (or older) to 197
Author Samuli Suominen <ssuominen@gentoo.org>
Posted 2013-01-23
Revision 1
Upgrading udev from 171 (or older) to 197 will require special attention:
- Remove udev-postmount from runlevels.
- 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)
- The case of predictable network interface names; if the file
/etc/udev/rules.d/70-persistent-net.rules is being used for renaming
network interface names to already existing names, then you need to
read following bug[1] because it's no longer possible. This won't
be a problem with the new predictable network interface name scheme[2].
[1] https://bugs.gentoo.org/453494
[2] http://www.freedesktop.org/wiki/Software/systemd/
PredictableNetworkInterfaceNames
- Support for older kernels than 2.6.39 is dropped. If you need older kernel
we recommend you to look into sys-fs/eudev or use local overlay for keeping
the old ebuild. Remember to also get the distfiles where the patchsets are.
The upgrade into current stable version of gentoo-sources is recommended.
- The case of separate /usr; if it worked for you with 171 it will continue
to work for you with 197. We still recommend initramfs with separate /usr
mounting capabilities because you might need packages like sys-apps/kbd
(keymaps in /usr) or net-wireless/bluez (possible keyboard) in early boot.
And read every message printed by the emerge of udev and udev-init-scripts
to ensure the system is in order before booting as this news item might
not be complete.
Apologies if this news came too late for you. |
My questions are as follows:
I don't use an initramfs and have never used one. I moved '/usr' and '/var' to '/' about a year ago when I read about an upcoming udev update that would break systems with no initramfs having '/usr' and '/var' mounted on separate partitions. Is this news alert telling me that for some reason I need to make an initramfs now?
I have devtmps properly compiled into my kernel and have done so for quite some time, but I don't have any references to devtmpfs, tmpfs, shm or any other 'temp' file systems in my fstab. I removed them a while back when I noticed they were being created automagically by during startup by various boot scripts in '/etc/init.d'.
My fstab looks like this: | Code: | # <fs> <mountpoint> <type> <opts> <dump/pass>
/dev/sda7 / ext4 defaults,relatime 1 1
/dev/sda8 /home ext4 defaults,relatime 1 2
/dev/sda9 /usr/portage ext4 defaults,relatime 1 2
/dev/sda5 /boot ext2 noauto,relatime 1 2
/dev/sda6 none swap sw 0 0
#tmpfs /dev/shm tmpfs defaults 0 0
#proc /proc proc defaults 0 0
#sysfs /sys sysfs defaults 0 0
#devpts /dev/pts devpts defaults 0 0 |
As you can see I've commented out all references to any temp file systems from my fstab.
My mtab looks like this: | Code: | rootfs / rootfs rw 0 0
/dev/root / ext4 rw,relatime,commit=0 0 0
devtmpfs /dev devtmpfs rw,relatime,size=1668232k,nr_inodes=417058,mode=755 0 0
proc /proc proc rw,nosuid,nodev,noexec,relatime 0 0
tmpfs /run tmpfs rw,nosuid,nodev,relatime,mode=755 0 0
devpts /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620 0 0
shm /dev/shm tmpfs rw,nosuid,nodev,noexec,relatime 0 0
sysfs /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0
securityfs /sys/kernel/security securityfs rw,nosuid,nodev,noexec,relatime 0 0
/dev/sda8 /home ext4 rw,relatime,commit=0 1 2
/dev/sda9 /usr/portage ext4 rw,relatime,commit=0 1 2
/dev/sda5 /boot ext2 noauto,relatime 1 2
binfmt_misc /proc/sys/fs/binfmt_misc binfmt_misc rw,nodev,noexec,nosuid 0 0 |
My start-up file are as follows: | Code: | rc-update show
acpid | boot
alsasound | boot
bluetooth | default
bootmisc | boot
clamd | default
consolekit | default
dbus | default
devfs | sysinit
dmesg | sysinit
fbcondecor | boot
hostname | boot
hwclock | boot
keymaps | boot
killprocs | shutdown
lm_sensors | default
local | default
microcode_ctl | boot
modules | boot
mount-ro | shutdown
mtab | boot
net.lo | default
procfs | boot
savecache | shutdown
swap | boot
sysctl | boot
sysfs | sysinit
syslog-ng | default
tmpfiles.setup | boot
udev | sysinit
udev-mount | sysinit
ufw | boot
urandom | boot
vixie-cron | default
wicd | default
xdm | boot |
My question is do I now have to explicitly enter all of these file systems that currently reside in mtab into my fstab? If I don't will I have issues that I'm not experiencing now?
Any help would be greatly appreciated. TIA
Ciao |
|
| Back to top |
|
 |
The Doctor
Moderator
Joined: 27 Jul 2010
Posts: 2678
|
| Posted: Wed Jan 23, 2013 11:46 pm Post subject: |
|
|
You are fine. Udev is not going to render your system unbootable.
Your fstab looks about like mine from a 2 day old install. I wouldn't worry about that.
You should pay attention to what it says about network naming. This one can be uncomfortable if you are not prepared.
_________________
First things first, but not necessarily in that order.
Apologies if I take a while to respond. I'm currently working on the dematerialization circuit for my blue box. |
|
| Back to top |
|
|
ulenrich
Veteran
Joined: 10 Oct 2010
Posts: 1483
|
| Posted: Thu Jan 24, 2013 1:12 am Post subject: |
|
|
| The Doctor wrote: | | You should pay attention to what it says about network naming. This one can be uncomfortable if you are not prepared. |
What the news could say more clearly:
If you put an all commented out - empty (*)
/etc/udev/rules.d/80-net-name-slot.rules
this overtunes the new network naming feature.
All keeps as used to - no problems.
And you can try later with new names - if you are curious about....
(*)PS: I think udev-197 installed this unfeaturing file for me. |
|
| Back to top |
|
|
Ant P.
Watchman
Joined: 18 Apr 2009
Posts: 6920
|
| Posted: Thu Jan 24, 2013 5:13 am Post subject: |
|
|
| You don't need any new fstab entries - all the commented out ones are handled by initscripts already. The /dev/ ones are done in /etc/init.d/udev-mount. |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Thu Jan 24, 2013 5:33 am Post subject: |
|
|
| Ant P. wrote: | | You don't need any new fstab entries - all the commented out ones are handled by initscripts already. The /dev/ ones are done in /etc/init.d/udev-mount. |
Right. That's why the news item said "possible /dev line" as most people don't have any line there. |
|
| Back to top |
|
|
modnaruved
Apprentice
Joined: 21 Mar 2011
Posts: 164
|
| Posted: Thu Jan 24, 2013 6:00 am Post subject: |
|
|
After post news and success upgraded too I have same questions on this news advice:
| Quote: | - 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) |
my kernel devtmpfs settings are:
| Code: | CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y |
my mount output:
| Code: | rootfs on / type rootfs (rw)
/dev/root on / type reiserfs (rw,noatime)
devtmpfs on /dev type devtmpfs (rw,relatime,size=1035092k,nr_inodes=220681,mode=755)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
tmpfs on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620)
shm on /dev/shm type tmpfs (rw,nosuid,nodev,noexec,relatime)
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
cgroup_root on /sys/fs/cgroup type tmpfs (rw,nosuid,nodev,noexec,relatime,size=10240k,mode=755)
openrc on /sys/fs/cgroup/openrc type cgroup (rw,nosuid,nodev,noexec,relatime,release_agent=/lib/rc/sh/cgroup-release-agent.sh,name=openrc)
cpuset on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cpu on /sys/fs/cgroup/cpu type cgroup (rw,nosuid,nodev,noexec,relatime,cpu)
cpuacct on /sys/fs/cgroup/cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpuacct)
freezer on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
/dev/sda7 on /mnt/data-vol-30 type ext4 (rw,noatime,commit=0)
/dev/sda9 on /mnt/data-vol-57 type ext4 (rw,noatime,commit=0)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev) |
my fstab content:
| Code: | /dev/sda3 /boot ext2 noauto,noatime 1 2
/dev/sda6 / reiserfs noatime 0 1
/dev/sda8 none swap sw 0 0
/dev/cdrom /mnt/cdrom auto noauto,ro,user 0 0
# glibc 2.2 and above expects tmpfs to be mounted at /dev/shm for
# POSIX shared memory (shm_open, shm_unlink).
# (tmpfs is a dynamically expandable/shrinkable ramdisk, and will
# use almost no memory if not populated with files)
shm /dev/shm tmpfs nodev,nosuid,noexec 0 0
/dev/sda7 /mnt/data-vol-30 ext4 auto,noatime 0 0
/dev/sda9 /mnt/data-vol-57 ext4 auto,noatime 0 0
|
what need to replace|edit|delete in my fstab for devtmpfs?
just replace tmpfs to devtmpfs or add new line with devtmpfs or remove whole line with shm entry?
These tips form news about line in fstab seems not understandable for me.
I think many users have same questions too.
I would be very grateful for your advice on this matter. Please.
In my opinion if I have CONFIG_DEVTMPFS_MOUNT=y then I dont need add any entry for devtmpfs in my fstab, but
| Quote: | | possible /dev line in /etc/fstab is devtmpfs (and not, for example, tmpfs) |
confuse me, because I have mounted devtmpfs and have also tmpfs in fstab... What should be done with this shm .... tmpfs entry?
Will be great if these details will be reflected in news or in upgrade guide|wiki |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Thu Jan 24, 2013 6:07 am Post subject: |
|
|
CONFIG_DEVTMPFS_MOUNT=y can be used but is not mandatory; the udev-mount init script will take care of mounting it if CONFIG_DEVTMPFS_MOUNT=y is missing
CONFIG_DEVTMPFS=y is the mandatory one
The news item means /dev, not /dev/shm or /dev/porn, just /dev, most people don't have such line at all and that's fine
Details? The news item is accurate enough in my opinion, rest is just bikeshedding |
|
| Back to top |
|
|
DaggyStyle
Watchman
Joined: 22 Mar 2006
Posts: 5945
|
| Posted: Thu Jan 24, 2013 6:10 am Post subject: |
|
|
| ssuominen wrote: | CONFIG_DEVTMPFS_MOUNT=y can be used but is not mandatory; the udev-mount init script will take care of mounting it if CONFIG_DEVTMPFS_MOUNT=y is missing
CONFIG_DEVTMPFS=y is the mandatory one
The news item means /dev, not /dev/shm or /dev/porn, just /dev, most people don't have such line at all and that's fine
Details? The news item is accurate enough in my opinion, rest is just bikeshedding |
huh? come again?
_________________
Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein |
|
| Back to top |
|
|
modnaruved
Apprentice
Joined: 21 Mar 2011
Posts: 164
|
| Posted: Thu Jan 24, 2013 6:13 am Post subject: |
|
|
| ssuominen wrote: | CONFIG_DEVTMPFS_MOUNT=y can be used but is not mandatory; the udev-mount init script will take care of mounting it if CONFIG_DEVTMPFS_MOUNT=y is missing
CONFIG_DEVTMPFS=y is the mandatory one
The news item means /dev, not /dev/shm or /dev/porn, just /dev, most people don't have such line at all and that's fine |
thanks and very fast reply  |
|
| Back to top |
|
|
SamuliSuominen
Retired Dev
Joined: 30 Sep 2005
Posts: 2133
Location: Finland
|
| Posted: Thu Jan 24, 2013 6:16 am Post subject: |
|
|
| DaggyStyle wrote: | | ssuominen wrote: | CONFIG_DEVTMPFS_MOUNT=y can be used but is not mandatory; the udev-mount init script will take care of mounting it if CONFIG_DEVTMPFS_MOUNT=y is missing
CONFIG_DEVTMPFS=y is the mandatory one
The news item means /dev, not /dev/shm or /dev/porn, just /dev, most people don't have such line at all and that's fine
Details? The news item is accurate enough in my opinion, rest is just bikeshedding |
huh? come again? |
I mean pr0n of course. |
|
| Back to top |
|
|
modnaruved
Apprentice
Joined: 21 Mar 2011
Posts: 164
|
| Posted: Thu Jan 24, 2013 6:22 am Post subject: |
|
|
| ssuominen wrote: | | DaggyStyle wrote: | | ssuominen wrote: | CONFIG_DEVTMPFS_MOUNT=y can be used but is not mandatory; the udev-mount init script will take care of mounting it if CONFIG_DEVTMPFS_MOUNT=y is missing
CONFIG_DEVTMPFS=y is the mandatory one
The news item means /dev, not /dev/shm or /dev/porn, just /dev, most people don't have such line at all and that's fine
Details? The news item is accurate enough in my opinion, rest is just bikeshedding |
huh? come again? |
I mean pr0n of course. |
This just mean that udev is very sexy |
|
| Back to top |
|
|
DaggyStyle
Watchman
Joined: 22 Mar 2006
Posts: 5945
|
| Posted: Thu Jan 24, 2013 8:06 am Post subject: |
|
|
| devurandom wrote: | | ssuominen wrote: | | DaggyStyle wrote: | | ssuominen wrote: | CONFIG_DEVTMPFS_MOUNT=y can be used but is not mandatory; the udev-mount init script will take care of mounting it if CONFIG_DEVTMPFS_MOUNT=y is missing
CONFIG_DEVTMPFS=y is the mandatory one
The news item means /dev, not /dev/shm or /dev/porn, just /dev, most people don't have such line at all and that's fine
Details? The news item is accurate enough in my opinion, rest is just bikeshedding |
huh? come again? |
I mean pr0n of course. |
This just mean that udev is very sexy |
udev is very sexy as Lennard Pottering is very sexy.
_________________
Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein |
|
| Back to top |
|
|
Odysseus
Apprentice
Joined: 23 Jun 2004
Posts: 250
Location: Miami, FL. I miss San Francisco!!!
|
| Posted: Thu Jan 24, 2013 9:37 am Post subject: |
|
|
Thanks to all for the rapid responses! I just got home from work and was quite pleasantly surprised to see so many of them. This is one of the reasons I love Gentoo, the community is knowledgeable and helpful (provided it isn't an obvious question that's been answered numerous times) 
Anyhow I feel better now that my system remains usable and relatively stable (as stable as one can be when running ~amd64 and other bits of leading edge software like gcc-4.7.2 and glibc-2.17). 
I think I'll wait a bit before tackling the network naming stuff until it's been in use for a while and I'm convinced the applications in my system are up to the task.
Thanks again everyone!
Ciao |
|
| 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
|
|
Kernel & Hardware
