| View previous topic :: View next topic |
| Author |
Message |
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
 Posted: Mon Mar 19, 2012 12:36 pm Post subject: |
 |
|
| DaggyStyle wrote: | | imho this is completely stupid, is there any way to avoid this and still update udev |
Well that's what motivated this thread (wanting udev to start after localmount iff we know we don't have any esoteric devices which need setting by udev before localmount can start) but I have no idea how things will work out going into the future. One would hope the udev developers would settle for "all partitions are mounted before starting udev OR initramfs is mounted" as a requirement, vs strict "initramfs is mounted" but I can't be overly optimistic.
<rant>
I can just imagine the "systemd needs this" argument coming, in the same way as it has been pushed in the kernel to apparently justify ignoring portability concerns ie: building a box without cgroups and associated paraphernalia (concerns raised in that regard that I've read simply get no response.) And ofc, it'll again be a mess created by the software that needs it, which everyone else will spend years picking up the pieces for. Until the next round of "ooh.. shiny."
</rant>
| Quote: | | 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. |
That's a good point; you might want to raise it in this topic (although I wouldn't go calling anyone lazy - just mention it as overlooked ;) |
|
| Back to top |
|
 |
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6227
Location: Dallas area
|
| Posted: Mon Mar 19, 2012 1:12 pm Post subject: |
|
|
| Trog Dog wrote: | | 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. |
I fortunately left /usr and /var on /, I did split off /boot, /usr/portage, /home, /usr/local and my data directories but those typically don't cause problems.
_________________
UM780, 6.12 zen kernel, gcc 13, openrc, wayland |
|
| Back to top |
|
|
Trog Dog
Apprentice
Joined: 04 Aug 2007
Posts: 282
|
| Posted: Mon Mar 19, 2012 2:44 pm Post subject: |
|
|
| Anon-E-moose wrote: |
I fortunately left /usr and /var on /, I did split off /boot, /usr/portage, /home, /usr/local and my data directories but those typically don't cause problems. |
This is looking more attractive after another failed attempt - I'll try again tomorrow
_________________
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: 5941
|
| Posted: Mon Mar 19, 2012 3:34 pm Post subject: |
|
|
| steveL wrote: | | DaggyStyle wrote: | | imho this is completely stupid, is there any way to avoid this and still update udev |
Well that's what motivated this thread (wanting udev to start after localmount iff we know we don't have any esoteric devices which need setting by udev before localmount can start) but I have no idea how things will work out going into the future. One would hope the udev developers would settle for "all partitions are mounted before starting udev OR initramfs is mounted" as a requirement, vs strict "initramfs is mounted" but I can't be overly optimistic.
<rant>
I can just imagine the "systemd needs this" argument coming, in the same way as it has been pushed in the kernel to apparently justify ignoring portability concerns ie: building a box without cgroups and associated paraphernalia (concerns raised in that regard that I've read simply get no response.) And ofc, it'll again be a mess created by the software that needs it, which everyone else will spend years picking up the pieces for. Until the next round of "ooh.. shiny."
</rant>
| Quote: | | 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. |
That's a good point; you might want to raise it in this topic (although I wouldn't go calling anyone lazy - just mention it as overlooked  |
major overlooked... bordering in laziness..
_________________
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: Tue Mar 20, 2012 12:22 pm Post subject: |
|
|
Ok, after an unsuccessful attempt last night (box booted but I don't believe /usr did) - tonight I tried, but only applied the 3 patches, did not modify /etc/fstab (lvm partitions are still referenced as /dev/vg...) didn't modify any runlevels - and this box boots fine and as far as I can tell everything works. I'm going to try this process on another box.
EDIT: Confirmed on second box - set CONFIG_DEVTMPFS in kernel and recompiled, reboot, ok, applied 3 patches - reboot all ok but for gnome-terminal - ssh'd into box set CONFIG_DEVTMPFS_MOUNT in kernel and recompiled, reboot, ok.
did not modify fstab or runlevels
AFAICT both boxes are working correctly
_________________
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: 5941
|
| Posted: Tue Mar 20, 2012 6:58 pm Post subject: |
|
|
| Trog Dog wrote: | Ok, after an unsuccessful attempt last night (box booted but I don't believe /usr did) - tonight I tried, but only applied the 3 patches, did not modify /etc/fstab (lvm partitions are still referenced as /dev/vg...) didn't modify any runlevels - and this box boots fine and as far as I can tell everything works. I'm going to try this process on another box.
EDIT: Confirmed on second box - set CONFIG_DEVTMPFS in kernel and recompiled, reboot, ok, applied 3 patches - reboot all ok but for gnome-terminal - ssh'd into box set CONFIG_DEVTMPFS_MOUNT in kernel and recompiled, reboot, ok.
did not modify fstab or runlevels
AFAICT both boxes are working correctly |
afaik, CONFIG_DEVTMPFS is no good, I'd wait for neddy to come and comment on this.
btw, what three patches?
_________________
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
|
|
| Back to top |
|
|
hujuice
Guru
Joined: 16 Oct 2007
Posts: 347
Location: Nicosia, Cyprus
|
| Posted: Wed Mar 21, 2012 8:49 am Post subject: |
|
|
| Trog Dog wrote: | | AFAICT both boxes are working correctly |
You mean that you did the trick with >=udev-181?
HUjuice
_________________
Who hasn't a spine, should have a method.
Chi non ha carattere, deve pur avere un metodo. |
|
| Back to top |
|
|
Trog Dog
Apprentice
Joined: 04 Aug 2007
Posts: 282
|
| Posted: Wed Mar 21, 2012 10:50 am Post subject: |
|
|
| hujuice wrote: | | Trog Dog wrote: | | AFAICT both boxes are working correctly |
You mean that you did the trick with >=udev-181?
HUjuice |
No, 171-r5 (as per the first post in this thread). Once I'm confident that both boxes are working correctly I will try with 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 |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Mar 21, 2012 4:21 pm Post subject: |
|
|
| Trog Dog wrote: | Ok, after an unsuccessful attempt last night (box booted but I don't believe /usr did) - tonight I tried, but only applied the 3 patches, did not modify /etc/fstab (lvm partitions are still referenced as /dev/vg...) didn't modify any runlevels - and this box boots fine and as far as I can tell everything works. I'm going to try this process on another box.
EDIT: Confirmed on second box - set CONFIG_DEVTMPFS in kernel and recompiled, reboot, ok, applied 3 patches - reboot all ok but for gnome-terminal - ssh'd into box set CONFIG_DEVTMPFS_MOUNT in kernel and recompiled, reboot, ok.
did not modify fstab or runlevels
AFAICT both boxes are working correctly |
w00t! that's great Trog Dog :-)
Can I check, when you say you "didn't modify any runlevels" do you mean that udev is still in sysinit? If so, it'll be starting before localmount (which is in boot; rc-update show), which means you're not actually using the new setup: to be sure all devices started by udev are ok, now and into the future, udev scripts must be able to access /usr (for pci-ids and hwdb, iirc) and afaict, technically there's no knowing what other partitions they might access (or at least, that's the new position.) It's a safe bet they're not going to need /home, /tmp or anything like /usr/{src,portage} but they might for example, install into /opt, or need access to /var.
I have to admit I don't understand how pushing the resolution of the chicken-and-egg nature of, say, needing a udev-configured device to access /usr, while also needing that same partition to run the udev initscripts, is any easier to handle without root (assuming ofc that the root device doesn't need initialising in userspace- which would be the traditional reason to need an initrd.) I guess the reasoning is that they have to support the initrd, and they don't want to support the traditional method, which I can understand. It's just a shame imo; if they'd had a similar process in terms of making such massive changes to user-space/ system-administration that Gentoo has for GLEPs, I really don't believe they'd have got through it, and scripts that were playing silly buggers would have been sorted out (perhaps by conceding pci-ids and hwdb should be installed to root if the distro/ user so configured it, and either redoing the 2-phase sequence they tried to implement before, or just insisting that device-initialisation be installed to root. After all, if it's going to be run by udev during sysinit, it'll be run as root.)
wrt lvm, what version are you on? I was running lvm2-2.02.73 for over a year, and everything was fine with udev; it was when I upgraded to 2.02.88 that things went awry; so if it messes up you know what to do: change fstab to use /dev/mapper/vg-lv as opposed to /dev/vg/lv. If you check /etc/init.d/udev in the populate_dev() function, you'll see the following comment:
| Code: |
# we can speed up booting under these conditions:
# * using devtmpfs so kernel creates device nodes for us
# * only using kernel created device nodes at boot
# (in /etc/fstab and elsewhere)
|
/dev/mapper is a kernel-created node, and prior to the upgrade to 2.02.88, lvm was creating the /dev/vg/lv nodes in its startup. The lvm initscript still passes the parameter in /lib/rcscripts/addons/lvm-start.sh -- it runs /sbin/vgscan --mknodes but on my machine at least, that doesn't set up the nodes (or maybe they get overwritten when udev starts, I'm not sure.) I was having to reboot and run the scan manually, which gave me a warning for each logical volume, about how udev was supposed to have made the nodes. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Mar 21, 2012 4:28 pm Post subject: |
|
|
| DaggyStyle wrote: | | afaik, CONFIG_DEVTMPFS is no good |
No, that's incorrect: udev will now require that setting, going forwards (it was mentioned on gentoo-dev ml by Greg KH sometime in last few months.)
You can see that it's good anyway by the comment I quoted above from /etc/init.d/udev
Given that, I think it's wise to use the _MOUNT option as well, even if udev-mount does always mount it for you- never know, for example, when you'll be booting into a rescue shell; at that point your lvm drives will still come up if you have the _MOUNT option and are using kernel-device names (/dev/mapper/vg-lv) in fstab.
(That's lvm only, NFC about md-raid, haven't used it ;) |
|
| Back to top |
|
|
Trog Dog
Apprentice
Joined: 04 Aug 2007
Posts: 282
|
| Posted: Thu Mar 22, 2012 11:34 am Post subject: |
|
|
| steveL wrote: |
w00t! that's great Trog Dog 
Can I check, when you say you "didn't modify any runlevels" do you mean that udev is still in sysinit? If so, it'll be starting before localmount (which is in boot; rc-update show), which means you're not actually using the new setup: to be sure all devices started by udev are ok, now and into the future, udev scripts must be able to access /usr (for pci-ids and hwdb, iirc) and afaict, technically there's no knowing what other partitions they might access (or at least, that's the new position.) It's a safe bet they're not going to need /home, /tmp or anything like /usr/{src,portage} but they might for example, install into /opt, or need access to /var. |
Maybe not so great 
| Code: | boinc | default
bootmisc | boot
consolefont | boot
consolekit | default
dbus | default
devfs | sysinit
device-mapper | boot
dmesg | sysinit
fsck | boot
hostname | boot
hwclock | boot
keymaps | boot
killprocs | shutdown
local | default nonetwork
localmount | boot
lvm | boot
modules | boot
mount-ro | shutdown
mtab | boot
net.eth0 | default
net.lo | boot
netmount | default
ntp-client | default
ntpd | default
procfs | boot
root | boot
samba | default
savecache | shutdown
sshd | default
swap | boot
sysctl | boot
syslog-ng | default
termencoding | boot
udev | sysinit
udev-postmount | default
urandom | boot
vixie-cron | default
xdm | default |
| Quote: |
wrt lvm, what version are you on? I was running lvm2-2.02.73 for over a year, and everything was fine with udev; it was when I upgraded to 2.02.88 that things went awry; so if it messes up you know what to do: change fstab to use /dev/mapper/vg-lv as opposed to /dev/vg/lv. If you check /etc/init.d/udev in the populate_dev() function, you'll see the following comment:
|
| Code: | | [ebuild R ] sys-fs/lvm2-2.02.88 USE="lvm1 readline static static-libs (-clvm) (-cman) (-selinux)" 0 kB |
I'll try messing around with the runlevels to see what works and what doesn't.
EDIT: the problem was fstab I used /dev/mapper/vg/lv instead of /dev/mapper/vg-lv correcting this errror I was able to make the runlevel changes and both boxes are AFAICT running normally
| Code: | boinc | default
bootmisc | boot
consolefont | boot
consolekit | default
dbus | default
devfs | sysinit
device-mapper | boot
dmesg | sysinit
fsck | boot
hostname | boot
hwclock | boot
keymaps | boot
killprocs | shutdown
local | default nonetwork
localmount | boot
lvm | boot
modules | boot
mount-ro | shutdown
mtab | boot
net.eth0 | default
net.lo | boot
netmount | default
ntp-client | default
ntpd | default
procfs | boot
root | boot
samba | default
savecache | shutdown
sshd | default
swap | boot
sysctl | boot
sysfs | sysinit
syslog-ng | default
termencoding | boot
udev | boot
udev-mount | sysinit
udev-postmount | default
urandom | boot
vixie-cron | default
xdm | default |
_________________
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
Last edited by Trog Dog on Thu Mar 22, 2012 1:46 pm; edited 1 time in total |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Mar 22, 2012 1:37 pm Post subject: |
|
|
| Trog Dog wrote: | | I'll try messing around with the runlevels to see what works and what doesn't. |
Yeah- make sure you use /dev/mapper/vg-lv in fstab as the first thing (and test it boots okay), as you need that before you put udev in boot runlevel. (Or you'll need to boot with init=/bin/bash to edit fstab, or switch runlevels for udev and edit /etc/conf/udev to revert. If you do end up in a rescue shell and need lvm drives, use vgscan --mknodes before mount.)
Don't forget to add sysfs and udev-mount to sysinit -- those can always stay there, it doesn't hurt them being there when udev is in sysinit (the default).
Whenever udev is in boot, you must have initramfs="no" in /etc/conf.d/udev, and whenever it's in sysinit, you must have initramfs="yes" (or comment the line out.)
That's what makes things a bit tricky, as you need to edit the file whenever you switch udev runlevel, or you'll end up back in a rescue shell. |
|
| Back to top |
|
|
Trog Dog
Apprentice
Joined: 04 Aug 2007
Posts: 282
|
| Posted: Thu Mar 22, 2012 1:49 pm Post subject: |
|
|
| steveL wrote: | | Trog Dog wrote: | | I'll try messing around with the runlevels to see what works and what doesn't. |
Yeah- make sure you use /dev/mapper/vg-lv in fstab as the first thing (and test it boots okay), as you need that before you put udev in boot runlevel. (Or you'll need to boot with init=/bin/bash to edit fstab, or switch runlevels for udev and edit /etc/conf/udev to revert. If you do end up in a rescue shell and need lvm drives, use vgscan --mknodes before mount.)
Don't forget to add sysfs and udev-mount to sysinit -- those can always stay there, it doesn't hurt them being there when udev is in sysinit (the default).
Whenever udev is in boot, you must have initramfs="no" in /etc/conf.d/udev, and whenever it's in sysinit, you must have initramfs="yes" (or comment the line out.)
That's what makes things a bit tricky, as you need to edit the file whenever you switch udev runlevel, or you'll end up back in a rescue shell. |
Cheers Steve - I was using /dev/mapper/vg/lv not /dev/mapper/vg-lv [doh  ]
_________________
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 |
|
|
dalek
Veteran
Joined: 19 Sep 2003
Posts: 1353
Location: Mississippi USA
|
| Posted: Thu Mar 22, 2012 6:10 pm Post subject: |
|
|
| Trog Dog wrote: | | Cheers Steve - I was using /dev/mapper/vg/lv not /dev/mapper/vg-lv [doh ] |
I used to do this a lot. Allow me to introduce you to tab completion. I swear, if my tab key were to stop working, I couldn't find anything. 
_________________
My rig: Gigabyte GA-970A-UD3P mobo, AMD FX-8350 Eight-Core CPU, ZALMAN CNPS10X Performa CPU cooler,
G.SKILL 32GB DDR3 PC3 12800 Memory Nvidia GTX-650 video card LG W2253 Monitor
60TBs of hard drive space using LVM
Cooler Master HAF-932 Case |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Thu Mar 22, 2012 8:21 pm Post subject: |
|
|
Heh, glad it's sorted, Trog.
FWIW, update (use git ebuild) has an ABI warning on udev-181, so it won't allow an automatic upgrade (you'd have to specifically use update udev.) |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Apr 04, 2012 11:36 am Post subject: |
|
|
Wrt udev-181 and above, I read that the only difference is that there is no longer support for retrying devices that failed first time around (eg if a file needed is on /usr which wasn't mounted) which is what udev-postmount did. With our patches, that's not an issue, as we have localmount up before udev. I haven't tried it yet- not going to til it goes stable, but for anyone who's going to upgrade, this method should work (though you'll have to take care with the patch. If anyone has copies of the udev and udev-mount scripts for 181+ then please post them and I'll do a patch if you've found it hard, or even better post working patches ;-) Anyone trying unstable udev in a VM?
Oh, there's also this method which is an earlymount init script that mounts selected partitions before udev, though it appears to have some teething troubles. I'm going to stick with our method, as I prefer being able to start after localmount and feel better knowing that it and all of its dependencies, whatever they might be going into the future, are taken care of, since I know I don't need any udev-configured devices to get local drives mounted on my machines. (This is also where udev used to start in the boot sequence.) It also makes fsck a lot simpler (ie it works in the standard manner.) |
|
| Back to top |
|
|
krenshala
Tux's lil' helper
Joined: 28 Jan 2006
Posts: 85
Location: Austin TX, NorAm, Sol III
|
| Posted: Sat Apr 07, 2012 7:34 am Post subject: |
|
|
Thank you for this thread. I was planning to (eventually) find the time to move /usr back to / with /usr/portage keeping what is now that partition when I saw this. I don't want /var in /, however, so I guess I'm going to have to do this or an initrd ... and I really don't want to do an initrd if I can help it.
Now if only I can find the time to sit down and get this working on my systems.
_________________
krenshala
:wq |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Apr 09, 2012 3:59 pm Post subject: |
|
|
| krenshala wrote: | | Thank you for this thread. I was planning to (eventually) find the time to move /usr back to / with /usr/portage keeping what is now that partition when I saw this. I don't want /var in /, however, so I guess I'm going to have to do this or an initrd ... and I really don't want to do an initrd if I can help it. |
Hi krenshala; yeah that's exactly how I felt about it-- I've never needed an initrd since I have what I need (and only what I need) to mount local filesystems compiled into the kernel, and I don't have any encryption, just non-root lvm and a load of partitions.
| Quote: | | Now if only I can find the time to sit down and get this working on my systems. |
Well let us know how you get on/ if you need any help. I'm in #friendly-coders on chat.freenode.net when I'm online, if you need live assistance. (My nick is 'igli'.)
Make sure you follow instructions in first post closely, particularly about getting everything you need in the correct runlevels: sysfs and udev-mount added to sysinit, udev deleted from sysinit and added to boot. udev must be in boot runlevel whenever you have initramfs="no" in /etc/conf.d/udev. Don't do that first though!
I'd apply the patches first, without initramfs added to the config file, just to make sure they boot clean. Then, set up CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT, and change /dev/vg/lv to /dev/mapper/vg-lv for any lvm volumes in /etc/fstab and make sure the system boots with those. Then you can try adding the parameter and changing udev's runlevel.
You can leave sysfs and udev-mount in sysinit: it's when you change udev's runlevel that you must have initramfs correct (="no" when udev is in boot, ="yes" or unset when udev is in sysinit.) |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9340
|
| Posted: Sat Apr 28, 2012 12:13 pm 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.) |
Are you 100% sure? I haven't read about this anywhere else yet, all the talks is about /usr only.
EDIT: (taken from L.P. himself)
| Quote: | Lennart Poettering 24.04.2012 +4
you are mistaken, we support /var split off just fine, without initrd. Same for /home. These splits make a lot of sense and are not cumbersome to implement, hence we support them. |
|
|
| Back to top |
|
|
DaggyStyle
Watchman
Joined: 22 Mar 2006
Posts: 5941
|
| Posted: Sat Apr 28, 2012 5:19 pm Post subject: |
|
|
| genstorm wrote: | | 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.) |
Are you 100% sure? I haven't read about this anywhere else yet, all the talks is about /usr only.
EDIT: (taken from L.P. himself)
| Quote: | Lennart Poettering 24.04.2012 +4
you are mistaken, we support /var split off just fine, without initrd. Same for /home. These splits make a lot of sense and are not cumbersome to implement, hence we support them. |
|
so according to you, I can upgrade without any problems?
_________________
Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein |
|
| Back to top |
|
|
asturm
Developer
Joined: 05 Apr 2007
Posts: 9340
|
| Posted: Sat Apr 28, 2012 5:45 pm Post subject: |
|
|
| Don't quote me on it yet, I really can't tell unless I've tried it myself. |
|
| Back to top |
|
|
dalek
Veteran
Joined: 19 Sep 2003
Posts: 1353
Location: Mississippi USA
|
| Posted: Sat Apr 28, 2012 6:58 pm Post subject: |
|
|
I follow -dev mailing list pretty well. Right now, /var is supported. That may change in the future tho. That is what is being said on -dev. At some point, /var may be needed like /usr is about to be needed.
Me and what I see on my box; I see errors that I think are because /var is not mounted. The complaints are that it can't write the PID files in /var. I wish I could tell dracut to mount and /usr and /var then let the system switch_root and boot. My system does boot since the services do start later on. So, this is not a problem right now.
Your mileage may vary. I would have a binpkg of the older udev, the instructions on how to chroot and a bootable CD/DVD/USB stick thingy if it were me. It may ward off the evil broken OS spirits. 
_________________
My rig: Gigabyte GA-970A-UD3P mobo, AMD FX-8350 Eight-Core CPU, ZALMAN CNPS10X Performa CPU cooler,
G.SKILL 32GB DDR3 PC3 12800 Memory Nvidia GTX-650 video card LG W2253 Monitor
60TBs of hard drive space using LVM
Cooler Master HAF-932 Case |
|
| Back to top |
|
|
DaggyStyle
Watchman
Joined: 22 Mar 2006
Posts: 5941
|
| Posted: Sun Apr 29, 2012 5:47 am Post subject: |
|
|
| dalek wrote: | I follow -dev mailing list pretty well. Right now, /var is supported. That may change in the future tho. That is what is being said on -dev. At some point, /var may be needed like /usr is about to be needed.
Me and what I see on my box; I see errors that I think are because /var is not mounted. The complaints are that it can't write the PID files in /var. I wish I could tell dracut to mount and /usr and /var then let the system switch_root and boot. My system does boot since the services do start later on. So, this is not a problem right now.
Your mileage may vary. I would have a binpkg of the older udev, the instructions on how to chroot and a bootable CD/DVD/USB stick thingy if it were me. It may ward off the evil broken OS spirits.
|
no dracut here, I'm trying to keep my system junk free.
_________________
Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein |
|
| Back to top |
|
|
dalek
Veteran
Joined: 19 Sep 2003
Posts: 1353
Location: Mississippi USA
|
| Posted: Sun Apr 29, 2012 6:11 pm Post subject: |
|
|
| DaggyStyle wrote: | | no dracut here, I'm trying to keep my system junk free. |
The info I was trying to provide wasn't about dracut. I would suspect that you would get the same errors if you used any other init thingy, unless you had it mount /var as well as /usr before switching root.
The point was, /var is fine without a init thingy, right now. It may change soon tho since /var has been discussed and I see the errors on my machine already. I have all but /boot and / on LVM.
Also, there is talk of moving /bin and /sbin to /usr/*bin as links in the future. In other words, /bin and /sbin doesn't contain anything, it is just a link to the /usr bins. At that point, everything will be in /usr. I'm not sure what sort of init thingy we will all need then.
This, to me, is starting to look a LOT like winders. Next it will be C: for the hard drive. 
_________________
My rig: Gigabyte GA-970A-UD3P mobo, AMD FX-8350 Eight-Core CPU, ZALMAN CNPS10X Performa CPU cooler,
G.SKILL 32GB DDR3 PC3 12800 Memory Nvidia GTX-650 video card LG W2253 Monitor
60TBs of hard drive space using LVM
Cooler Master HAF-932 Case |
|
| 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
|
|
Unsupported Software
