Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
HOWTO: udev, sep /usr, no initramfs. eudev:3.1.5 rc:0.23.2
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6  Next  
Reply to topic    Gentoo Forums Forum Index Unsupported Software
View previous topic :: View next topic  
Author Message
DaggyStyle
Watchman
Watchman


Joined: 22 Mar 2006
Posts: 5909

PostPosted: Sun Apr 29, 2012 7:44 pm    Post subject: Reply with quote

dalek wrote:

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.


same here, so if you see errors, than something is not good.
_________________
Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein
Back to top
View user's profile Send private message
dalek
Veteran
Veteran


Joined: 19 Sep 2003
Posts: 1353
Location: Mississippi USA

PostPosted: Sun Apr 29, 2012 10:29 pm    Post subject: Reply with quote

The errors are not init related tho. The errors is because /var is on a separate partition. If I built a init thingy from scratch and only mounted /usr then did the switch_root, I would get the same errors. I know this because I got the errors even when /usr was on /.

The reason I mentioned it is about the question related to /var. Right now it works without a init thingy and /var on a separate partition. In the future that may change. Given the errors, it may be sooner than some think. The reason I run into this is because /var is also on LVM now. LVM is complaining, not the init thingy or udev.

I hope that is clear. This is not one of my better days. :oops:

:D :D
_________________
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
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Mon Apr 30, 2012 5:29 pm    Post subject: Reply with quote

dalek wrote:
The errors are not init related tho. The errors is because /var is on a separate partition... The reason I run into this is because /var is also on LVM now. LVM is complaining, not the init thingy or udev.

Sounds like the lvm2 changes TrogDog and I ran into as well (second half of post.)

genstorm wrote:
Are you 100% sure? I haven't read about this anywhere else yet, all the talks is about /usr only.

Yes, it was discussed on gentoo-dev a while back, in the context of alsa initscript saving state in /var, and alsa started up by udev in response to finding a sound-card. While I'm not sure if alsa still does that, we were told that there is no way to stop third-party device-startup scripts requiring a file effectively anywhere (the second url gives other examples.)

Lennart Poettering wrote:

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.

It's funny that he still can't get past /usr split "not making sense" when the RedHat move of everything to /usr now touts its benefits.

It's u-turns like that (another one is how dbus requires xml config files: I mean, really? and having finally learnt it's not a good idea, systemd doesn't use them) that make one doubt the experience of those involved. Another recent example is their insane usage of binary logfiles.
Linus wrote:
this is just pure and utter shit.. It's pure crap.. the kind of thinking and code that just makes me go "No way, not today, not ever". It's stupid.

The thing is, they can't get those ideas to fly in kernel-space, as core devs have veto over their work. There is no such control in user-space: most kernel devs don't really care what happens in user-space; in fact they plan for it to do crazy things, or their OS is not robust. The only strict rule is not to break an ABI exported to user-space. These changes are far more invasive (in terms of their consequences for other people's work) and throw away 50 years of design principles.
Linus wrote:
You made the statement that you want to get away from 30 years of history, but the fact is, "30 years of history" is a damn good argument for "that thing worked".

I'm not saying they haven't done anything worthwhile, nor learnt anything in the last few years. They just really don't get Unix principles, imo, and see them as needless restrictions rather than useful discipline. I know the nature of voluntary development (those who write the code, decide what it does) but still find it amazing that what I see as a bunch of students can get away with such far-reaching, ill thought-out changes across a *nix ecosystem, especially given the amount of money in Linux-based corporations.

I also believe that there is a culture of "not worrying about it" which becomes complacency. In the case of Linux development, the core GNU make tool does expansion of library dependencies before any command sees them, which means if a lib happens to exist on the host system, or more relevantly in /usr, it'll get used irrespective of any -L parameters to ld. When I read about that, I suddenly understood why you get "random" linkage. That clearly leads developers not to worry about it, since they can't figure out where it comes from nor how to change it (it's GNU-specific and not very well-known), and it's a distro or installer problem, assuming any sort of portability. So we get to packagers deciding "it's easier just to assume that /usr is available" which leads to "split /usr is cumbersome."

IMO if there hadn't been such a long history of unwanted linkage to /usr, there never would have been this culture of just assuming /usr in distros, nor the desire to get away from "worrying about it."
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Mon Apr 30, 2012 5:53 pm    Post subject: Reply with quote

please provide a link where I can look up some more but just your selection of a setence ...
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Mon Apr 30, 2012 8:58 pm    Post subject: Reply with quote

eh? I provided the link above the quotes.
Back to top
View user's profile Send private message
dalek
Veteran
Veteran


Joined: 19 Sep 2003
Posts: 1353
Location: Mississippi USA

PostPosted: Mon Apr 30, 2012 9:24 pm    Post subject: Reply with quote

steveL wrote:
dalek wrote:
The errors are not init related tho. The errors is because /var is on a separate partition... The reason I run into this is because /var is also on LVM now. LVM is complaining, not the init thingy or udev.

Sounds like the lvm2 changes TrogDog and I ran into as well (second half of post.)


This I think fixes it according to a post on the mailing list:

Quote:
The secret, as Neil reminded us, is to change /etc/lvm/lvm.conf to read:

Code:
locking_dir = "/run/lock/lvm"


I have not tested it on my rig but others posted that it fixed their problem. I need to try that on mine but my problem is that I rarely reboot. Gotta love Linux. :lol:

All that is for folks that use dracut to build the init thingy. May work for others tho.

:D :D
_________________
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
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Mon Apr 30, 2012 10:16 pm    Post subject: Reply with quote

dalek wrote:
I have not tested it on my rig but others posted that it fixed their problem. I need to try that on mine but my problem is that I rarely reboot. Gotta love Linux.

Heh indeed. Thanks for reminding me about that file though, there's a few udev-related settings in there which could be useful for our setup:
Code:

# default settings
devices {
  # we should be able to change this:
  obtain_device_list_from_udev = 1
  # since these are set:
  sysfs_scan = 1
  md_component_detection = 1
}
activation {
  # wait for notification from udev
  udev_sync = 1
  # set to 0 to get lvm to manage /dev nodes and symlinks
  udev_rules = 1
}

Basically I think we could set the 3 udev-related ones to 0 (although I imagine the first is auto-detected during the scan, since udev is not running.) The last one looks the most promising in terms of our lost /dev/vg/lv links though we still have /dev/mapper/vg-lv (which is what makes me think it detects udev is not running.)

Since I don't run mdadm, I might as well set md_component_detection to 0 as well, though in general it's safest to leave it on.
Quote:
All that is for folks that use dracut to build the init thingy. May work for others tho.

Ah OK; yeah it's all useful info :-)
Back to top
View user's profile Send private message
dalek
Veteran
Veteran


Joined: 19 Sep 2003
Posts: 1353
Location: Mississippi USA

PostPosted: Mon Apr 30, 2012 10:44 pm    Post subject: Reply with quote

For me, it's about more than one way to skin a cat. Some find it useful to kill the cat first. Others like to get scratched a little bit first. :lol: We learn either way.

If one fix doesn't work, try another. Eventually one or a combination of two or maybe all three will fix it. Then again, I just put my sledge hammer beside my case and things tend to at least try harder. I did use a past rig for target practice once. It's amazing what 00 buckshot will do to a puter. It's a serious attitude 'adjustment' for sure.

Then again, it wouldn't boot up after that. 8O :twisted:

:D :D
_________________
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
View user's profile Send private message
krenshala
Tux's lil' helper
Tux's lil' helper


Joined: 28 Jan 2006
Posts: 85
Location: Austin TX, NorAm, Sol III

PostPosted: Fri May 04, 2012 1:13 am    Post subject: Reply with quote

So, haven't had time to mess with this until now, until a couple days ago when I rebooted and suddenly stuff didn't work. From what I saw in the logs, it looks like despite having udev 171 and things working previously, my system wasn't mounting more than the root partition at boot. ;(

I've followed all the steps in the first post (didn't even have to change the kernel settings, as I already had them), recompiled the kernel (to fix the nVidia driver bitching about a mis-match), and now I'm about to reboot.

For the record, steveL, your instructions are very easy to follow.

I'll update after this boot to see if it fixes things for me. ;)

[edit] Well, this has improved things. I get far enough into the system where I can manually mount the partitions, which I couldn't do before using your instructions. Having to update this post from my other (currently working) system, however.

Now to figure out why the system claims it can't find /dev/sda to mount my listed partitions, but I can manually mount them after logging in.

What I get now is a message that "fsck.ext3: no such file or directory trying to open /dev/sda3", which is / that its booting from, and "mount: special device /dev/sda5 does not exist", followed by the same for sda6, 7, 8, 9 and 10 (which are /tmp, /usr, /var, /var/log, /var/www and /home, respectively). A few other things bitch about not being able to run, obviously due to /usr not being mounted, then I get a login prompt. When I log in, I'm able to mount all the partitions just fine.

Could being on kernel 2.6.39 be part of the problem? The system I'm on now is running 3.2.1, iirc.

/sigh, and no more time to work on this tonight.
_________________
krenshala
:wq
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri May 04, 2012 11:39 am    Post subject: Reply with quote

krenshala wrote:
I rebooted and suddenly stuff didn't work. From what I saw in the logs, it looks like despite having udev 171 and things working previously, my system wasn't mounting more than the root partition at boot.

That sounds like you updated some software prior to the reboot. I'd start by running dispatch-conf or etc-update to make sure you haven't missed any config updates, then try a reboot.

Careful with any changes to udev initscripts! If you get any conflicts there and mess things up, the original scripts are in /usr/portage/distfiles/udev-gentoo-scripts-7.tar.bz2 for udev-171. (I never got anywhere with emerge --config and --noconfmem on my first upgrade.)

Then you could try checking /var/log/emerge.log to see what you built recently. (I don't use any log-viewers atm so can't recommend one; I just use less and hit End ;)

Quote:
I've followed all the steps in the first post (didn't even have to change the kernel settings, as I already had them), recompiled the kernel (to fix the nVidia driver bitching about a mis-match), and now I'm about to reboot.

Hmm that nvidia driver mismatch seems odd, if you hadn't upgraded the kernel. Upgrading the driver package itself compiles against current /usr/src/linux so shouldn't be an issue; you sure that link is correct? (ls -l /usr/src/linux)

Quote:
I get far enough into the system where I can manually mount the partitions, which I couldn't do before using your instructions.
..the system claims it can't find /dev/sda to mount my listed partitions, but I can manually mount them after logging in.

What I get now is a message that "fsck.ext3: no such file or directory trying to open /dev/sda3", which is / that its booting from, and "mount: special device /dev/sda5 does not exist", followed by the same for sda6, 7, 8, 9 and 10 (which are /tmp, /usr, /var, /var/log, /var/www and /home, respectively). A few other things bitch about not being able to run, obviously due to /usr not being mounted, then I get a login prompt. When I log in, I'm able to mount all the partitions just fine.

Hmm that's odd: it sounds like the device nodes aren't there, and are getting setup by udev instead when it does finally run. This post earlier in the thread might be apposite, but afaik the kernel should be setting the node up for you with DEVTMPFS_MOUNT. Also, I'm not sure how udev could be running if rootfs is not being mounted.

I'd try booting with init=/bin/bash (added to end of kernel bootline; hit 'e' in grub to edit it) to see what nodes are available. Though this will probably do exactly the same as you currently have, at least you'll be up with the nodes the kernel makes available in /dev and can check them yourself. If mount -a works there, I'm at a loss as to what's going on (I think I am anyway: can you tell? ;) Only things that come to mind are persistent naming (eg if you have a USB drive plugged in, it used to be the case that it could appear before local drives as sda, not sure if it still is) but you're able to mount via sda once system has come up so that seems wrong, and I know udevadm settle is about, but I don't see how that applies, as kernel module should take care of that.

You do have the modules for the disk-controller as built-ins to the kernel (Y), not as modules (M), right?
Quote:
Could being on kernel 2.6.39 be part of the problem? The system I'm on now is running 3.2.1, iirc.

Hmm not sure: it's worth a try. After all, there are bugfixes to kernel all the time, and I've been on 3.2.1 for a while as well (I also only run stable kernels :)

You should be running with rc-update del xdm default till you get this sorted in any case, so you shouldn't need to worry about nvidia stuff til your system is back.
Quote:
For the record, steveL, your instructions are very easy to follow.

Thanks, krenshala :D
Back to top
View user's profile Send private message
krenshala
Tux's lil' helper
Tux's lil' helper


Joined: 28 Jan 2006
Posts: 85
Location: Austin TX, NorAm, Sol III

PostPosted: Fri May 04, 2012 1:33 pm    Post subject: Reply with quote

I checked for missing config updates first thing (when chrooted from the LiveDVD last night) and that wasn't the problem. I also verified I am still using udev 171 (I am).

And yeah, nVidia shouldn't have been complaining, but it was stating it was using 295.xx when the kernel was compiled for 290.xx (don't remember the exact values right now). It didn't take long for a zero change kernel recompile, however, so I didn't worry about that part too much (a minor annoyance compared to the boot process failing, after all). ;)

And yes, I have only a single kernel module - the nVidia driver. Everything else is compiled into my kernel, which is my preference and the primary reason I don't see the need for an initrd being used on my systems. :D

I guess I'll just have to double check all the steps when I get home from work tonight. If nothing else, I'm learning more about administrating a linux box. :roll:

[edit] so, I found a typo in the udev-mount script ( parenthesis instead of braces), but correct that didn't really change much. I've decided to just try emerge --emptytree system from a chrooted environment to see if that unbreaks my system. it can't make it worse, thats for sure. i'll stop cluttering this thread with more on my systems until i'm actually doing something relevent. ;) Thank you again for the help, though. :D
_________________
krenshala
:wq
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Thu May 10, 2012 3:03 pm    Post subject: Reply with quote

krenshala wrote:
Now to figure out why the system claims it can't find /dev/sda to mount my listed partitions, but I can manually mount them after logging in.

I really would ask on IRC, in #gentoo on chat.freenode.net: treat this as a fresh install, and you're manually configuring your kernel to allow you to move from chroot to booting into console. Once you can get root mounting with fsck running correctly, you're there.

And please, check CONFIG_DEVTMPFS and CONFIG_DEVTMPFS_MOUNT again (especially the latter) and also see what device nodes exist in /mnt/gentoo/dev when nothing's mounted there. If you can boot, even with errors, try disabling udev and udev-mount services, and reboot, then see what nodes exist. These should be the ones provided by the devtmpfs kernel mount, so you can confirm that sda is missing: again #gentoo will be of more help from there.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Wed May 16, 2012 8:20 am    Post subject: Reply with quote

krenshala did you get anywhere; how did you fix it, if you did?

if not, check that other post I mentioned; summary: use MAKEDEV -n generic in /mnt/gentoo/dev as similar problems to do with /dev/console etc have hit udeved with his port of mkinitcpio (discussion was in #gentoo-dev-help.) Once you're happy with what it will do, remove the -n.

MAKEDEV, from sys-apps/makedev and on live CD, can be used to make any of the device nodes you might need, and should set up correct permissions, ownership etc.
Back to top
View user's profile Send private message
jkroon
Tux's lil' helper
Tux's lil' helper


Joined: 15 Oct 2003
Posts: 110
Location: South Africa

PostPosted: Thu May 24, 2012 6:47 pm    Post subject: Reply with quote

... now I would have been just FINE but for the fact that udev itself now installs into /usr since 181. 171 my systems (/usr on lvm on mdadm) are just fine. Guessing I'm masking >=181.
_________________
There are 10 kinds of people in the world,
those who understand binary and who don't
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri May 25, 2012 12:06 am    Post subject: Reply with quote

jkroon wrote:
... I would have been just FINE but for the fact that udev itself now installs into /usr since 181. 171 my systems (/usr on lvm on mdadm) are just fine. Guessing I'm masking >=181.

Don't give up yet. :) That was the situation this setup was designed for: that udev going forward needs /usr (and rules or scripts might need eg /var or /opt) mounted before it starts.

If the patches apply (they're not very complex so shouldn't take much working out but I need to review the new initscripts: if you have them to hand feel free to paste them) then there is no issue: this doesn't start udev til after localmount, so all partitions (including /usr and /var) are available.

We'll only be in difficulty if and when udev has a mandatory requirement for systemd; if that should happen, then I'll use a previous version, and assess the state of mdev at that time versus a fork.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Sun Jun 10, 2012 1:03 am    Post subject: udev 171-r6/ baselayout 2.1-r1 Reply with quote

Hi with recent changes to udev and baselayout for /run, I was finding things not working quite correctly, so I updated the patch for udev as follows:
/etc/init.d/udev
Code:

--- /etc/init.d/udev
+++ /etc/init.d/udev
@@ -15,11 +15,17 @@
 udev_settle_timeout="${udev_settle_timeout:-60}"
 kv_min="${kb_min:-2.6.32}"
 
+
 depend()
 {
-       provide dev
        need sysfs udev-mount
-       before checkfs fsck
+       if yesno "${initramfs:-yes}"; then
+               provide dev
+               before checkfs fsck
+       else
+               need localmount
+               before sysctl bootmisc net procfs logger termencoding urandom
+       fi

        # udev does not work inside vservers
        keyword -vserver -lxc

So where we just had:
Code:
               after localmount
now we have
Code:
               need localmount
               before sysctl bootmisc net procfs logger termencoding urandom

It had been bothering me for a while that udev was starting quite late: this makes it start immediately after localmount (before * didn't work as that just applies across the runlevel) and stop just before, which seems to be working much more nicely.

Don't ask me what the problems were, it was a big upgrade (I lost X for a bit, and decided to get rid of semantic-desktop crap in KDE) and for the life of me I can't remember what went wrong. It certainly works smoothly now, and I feel much more confident about the setup, since all devices are setup before anything else tries to run (apart from device-mapper/ lvm, fsck etc for localmount.)

I've been using it for the last week or so.
Back to top
View user's profile Send private message
Icer
Guru
Guru


Joined: 26 Aug 2003
Posts: 395
Location: @home

PostPosted: Tue Jul 10, 2012 9:14 am    Post subject: Reply with quote

Going to try this now. Thanks for the instructions Steve. This udev change hosed my system nicely. Especially since I had not been updating for a long time. :) I got /usr /var /home /opt and /tmp on lvm partitions.

I noticed that in my system the kernel option for the dev tmpfs(CONFIG_DEV_TMPFS) is named differently:
Code:
# zcat /proc/config.gz | grep TMPFS
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_TMPFS=y


AFAIK just the names of the options have changed. This info is from 3.2.12-gentoo kernel config.

Previously I used the earlymounts script. But I was thinking of getting rid of it now.
_________________
Everything can be done. There's just a longer delivery time for impossible projects.
Back to top
View user's profile Send private message
Icer
Guru
Guru


Joined: 26 Aug 2003
Posts: 395
Location: @home

PostPosted: Tue Jul 10, 2012 9:51 am    Post subject: Reply with quote

Great success! :)

As a reminder to myself: since I don't have the initramfs in use: udev must be at the boot runlevel and put the line 'initramfs="no"' in the /etc/conf.d/udev.

There's still a error message shown during the boot: ERROR: cannot start udev as fsck would not start
Trying to figure out where it's coming from.

Then when shutting down I get these errors:
Code:
* Stopping syslog-ng ...
 [ ok ]
 * udev: waiting for localmount (50 seconds)
 * udev: waiting for localmount (41 seconds)
 * udev: waiting for localmount (32 seconds)
 * udev: waiting for localmount (23 seconds)
 * udev: waiting for localmount (14 seconds)
 * udev: waiting for localmount (5 seconds)
 * Stopping udev ...
 [ ok ]
 * Unmounting loop devices

...

* Shutting down the Logical Volume Manager
 *   Shutting Down LVs & VGs ...
  device-mapper: remove ioctl on  failed: Device or resource busy
.
.
.
  device-mapper: remove ioctl on  failed: Device or resource busy
  Unable to deactivate lvm-usr (253:0)
 * Failed
 [ !! ]
 * Finished Shutting down the Logical Volume Manager

Afaik the first error comes from the udev init script.

The latter errors seem to be some sort of issue with the lvm init script.
_________________
Everything can be done. There's just a longer delivery time for impossible projects.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Mon Jul 16, 2012 3:19 pm    Post subject: Reply with quote

Icer wrote:
I noticed that in my system the kernel option for the dev tmpfs(CONFIG_DEV_TMPFS) is named differently

Yeah sorry, that was a typo that was pointed out before, so I'd edited the post, but for the new version of the patch, the file on my system still had the old text.

Quote:
As a reminder to myself: since I don't have the initramfs in use: udev must be at the boot runlevel and put the line 'initramfs="no"' in the /etc/conf.d/udev.

There's still a error message shown during the boot: ERROR: cannot start udev as fsck would not start
Trying to figure out where it's coming from.

As well as udev in boot, you also need sysfs and udev-mount added to sysinit runlevel: are you sure those are there? And you have patched /etc/init.d/udev-mount as well as /etc/init.d/udev?

Quote:
Then when shutting down I get these errors:
..
Afaik the first error comes from the udev init script.

The latter errors seem to be some sort of issue with the lvm init script.

That's odd: I've been running with lvm and the new patches for a while now, without any problems at all.

Unless you're on a version of udev greater than 180, it looks to me like either sysfs and udev-mount haven't been added to sysinit runlevel, or the patch to /etc/init.d/udev-mount hasn't been applied.
If udev is waiting for fsck, that sounds like its initscript has been patched, since patched (and with the option set) it needs localmount, which in turn needs fsck to have run. fsck needs dev which is provided by udev by default, but by udev-mount under the new setup.

So make sure udev-mount is in sysinit runlevel, and patched. (Add sysfs as well if that's not there, as it's needed by udev and must be in sysinit runlevel, which was where udev used to be.) For reference, here's what I've been using for quite a while:
Code:
# rc-update show
                acpid |      default nonetwork
            alsasound |      default nonetwork
             bootmisc | boot
          consolefont | boot
           consolekit |      default nonetwork
                 dbus |      default nonetwork
                devfs |                                        sysinit
        device-mapper | boot
                dmesg |                                        sysinit
                 fsck | boot
                  gpm |      default
             hostname | boot
              hwclock | boot
              keymaps | boot
            killprocs |                        shutdown
                local |      default nonetwork
           localmount | boot
                  lvm | boot
              modules | boot
             mount-ro |                        shutdown
                 mtab | boot
             net.eth0 | boot
               net.lo | boot
             netmount |      default
               procfs | boot
                 root | boot
            savecache |                        shutdown
                 sshd |      default
                 swap | boot
               sysctl | boot
                sysfs |                                        sysinit
            syslog-ng | boot
         termencoding | boot
                 udev | boot
           udev-mount |                                        sysinit
       udev-postmount |      default nonetwork
              urandom | boot
           vixie-cron |      default nonetwork
                  xdm |      default nonetwork

If you're on an unstable version of udev, then post the initscripts (udev-mount and udev) and we'll see what we can work out.

Sorry for delay in response, btw: I haven't been on the forums for a bit, and have only been working on the git version of update when I've had time for Gentoo stuff.
Back to top
View user's profile Send private message
Icer
Guru
Guru


Joined: 26 Aug 2003
Posts: 395
Location: @home

PostPosted: Thu Jul 19, 2012 6:09 am    Post subject: Reply with quote

Now that you mentioned the modifications to the init scripts I went through them again. I noticed that in the udev script I had not made the removals:
Code:
-       provide dev
        need sysfs udev-mount
-       before checkfs fsck


After making the above changes the booting up process is smooth again. No errors except consolekit, but hey that's another topic. :)
All the scripts are on correct runlevel. The udev version is 171-r6.

Now the only issue which remains is at the shutdown process. The
Code:
* udev: waiting for localmount (50 seconds)
messages have dissapeared though. But the issue with the lvm partitions is still there:
Code:
* Shutting down the Logical Volume Manager
 *   Shutting Down LVs & VGs ...
  device-mapper: remove ioctl on  failed: Device or resource busy
.
.
.
  device-mapper: remove ioctl on  failed: Device or resource busy
  Unable to deactivate lvm-usr (253:0)
  Unable to deactivate lvm-tmp (253:2)
 * Failed
 [ !! ]
 * Finished Shutting down the Logical Volume Manager


But anyway things seem to work. I may have messed up something myself when I was using the earlymounts script. I was experimenting with the run levels and modified some init scripts. Just can't remember which files I edited.

Thank's for the help Steve.
_________________
Everything can be done. There's just a longer delivery time for impossible projects.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri Jul 20, 2012 8:28 am    Post subject: Reply with quote

Icer wrote:
Now that you mentioned the modifications to the init scripts I went through them again.
..
After making the above changes the booting up process is smooth again. No errors except consolekit, but hey that's another topic. :)
All the scripts are on correct runlevel. The udev version is 171-r6.

Now the only issue which remains is at the shutdown process. The
Code:
* udev: waiting for localmount (50 seconds)
messages have dissapeared though. But the issue with the lvm partitions is still there:
Code:
device-mapper: remove ioctl on  failed: Device or resource busy
device-mapper: remove ioctl on  failed: Device or resource busy
  Unable to deactivate lvm-usr (253:0)
  Unable to deactivate lvm-tmp (253:2)

Well, glad udev isn't complaining any more; sounds like its dependencies are now ok. The "device or resource busy" messages mean something is still using the filesystems, so they can't be unmounted. The classic example is a daemon that doesn't chdir to root when it starts, meaning that its working directory elsewhere in the system is still open. Another typical case would be if another mount-point is still mounted on top of a mount-point one is trying to umount (eg /usr/local when trying to umount /usr.)

But I think you're right, that it's something to do with the earlymounts setup: I note from the second page that the extended lvm version involved a patch to /lib/rcscripts/addons/lvm-start.sh so you might want to check that file. You could always emerge -1 lvm2.
Quote:
Thanks for the help Steve.

You're very welcome :) Hope you get to a nice clean bootup and shutdown soon.
Back to top
View user's profile Send private message
DaggyStyle
Watchman
Watchman


Joined: 22 Mar 2006
Posts: 5909

PostPosted: Sun Aug 05, 2012 9:55 am    Post subject: Reply with quote

ok, as I've jumped on the /usr separation wagon, and the fact that the other days wine pulled udisks-1.99 which in turn must have udev-187, I think that it is time to lay down the options.
as I didn't followed the topic much, what are the options?
_________________
Only two things are infinite, the universe and human stupidity and I'm not sure about the former - Albert Einstein
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Wed Aug 08, 2012 6:31 pm    Post subject: Reply with quote

DaggyStyle wrote:
ok, as I've jumped on the /usr separation wagon, and the fact that the other days wine pulled udisks-1.99 which in turn must have udev-187, I think that it is time to lay down the options.
as I didn't followed the topic much, what are the options?

Well, if you want to avoid an initramfs, you can use the patches in the first post to start udev after localmount, though they will no doubt need tweaking for udev-187. (Hmm must run update as not even showing it in-tree here;)

That works fine provided you didn't need an initramfs before. iow you have drivers for stuff needed to get past localmount built-in to kernel, ie motherboard hard-disk controller and root filesystem: the stuff we've always traditionally sorted out as first part of kernel build.

If you're running lvm, you'll need device-mapper built-in (not module) as well. (I think: that's how I've always done it, but then I've had that built-in for the last few years.) I'd imagine you'd need same for mdadm/luks. Note that rootfs cannot be on lvm, raid or encrypted, which was always the traditional cut-off point to need an initrd, but everything else can.

It's relatively simple to switch back and forth, so long as you change udev's runlevel at the same time. (You'll soon find out if you don't and will need to run rc-update under init=/bin/sh or /bin/bash after a remount,rw of root, then a remount,ro for safety, and a reboot.)

The patches are in much better shape since I tweaked it to start as soon after localmount as possible (it starts directly after here, and everything's been fine on my machine since last summer, apart from missing a revdep-rebuild out after a big KDE upgrade.)

Alternatively, setup an initramfs, and get used to maintaining it. You'll need to keep it in sync with kernel and system upgrades, though it should come down to running a script once you've got used to it and set it up how you want. mkinitcpio looks like a contender.

I don't want to go down that route, as it's another thing to go wrong, in several senses, and no-one has answered the further contradiction inherent in it being both a rescue-system, supplanting the traditional rootfs, and only a trivial few hundred kilobytes (supposedly.)
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri Nov 02, 2012 7:19 am    Post subject: 171-r8 Reply with quote

This is working fine with 171-r8: there's just a new
Code:
        provide dev-mount
line in udev-mount (which you see in dispatch-conf or etc-update.)

I've updated the patch to reflect that.
Back to top
View user's profile Send private message
steveL
Watchman
Watchman


Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery

PostPosted: Fri Nov 23, 2012 5:48 am    Post subject: openrc 0.11.5 Reply with quote

This is working with the new openrc-0.11.5, which added two new services, swapfiles and tmpfiles.setup, both of which only need localmount.

Just to be safe, I've added them to the before line in the patch (and my local file of course, which I've tested) when we're not using an initramfs: this is for future reliability, to ensure that udev starts before them, and anything that needs them.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Unsupported Software All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6  Next
Page 3 of 6

 
Jump to:  
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