View previous topic :: View next topic |
Author |
Message |
pingtoo Veteran
Joined: 10 Sep 2021 Posts: 1339 Location: Richmond Hill, Canada
|
Posted: Sun Mar 26, 2023 9:44 pm Post subject: |
|
|
stefan11111,
You may or may not aware, In X "display" have special meaning. A "display" is where a program running accept X protocol. a.k.a "Display server", This display server could be running on local machine, but it also can be running on somewhere remotely. So it is possible for the display manager to manage sessions for local and remote user.
The "Display manager" It is acting kind of like telet server to authenticate and authorize service.
Because when the X server (or X display server) when allow remote access, it become much bigger thread if the server program is running under root account. because X protocol is very unsecured. it become a very easy point of exploit. Many request to eliminate the need to run as root for X server. That is when a external program like elogind came in.
For example elogind does not listen for network connect. (at least I hope) So it is one less risk to deal with. and elogind can manage privileged access for X server.
Just a simple example why need Display manager need manage remote access.
For a while I have new RPI I want to replace it for my X86 based machine as my day to day machine. But before I have the confident the RPI is configured as I want. I use XDM on the RPI so I can use my X86 machine connect with XMDCP so I can have my current desktop and RPI desktop so I compare them for correct configuration. |
|
Back to top |
|
|
stefan11111 l33t
Joined: 29 Jan 2023 Posts: 937 Location: Romania
|
Posted: Mon Mar 27, 2023 12:09 am Post subject: |
|
|
pingtoo wrote: | stefan11111,
You may or may not aware, In X "display" have special meaning. A "display" is where a program running accept X protocol. a.k.a "Display server", This display server could be running on local machine, but it also can be running on somewhere remotely. So it is possible for the display manager to manage sessions for local and remote user.
The "Display manager" It is acting kind of like telet server to authenticate and authorize service.
Because when the X server (or X display server) when allow remote access, it become much bigger thread if the server program is running under root account. because X protocol is very unsecured. it become a very easy point of exploit. Many request to eliminate the need to run as root for X server. That is when a external program like elogind came in.
For example elogind does not listen for network connect. (at least I hope) So it is one less risk to deal with. and elogind can manage privileged access for X server.
Just a simple example why need Display manager need manage remote access.
For a while I have new RPI I want to replace it for my X86 based machine as my day to day machine. But before I have the confident the RPI is configured as I want. I use XDM on the RPI so I can use my X86 machine connect with XMDCP so I can have my current desktop and RPI desktop so I compare them for correct configuration. |
Doesn't this become more of a security risk only for connections outside of lan?
It doesn't seem that much worse to run root xorg over lan than it is to run root xorg locally, unless you don't trust those on your lan, which would be worse than any vulnerability.
I have not done this, but can't you use the solution I described in this thread over ssh/telnet if you need too?
Even it xorg does get compromised, an attacked won't get root access with my solution.
It doesn't seem worth it to give elogind root access just to not give xorg access to /dev/input/mice.
I would rather give xorg full root permissions that use something like elogind, unless I connect from outside of lan, which would likely be a challenge to set up. _________________ My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
Back to top |
|
|
colo-des Tux's lil' helper
Joined: 20 May 2011 Posts: 97
|
Posted: Mon Mar 27, 2023 9:16 am Post subject: |
|
|
Quote: | stefan11111
Perhaps, but I am running xorg with startx, so it very much does matter to me
I suspect that a lot of people also start xorg like this too. |
Hooo...your suspicions are true...how did you know?
In my case, I'm even more minimalist, I run xinit directly from vt2 as user.
The x server running on tty7 and with a udev rule to give my user 600 permissions for tty7.
In vt2 the messages and errors of the applications that I run and from the x server appear,
I still haven't found a way to redirect them to a file in my home.
With an /etc/portage/env/x11-base/xorg-server I solve the input group dilemma without supposed security
problems (although that remains to be seen) my user is neither in the input group nor in the tty group.
Code: | my-user@pc-gentoo ~ $ ls -la {.xinitrc,.xserverrc}
-rwx------ 1 my-user my-user 48 feb 13 13:58 .xinitrc
-rwx------ 1 my-user my-user 308 mar 10 2021 .xserverrc
my-user@pc-gentoo ~ $ cat .xinitrc
#!/bin/sh
exec openbox-session
my-user@pc-gentoo ~ $ cat .xserverrc
#!/bin/sh
exec /usr/bin/X -nolisten tcp -nolisten local -br -deferglyphs 16 "$@" vt7 &>> $HOME/.local/share/xorg/xsession-errors
my-user@pc-gentoo ~ $ cat /etc/udev/rules.d/75-tty-perm.rules
SUBSYSTEM=="tty", KERNEL=="tty7", OWNER="my-user", GROUP="tty", MODE="0600"
my-user@pc-gentoo ~ $ ls -l /dev/tty7
crw------- 1 my-user tty 4, 7 mar 27 03:50 /dev/tty7 |
This is a PC (personal computer) and I am the only person using it, therefore with only one active session of the x server
I'm fine, also that happens automatically when using xinit, it only allows one x server session.
More than three years ago I have three PCs with gentoo with the same system and now BLFS has been added and all without
problems using this way.
Greetings. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54638 Location: 56N 3W
|
Posted: Mon Mar 27, 2023 9:51 am Post subject: |
|
|
colo-des,
Code: | my-user@pc-gentoo ~ $ cat /etc/udev/rules.d/75-tty-perm.rules
SUBSYSTEM=="tty", KERNEL=="tty7", OWNER="my-user", GROUP="tty", MODE="0600" |
udev has to run as root to do that. You trust udev?
As you are the only user, without udev installed, for a single unpriv user those permissions could be static. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
stefan11111 l33t
Joined: 29 Jan 2023 Posts: 937 Location: Romania
|
Posted: Mon Mar 27, 2023 10:03 am Post subject: |
|
|
colo-des wrote: | Quote: | stefan11111
Perhaps, but I am running xorg with startx, so it very much does matter to me
I suspect that a lot of people also start xorg like this too. |
Hooo...your suspicions are true...how did you know?
In my case, I'm even more minimalist, I run xinit directly from vt2 as user.
|
Is xinit more minimal than startx?
colo-des wrote: |
The x server running on tty7 and with a udev rule to give my user 600 permissions for tty7.
|
I wouldn't call using unneeded, buggy garbage, like udev, that also complicates things even if it would work properly "minimal".
Udev would often mangle my /dev/sd* and booting with /dev/sd* in /etc/fstab was russian roulette.
All these problems magically disappeared after switching to a static /dev.
I imagine my solution would have taken longer to find if I had to deal with udev between me and my /dev.
This solution is probably applicable to udev too by crafting udev rules.
colo-des wrote: |
In vt2 the messages and errors of the applications that I run and from the x server appear,
I still haven't found a way to redirect them to a file in my home.
With an /etc/portage/env/x11-base/xorg-server I solve the input group dilemma without supposed security
problems (although that remains to be seen) my user is neither in the input group nor in the tty group.
|
I have my user in the audio and video group only.
Code: | $ groups stefan
audio video stefan
|
_________________ My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
Back to top |
|
|
stefan11111 l33t
Joined: 29 Jan 2023 Posts: 937 Location: Romania
|
Posted: Mon Mar 27, 2023 10:38 am Post subject: |
|
|
stefan11111 wrote: | NeddySeagoon,
Can you post the output of a few more commands after running them on your system?
Code: | ls -lah /dev/null
ls -lah /dev/ptmx
ls -lah /dev | grep snd
ls -lah /dev/sr0
ls -lah /dev/rtc0
|
|
pretty please _________________ My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54638 Location: 56N 3W
|
Posted: Mon Mar 27, 2023 10:47 am Post subject: |
|
|
stefan11111,
udev does not create or remove /dev entries. The kernel DEVTMPFS does that.
udev gets prodded by the kernel as devices come and go. udev can change device names but never to another kernel device name.
Hence 'persistent device names' for network interfaces.
It changes /dev permissions and ownership and makes/removes symbolic links.
Kernel generated /dev entries are created in device detection order, which is not deterministic.
The 'race' problem you describe goes back 10's of years.
The fix is to not use kernel allocated device names.
In grub.cfg, use PARTUUID. In fstab, use UUID. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
stefan11111 l33t
Joined: 29 Jan 2023 Posts: 937 Location: Romania
|
Posted: Mon Mar 27, 2023 11:11 am Post subject: |
|
|
NeddySeagoon wrote: | stefan11111,
udev does not create or remove /dev entries. The kernel DEVTMPFS does that.
udev gets prodded by the kernel as devices come and go. udev can change device names but never to another kernel device name.
Hence 'persistent device names' for network interfaces.
It changes /dev permissions and ownership and makes/removes symbolic links.
Kernel generated /dev entries are created in device detection order, which is not deterministic.
The 'race' problem you describe goes back 10's of years.
The fix is to not use kernel allocated device names.
In grub.cfg, use PARTUUID. In fstab, use UUID. |
I have static /dev provided by copying the /dev nodes from a livecd.
Code: | $ ls -lah /dev/sd*
brw-r----- 1 root root 8, 0 Mar 26 21:37 /dev/sda
brw-r----- 1 root root 8, 1 Mar 26 21:37 /dev/sda1
brw-r----- 1 root root 8, 2 Mar 26 21:37 /dev/sda2
brw-r----- 1 root root 8, 3 Mar 26 21:37 /dev/sda3
brw-r----- 1 root root 8, 16 Mar 26 21:37 /dev/sdb
brw-r----- 1 root root 8, 17 Mar 26 21:37 /dev/sdb1
brw-r----- 1 root root 8, 32 Mar 26 21:37 /dev/sdc
brw-r----- 1 root root 8, 33 Mar 26 21:37 /dev/sdc1
|
I would often see the /dev/sda* and /dev/sdb* nodes swapped with udev, like this.
Code: |
/dev/sda /dev/sda1 /dev/sdb /dev/sdb1 /dev/sdb2 /dev/sdb3 |
Now, my fstab looks like this:
Code: | $ cat /etc/fstab
# /etc/fstab: static file system information.
#
# noatime turns off atimes for increased performance (atimes normally aren't
# needed); notail increases performance of ReiserFS (at the expense of storage
# efficiency). It's safe to drop the noatime options if you want and to
# switch between notail / tail freely.
#
# The root filesystem should have a pass number of either 0 or 1.
# All other filesystems should have a pass number of 0 or greater than 1.
#
# See the manpage fstab(5) for more information.
#
# <fs> <mountpoint> <type> <opts> <dump/pass>
# NOTE: If your BOOT partition is ReiserFS, add the notail option to opts.
#
# NOTE: Even though we list ext4 as the type here, it will work with ext2/ext3
# filesystems. This just tells the kernel to use the ext4 driver.
#
# NOTE: You can use full paths to devices like /dev/sda3, but it is often
# more reliable to use filesystem labels or UUIDs. See your filesystem
# documentation for details on setting a label. To obtain the UUID, use
# the blkid(8) command.
#LABEL=boot /boot ext4 noauto,noatime 1 2
#UUID=58e72203-57d1-4497-81ad-97655bd56494 / ext4 noatime 0 1
#LABEL=swap none swap sw 0 0
#/dev/cdrom /mnt/cdrom auto noauto,ro 0 0
#UUID="8CC6-F48A" /boot vfat defaults 0 2
/dev/sda1 /boot vfat defaults 0 2 moauto,ro 0 0 noatime 0 1
#UUID="37e7edfc-3cb8-4569-b90e-21e0bf464618" none swap sw 0 0
/dev/sda2 none swap sw 0 0
#UUID="1614c2d1-be93-4b94-bea5-a3ac772ae4bf" / ext4 defaults,noatime 0 2
/dev/sda3 / ext4 defaults,noatime 0 2
#UUID="213d31b7-bd4c-4f97-8b26-4abffb6fc142" /home/stefan/hdd ext4 rw,exec,async,user 0 2
/dev/sdb1 /home/stefan/hdd ext4 rw,exec,async,user 0 2
//10.0.15.220/hdd1 /home/stefan/HDD1 cifs username=admin,password=raspberry,uid=stefan,_netdev 0 0
//10.0.15.220/hdd2 /home/stefan/HDD2 cifs username=admin,password=raspberry,uid=stefan,_netdev 0 0
//10.0.15.220/MyBook /home/stefan/MyBook cifs username=admin,password=raspberry,uid=stefan,_netdev 0 0
//10.0.15.115/DuneHDD_349216fe_819a_4f56_b771_d977ce430eb3/ /home/stefan/DuneHDD cifs username=root,password=,vers=1.0,uid=stefan,_netdev 0 0
#//10.0.15.115/D /home/stefan/DuneHDD cifs username=root,password=,vers=1.0,uid=stefan,_netdev 0 0
/dev/cdrom /mnt/cdrom auto noauto,user 0 0 |
All the UUID's are commented out.
I use PARTUUID's in the grub config as that is what grub-mkconfig gives me and it worked without issues.
Since using a static /dev, these have never been mangled.
Before, I don't think I've gotten 10 boots in a row with udev and /dev/sd* in /etc/fstab.
EDIT
So you mean it's the kernel's fault for mangling /dev, not udev's? _________________ My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
Back to top |
|
|
Leonardo.b Guru
Joined: 10 Oct 2020 Posts: 308
|
Posted: Mon Mar 27, 2023 12:14 pm Post subject: |
|
|
stefan11111 wrote: | Is xinit more minimal than startx? |
startx is a shell script. Check comments at the beginning. |
|
Back to top |
|
|
colo-des Tux's lil' helper
Joined: 20 May 2011 Posts: 97
|
Posted: Mon Mar 27, 2023 12:14 pm Post subject: |
|
|
I use eudev, but as I said in a previous message I'm interested in converting to static and I'm reading them carefully.
Of course, setting a static permission does not need udev and its rules at all.
startx is a script that first creates the cookie with xauth and then calls xinit which is binary and starts the x server
Code: | my-user@pc-gentoo ~ $ file /usr/bin/startx
/usr/bin/startx: POSIX shell script, ASCII text executable
my-user@pc-gentoo ~ $ less /usr/bin/startx |
I don't want xauth and yours cookies, which for the worse now goes to /tmp, that's not safe... investigate and you'll see why.
I directly use xinit which does not create cookies and only supports an active x server session.
For fstab I use LABEL=RootGentoo it was the simplest way and that the partitions do not get mixed up, I don't think that is possible in
static since the labels are created by a udev/eudev script.
Greetings. |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54638 Location: 56N 3W
|
Posted: Mon Mar 27, 2023 12:22 pm Post subject: |
|
|
stefan11111,
Quote: | EDIT
So you mean it's the kernel's fault for mangling /dev, not udev's? |
Its the hardwares 'fault'. The kernel scans the devices and allocates the kernel names as the devices become ready.
The kernel doesn't know what devices are connected until the report that they are ready.
See A new issue with gentoo-sources-6.2.7 not waiting for nvme for a recent example.
With HDD, the spin up times vary from start to start. It's just luck if they always start in the same order.
A static /dev does not fix the problem. The kernel can attach a different device to /dev/sda is a different device is ready first.
/dev is a lookup table from device names that you like to kernel major,minor device numbers, that the kernel works with.
Indeed, root=major,minor works. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
stefan11111 l33t
Joined: 29 Jan 2023 Posts: 937 Location: Romania
|
Posted: Mon Mar 27, 2023 1:21 pm Post subject: |
|
|
colo-des wrote: |
I use eudev, but as I said in a previous message I'm interested in converting to static and I'm reading them carefully.
Of course, setting a static permission does not need udev and its rules at all.
|
NeedySeagoon made a great guide for using a static /dev.
https://wiki.gentoo.org/wiki/Old_Fashioned_Gentoo_Install
https://wiki.gentoo.org/wiki/User:NeddySeagoon/YeOldeGentoo_2021_Edition
I have deviated a bit from it with the things described in this thread.
I also use this script to fix /dev/snd if it gets mangled:
https://github.com/stefan11111/config-files/blob/main/mknod_snd
Neddy also has a overlay for packages to work without udev.
https://github.com/NeddySeagoon/gentoo-static
colo-des wrote: |
startx is a script that first creates the cookie with xauth and then calls xinit which is binary and starts the x server
Code: | my-user@pc-gentoo ~ $ file /usr/bin/startx
/usr/bin/startx: POSIX shell script, ASCII text executable
my-user@pc-gentoo ~ $ less /usr/bin/startx |
I don't want xauth and yours cookies, which for the worse now goes to /tmp, that's not safe... investigate and you'll see why.
I directly use xinit which does not create cookies and only supports an active x server session.
|
How do you pass virtual terminals to xinit.
How can I port this to xinit:
Code: | alias startx="startx -- vt$(tty | sed -e 's|/dev/tty||')" |
colo-des wrote: |
For fstab I use LABEL=RootGentoo it was the simplest way and that the partitions do not get mixed up, I don't think that is possible in
static since the labels are created by a udev/eudev script.
Greetings. |
I have never used labels as I never needed then and I create my grub config with grub-mkconfig, which does not use labels.
EDIT
It appears that porting my alias to xinit is quite simple:
alias startx="xinit -- vt$(tty | sed -e 's|/dev/tty||')" _________________ My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev"
Last edited by stefan11111 on Mon Mar 27, 2023 2:31 pm; edited 1 time in total |
|
Back to top |
|
|
stefan11111 l33t
Joined: 29 Jan 2023 Posts: 937 Location: Romania
|
Posted: Mon Mar 27, 2023 1:27 pm Post subject: |
|
|
NeddySeagoon wrote: | stefan11111,
Quote: | EDIT
So you mean it's the kernel's fault for mangling /dev, not udev's? |
Its the hardwares 'fault'. The kernel scans the devices and allocates the kernel names as the devices become ready.
The kernel doesn't know what devices are connected until the report that they are ready.
See A new issue with gentoo-sources-6.2.7 not waiting for nvme for a recent example.
With HDD, the spin up times vary from start to start. It's just luck if they always start in the same order.
A static /dev does not fix the problem. The kernel can attach a different device to /dev/sda is a different device is ready first.
/dev is a lookup table from device names that you like to kernel major,minor device numbers, that the kernel works with.
Indeed, root=major,minor works. |
Since switching to a static /dev, removing udev and disabling the related kernel options, /dev/sd* stopped being mangled, so I don't think I should write this off as a hardware problem.
I do have a ssd and a hdd, so that might have played a part.
I do not use root=major,minon and instead use root=PARTUUID=
Also, since I don't use evdev, can these /dev nodes be deleted?
Code: | # grep -i EVDEV .config
# CONFIG_INPUT_EVDEV is not set |
Code: | $ ls -lah /dev/input/event*
crw-r----- 1 root root 13, 64 Mar 26 21:37 /dev/input/event0
crw-r----- 1 root root 13, 65 Mar 26 21:37 /dev/input/event1
crw-r----- 1 root root 13, 74 Mar 26 21:37 /dev/input/event10
crw-r----- 1 root root 13, 75 Mar 26 21:37 /dev/input/event11
crw-r----- 1 root root 13, 76 Mar 26 21:37 /dev/input/event12
crw-r----- 1 root root 13, 77 Mar 26 21:37 /dev/input/event13
crw-r----- 1 root root 13, 78 Mar 26 21:37 /dev/input/event14
crw-r----- 1 root root 13, 79 Mar 26 21:37 /dev/input/event15
crw-r----- 1 root root 13, 80 Mar 26 21:37 /dev/input/event16
crw-r----- 1 root root 13, 81 Mar 26 21:37 /dev/input/event17
crw-r----- 1 root root 13, 82 Mar 26 21:37 /dev/input/event18
crw-r----- 1 root root 13, 83 Mar 26 21:37 /dev/input/event19
crw-r----- 1 root root 13, 66 Mar 26 21:37 /dev/input/event2
crw-r----- 1 root root 13, 84 Mar 26 21:37 /dev/input/event20
crw-r----- 1 root root 13, 85 Mar 26 21:37 /dev/input/event21
crw-r----- 1 root root 13, 86 Mar 26 21:37 /dev/input/event22
crw-r----- 1 root root 13, 87 Mar 26 21:37 /dev/input/event23
crw-r----- 1 root root 13, 88 Mar 26 21:37 /dev/input/event24
crw-r----- 1 root root 13, 67 Mar 26 21:37 /dev/input/event3
crw-r----- 1 root root 13, 68 Mar 26 21:37 /dev/input/event4
crw-r----- 1 root root 13, 69 Mar 26 21:37 /dev/input/event5
crw-r----- 1 root root 13, 70 Mar 26 21:37 /dev/input/event6
crw-r----- 1 root root 13, 71 Mar 26 21:37 /dev/input/event7
crw-r----- 1 root root 13, 72 Mar 26 21:37 /dev/input/event8
crw-r----- 1 root root 13, 73 Mar 26 21:37 /dev/input/event9 |
EDIT
Guess only some of them can be removed.
Code: | by-id:
total 8.0K
drwxr-xr-x 2 root root 4.0K Mar 26 21:37 .
drwxr-xr-x 4 root root 4.0K Mar 27 21:09 ..
lrwxrwxrwx 1 root root 9 Mar 26 21:37 usb-Logitech_G413_Silver_Mechanical_Gaming_Keyboard_037D36533933-event-kbd -> ../event4
lrwxrwxrwx 1 root root 9 Mar 26 21:37 usb-Logitech_G413_Silver_Mechanical_Gaming_Keyboard_037D36533933-if01-event-kbd -> ../event5
lrwxrwxrwx 1 root root 9 Mar 26 21:37 usb-Razer_Razer_Basilisk_V2-event-if01 -> ../event2
lrwxrwxrwx 1 root root 9 Mar 26 21:37 usb-Razer_Razer_Basilisk_V2-event-mouse -> ../event0
lrwxrwxrwx 1 root root 9 Mar 26 21:37 usb-Razer_Razer_Basilisk_V2-if01-event-kbd -> ../event1
lrwxrwxrwx 1 root root 9 Mar 26 21:37 usb-Razer_Razer_Basilisk_V2-if02-event-kbd -> ../event3
lrwxrwxrwx 1 root root 9 Mar 26 21:37 usb-Razer_Razer_Basilisk_V2-mouse -> ../mouse0
lrwxrwxrwx 1 root root 9 Mar 26 21:37 usb-Razer_Razer_Kraken_Ultimate_00000000-event-if03 -> ../event7 |
Seems like these udev relics can help. _________________ My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev"
Last edited by stefan11111 on Mon Mar 27, 2023 6:12 pm; edited 2 times in total |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54638 Location: 56N 3W
|
Posted: Mon Mar 27, 2023 1:27 pm Post subject: |
|
|
stefan11111, colo-des
LABELs work with a static /dev
You need to use filesystems that support labels and set the labels yourself, so its your problem to make them all unique.
mount by label needs the userspace mount command, which means an initrd to be able to use root=LABEL= in the boot loader. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
stefan11111 l33t
Joined: 29 Jan 2023 Posts: 937 Location: Romania
|
Posted: Mon Mar 27, 2023 1:34 pm Post subject: |
|
|
NeddySeagoon wrote: |
mount by label needs the userspace mount command, which means an initrd to be able to use root=LABEL= in the boot loader. |
No, thanks.
Removing genkernel's initrd shaved over 10 seconds from my boot time.
Now I boot in 3 seconds. _________________ My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
Back to top |
|
|
colo-des Tux's lil' helper
Joined: 20 May 2011 Posts: 97
|
Posted: Mon Mar 27, 2023 8:08 pm Post subject: |
|
|
Thanks for the info that LABEL= works in static, at the time of formatting the partitions I give a label
unique, although that can be put or changed with e2label, I use ext4.
mdadm raid1 with 0.90 metadata is directly recognized by the kernel at the boot time, metadata greater
than 0.90 are not recognized and need initrd.
To generate grub.cfg I use the manual method, using the custom file in /etc/grub.d/09-custom with
/dev/md0 and /dev/md2 which are /boot and /
The UUID of the partitions are defined with the array directive in /etc/mdadm.conf
Code: | my-user@pc-gentoo ~ $ ls -l /dev/md?
brw-rw---- 1 root disk 9, 0 mar 27 15:47 /dev/md0
brw-rw---- 1 root disk 9, 1 mar 27 15:47 /dev/md1
brw-rw---- 1 root disk 9, 2 mar 27 15:47 /dev/md2
brw-rw---- 1 root disk 9, 3 mar 27 15:47 /dev/md3
my fstab
# /dev/md0
LABEL=GentooBoot /boot ext4 noatime,noauto,barrier=1,data=ordered 0 3
# /dev/md1
LABEL=GentooSwap none swap swap 0 0
# /dev/md2
LABEL=GentooRoot / ext4 noatime,barrier=1,data=ordered 0 1
# /dev/md3
LABEL=GentooHome /home ext4 noatime,barrier=1,data=ordered 0 2
my-user@pc-gentoo ~ $ cat /etc/grub.d/09_custom
#!/bin/sh
exec tail -n +3 $0
# This file provides an easy way to add custom menu entries. Simply type the
# menu entries you want to add after this comment. Be careful not to change
# the 'exec tail' line above.
menuentry 'Gentoo GNU/Linux, with Linux 6.2.5-gentoo' --class gentoo --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-6.2.5-gentoo' {
load_video
insmod gzio
insmod part_msdos
insmod part_msdos
insmod diskfilter
insmod mdraid09
insmod ext2
set root='md/md0'
echo 'Loading Linux 6.2.5-gentoo...'
linux /vmlinuz-6.2.5-gentoo root=/dev/md2 ro quiet console=tty1 radeon.audio=1 radeon.dpm=1
}
my-user@pc-gentoo ~ $ cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-6.2.5-gentoo root=/dev/md2 ro quiet console=tty1 radeon.audio=1 radeon.dpm=1 |
Regards. |
|
Back to top |
|
|
stefan11111 l33t
Joined: 29 Jan 2023 Posts: 937 Location: Romania
|
Posted: Mon Mar 27, 2023 8:16 pm Post subject: |
|
|
In what case is an initrd actually needed?
From my understanding, it's only really needed when modules need to be loaded at boot time, with some raid/encrypted disks and with weird partition layouts, like having every folder under / on a separate partition. _________________ My overlay: https://github.com/stefan11111/stefan_overlay
INSTALL_MASK="/etc/systemd /lib/systemd /usr/lib/systemd /usr/lib/modules-load.d *udev* /usr/lib/tmpfiles.d *tmpfiles* /var/lib/dbus /usr/bin/gdbus /lib/udev" |
|
Back to top |
|
|
NeddySeagoon Administrator
Joined: 05 Jul 2003 Posts: 54638 Location: 56N 3W
|
Posted: Mon Mar 27, 2023 8:37 pm Post subject: |
|
|
stefan11111,
When the kernel is made with everything configured as <*> to mount root (it can be) then an initrd is only required to house userspace programs required to make the root filesystem visible to the kernel.
Than its not a burden. Its like firmware. There is no need to update it.
See for more detail.
That's based on the initrd for my arm64 server. _________________ Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
Back to top |
|
|
pingtoo Veteran
Joined: 10 Sep 2021 Posts: 1339 Location: Richmond Hill, Canada
|
Posted: Mon Mar 27, 2023 9:11 pm Post subject: |
|
|
stefan11111,
initrd (Ramfs, rootfs and initramfs), From Linux Kernel point of view, it is actually the rootfs. In Linux Kernel it is known as Early Userspace.
In majority case it is like you described, it is use to locate the real rootfs on persistent storage, so usually it will contain logic on how to identify rootfs and what module(s) required for examine connected storage system.
However It is not always necessary to use a persistent storage for rootfs. As the initrd can be a complete rootfs i.e. have /bin, /lib, /etc, /tmp, /var and /dev .... So it is possible to run entire system in RAM. Or use NFS to serve a rootfs over network. |
|
Back to top |
|
|
stefan11111 l33t
Joined: 29 Jan 2023 Posts: 937 Location: Romania
|
|
Back to top |
|
|
colo-des Tux's lil' helper
Joined: 20 May 2011 Posts: 97
|
Posted: Tue Apr 04, 2023 9:21 pm Post subject: |
|
|
To shutdown or reboot, I first log out of gui session, then root in vt and from there # shutdown -h now or # reboot. |
|
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
|
|