ychaouche | Hello #devuan | 12:40 |
---|---|---|
ychaouche | If I want to run a script at boot time, should I just call it from /etc/rc.local or is that a bad idea ? | 12:40 |
rrq | should be fine; make sure that rc.local doesn't return with failure though | 12:42 |
ychaouche | the comment inside rc.local says "This script is executed at the end of each multiuser runlevel." | 12:43 |
ychaouche | So in theory there's a possibility that my script would be run more than once | 12:44 |
rrq | if you change runlevel | 12:44 |
gnarface | only if you change runlevels manually | 12:44 |
gnarface | everything just uses runlevel 2 | 12:44 |
gnarface | runlevel 3 now? | 12:45 |
ychaouche | how many multiuser runlevels are they anyway ? | 12:45 |
ychaouche | are there* | 12:45 |
gnarface | i don't think there's any distinction? | 12:45 |
gnarface | not sure | 12:45 |
rrq | man inittab | 12:45 |
* rrq oops wrong window | 12:46 | |
ychaouche | :p | 12:46 |
gnarface | oh, there's 4 of them | 12:46 |
gnarface | 1 isn't, apparently | 12:46 |
GyrosGeier | 0 is shutdown, 1 is singleuser, 2-5 are multiuser, 6 is reboot | 12:47 |
jonadab | Traditionally, 2 was multiuser without X11 logins (you could use startx...), 3 was multiuser with X11. | 15:44 |
jonadab | And I guess 4 and 5 were for room for expansion, not sure. | 15:44 |
jonadab | In practice, I think most modern distributions only normally ever use runlevel 3, and reboot/shutdown. Unless you trigger one of the other runlevels manually somehow. | 15:46 |
Tenkawa | back in the old old days 5 was x | 15:47 |
jonadab | Oh, was it? Ok. | 15:47 |
Tenkawa | 25 years ago | 15:47 |
jonadab | I didn't start using Linux until 1998. | 15:47 |
jonadab | So I don't know the _early_ history. | 15:47 |
jonadab | I do remember that in Debian 1.3, X11 wasn't on the main CD, you needed an additional CD, or remote repositories. | 15:48 |
Tenkawa | yeah... it was a mess | 15:49 |
jonadab | Also, that was the dselect era, which was terrible. apt is so much better. | 15:50 |
Tenkawa | indeed | 15:50 |
Tenkawa | what are they trying to do with startx btw? | 15:50 |
jonadab | Now? No idea. | 15:50 |
Tenkawa | oh I thought someone in chaneel asked something I missed | 15:51 |
jonadab | Traditionally, you could use startx to start an X11 GUI after you logged in. As opposed to having X11 running already and logging in through it. | 15:51 |
jonadab | I suppose that still works? | 15:51 |
jonadab | Haven't tried it lately. | 15:51 |
Tenkawa | yeah... painful but it works | 15:51 |
Tenkawa | I like the ease of *dm :) | 15:52 |
jonadab | It was useful if you were having issues getting your XF86Config file right. | 15:52 |
Tenkawa | or trying to get X -configure to produce a useable file | 15:53 |
Tenkawa | (that got bad once AMD & NVIDIA came on the scene ) | 15:54 |
jonadab | Oh, I had Matrox graphics cards back then. | 15:54 |
jonadab | But there could still be things I wanted to tweak, like trying to get a scrollmouse wheel working, or multiple resolutions for ctrl-alt-+ / ctrl-alt-- | 15:55 |
Tenkawa | I started on Unix itself in 79... never even had a need for graphical terminal at that point | 15:55 |
jonadab | There are relatively few things you *need* a GUI for. Photo editing is one. | 15:56 |
Tenkawa | indeed | 15:56 |
jonadab | But it's kind of nice to have. | 15:56 |
jonadab | Even if all you use it for is to run terminals. | 15:57 |
jonadab | Well, terminals and a web browser, these days. | 15:57 |
GyrosGeier | Debian never used any other runlevel than 2 | 16:00 |
GyrosGeier | and I still log in on console and run "exec startx" | 16:01 |
GyrosGeier | that's a lot saner than allowing root logins on X11 | 16:01 |
Tenkawa | GyrosGeier: and debian isnt the only os/linux out there | 16:02 |
Tenkawa | many others use tradional sysvinit levels | 16:03 |
Tenkawa | and actually you are wrong | 16:03 |
Tenkawa | root@OMENPC:/etc/rc3.d# ls -l | wc -l | 16:06 |
Tenkawa | 31 | 16:06 |
Tenkawa | /etc/os-release - PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" | 16:06 |
GyrosGeier | default config in Debian is to install start/stop symlinks into all multiuser runlevels | 16:09 |
GyrosGeier | basically, so admins have a base for local customizations | 16:09 |
GyrosGeier | so there is no difference between runlevels in packages | 16:10 |
Tenkawa | GyrosGeier: yes.... and if you want to get pedantic... it uses systemctl so these runlevels arent used at all | 16:10 |
GyrosGeier | unlike redhat, which installed xdm into runlevel 3, but not 2, and set 3 as default | 16:10 |
Tenkawa | like I said though.. this isnt all distros | 16:10 |
Tenkawa | s/systemctlsyste,d | 16:11 |
Tenkawa | er systemctl/systemd | 16:11 |
Tenkawa | cheers all.. impendending storm approaches... snow 3 days ago.. tstorms today... figures | 16:14 |
ham5urg | Is it possible to boot up without GPU (headless) and pass the built-in GPU of the server towards a VM? | 18:41 |
ErRandir | I think you would need to blacklist DRM in your hypervisor kernel, not start anything display manager and X server, and pass through the PCI device of the GPU into the VM. | 20:37 |
rwp | ham5urg, Yes. Do a web search for "kvm gpu passthrough" and you will find many guides on how to do it. | 20:48 |
rwp | (I have looked into it but so far have not done it myself yet. But supposedly it works.) | 20:48 |
lts- | There may be complications if it's the internal GPU though https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF#Passing_the_boot_GPU_to_the_guest | 20:50 |
rwp | I think it always needs to be a secondary gpu that is otherwise not touched by the host system. | 20:52 |
rwp | I was trying to set up a VM to run an old game that I liked. Thought gpu passthrough might be required. But then found using the Cirrus emulation worked excellently and did not need it. | 20:53 |
rm | wow wow exactly what I'm wrangling with today... | 20:55 |
rm | I did not succeed with the primary GPU yet | 20:56 |
rm | it appeared like setting "vfio-pci.ids=..." would allow the VFIO driver to grab the GPU early during boot https://wiki.archlinux.org/index.php/PCI_passthrough_via_OVMF#Binding_vfio-pci_via_device_ID | 20:59 |
rm | but now reading the previously posted link, it might be also needed to save and provide the VGA BIOS | 20:59 |
ham5urg | rm, did you succeed to pass through the primary GPU? | 22:12 |
rm | not yet, I did not reboot to try the vfio-pci.ids= yet | 22:12 |
rm | and just now downloaded the BIOS for my card and prepared that | 22:13 |
rm | did not reboot for that either | 22:13 |
rm | try and tell me how it goes :) | 22:13 |
rm | first I have to figure out how to make the secondary GPU to be the console GPU for host | 22:13 |
rm | radeonfb failed to load on secondary GPU on previous attempts | 22:14 |
ham5urg | rm, why you need the secondary gpu? Try without any GPU. Remotely | 22:14 |
rm | I like being able to still access the host console directly | 22:14 |
ham5urg | I use a usb-serial device for that | 22:15 |
rm | it wasn't a big deal previously to run an old PCI video card as my primary "GPU" | 22:16 |
rm | so I upgraded literally today, and now the console GPU wants an entire PCI Express slot | 22:16 |
ham5urg | rm, AFAIK, you swith gpu0 and gpu1 via bios/efi | 22:16 |
rm | so yeah I might reconsider how necessary that is, actually | 22:16 |
ham5urg | switch* | 22:17 |
rm | I don't remember seeing there a literal option to do that | 22:17 |
rm | people say on forums this is sometimes swapped as a side effect via disabling CSM | 22:17 |
ham5urg | I remember one for dell computer, but won't bet for my actual machine. | 22:17 |
rm | there could be, but only if "gpu0" would be the onboard one | 22:18 |
rm | not for when you have multiple ones in PCI-E | 22:18 |
ham5urg | Why not pass the secondary? You need an Intel GPU inside VM? | 22:19 |
rm | If I want to keep my console-only old Radeon X300SE GPU as primary, that means keeping it in the first PCI-E x16 slot, and that throws both of the main slots into x8/x8 | 22:20 |
rm | seems like a waste | 22:21 |
Generated by irclog2html.py 2.17.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!