Jump to content
Hedon James

Debian advice

Recommended Posts

sunrat

What you need is Apt Pinning.

https://jaqque.sbih.org/kplug/apt-pinning.html

https://wiki.debian.org/AptConfiguration

 

It's best to stick with Stable or backports packages on Stable. You can also use pinning to hold a package to a certain version, and some packages are easy to backport yourself. Just be prepared for an occasional dependency conflict, or a more occasional total meltdown. :D

  • Like 2

Share this post


Link to post
Share on other sites
V.T. Eric Layton

Yup. The article I posted above is about apt-pinning.

 

Merry-Merry ALL! :)

Share this post


Link to post
Share on other sites
Hedon James
15 hours ago, sunrat said:

What you need is Apt Pinning.

https://jaqque.sbih.org/kplug/apt-pinning.html

https://wiki.debian.org/AptConfiguration

 

It's best to stick with Stable or backports packages on Stable. You can also use pinning to hold a package to a certain version, and some packages are easy to backport yourself. Just be prepared for an occasional dependency conflict, or a more occasional total meltdown. :D

 

Yes, this is exactly what I was looking for.  I saw the Debian Wiki, but couldn't connect the dots; your other link, and VTs link make perfect sense to me.  THANK YOU!

 

But now I have another question.  Your comments regarding backports, and meltdown warnings catch my ear.  That's exactly what I'm trying to avoid.  I had assumed that if a package was working as expected in Testing or SID, that it's simply a matter of time before it filters to stable.  But I'm thinking like the 'Buntus, rather than Debian.  Stable packages in Testing simply become part of the NEXT Debian Stable, not the current Stable, correct?  And maybe the reason those packages are stable in Testing/SID is because of dependencies in Testing/SID that aren't in Stable, and won't be.

 

So your "backports" comment makes a little sense to me.  But in my 'Buntu brain, backports are packages from a NEWER distro/version that are ported to an OLDER version.  For instance, an 18.04 LTS package ported to 16.04 LTS.  But if Debian 10 is the newest version of Debian, where does the backport come from?  Testing?  And how is that different from APT pinning, if I assign highest priority to Stable, lower priority to Testing, and lowest priority to Unstable?

 

Before I stumbled onto APT pinning and understood it as you and VT presented it, I was thinking that DEB packages are the best path forward.  That way, if I have a problem with a package, at least I can have the package manager uninstall it, reverting my system to a previously good state.

 

Keeping in mind my original criteria:  simply "fill in" packages that aren't (yet) existing in Debian 10; and given that there are only 3-4 software packages not (currently) available

 

What strategy would you pursue?  And more importantly, your reasoning for your choice?  Thanks in advance for your good advice!

 

Merry Christmas and Happy Holidays to all my BATL bruthas and sistas!

  • Like 2

Share this post


Link to post
Share on other sites
saturnian

See: https://backports.debian.org/

 

Are there a quite a few packages you'd normally get from 'Buntu repos that are not available in the Stable repos? I guess I'm lucky since with both distros I can normally just stick with what's in the repos.

Share this post


Link to post
Share on other sites
V.T. Eric Layton

I run Slackware. We don't "find" things in our repos. We just make stuff as we go along. ;)

Share this post


Link to post
Share on other sites
Hedon James
2 hours ago, saturnian said:

See: https://backports.debian.org/

 

Are there a quite a few packages you'd normally get from 'Buntu repos that are not available in the Stable repos? I guess I'm lucky since with both distros I can normally just stick with what's in the repos.

 

If something isn't in the 'Buntu repos, I'd get it from a PPA.  But Debian has been very clear NOT to do that with Debian.  I only need 2-3 or maybe 4 packages that aren't in Stable.  Off the top of my head, Kvantum, obmenu-generator, masterpdfeditor, and maybe Draftsight, although I think I can use LibreCAD as a substitute, which is in the repos.  So I'd say 3 packages.  I've got DEBs of each, but was thinking that APT pinning would be a better solution, until I saw Sunrats comment about potential issues and reading up on mixing/matching Testing & Unstable repos with Stable.  Now I'm thinking DEBs were the right solution.  Unless someone educates me with an alternative scenario of pros/cons that I haven't thought of.

 

But making my own "backports" could be an option.  I've used make install and make checkinstall to compile source into DEBs before.  Is that what I would need to do to make my own "backports"?

Share this post


Link to post
Share on other sites
securitybreach
3 hours ago, V.T. Eric Layton said:

I run Slackware. We don't "find" things in our repos. We just make stuff as we go along. ;)

 

I thought that Slackware finally got a package manager of sorts??? 

  • Haha 1

Share this post


Link to post
Share on other sites
V.T. Eric Layton

There are actually a few different package managers that can be used for Slack. The current one that comes with Slackware is "Slackpkg". I was just being kinda' sarcastic on the post above. :)

 

 

 

Share this post


Link to post
Share on other sites
securitybreach

Ah, ok. I used Slackware back when you had to

tar -xzf packagename.tar.gz && ./configure && make && su -c make install

Share this post


Link to post
Share on other sites
V.T. Eric Layton

Oh, you can still compile like that in Slack. It's pretty rare that I have to do that these days, though. If it's something that's even somewhat popular, someone (usually Robbie Workman or Eric Hameleers {alienBob}) has already made a SlackBuild for it. If I ever hit the lottery, I'm going to drop good-sized donations in both of their pockets. :)

Share this post


Link to post
Share on other sites
securitybreach

Ok, I forgot to list the worst part, running ./configure and chasing down the dependency errors until it compiled without an error. Then you hope that it doesn't error out on the make command.

Share this post


Link to post
Share on other sites
V.T. Eric Layton

Yes, of course...

 

9jHiPVg.jpg

  • Like 1

Share this post


Link to post
Share on other sites
securitybreach
7 minutes ago, V.T. Eric Layton said:

Yes, of course...

 

9jHiPVg.jpg

 

Ah yeah, the "good" old days B)

  • Haha 1

Share this post


Link to post
Share on other sites
sunrat

As saturnian mentioned, Backports is an official repo for Stable which contains packages which have been rebuilt from testing/unstable sources with dependencies on Stable to make them compatible.

You can make your own - https://wiki.debian.org/SimpleBackportCreation

Many packages have been ported for MX Linux as well so it's worth checking their repos. They even have a package request forum where you can ask for a package to be ported. MX-19 is based on Debian Buster so its packages are generally compatible.

  • Like 1

Share this post


Link to post
Share on other sites
saturnian
On 12/25/2019 at 10:45 AM, Hedon James said:

 

If something isn't in the 'Buntu repos, I'd get it from a PPA.  But Debian has been very clear NOT to do that with Debian.  I only need 2-3 or maybe 4 packages that aren't in Stable.  Off the top of my head, Kvantum, obmenu-generator, masterpdfeditor, and maybe Draftsight, although I think I can use LibreCAD as a substitute, which is in the repos.  So I'd say 3 packages.  I've got DEBs of each, but was thinking that APT pinning would be a better solution, until I saw Sunrats comment about potential issues and reading up on mixing/matching Testing & Unstable repos with Stable.  Now I'm thinking DEBs were the right solution.  Unless someone educates me with an alternative scenario of pros/cons that I haven't thought of.

 

But making my own "backports" could be an option.  I've used make install and make checkinstall to compile source into DEBs before.  Is that what I would need to do to make my own "backports"?

 

Looking forward, I'm wondering about one of my favorites -- the obmenu GUI -- which I see is not currently in the "testing" repos. It's in the "sid" repos, though. Arch has it in AUR. I could get by without it but I hope it makes it into the next "stable" release, or I'll be trying to get it some other way.

Share this post


Link to post
Share on other sites
Hedon James
3 hours ago, saturnian said:

 

Looking forward, I'm wondering about one of my favorites -- the obmenu GUI -- which I see is not currently in the "testing" repos. It's in the "sid" repos, though. Arch has it in AUR. I could get by without it but I hope it makes it into the next "stable" release, or I'll be trying to get it some other way.

 

Same with obmenu-generator...not in stable, nor testing, but in SID.  I found the latest DEB and installed via gdebi.  It's a lesser concern for me, as I'm primarily a fluxbox user, with occasional pekwm flings, but openbox has its moments also.  I prefer openbox to xfwm.  Those desktop root menus have me HOOKED (all 3 wms have that); with tabbed windows and autostart on specified windows (flux & pek) being the killer feature.  Looking forward, I'm more worried about Wayland compatibility, as all 3 of my favorites have indicated they have no intentions of porting to Wayland.  That's a ways off in the future, but I hope something changes.  I'm so invested in those functions (especially flux & pek) that I think I'd consider migrating to BSD before I migrated to a different WM.  But that's just me...

  • Like 1

Share this post


Link to post
Share on other sites
saturnian

I'm fine with either Fluxbox or Openbox. I've been using Openbox more, but my days with Fluxbox go back  much further. I recently added Fluxbox to another installation, though -- kinda becoming addicted to it again. But I hardly ever use Fluxbox's tabbed windows, and haven't used the autostart on specified windows. And I'm using the tint2 panel instead of the Fluxbox toolbar.

 

With either of those two WMs, the key feature for me is easy configuration via text files. My ~/.fluxbox/menu file has certainly evolved over the years!

 

I don't know much about the Wayland compatibility issue. It'll be a sad day for me if ever I can't use use Openbox and Fluxbox in Linux.

Share this post


Link to post
Share on other sites
Hedon James

Okay, I've finally gotten Debian 10 (stable) configured the way I like with Openbox/Fluxbox/PekWM WMs and menu/config files, but with the new LXQt desktop.  I've swapped out some of my former "favorite" tools and substituted QT tools wherever practical.  I've "filled in the gaps" of obmenu-generator, masterpdfeditor, and madebits (extensions for PCManFM) with DEB packages, and installed RefractaSnapshot & RefractaInstaller to "remaster" my system to an ISO in preparation of installing a homogeneous OS on about 10 computers in my home network.  The RefractaInstaller is different from Ubiquity and Calamares that I'm familiar with, but I figured it out and got it done.  If Linux is a "manual stick" and Windows is an "automatic"; then Debian is certainly the "stick" to Ubuntu's "automatic"; but I think I'm getting it figured out and installing proprietary firmware and/or codecs as needed.  I've been using my remastered OS on a hardware-challenged laptop, as a sort of Beta run, and I think I'm satisfied enough for installations...one machine at a time.

 

I've currently got Lubuntu 16.04.3 installed on all these machines, so I'm already "expired" from the Lubuntu support window, although I still have about 16 months left in the Ubuntu support window.  Reinstallation over the existing Lubuntu 16.04.3 OS is pretty straightforward, but my main production rig has me thinking and trying to problem-solve before the problem exists.  It's my main machine, used everyday in my business (often 7 days a week), and I can't afford to be down for an extended time frame.

 

Currently, my installation consists of a dual-boot arrangement with Win7 and Lubuntu 16.04.3 on a 256GB SSD.  This machine came with Win7 pre-installed and I only booted into Win7 ONCE, to ensure that it would, before I installed Lubuntu 16.04 side-by-side.  I've been booting Lubuntu ever since, without issue.

 

I've got my root system / on the SSD, with a /home partition on a 2TB HDD, and a 2nd 2TB HDD (twin HDD, both WD blues?) as a "Data BAK drive".  Originally, I was thinking I would duplicate this arrangement, but when I look in my existing /home directory, there's a LOT of old cruft in the form of config files for software no longer installed, BAKup files of older configs, and LXQt has a few slightly different directory/file structures compared to my Lubuntu/LXDE installation.  Which has me thinking that maybe I'd be smarter to install /home on the same / partition as my OS, and just symlink my home directory to the external HDD (I've done this before, and actually liked that arrangement) as a "Data Drive", with the added benefit of /home configs on the speedier SSD.

 

When I do a major OS installation such as this, I like to pull the original OS drive & put in a sealed plastic bag & label it for future reference, as an emergency backup situation.  So I'll probably pull the existing 256GB SSD with Win7 and Lubuntu 16.04 and store it; and replace with a new SSD for Debian 10 installation.

 

Current configuration

/dev/sda is 256GB SSD - dual boot Win7 and Lubuntu 16.04 with / partition

/dev/sdb is 1TB HDD - /home partition for Lubuntu 16.04

/deb/sdc is 1TB HDD - Backup drive for /home partition of /dev/sdb

 

Proposed configuration

/dev/sda is new SSD - configured with Debian 10 ONLY, with / and /home partition, sym-linked to external "Data Drive" HDD (former external /home HDD)

/dev/sdb is 1TB HDD - renamed "Data Drive"

/dev/sdc is 1TB HDD - Backup drive for "Data Drive" of /dev/sdb

 

I also have several USB/flash drives that mount as devices /dev/sdd-sdk.  Here's where I get nervous...limited experience with replacing hard drives.  I've bought parts and built machines from scratch, and added new drives to existing configs, but never really "replaced" a drive in a pre-built machine with OS.

 

Terminal incantations seem to suggest that my partitions use GPT partition schemes (sda, sdb & sdc), but my usb/flash drives seem to suggest they are using MBR partitions (msdos).  Furthermore, I'm pretty certain that my motherboard uses UEFI, with a "CSM" mode enabled for legacy boots.  And in order to maintain compatibility with the "emergency backup" SSD that I remove, I'd like to format the new SSD the exact same way.  So I'm not sure how to format a brand new drive now.  Do I format with GPT flags?  MBR flags?  Or hybrid flags?  And what would be the flags for each?

 

Any advice would be greatly appreciated, as I can't afford to troubleshoot unforseen issues after the fact.  I really need to have an end-to-end plan, start to finish,  before I pull the trigger on this operation.  Thanks in advance!

Share this post


Link to post
Share on other sites
securitybreach

Well if its just an additional drive, it doesn't matter if its GPT or legacy as the computer will recognize both. As far as the OS drive, there is no "flag" per se, it is about the partitioning whether you choose MBR or GPT. You won't really notice any differences on how you set them up as process is basically the same except you need a EFI partition for GPT. Look at this:

https://wiki.archlinux.org/index.php/Partitioning#Choosing_between_GPT_and_MBR

 

Also, read through this as it will explain the differences and how GPT should be setup. This is the same for any distro:

https://wiki.archlinux.org/index.php/Partitioning

 

The last link is very informative

Share this post


Link to post
Share on other sites
Hedon James

So the presence of an EFI partition indicates GPT, whereas an MBR scheme will not have that partition.  Here's a screenshot of my system, as seen by Gnome Disks, which indicates GPT correct?

 

image.png.03edd634eb04c7eda38166d79b9c3738.png

  • Like 1

Share this post


Link to post
Share on other sites
securitybreach

Correct :thumbsup:

Share this post


Link to post
Share on other sites
Hedon James
Posted (edited)
3 hours ago, securitybreach said:

Correct :thumbsup:

 

so my motherboard will force the GPT scheme it wants, unless I specifically force something else?  is it as simple as

- disconnect my old sda and connect new sda

- disconnect my sdb & sdc drives (for safety sake)

- fire up gparted on LiveUSB, create GPT partition scheme on newly connected sda (SDD drive to replace current drive) and create 500MB EFI partition (FAT32 with boot flag), format remainder of SDD as EXT4

- install Debian OS on newly formatted SSD, like I've done dozens of times before (installer "sees" EFI partition and installs GRUB there by default, without manual intervention?)

- reconnect my sdb & sdc drives so Debian can "see" them

- add fstab entries for automount of sdb and sdc devices

- symlink my SDD /home to my sdb drive as a "Data Drive"

 

What am I missing?  Anything?  Or am I over-thinking this?

Edited by Hedon James

Share this post


Link to post
Share on other sites
securitybreach

That looks fine to me but there is no need to use Gparted live as Debian will ask you about GPT or MBR:

https://linuxhint.com/install_debian_10/

 

10-14.png

Share this post


Link to post
Share on other sites
Hedon James

I'm using RefractaInstaller to install my customized RefractaSnapshot (which includes gparted), and I like my partitions carved out ahead of time whenever possible.

  • Like 1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...