Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[Good] udev, /usr fs and no initramfs, what's the status?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
lyallp
Veteran
Veteran


Joined: 15 Jul 2004
Posts: 1552
Location: Adelaide/Australia

PostPosted: Sun Jan 20, 2013 9:59 pm    Post subject: [Good] udev, /usr fs and no initramfs, what's the status? Reply with quote

I just noticed on my 32 and 64 bit gentoos that udev-197-r4 has suddenly popped up as a requirement.

Ages ago, I blocked >=sys-fs/udev-172 as I didn't want to have to deal with the whole initramfs because /usr is a separate filesystem and systemd/udev decided they wanted executables from /usr at boot time.

It appears that lvm is driving this requirement, with a new udev use flag (at least, that's how I am interpreting my output)

What is the state of play now?

Can I unblock up til 197-r4 and still retain my separate /usr without having to setup an initramfs?

Code:
# emerge --jobs=4 --verbose --update --deep --with-bdeps y --tree --reinstall changed-use --color=n --keep-going --complete-graph --pretend world

These are the packages that would be merged, in reverse order:

Calculating dependencies  ... ..... ........ ... .... ... done!
[ebuild     U ~] app-crypt/ccid-1.4.9 [1.4.8] USE="usb -twinserial" 460 kB
[ebuild     U ~]  sys-apps/pcsc-lite-1.8.8 [1.8.7] USE="udev -libusb" 539 kB
[ebuild     U  ] sys-fs/lvm2-2.02.97-r1 [2.02.88] USE="lvm1 readline thin%* udev%* (-clvm) (-cman) (-selinux) -static* -static-libs*" 1,166 kB
[nomerge       ]  sys-fs/udev-197-r4 [171-r9] USE="acl%* gudev hwdb introspection keymap kmod%* openrc%* -doc% (-selinux) -static-libs% (-action_modeswitch%) (-build%) (-debug%) (-edd%) (-extras%) (-floppy%) (-rule_generator%*) (-test%)"
[ebuild  N     ]   sys-fs/udev-init-scripts-19  5 kB
[ebuild     U  ]    virtual/udev-197 [171] USE="gudev hwdb introspection keymap (-selinux) -static-libs" 0 kB
[ebuild     U #]     sys-fs/udev-197-r4 [171-r9] USE="acl%* gudev hwdb introspection keymap kmod%* openrc%* -doc% (-selinux) -static-libs% (-action_modeswitch%) (-build%) (-debug%) (-edd%) (-extras%) (-floppy%) (-rule_generator%*) (-test%)" 2,008 kB
[ebuild     U  ] www-plugins/adobe-flash-11.2.202.261 [11.2.202.258] USE="kde sse2check (-32bit) (-64bit) (-multilib) (-selinux) -vdpau" 6,756 kB
[nomerge       ] gnome-base/gconf-2.32.4:2  USE="gtk introspection ldap policykit -debug"
[ebuild     U  ]  sys-auth/polkit-0.110 [0.107-r1] USE="gtk introspection kde nls pam -examples (-selinux) (-systemd)" 1,358 kB
[ebuild     U  ] dev-db/mysql-5.1.67 [5.1.66] USE="berkdb community embedded latin1 perl ssl -big-tables -cluster -debug -extraengine -max-idx-128 -minimal -pbxt -profiling (-selinux) -static {-test} -xtradb" 24,202 kB
[nomerge       ] media-video/dvdrip-0.98.11-r1  USE="ffmpeg mplayer ogg subtitles vcd vorbis xine xvid -fping"
[ebuild     U  ]  media-video/xine-ui-0.99.7 [0.99.6] USE="X nls readline xinerama -aalib -curl -debug -libcaca -lirc -vdr" 1,712 kB
[nomerge       ] dev-util/ddd-3.3.12-r2  USE="gnuplot"
[ebuild     U  ]  sci-visualization/gnuplot-4.6.1 [4.4.4-r1] USE="X cairo emacs gd qt4%* readline wxwidgets -bitmap% -doc -examples -ggi -latex -lua -plotutils -svga -thin-splines -xemacs" 4,844 kB
[ebuild     U ~] dev-java/icedtea-7.2.3.4:7 [7.2.3.3:7] USE="X alsa cups javascript jbootstrap nsplugin nss source webstart -cjk -debug -doc -examples -pax_kernel -pulseaudio -systemtap {-test}" 6                     8,459 kB
[nomerge       ] media-video/kaffeine-1.2.2:4  USE="(-aqua) -debug" LINGUAS="-ar -ast -be -bg -ca -ca@valencia -cs -da -de -el -en_GB -eo -es -et -fi -fr -ga -gl -hr -hu -it -ja -km -ko -ku -lt -mai -nb -nds -nl -nn -pa -pl -pt -pt_BR -ro -ru -se -sk -sr@ijekavian -sr@ijekavianlatin -sr@latin -sv -th -tr -uk -zh_CN -zh_TW"
[ebuild     U  ]  media-libs/xine-lib-1.2.2:1 [1.2.1-r1:1] USE="X a52 aac alsa css dts flac gtk ipv6 mad mmap mng nls opengl oss samba sdl truetype v4l vcd vorbis xcb xinerama xv xvmc -aalib (-altivec) -bluray -directfb -dvb -dxr3 -fbcon -fusion -imagemagick -jack -libcaca -modplug -musepack -pulseaudio (-real) -speex -theora -vdpau -vdr -vidix (-vis) -wavpack -win32codecs" 4,744 kB
[ebuild     U  ] www-client/firefox-17.0.2 [10.0.11] USE="alsa dbus jit%* libnotify minimal startup-notification wifi -bindist -custom-cflags -custom-optimization -debug -gstreamer% (-pgo) (-selinux) -system-sqlite (-ipc%*) (-webm%*)" LINGUAS="-af -ak -ar -as -ast -be -bg -bn_BD -bn_IN -br -bs -ca -cs -csb -cy -da -de -el -en_GB -en_ZA -eo -es_AR -es_CL -es_ES -es_MX -et -eu -fa -fi -fr -fy_NL -ga_IE -gd -gl -gu_IN -he -hi_IN -hr -hu -hy_AM -id -is -it -ja -kk -km% -kn -ko -ku -lg -lt -lv -mai -mk -ml -mr -nb_NO -nl -nn_NO -nso -or -pa_IN -pl -pt_BR -pt_PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv_SE -ta -ta_LK -te -th -tr -uk -vi -zh_CN -zh_TW -zu" 88,751 kB
[ebuild     U  ] dev-java/java-config-2.1.12-r1:2 [2.1.11-r3:2] PYTHON_TARGETS="python2_7%* python3_2%* (-pypy1_8) (-pypy1_9) -pytho n2_6% -python3_1% (-python3_3)" 48 kB
[blocks b      ] sys-apps/kmod ("sys-apps/kmod" is blocking sys-apps/module-init-tools-3.16-r2)
[uninstall     ]  sys-apps/module-init-tools-3.16-r2  USE="-static"
[nomerge       ] virtual/modutils-0
[ebuild  N     ]  sys-apps/kmod-12-r1  USE="tools zlib -debug -doc -lzma -static-libs" 1,246 kB
[nomerge       ] net-analyzer/iftop-0.17
[ebuild     U  ]  net-libs/libpcap-1.3.0-r1 [1.3.0] USE="ipv6 -bluetooth -canusb -netlink -static-libs" 0 kB
[nomerge       ] x11-plugins/pidgin-sipe-1.14.1  USE="-debug -kerberos -ocs2005-message-hack -voice"
[ebuild     U  ]  dev-libs/nss-3.14.1 [3.14] USE="utils" 5,703 kB
[ebuild     U  ]   dev-libs/nspr-4.9.4 [4.9.2] USE="-debug" 1,134 kB
[nomerge       ] net-print/cups-1.6.1  USE="X acl avahi dbus filters gnutls java pam ssl threads usb -debug -kerberos -python (-selinux) -static-libs -systemd -xinetd -zeroconf" LINGUAS="-ca -es -ja"
[nomerge       ]  net-print/foomatic-filters-4.0.17  USE="cups dbus"
[nomerge       ]   net-print/cups-filters-1.0.25  USE="jpeg png tiff -perl -static-libs"
[ebuild     U ~]    app-text/qpdf-4.0.1:0/10 [4.0.0:0/0] USE="-doc -examples -static-libs {-test}" 4,914 kB
[nomerge       ] sys-fs/udev-197-r4 [171-r9] USE="acl%* gudev hwdb introspection keymap kmod%* openrc%* -doc% (-selinux) -static-libs% (-action_modeswitch%) (-build%) (-debug%) (-edd%) (-extras%) (-floppy%) (-rule_generator%*) (-test%)"
[ebuild     U  ]  sys-apps/hwids-20130114 [20121119] USE="udev%*" 1,437 kB
[nomerge       ] sys-fs/lvm2-2.02.97-r1 [2.02.88] USE="lvm1 readline thin%* udev%* (-clvm) (-cman) (-selinux) -static* -static-libs*"
[ebuild  N     ]  sys-block/thin-provisioning-tools-0.1.5-r1  118 kB
[nomerge       ] x11-drivers/nvidia-drivers-295.75  USE="acpi tools (-multilib)"
[ebuild     U  ]  sys-power/acpid-2.0.17-r1 [2.0.17] USE="(-selinux)" 0 kB
[nomerge       ] dev-java/java-config-2.1.12-r1:2 [2.1.11-r3:2] PYTHON_TARGETS="python2_7%* python3_2%* (-pypy1_8) (-pypy1_9) -python2_6% -python3_1% (-python3_3)"
[ebuild   R    ]  dev-python/python-exec-0.1.1  PYTHON_TARGETS="(jython2_5) (python2_5) (python2_6) (python2_7) (python3_1) (python3_2) (-pypy1_8) (-pypy1_9*) (-pypy2_0*) (-python3_3)" 0 kB
[blocks B      ] <sys-fs/udev-186 ("<sys-fs/udev-186" is blocking sys-fs/udev-init-scripts-19)

Total: 24 packages (20 upgrades, 3 new, 1 reinstall, 1 uninstall), Size of downloads: 219,592 kB
Conflict: 2 blocks

WARNING: One or more updates have been skipped due to a dependency conflict:

x11-drivers/nvidia-drivers:0

  (x11-drivers/nvidia-drivers-304.64::gentoo, ebuild scheduled for merge) conflicts with
    =x11-drivers/nvidia-drivers-2* required by (media-video/nvidia-settings-295.20::gentoo, installed)

x11-base/xorg-server:0

  (x11-base/xorg-server-1.13.1::gentoo, ebuild scheduled for merge) conflicts with
    <x11-base/xorg-server-1.12.99 required by (x11-drivers/nvidia-drivers-295.75::gentoo, installed)


The following keyword changes are necessary to proceed:
#required by virtual/udev-197, required by sys-fs/udev-init-scripts-19
=sys-fs/udev-197-r4 ~x86

The following mask changes are necessary to proceed:
#required by virtual/udev-197, required by sys-fs/udev-init-scripts-19
# /etc/portage/package.mask:
=sys-fs/udev-197-r4

NOTE: The --autounmask-keep-masks option will prevent emerge
      from creating package.unmask or ** keyword changes.
root@pearcely:/etc/portage
#

_________________
...Lyall


Last edited by lyallp on Tue Jan 22, 2013 1:16 am; edited 1 time in total
Back to top
View user's profile Send private message
VoidMage
Watchman
Watchman


Joined: 14 Oct 2006
Posts: 6196

PostPosted: Mon Jan 21, 2013 7:12 am    Post subject: Reply with quote

Actually, the real problem with with systemd is not 'separate /usr setup', as that's sort of bogus - it's not really udev, that's a problem here, it's more the other packages, that might need/use files from /usr|/var during early boot.

It's the hamfisted way its upstream goes about shoving it down our collective throat. Well, that and "too many moving elements" regarding its reliance on some of the libs.

TBH, I've got yet to learn how to produce a minimal initramfs (read some recommendations of dracut), but yes, you'll need one now.
As udev 197 went stable, some of the udev rules in the stable tree might become incompatible with previous versions leading to odd, hard to debug, failures.
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Mon Jan 21, 2013 10:46 am    Post subject: Reply with quote

If you have separate /usr and booting worked without problems with 171, then it will continue working with 197-r3. The problem is not udev, it could be in something you need in early booting that is in /usr. This has been broken for years, and is no new news.

So upgrade is safe with separate /usr without initramfs for everyone that it used to work before.

Don't block the upgrade for this.
Back to top
View user's profile Send private message
DaggyStyle
Watchman
Watchman


Joined: 22 Mar 2006
Posts: 5909

PostPosted: Mon Jan 21, 2013 11:33 am    Post subject: Reply with quote

ssuominen wrote:
If you have separate /usr and booting worked without problems with 171, then it will continue working with 197-r3. The problem is not udev, it could be in something you need in early booting that is in /usr. This has been broken for years, and is no new news.

So upgrade is safe with separate /usr without initramfs for everyone that it used to work before.

Don't block the upgrade for this.

wait, you say that udev-197-r3 supports what was working in 171 and broken in between the versions?
_________________
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
bandreabis
Advocate
Advocate


Joined: 18 Feb 2005
Posts: 2489
Location: イタリアのロディで

PostPosted: Mon Jan 21, 2013 12:37 pm    Post subject: Reply with quote

DaggyStyle wrote:
ssuominen wrote:
If you have separate /usr and booting worked without problems with 171, then it will continue working with 197-r3. The problem is not udev, it could be in something you need in early booting that is in /usr. This has been broken for years, and is no new news.

So upgrade is safe with separate /usr without initramfs for everyone that it used to work before.

Don't block the upgrade for this.

wait, you say that udev-197-r3 supports what was working in 171 and broken in between the versions?

This is a good question. Crucial!
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Mon Jan 21, 2013 1:40 pm    Post subject: Reply with quote

DaggyStyle wrote:
ssuominen wrote:
If you have separate /usr and booting worked without problems with 171, then it will continue working with 197-r3. The problem is not udev, it could be in something you need in early booting that is in /usr. This has been broken for years, and is no new news.

So upgrade is safe with separate /usr without initramfs for everyone that it used to work before.

Don't block the upgrade for this.

wait, you say that udev-197-r3 supports what was working in 171 and broken in between the versions?


Yes, that's exactly what I'm saying. I or we sanitized the 197 ebuild. Just make sure you read anything Portage prints when you emerge it. All the kernel requirements, and postinst messages.

We first decided there won't be a news item, but I'm thinking I'll add one just for CONFIG_DEVTMPFS requirement, since many people seem to have missed it, despite Portage warning about it.

To clarify: The only reason to emerge sys-fs/eudev instead of sys-fs/udev is support for older kernels than 2.6.39. It doesn't bring in anything other emerge worthy. It's actually a downgrade, since eudev is based on top of 196 at most.
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Mon Jan 21, 2013 1:44 pm    Post subject: Reply with quote

In the "equery c -f udev|less" it is a bit hidden. Also after emerge udev:
Quote:
>>> Messages generated by process 24372 on 2013-01-21 00:32:17 CET for package sys-fs/udev-197-r4:

WARN: postinst

Please re-emerge all packages on your system which install
rules and helpers in /usr/lib/udev. They should now be in
/lib/udev.

One way to do this is to run the following command:
emerge -av1 $(qfile -q -S -C /usr/lib/udev)
I wonder if this is bloody hidden too for some guys. A NEWS needed?
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Mon Jan 21, 2013 1:55 pm    Post subject: Reply with quote

ulenrich wrote:
In the "equery c -f udev|less" it is a bit hidden. Also after emerge udev:
Quote:
>>> Messages generated by process 24372 on 2013-01-21 00:32:17 CET for package sys-fs/udev-197-r4:

WARN: postinst

Please re-emerge all packages on your system which install
rules and helpers in /usr/lib/udev. They should now be in
/lib/udev.

One way to do this is to run the following command:
emerge -av1 $(qfile -q -S -C /usr/lib/udev)
I wonder if this is bloody hidden too for some guys. A NEWS needed?


I don't think that one is a real problem since the versions of udev that pointed udevdir= to /usr was never stable. News items are targeted for stable users.
Back to top
View user's profile Send private message
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Mon Jan 21, 2013 2:24 pm    Post subject: Reply with quote

@ssuominen, nevertheless feedback on udev-197-r4, systemd-197-r1:
without problems yet - very thanks to Gentoo maintainers!
(I closely follow portage hints though!)

if udev-197-r3 is stable now, I wonder if systemd could also go stable, because my guess:
newbies to Gentoo would have a lot less problems using systemd ....
Back to top
View user's profile Send private message
DaggyStyle
Watchman
Watchman


Joined: 22 Mar 2006
Posts: 5909

PostPosted: Mon Jan 21, 2013 2:53 pm    Post subject: Reply with quote

ssuominen wrote:
DaggyStyle wrote:
ssuominen wrote:
If you have separate /usr and booting worked without problems with 171, then it will continue working with 197-r3. The problem is not udev, it could be in something you need in early booting that is in /usr. This has been broken for years, and is no new news.

So upgrade is safe with separate /usr without initramfs for everyone that it used to work before.

Don't block the upgrade for this.

wait, you say that udev-197-r3 supports what was working in 171 and broken in between the versions?


Yes, that's exactly what I'm saying. I or we sanitized the 197 ebuild. Just make sure you read anything Portage prints when you emerge it. All the kernel requirements, and postinst messages.

We first decided there won't be a news item, but I'm thinking I'll add one just for CONFIG_DEVTMPFS requirement, since many people seem to have missed it, despite Portage warning about it.

To clarify: The only reason to emerge sys-fs/eudev instead of sys-fs/udev is support for older kernels than 2.6.39. It doesn't bring in anything other emerge worthy. It's actually a downgrade, since eudev is based on top of 196 at most.

I find the bold strange.

I don't use systemd nor I don't want it, I understand that I cannot prevent it from getting installed, will udev-197-r3 force it on me?
_________________
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
ulenrich
Veteran
Veteran


Joined: 10 Oct 2010
Posts: 1480

PostPosted: Mon Jan 21, 2013 3:23 pm    Post subject: Reply with quote

DaggyStyle wrote:
ssuominen wrote:
To clarify: The only reason to emerge sys-fs/eudev instead of sys-fs/udev is support for older kernels than 2.6.39. It doesn't bring in anything other emerge worthy. It's actually a downgrade, since eudev is based on top of 196 at most.
I find the bold strange.

I don't use systemd nor I don't want it, I understand that I cannot prevent it from getting installed, will udev-197-r3 force it on me?

You surely read something strange between the lines. If you want others to follow your paranoia concerns you have to explicitly express what they are, otherwise: No


Last edited by ulenrich on Mon Jan 21, 2013 3:28 pm; edited 1 time in total
Back to top
View user's profile Send private message
VoidMage
Watchman
Watchman


Joined: 14 Oct 2006
Posts: 6196

PostPosted: Mon Jan 21, 2013 3:24 pm    Post subject: Reply with quote

DaggyStyle wrote:
ssuominen wrote:

To clarify: The only reason to emerge sys-fs/eudev instead of sys-fs/udev is support for older kernels than 2.6.39. It doesn't bring in anything other emerge worthy. It's actually a downgrade, since eudev is based on top of 196 at most.

I don't use systemd nor I don't want it, I understand that I cannot prevent it from getting installed, will udev-197-r3 force it on me?


Not at the time being, but with systemd upstream you can't quite tell about the future. Just i.e. search the Gnome mailing list archives on systemd topic.
That's obviously not the same people, but you can note some ugly trends.
Back to top
View user's profile Send private message
DaggyStyle
Watchman
Watchman


Joined: 22 Mar 2006
Posts: 5909

PostPosted: Mon Jan 21, 2013 5:45 pm    Post subject: Reply with quote

ulenrich wrote:
DaggyStyle wrote:
ssuominen wrote:
To clarify: The only reason to emerge sys-fs/eudev instead of sys-fs/udev is support for older kernels than 2.6.39. It doesn't bring in anything other emerge worthy. It's actually a downgrade, since eudev is based on top of 196 at most.
I find the bold strange.

I don't use systemd nor I don't want it, I understand that I cannot prevent it from getting installed, will udev-197-r3 force it on me?

You surely read something strange between the lines. If you want others to follow your paranoia concerns you have to explicitly express what they are, otherwise: No

paranoia? like you've decided to go the systemd way, I decided not to go that way.
the maintainers of udev/systemd don't give a fuck about anything, it is their way or the highway, so my concerns are valid.

summing it, I don't want crap on my system.
_________________
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
Anon-E-moose
Watchman
Watchman


Joined: 23 May 2008
Posts: 6095
Location: Dallas area

PostPosted: Mon Jan 21, 2013 6:00 pm    Post subject: Reply with quote

I'm glad there are packages like systemd for people that want to use it

The old way should be kept around for those who wish to use it, whatever their reasons.

It's just getting a little old that some get an attitude with others who don't want to hop on the systemd bandwagon.

I don't use cgroups, don't need them.
Saving a few seconds, if that, when I reboot once a week is meaningless to me.
I have no problem looking at and understanding an init script if a problem occurs and easily finding a workaround.
I dislike complexity simply for complexities sake, I've gotten rid of *kit, *dbus, pam, etc.
Therefore systemd is meaningless for me on my home system.
If I were an admin on a large system or someone recently weaned from windows perhaps I would think differently.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Back to top
View user's profile Send private message
SamuliSuominen
Retired Dev
Retired Dev


Joined: 30 Sep 2005
Posts: 2133
Location: Finland

PostPosted: Mon Jan 21, 2013 6:23 pm    Post subject: Reply with quote

Just to clarify again, I couldn't care less about systemd except in the sense that I like the idea of common init system so upstreams can write the init scripts for me (and other distribution maintainers)
I don't use it, and I don't plan on using it at the moment
I still want to use the udev from the systemd tarball, it works very well on non-systemd platforms, despite people offending it's build system, we have it in very managable status in ebuild and
I can't remember when the ebuild was readable as it is now. The old Gentoo udev maintainer left things in a way he didn't instruct anyone to his workflow for it. I don't want to say anything
bad about him, just that he really had his own environment set in a way I can't comprehend
I saw WilliamH struggling alone with the ebuild and decided to jump in the wagon where as some others decided to completely fork the source tree and ditch some of the well justified changes
the original upstream had done
I'm sure I'm not alone in the camp of wanting to keep using the udev, and accept the new features it comes with, and make them compatible with OpenRC
I completely support systemd developers and users in a sense that if and when I'll switch, things will be in good order and tested
I completely also support the eudev team, since they provide support for older kernels, and I have my own ARM development machine I need temporarily older kernel for, or do too much work
on getting new one working. I support the idea that they will provide complete uClibc support, the one in udev is only worked around for the glibc specific function secure_getenv()

I'm also maintaining almost full stack of ConsoleKit, polkit, udisks, upower and co. and they work very well for me at home and work where we have deployed LTSP/PXE server and hundreds of clients using them

I also maintain Xfce and intend in keeping ConsoleKit supported for long as humanly possible, in way that systemd-logind will only be an alternative, not replacement

End of monolog. :oops:


Last edited by SamuliSuominen on Mon Jan 21, 2013 10:51 pm; edited 1 time in total
Back to top
View user's profile Send private message
lyallp
Veteran
Veteran


Joined: 15 Jul 2004
Posts: 1552
Location: Adelaide/Australia

PostPosted: Mon Jan 21, 2013 9:34 pm    Post subject: Reply with quote

I guess the reason I asked was, due to workplace encryption mandates, I have

1. luks (encrypted partition)
2. LVM inside an encrypted partition
3. All filesystems, including root as LVM volumes
4. /usr and /var as separate filesystems
5. my own home brewed initramfs which
  • activates the luks partition, including prompting for the passphrase
  • activates LVM
  • mounts root


I guess I was wondering if I needed to make the effort to tweak my initramfs to mount /var and /usr prior to passing control to the system init process or whether things will continue to work, as is :)

After reading this, I am going to 'give it a try'.

:)
_________________
...Lyall
Back to top
View user's profile Send private message
lyallp
Veteran
Veteran


Joined: 15 Jul 2004
Posts: 1552
Location: Adelaide/Australia

PostPosted: Tue Jan 22, 2013 1:16 am    Post subject: Reply with quote

I unblocked udev and re-built, making sure I had the appropriate kernel settings and all went smoothly, even though I had a custom startup :)
_________________
...Lyall
Back to top
View user's profile Send private message
DaggyStyle
Watchman
Watchman


Joined: 22 Mar 2006
Posts: 5909

PostPosted: Tue Jan 22, 2013 6:09 am    Post subject: Reply with quote

I have a root on raid1, rest on raid5, swap on lvm and /var,/usr on seperate partitions.

currently I boot them without any problem without initrd and initramfs, if I can migrate to latest udev, keep my current setup and for the time being not be forced to use systemd (I guess I don't mind much it is installed as part of udev), I'll migrate, question is, can I do that?
_________________
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
dmpogo
Advocate
Advocate


Joined: 02 Sep 2004
Posts: 3264
Location: Canada

PostPosted: Tue Jan 22, 2013 6:53 am    Post subject: Reply with quote

Anon-E-moose wrote:

Therefore systemd is meaningless for me on my home system.
If I were an admin on a large system or someone recently weaned from windows perhaps I would think differently.


If you were an admin of a large system, you would probably be still running 2.6.32 and would not dream of touching init system (*)

(*) Just was launching my computational jobs on high performance clusters of Compute Canada - majority of them are running 2.6.18 kernel.
Not under Gentoo though :)
Back to top
View user's profile Send private message
lyallp
Veteran
Veteran


Joined: 15 Jul 2004
Posts: 1552
Location: Adelaide/Australia

PostPosted: Tue Jan 22, 2013 7:00 am    Post subject: Reply with quote

My home machine uses raid, over 2 disks (plus a couple of other Windows disks)
Root, boot on raid
LVM on the raid
All my filesystems, including /tmp, /var, /usr, /home, /portage, /usr/local as XFS within LVM.
No initramfs (other than v86d for better console support)

Happy to supply config details, but unblocking udev appeared to be seamless.

I will admit I have noticed something a little weird with my mouse lately, not responding on boot, but if I unplug the hub it's plugged into and re-plug, things all work. Things are complicated by the USB Belkin KVM switch, but if I use that to switch out the hub the mouse is connected to and back, things also work.

Other than that little glitch, which I am sure I will figure out eventually, my system is fine.
_________________
...Lyall
Back to top
View user's profile Send private message
Xtroce
n00b
n00b


Joined: 27 Apr 2004
Posts: 12

PostPosted: Fri Jan 25, 2013 9:16 pm    Post subject: Reply with quote

lyallp wrote:
I unblocked udev and re-built, making sure I had the appropriate kernel settings and all went smoothly, even though I had a custom startup :)


hey man, thanks. This was the answer i was looking for in this thread :). Will save me from a headache,... and reboots ... :P
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Page 1 of 1

 
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