Using Debian Bookworm, and tried adding Kali Repositories - much chaos and work (with a little bit of confusion and hilarity) ensued...

[Priest_Apostate]

Currently using Debian 12 on my laptop, and thought to learn about some of the Pentesting tools in Kali Linux (listed here). As some of the tools weren't in the Debian repos, I got the bright idea to add the Kali repositories to my /etc/apt/sources.list. My logic was that as Kali is a Debian fork, there shouldn't be too much of an issue with that. However, upon performing an apt update && apt upgrade -y, I found that the experiment/attempt resulted in my OS being overwritten by Kali OS - according to grub, neofetch and uname.

Strangely, this also affected my older Debian kernel installs: they all showed up as Kali upon rebooting the system - which prevented me from using the earlier kernel version, and attempting to mitigate the damage from there. Attempts to check out dmesg to determine what went wrong revealed nothing. As of now, I still do not know what caused the Kali OS to be imprinted over the Debian OS, as I received no prompt/confirmation to do so.

While this didn't seem to cause any other issues with my installed applications' functionality (which was also curious: all of the post-Debian-installed applications were still there - so that didn't indicate a full wipe/reinstall to me) - the fact that the OS overwrite was unintended bugged me - which resulted in me wiping and reinstalling the OS, and relearning how to re-install my wireless driver to start over (which isn't a bad thing, as I could use the practice); data was already backed up - so there was no issue there. Further researching resulted in me being recommended the application "Timeshift," which allows you to take a snapshot of your system, if I understand it correctly (though I'm unsure as to whether it would have resolved this situation). I'm also researching on how to save an image manually (both as a system restore, and--as a later project--to experiment installing upon a cloud VM).

While I wish to try this again, to find out what went wrong (as according to my understanding, even if that resulted in overwriting my OS, I didn't think it should have affected the earlier kernel versions).

EDIT TO ADD:
1. I am not experiencing any issue with my system currently, and
2. I am not trying to install Kali Linux - I was just wanting to install and work with some of the tools offered on that OS. Part of my other curiosity was to determine what would happen if I installed Kali's repositories onto my Debian install.

With the above stated, my question to you is: have you ever tried installing repos from a different Debian fork - and, if so, how did it work out for you?

 

[wendy-lebaron]

There is a lot of reason why keeps being recalled the chief creation of the chief protagonist of the novel written by this author:

Mary Shelley - Wikipedia

en.wikipedia.org

Just... don't add repositories from any other distro nor descendant. Only because another distro is based on Debian, it is tempting, but it doesn't work most of the time for a reason. Ubuntu started from Debian "Sid" and after a long while, must update that only for their repositories. Pardus have their own repositories. A few systems without "systemd" such as MX Linux have their own repositories to resolve a lot of stuff such as Wine.

With Ubuntu there are the ever-famous PPA's but those are like loading apps on the side. Not like installing a later release of "glibc" or something else deep like that which would wreck a system that has worked well, but its only problem is that it lacks certain tools.

You are trying to mix two different worlds here although one was derrived from the other. If you want Kali Linux you're better off installing it from fresh start. You cannot have convenience of a typical desktop system, and a pen-testing distro at the same time. Whoever claims could run Kali Linux as daily driver, like somebody who uses Ubuntu is lying, and even if it could be achieved it takes some sacrifices.

 

[osprey]

The usual, and informative response to the sort of situation you have described is to have a look at:

DontBreakDebian - Debian Wiki

wiki.debian.org

There it proposes some methods for installing software not found in the debian repositories.

One relatively safe way of installing such software is to seek out the tarballs upstream, often in github or some other development site, and install into /usr/local files, whilst noting all the dependencies described for the software, usually in a README or INSTALL file once the tarball has been decompressed. It's sometimes the case that the dependencies have been satisfied by existing debian packages which may or may not be installed, so that makes things easier, otherwise dependencies may need to be installed also in the /usr/local directories. Careful and sometime painstaking attention can be successful with this method. It's partly the reason that the /usr/local directories exist.

 

[Priest_Apostate]

Just... don't add repositories from any other distro nor descendant. Only because another distro is based on Debian, it is tempting, but it doesn't work most of the time for a reason. Ubuntu started from Debian "Sid" and after a long while, must update that only for their repositories. Pardus have their own repositories. A few systems without "systemd" such as MX Linux have their own repositories to resolve a lot of stuff such as Wine.

With Ubuntu there are the ever-famous PPA's but those are like loading apps on the side. Not like installing a later release of "glibc" or something else deep like that which would wreck a system that has worked well, but its only problem is that it lacks certain tools.

Gotcha - thanks for this explanation! I didn't want to install Kali Linux on the laptop (I prefer that as a VM on the laptop) - I just wanted some of the tools to test/learn upon.

You cannot have convenience of a typical desktop system, and a pen-testing distro at the same time. Whoever claims could run Kali Linux as daily driver, like somebody who uses Ubuntu is lying, and even if it could be achieved it takes some sacrifices.

Why not? What sacrifices are there (as in: others in addition to what was mentioned above)? Not trying to throw shade - I just don't understand how there would be an issue using tools that were stock installed to Kali, upon Debian.

 

[Priest_Apostate]

The usual, and informative response to the sort of situation you have described is to have a look at:

DontBreakDebian - Debian Wiki

wiki.debian.org

There it proposes some methods for installing software not found in the debian repositories.

One relatively safe way of installing such software is to seek out the tarballs upstream, often in github or some other development site, and install into /usr/local files, whilst noting all the dependencies described for the software, usually in a README or INSTALL file once the tarball has been decompressed. It's sometimes the case that the dependencies have been satisfied by existing debian packages which may or may not be installed, so that makes things easier, otherwise dependencies may need to be installed also in the /usr/local directories. Careful and sometime painstaking attention can be successful with this method. It's partly the reason that the /usr/local directories exist.

Thanks for this info as well! You don't learn without making some mistakes!
I am curious about something on that page, though: how does one perform "apt pinning?"

 

[wizardfromoz]

...(though I'm unsure as to whether it would have resolved this situation)...

Yes, Timeshift could have resolved that in a few minutes.

I have been using it for 9 years and 4 months, since about 3 months after it was first released.

I run 83 Linux distros and have Timeshift installed on each and every one.

If you are interested in using it, come and see me over at my Thread at


https://www.linux.org/threads/timeshift-similar-solutions-safeguard-recover-your-linux.15241/page-18

... and yes, that's page 18

and I can customise a plan for you

On the pen testing apps here, if you give me, say, a half dozen of the apps from Kali that aren't in your Debian repos, I might have some ideas.

Cheers

Wizard

 

[Priest_Apostate]

Yes, Timeshift could have resolved that in a few minutes.

I have been using it for 9 years and 4 months, since about 3 months after it was first released.

I run 83 Linux distros and have Timeshift installed on each and every one.

If you are interested in using it, come and see me over at my Thread at


https://www.linux.org/threads/timeshift-similar-solutions-safeguard-recover-your-linux.15241/page-18

... and yes, that's page 18

and I can customise a plan for you

On the pen testing apps here, if you give me, say, a half dozen of the apps from Kali that aren't in your Debian repos, I might have some ideas.

Cheers

Wizard

Thanks for that information!
My understanding was that Timeshift was useful in just making a snapshot of the filesystem - as such, it wouldn't have been as useful, as the filesystem didn't change when it overwrote the OS. I am also not sure as to what Timeshift would have done to restore the earlier kernel versions.

While I have everyone here, I have another question: I am experimenting (just for learning purposes) with compiling kernels for Debian from kernels.org - as opposed to just updating to the Debian kernel versions listed with the "aptitude search linux-image" command. As that command only goes up to 6.5.0 - but kernels.org offers 6.6.9, my question is: would I suffer any issues by compiling and updating the Debian kernel with the 6.6.9 available on the kernels.org - or should I just stick to the kernels offered by the "aptitude search" command?

 

[Brickwizard]

My advice for those of limited Linux experience, who wish to play with Pen-testing is to use one of the more friendly Pentesting distributions [defiantly not Kali], and run it either in a VM or from a pen-drive with persistence, using either of these methods will protect you daily drive and machine, when you bulk it [which you will at some point]

 

[Brickwizard]

would I suffer any issues by compiling and updating the Debian kernel with the 6.6.9 available on the kernels.org

The kernel offered by your distribution will have been tested to ascertain that it will cause minimal problems, by the distribution builders, you can update to the latest offering direct from Kernel.org but at your own risk

 

[Priest_Apostate]

My advice for those of limited Linux experience, who wish to play with Pen-testing is to use one of the more friendly Pentesting distributions [defiantly not Kali], and run it either in a VM or from a pen-drive with persistence, using either of these methods will protect you daily drive and machine, when you bulk it [which you will at some point]

I wasn't trying to install Kali Linux to the system - I was just wanting to install some of the tools being offered on the OS, to gain more familiarity with said tools.

I am also curious: what are the other pentesting distributions to which you refer - the more friendly ones? I ask, as the ones mentioned here seem to list Kali as being the most recommended, for ease of use, all around support, and documentation.

 

[Brickwizard]

what are the other pentesting distributions

in no particular order, these are the ones that spring to mind [there are more if you search]. Parrot is probably the friendless to the newbie [admit bias as Im a mod on their forums] heard good things about Pentoo although its comparatively new. and with a good training plan HTB stands out

Parrot
Samuri
Pentoo
Caine
Network
Fedora security spin
Black Arch
Arch strike
HTB [Hack the box]

 

[Aristarchus]

Thanks for that information!
My understanding was that Timeshift was useful in just making a snapshot of the filesystem - as such, it wouldn't have been as useful, as the filesystem didn't change when it overwrote the OS. I am also not sure as to what Timeshift would have done to restore the earlier kernel versions.

While I have everyone here, I have another question: I am experimenting (just for learning purposes) with compiling kernels for Debian from kernels.org - as opposed to just updating to the Debian kernel versions listed with the "aptitude search linux-image" command. As that command only goes up to 6.5.0 - but kernels.org offers 6.6.9, my question is: would I suffer any issues by compiling and updating the Debian kernel with the 6.6.9 available on the kernels.org - or should I just stick to the kernels offered by the "aptitude search" command?

There is nothing wrong with custom kernels: I have used customized kernels in OpenBSD, FreeBSD, Gentoo, Arch, Slackware, Devuan and so on.
First thing is to understand how to add, not replace kernel to your boot manager so if custom build fails, you can easily boot your distro default kernel.
However, the question is why do you want to build custom kernel.
Your Kali mishap suggest that you act first, then ask questions if something fails. Unless you reverse this attitude: read first, ask questions and then act, you will stumble on many issues that in fact aren't issues at all.

 

[wizardfromoz]

Three points to explain here, I'll take the "oldest" one first.

1.

However, upon performing an apt update && apt upgrade -y, I found that the experiment/attempt resulted in my OS being overwritten by Kali OS -

With using the -y option, this tells apt to follow through with any and all changes without asking your permission or prompting you for an interactive choice, or warning you.

So if there was ever going to be a point where Linux would have said something like "Hey, I'm about to overwrite all your Debian stuff with Kali stuff, do you want to proceed? Y/n" - that was not going to appear.

2. Whenever you are going to add software that is not in your distro's repositories, you should first have in place a backup solution, and/or a recovery solution, the latter so that you can roll back your system to a working state from the time before you made the changes.

The data for such solutions preferably should be stored on a different drive, which might even include a large enough capacity USB stick. If not, you have no recourse if your entire operating system goes down the drain.

Also have a Live USB stick available that you can use to boot the system and access the backup/recovery solution data. In your case, that might be a Debian stick. It's like having the Windows installation DVD.

For below, it is useful to have a Linux Mint Live or Linux Lite Live stick, as both have Timeshift on them by default, but you can still temporarily install Timeshift on any live USB stick.

3. On Timeshift - it is not technically a backup solution. My best friend here describes it as being "like Windows System Restore ... except it works".

You can schedule it to create snapshots, or run them manually (I do the latter). The snapshots include all the system files and folders required to restore to the previous state. Not the default, but you can include your Home folder or partition. I do, but I keep all my important docs, photos and videos elsewhere - I include Home to recover all my settings.

So

that Timeshift was useful in just making a snapshot of the filesystem - as such, it wouldn't have been as useful, as the filesystem didn't change when it overwrote the OS. I am also not sure as to what Timeshift would have done to restore the earlier kernel versions.

... becomes a non-sequitur. A Timeshift snapshot previously taken would have restored your Debian, including kernels, to the point before you added the Kali repos to /etc/apt/sources.list. You would then have a working system, and not add the Kali repos, but source an alternative or ask here.

Cheers

Wizard

 

[Alexzee]

My advice for those of limited Linux experience, who wish to play with Pen-testing is to use one of the more friendly Pentesting distributions [defiantly not Kali], and run it either in a VM or from a pen-drive with persistence, using either of these methods will protect you daily drive and machine, when you bulk it [which you will at some point]

Tried Parrot, it rocks!

 

[Vimmer]

Whoever claims could run Kali Linux as daily driver, like somebody who uses Ubuntu is lying, and even if it could be achieved it takes some sacrifices.

More likely that too many see themselves as experts just because they have some basic knowledge from the internet, its kinda disturbing seeing lots of people make claims things working even though they haven't tried it...

 

[Vimmer]

Further researching resulted in me being recommended the application "Timeshift," which allows you to take a snapshot of your system, if I understand it correctly (though I'm unsure as to whether it would have resolved this situation).

Timeshift basically just makes a boot restoration image of your OS in its current state, at least thats what it seemed to be when i tried it out.

 

[Aristarchus]

More likely that too many see themselves as experts just because they have some basic knowledge from the internet, its kinda disturbing seeing lots of people make claims things working even though they haven't tried it...

have you red OP's first post:

As some of the tools weren't in the Debian repos,..

He did not want to install Kali. Not to mention that there is nothing wrong about Kali. Any distro can be screw up or not.

 

[Vimmer]

have you red OP's first post:

He did not want to install Kali. Not to mention that there is nothing wrong about Kali. Any distro can be screw up or not.

Oh, i was just speaking in generalizations about "lying", i dont see how your point is really connected to what i was saying

 

[Priest_Apostate]

have you red OP's first post:

He did not want to install Kali. Not to mention that there is nothing wrong about Kali. Any distro can be screw up or not.

Thank you - I am trying to understand why are people thinking that that was my intention; while I have Kali as a VM, I just wanted to add the Kali repositories (which has been discouraged by the above posts).

 

[Alexzee]

Most of the packages for Kali are from the Debian Testing repo.
I did a quick search and found out that newer packages may be imported from Debian Unstable or Debian Experimental, to improve user experience.

Check your sources.list and you should be good to go and enjoy your Kali Linux in a vm.