“The XDNA driver will work with AMD Phoenix/Strix SoCs so far having Ryzen AI onboard.”. So only mobile SoC with dedicated AI hardware for the time being.
Welp…I guess Radeon will keep being a GPU for gaming only instead of productivity as well. Thankfully I no longer need to use my gpu for productivity stuff anymore
After my bios splash, it shows „welcome to grub“ and then switches to the debian start menu for 3 seconds or so, then shows some terminal stuff and then starts kde splash and then login.
Yeah, the reason for this is that sometimes Debian doesn’t enable Plymouth splash screens by default, so you just see the text stuff. It actually annoys me a bit.
Not on my computer at the moment, so I can’t remember the exact packages you might need, but if I recall, they should be plymouth-themes and kde-config-plymouth (so that you can choose the splash screen theme in your system settings). You can also find other themes online, but I forgot the name of that website where all the stuff is. Pling? I think it’s that.
Anyway, once you have the themes installed, you need to sudo edit /etc/default/grub and append “quiet splash” (with the quotes) to GRUB_CMDLINE_LINUX_DEFAULT= (“quiet” might already be there).
You can also change the value of GRUB_TIMEOUT= in that file to whatever your preference might be for the duration of grub’s boot menu, but there might be other things you need to adjust in order to hide it completely and still be able to access it if necessary.
After that, run sudo update-grub so that it’s using the new config and choose whichever theme you want in the system settings.
Alternatively, grub-customizer is a GUI app that you can install to do all of the above (which will also update grub when you save your changes). Just don’t touch anything that’s not relevant. Stick to just the duration of the grub boot menu and add the splash parameter. Ignore boot priority, etc.
It should feel less “slow” to start up once all that’s sorted.
Yeah, the reason for this is that sometimes Debian doesn’t enable Plymouth splash screens by default, so you just see the text stuff. It actually annoys me a bit.
I always go through and turn off all the stuff that’s covering up the diagnostic information that I want to see, myself.
Looks like ee is legacy mbr type with an EFI entry right after it, it could be that somebody has solved mounting this if you deep dive. And maybe an additional package is needed. Buy are you able to remount to sata and just transfer data? becuase you would want to reformat this to a modern GPT and filesystem at some point. Or see if you can pass it through to an XP VM for data transfer.
I tried installing Debian recently as well but didn’t get too far into it. I was annoyed at the base configuration* though. I wasn’t able to use sudo, so I went to add myself to the sudo group and it told me the command didn’t exist… I looked it up and realised that /usr/sbin* wasn’t on terminal path. Extremely fixable but something I never ran into on other distros, made me nervous how many other tweaks I may have to do.
I was simultaneously testing Lubuntu and ended up sticking with that after following install instructions for another app kept complaining about bookworm errors. Perhaps the Debian version was too new?..
Edited a couple of details to make them more accurate.
I suppose it depends on a lot of things. Errors are pretty common once you start installing a lot of apps in any distro imo. Especially unstable and sid are more up to date but as the name suggests less stable.
beside op’s bashrc fud, it’s a common newbie misconception that testing and sid are not stable like some kind of exotic experimentation would make them so. It is more a stabilization process in respect to the project’s policy/processes and you will definitely find /usr/bin in pathh in either testing and sid rofl
Thats stable atm. No clue what it was back then. It took me a bit to add myself to the sudo group since sudo visudo doesn’t work. No idea what the use of that is.
you obviously can’t use sudo visudo if you’re not already in the sudoers file LOL - is the same security, which you also desire, as having a spare set of keys in the bowl at the entrance to your house, where, however, no one comes unless they already have a key to open the door
I made a mistake, fine. Visudo doesnt work either from my recent experience. At the very least, it should say „dont use sudo as root“ instead of „the command doesnt exist“.
You could have explained it without the elitist touch. Tyvm
I added my user to the sudo group and rebooted (as relogging doesnt work either).
So, debian is cool but you can definitely see how fanboiism keeps it from being great.
and instead you needed a slap on the wrist so the next time you come to lemmy you’ll think twice about pointing out a community, whatever it is, as idiotic to the point of making a trivial mistake that only you know how to fix with a more-than-trivial workaround. It’s not a matter of being a debian fanboy, in this case the distro packages the vanilla behaviour of an upstream present everywhere, which does exactly the same thing everywhere
I have no idea what you‘re talking about. I didnt point out anything and surely didnt need a slap on the wrist. Whatever bdsm fantasy you‘re having atm.
I was nice enough to admit my mistake, whereas you were a jerk enough to make fun about it you sad person. Now go away.
Well, I don’t know what to tell you when I had just installed and the system tells me the command does not exist, so I look up the error and adding the path to bashrc fixed the issue. The only PATH export in that bashrc file is the one I added after searching the issue.
Well, I don’t know what kind of mess you made on your machine, nonetheless I find it mind-boggling your assumption that one of the most used/derived distros in the world exits the installation with such an error without anyone noticing/fixing it. That said, glad you fixed it, and for the affection I feel for the Debian project, even happier that you are not a user of it :P
You don’t need to be defensive about this. I’m just sharing my experience, I’m not trying to insult Debian or it’s maintainers. And yes I believe anything can happen considering the crazy bugs I have seen get shipped. Windows wiping One Drive files, multiple Steam bugs on Linux that can wipe your system, etc. Or it may be my choices during install, but it is still unusual compared to all of my Ubuntu installs.
Anyway, I took another shot at it and it still happened. I downloaded the 12.4.0 net install that is on the front page of debian.org. Installed two different times in Virtualbox, once using the graphical and once using the CLI install, using two different mirrors. I unchecked Gnome and ticked LXDE during installation (as I did before), because that is the DE I wanted. I would hope that would not change bashrc settings. Tried sudoing and got the exact same error. https://i.imgur.com/dhFnLgc.png
Here’s the generated .bashrc which I have not touched.
.bashrc`# ~/.bashrc: executed by bash(1) for non-login shells. # see /usr/share/doc/bash/examples/startup-files (in the package bash-doc) # for examples # If not running interactively, don’t do anything case $- in i) ;; ) return;; esac # don’t put duplicate lines or lines starting with space in the history. # See bash(1) for more options HISTCONTROL=ignoreboth # append to the history file, don’t overwrite it shopt -s histappend # for setting history length see HISTSIZE and HISTFILESIZE in bash(1) HISTSIZE=1000 HISTFILESIZE=2000 # check the window size after each command and, if necessary, # update the values of LINES and COLUMNS. shopt -s checkwinsize # If set, the pattern “**” used in a pathname expansion context will # match all files and zero or more directories and subdirectories. #shopt -s globstar # make less more friendly for non-text input files, see lesspipe(1) #[ -x /usr/bin/lesspipe ] && eval “$(SHELL=/bin/sh lesspipe)” # set variable identifying the chroot you work in (used in the prompt below) if [ -z “${debian_chroot:-}” ] && [ -r /etc/debian_chroot ]; then debian_chroot=$(cat /etc/debian_chroot) fi # set a fancy prompt (non-color, unless we know we “want” color) case “$TERM” in xterm-color|-256color) color_prompt=yes;; esac # uncomment for a colored prompt, if the terminal has the capability; turned # off by default to not distract the user: the focus in a terminal window # should be on the output of commands, not on the prompt #force_color_prompt=yes if [ -n “$force_color_prompt” ]; then if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then # We have color support; assume it’s compliant with Ecma-48 # (ISO/IEC-6429). (Lack of such support is extremely rare, and such # a case would tend to support setf rather than setaf.) color_prompt=yes else color_prompt= fi fi if [ “$color_prompt” = yes ]; then PS1=‘${debian_chroot:+($debian_chroot)}[
lol I’m not defensive at all, I swear I don’t need that :D. The theme here is that you keep thinking you don’t have an ass because you’re looking for it on your forehead instead of between your butt cheeks :D
What we can already see:
sudo is indeed installed, and in path
bash is running since system is newly installed => /usr/bin is obviously in path (bash lives in /usr/bin/bash)
set | grep ^PATH will show that /usr/bin is indeed in path, also the fact that grep runs tell it path is correct, since grep lives in /usr/bin/grep :)
that said, your user isn’t in the sudoers file because you choose to give login access to root during install (which is strange, because no sudo package get installed if you choose that, so you probably made some other strange not-obvious thing), and no, groupadd can’t be run by the user you keep being after a failed sudo invocation (of course you can invoke it w/ the fully qualified path which is /usr/sbin/groupadd w/ /usr/sbin not in user’s path because the binary here usually require high permissions).
now you have a chance to learn something: where is PATH env var configured? Is it in your home or outside? Why and how it gets parsed?
cmon, let’s explore a bit my good boy, let’s be curious about the world that is not wrong by default and only we are right ;) let’s learn stuff, for real
I never said sudo was not installed, I said I wasn’t able to use sudo, which I wasn’t. This is why I went to run groupadd, which is when I discovered that it is not on PATH, which it isn’t. You’re right I shouldn’t have run groupadd as an unpriviledged user, that is fair, although it also isn’t on my root PATH. https://i.imgur.com/xJsXMVX.png
You’re also correct that /usr/bin is on PATH, so my initial statement is not correct: /usr/sbin is not on PATH. Forgive me mixing up the two, it didn’t seem like an important disctinction earlier when I recalled the experience off memory.
Going back to my original post though, I was simply stating that every Ubuntu variant I have used sets me up with all this out of the box, meanwhile Debian immediately required more set up. It felt more “raw”. I can see the logic behind these changes, but as a new user it was off-putting as compared with every other distro I had used. That is all my point was. I got around the issue, it was not world-ending, but, to quote earlier me, I “was annoyed”. Simple as. I was sharing my experience with Debian because the pitfalls I encountered seemed relevant to the thread title: coming from Ubuntu to Debian.
now you have a chance to learn something
cmon, let’s explore a bit my good boy, let’s be curious about the world that is not wrong by default and only we are right ;) let’s learn stuff, for real
I am not averse to learning and I have learned a couple of new things, yes. Thank you for the insight. It doesn’t change my initial statement.
your user isn’t in the sudoers file because you choose to give login access to root during install
This makes sense, thanks. I don’t really mind not having sudo from install though, I mentioned it because it is what started me down the “groupadd” road.
so you probably made some other strange not-obvious thing
I followed the graphical install and used default options except for LXDE.
as you wish my friend, I see no value in insisting you’re doing something wrong. Good luck with your distro of choice which, I repeat, I’m glad isn’t debian :D (still PEBKAC, but really, no value in insisting :PPP)
/usr/sbin not being included in PATH by default is definitely annoying, but I understand why it is that way. It’s because they’re infrequently accessed admin tools.
If it was my decision, I’d include them in PATH though.
and I understand you reason that way because you have no clue and THAT’S OK (to some extent). Go ahead and be free, all of this shit is ultimately about that and I’m glad too because I know I’ll keep having a predictable, understandable system so yay for us my friend :)
also, there is not a “specific default”, I don’t care about debian and even if I’m not using since longtime in this thread stupidity has been expressed :P
I read your entire comment and responded to everything relevant. I didn’t break down every sentence word by word because most people don’t enjoy reading those sorts of replies, so I kept it to the bits that required a response. I don’t know what you are talking about at this point, but considering I had the attention span to spend an hour re-installing Debian twice to verify, I don’t think that is the issue here. I have been exceedingly pleasant considering your condescending tone, so your repeated quips and assumptions of the worst are uncalled for.
I stated an experience I had that I disliked. You stated my experience didn’t happen, and I have laid out how it occured and explained what my initial issue was. I am allowed to dislike how a distro does things while acknowledging it is doing those things intentionally. I thank you for the bits of wisdom amongst your snark, but I’m going to go do more enjoyable things now. And maybe I’ll use Debian on my next server, sorry to disappoint you since you are so determined to gatekeep it (or why else are you so glad I’m not using it?).
sure you’re right! Go ahead, not that I care a lot :P
probably belonging to a divine elite, or maybe one of assholes, it’s enough for me to pay my bills knowing how to use the systems and after a quarter of a century I don’t give a shit if on lemmy some pirate comes along and tells me otherwise, my bills keep paying so ciaoooo :)
also let’s be curious about the things we copy-paste in order to prove whatever theory: in literally the first line of your bashrc non-login shells are named. What are those non-login? If we need to defined them like that, do also we have a non-non-login ones? How do they get executed? How do they get initialized? Let’s explore and understand some new stuff (that we should have learned already, but who cares, it’s not our job!)
It was probably /usr/sbin you’re thinking of rather than /usr/bin. IIRC – don’t quote me on this – Red Hat puts it in non-root user paths by default, and Debian doesn’t.
You’re correct. That’s one of the few useful things superbirra mentioned, and I’ve updated the parent comment to correct my initial error. I was recalling from memory and just remembered it was a “bin” folder.
Good but slow. Zypper has nice features but for some reason it can only download one package at a time. There is a GitHub issue about this that has been around for years.
The biggest is the baked in support for nVidia GPUs, but their DE has a lot of work done to it for usability purposes. No real advances have been made over the past few years to really set it apart again, but there is a massive overhaul coming that will make it one of a kind again.
To clarify, Cosmic desktop is not the default. It’s very much a WIP. Pop OS uses Gnome by default. They add some nice customizations to it too like tiling support and some enhanced power management options.
Pop OS is Ubuntu based, but they replace Snap with Flatpak, package a kernel as close to mainline as possible, and include Nvidia drivers (if you grab the Nvidia installer ISO).
I used Pop for a few years, loved it. Last I used it they still defaulted to Xorg instead of Wayland and that was a no go for me with an eGPU so I switched to Opensuse.
LMDE is really great. Just migrated an old 2013 iMac to it today. Everything works out of the box. Everything easy like you can expect from Mint and stable like on Debian. Difficult not to love.
That sounds great. The last driver they released fixed Starfield but broke Cyberpunk for me, pretty bad trade. Hopefully this rolls around to my distro soon
I think the first time you are trying to mount the drive and not the partition “sudo mount /dev/sdc /mnt” and on the second and third attempt have the sdc1 right, but need to make a folder under mnt to mount the drive onto. Make a folder like ‘tempdrive’ under /mnt and then try it with this since you said it was an ext4 filesystem. Note, you can name it whatever you want I just picked that as an example:
cd /mnt
sudo mkdir tempdrive
sudo mount /dev/sdc1 /mnt/tempdrive
If it doesn’t recognize the filesystem then use -t
sudo mount -t ext4 /dev/sdc1 /mnt/tempdrive
And yes, once you get it down, an fstab entry will make this mount every time, but I would use the uuid in the fstab. I have two mounted on a machine like this in my /etc/fstab:
You can run different userland drivers but not kernel drivers. Thankfully the kernel drivers are pretty much unified for AMD. to use the proprietary ones, install the appropriate driver in the distrobox container.
Vulkan and Opengl are different drivers so you will need to figure out the flags you need to set appropriately. arch wiki is a food resource for this.
For rocm and stuff make sure your kernel has the necessary bits, this will be distro specific, but I can at least say arch will work fine simply. and fedors too iirc
Your fdisk output shows a single partition of type ee which according to en.wikipedia.org/wiki/GUID_Partition_Table is the type for the protective MBR partition shown by MBR tools when looking at GPT partition tables.
Try using gdisk -l instead of show the GPT partition table.
linux
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.