Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

HowTo Speed Up Boot & Increase Responsiveness (Desktop)

Share your HowTo, Documentation, Tips and Tricks. Not for support questions!.
Message
Author
User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

HowTo Speed Up Boot & Increase Responsiveness (Desktop)

#1 Post by julian67 »

Purpose

Speed up boot and application start times and general responsiveness on a desktop/laptop (i.e. not a server or console based system)

Debian, at default settings, boots rather slowly compared to some other distros and operating systems. The start up time of larger desktop applications such as OpenOffice.org Writer, Firefox/Iceweasel is somewhere between slow and glacial. And once opened, the responsiveness of applications can sometimes leave a lot to be desired.

Can we fix it? Yes we can!

Requirements

This howto uses only applications available from Debian main repository, for Lenny and newer. You'll need a package manager, a net connection, a terminal emulator and 5 or 10 minutes of your time. No other tools are needed. No special knowledge is assumed though some familiarity with Debian in general is assumed. You should follow good practice and be able to back up and restore files and directories in case disaster strikes. I'm going to use apt-get in my examples because everyone has got it and it's what I'm familiar with. You can just as well use Synaptic, aptitude etc.

You will see some warnings/advisories generated by dpkg and/or shown in package descriptions (if you read them). It is up to you to read them and make your own decisions.

I strongly suggest backing up your current configuration before making any changes, to a medium you can easily access if you render your system unbootable. Make sure you know how to restore it. Before I made any changes to my own system I backed up /etc and I can use a live utility CD such as PartedMagic or SystemRescueCD to restore /etc if necessary.

If you hose your system and didn't make a backup, or made a backup and don't know what to do with it, you can tell me all about it if you like but I don't recommend it.

Having said all the scary stuff I can also say that I had no problems of any kind.

Why We Love Debian

There are several ways to speed boot times, application starts and increase general responsiveness for desktop users. By default Debian doesn't use any of them :lol:

Boot Speed Up

You've possibly also been bored to tears by Arch fanboys banging the drum about backgrounding services. All it means is that services at boot time don't start entirely sequentially. Sequential starting means that if one process is slow to start then everything subsequent is delayed. The solution is parallel starting (backgrounding) where one service starting slowly doesn't delay the start of other services which don't depend on it.

Another thing you might notice as Debian boots is that some services start/stop/start again (firestarter is an obvious one). This is because the order of the start up scripts doesn't conform to LSB's dependency based order, to which the scripts refer.

So let's get the start up scripts conforming to LSB and also allow parallel startup.

Re-order the scripts:

Code: Select all

# apt-get install insserv
Read the warning and go ahead if you like.

Allow parallel starts:

Code: Select all

# echo 'CONCURRENCY=shell' >> /etc/default/rcS
Some people would use CONCURRENCY=startpar instead. They're basically the same thing but shell lets the output print to screen in any old order and is apparently faster.

Readahead

<edit> readahead has been replaced in squeeze by readahead-fedora. This readahead section of the howto is probably not useful or accurate if you run squeeze or newer.</edit>
The readahead package runs at boot and populate the kernel disk cache with the files that is going to be needed at boot time. To activate it, install the readahead package, touch the file /etc/readahead/profile-once and reboot once. The profiling boot is very slow, and will tune the list of files loaded to match the list of files used during the profile run.
Which sounds great but I found no benefit. I'm not the only one. It might even add a second or two :shock: but I can only suggest trying it on your hardware with your OS.

Code: Select all

# apt-get install readahead

Code: Select all

# touch /etc/readahead/profile-once
reboot.

Other issues affecting boot speed:

What services are you running? This is up to you and outside the scope of this howto. I'm assuming you don't run cups if you don't have a printer etc etc.

Replacing bash with dash as the default system shell (not log-in shell). This is/was one of the release goals for Lenny. I'm running Lenny fully up to date and /bin/sh is still linked to bash. I'm assuming the change hasn't happened because there are still important scripts which explicitly depend on bash. Try it if you like but stock up on tranquilisers/anti-depressants/bullets/ubuntu CDs first.

Application Start Up Speed

Typically the way to boost responsiveness (apparent performance) on the desktop is to use caching. While the system boots it caches to RAM the files/binaries you're likely to use. There's an excellent package to do this in Debian, called preload. Preload is all about user applications, it is not intended to speed up boot and may do the opposite (very marginally).

Preload runs as a daemon, monitoring what you actually do and adapting to that. It means that initially you see no benefit, but after you've used it for a few days or weeks it makes an unmistakable and significant difference. I've been running it for...err...so long that I'm not sure. I disabled it today and rebooted to see how my applications launched without preloading. It was hideous. Grindingly slow, and this on a Core Duo with 1.5GB DDR2. OpenOffice Writer took so long to start that I'd rolled a cigarette and put the kettle on before it was up. I re-enabled preload and rebooted. Writer fired up in a couple of seconds. Preload imo is not an option but a necessity on desktop systems.

Code: Select all

# apt-get install preload
That's it. It is configurable but the defaults should be absolutely perfect for most people.

Application/General Responsiveness

caveat: it's been a long time since I installed Debian and I'm not sure what the current fstab defaults are. This section may be superfluous now.

A huge hit on performance on Linux based OSs has been the way file and directory access times are recorded. Basically every time you merely access a file or directory, even cached, (just read it, not even modify/write to it) the access time is written to disk. I'll quote Ingo Molnar, he's Linus Torvald's right hand man on the kernel team:
I cannot over-emphasize how much of a deal it is in practice. Atime updates are by far the biggest IO performance deficiency that Linux has today. Getting rid of atime updates would give us more everyday Linux performance than all the pagecache speedups of the past 10 years, _combined_.

It's also perhaps the most stupid Unix design idea of all times. Unix is really nice and well done, but think about this a bit: 'For every file that is read from the disk, lets do a ... write to the disk! And, for every file that is already cached and which we read from the cache ... do a write to the disk!'
Luckily the solution is very easy, a quick edit of /etc/fstab in order to add either the noatime or the relatime flag. If you use noatime you don't need to also use nodiratime. Lots of people do this, and recommend it, but it's silly because nodiratime is anyway a subset of noatime.

Example:

change this:

Code: Select all

/dev/sda1       /               ext3    defaults,errors=remount-ro 0       1
/dev/sda3       /home           ext3    defaults       0       2
to

Code: Select all

/dev/sda1       /               ext3    defaults,noatime,errors=remount-ro 0       1
/dev/sda3       /home           ext3    defaults,noatime        0       2
and reboot.

There are two more easy fixes to make your system more responsive. By default the Linux kernel swaps data and applications to disk in order to free RAM. It does it really well but if you run a desktop it might make you want to scream or lie down in a darkened room. On the desktop you want (perceived) application responsiveness to be prioritised. For example could you care at all if you unzip a huge file (while getting on with other tasks) and it takes 100 seconds as opposed to 95 seconds to do this? No, me neither. But how about if now your other applications, or even your entire desktop, take 5 seconds longer to respond, i.e 6 seconds instead of 1 second, or is apparently frozen? Yup, this will drive you nuts. It's fine on servers because there's no desk jockey anxiously waiting to open another tab, play a tune or browse a directory, and data throughput is far more important than pretty much anything. But on a desktop it's truly horrible.

This can be changed in our favour in two ways. First by changing the kernel's paging behaviour. It's done with a simple file edit to /etc/sysctl.conf and adding a value for vm.swappiness. We can choose a value between 0 and 100 where 0 means the kernel tries to keep everything in RAM and not cached to disk and 100 means it aggressively caches to disk to free RAM. The default in Debian is 60, which is OK but conservative. Laptop users should in any case use a low value to reduce writing to disk (because writing to disk negates benefits of power management and runs down your battery very quickly).

Code: Select all

# echo 'vm.swappiness=20' >> /etc/sysctl.conf
The second change will affect the way the kernel frees caches of block devices vs filesystem entries. We'd prefer that when the kernel tries to free up cache it gets rid of cached block devices before cached filesystem entries, because having cached filesystem entries makes our filemanagers and other applications much more responsive than if they had to seek everything from the actual filesystem. This time we set a value for vm.vfs_cache_pressure, also in /etc/sysctl.conf. The default is 100, I don't know what the top limit might be but if you choose 0 your system may indulge in a horrible swapfest when handling large files. Try this:

Code: Select all

# echo 'vm.vfs_cache_pressure=50' >> /etc/sysctl.conf
Reboot.

Disclaimers and references

Some people, even Debian forums members, will see a howto like this as some kind of evidence that Debian is not a good desktop system. Take a minute to pity/slap them and then remind them that Debian is the Universal Operating System (if you get kidnapped by aliens, they'll be running Debian) and if they want a preconfigured desktop-centric distribution many are available. Debian requires a little configuration and then excels, exceeds all others, goes to warp factor and exterminates/saves entire galaxies (or something).

I've used noatime flag in fstab for ages and it has clear benefits and no downside for desktop users. If you run a mailserver or other application that needs to know access times, or you like to do thorough security audits you should use system defaults or maybe relatime.

Preload: imo brilliant, can't find any problem or drawback in actual use but the software's author does point some out: http://www.techthrob.com/tech/preload_files/preload.pdf You'll see your system's memory footprint increase a little as you use preload. This is a good thing. You bought that RAM to make your computer work fast, not to avoid using it and instead have everything swap out to disk. This is not Windows and we are not doofus Power Users.

vm.vfs_cache_pressure & vm.swappiness

I don't have the technical knowledge to understand every effect these values have on your OS. I've read quite a lot by kernel developers/maintainers/contributors and I certainly didn't understand all (much!) of it. I've also read a lot of other people's writings on the subject and I'm not convinced they do either :D I welcome any corrections or useful suggestions you may have regarding my understanding or method.


Some useful links:

http://packages.debian.org/lenny/preload

http://www.techthrob.com/tech/preload_files/preload.pdf

http://www.cyberciti.biz/tips/speed-up- ... ystem.html

http://packages.debian.org/lenny/readahead

http://wiki.debian.org/BootProcessSpeedup

Improve the Debian boot process - blog

http://initscripts-ng.alioth.debian.org ... harts.html

http://wiki.debian.org/LSBInitScripts/D ... yBasedBoot

http://packages.debian.org/lenny/insserv

Linux: Replacing atime With relatime

http://rudd-o.com/archives/2007/10/02/t ... -fix-that/
Last edited by julian67 on 2010-10-10 20:32, edited 1 time in total.

User avatar
MeanDean
Posts: 3866
Joined: 2007-09-01 01:14

#2 Post by MeanDean »

Good info. Nice to have this all in one place. I already use a few of the suggestions and I may try more of them. I have used dash as default for a long while and I have never ran into a problem.

I would of like to seen some before/after benchmarks for some of the suggestions though.

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

#3 Post by julian67 »

MeanDean wrote:Good info. Nice to have this all in one place. I already use a few of the suggestions and I may try more of them. I have used dash as default for a long while and I have never ran into a problem.

I would of like to seen some before/after benchmarks for some of the suggestions though.
I didn't benchmark for several reasons:

Inertia

Laziness

My benchmarks mean nothing on someone else's system, particularly the use of readahead and insserv and CONCURRENCY=shell which, I believe, will offer vastly different results depending on the services you run.

Measurement (for me) is more important where differences might be marginal or ascribed to placebo effect. noatime flag and preload offer such obvious differences that you really don't need to measure them to know it's good.

Things like vm.swappiness and vm.vfs_cache_pressure settings, if you measure things, should by definition show "worse" performance in some areas. But "worse" performance of background tasks with the payoff of excellent responsiveness on the desktop is what we want on a desktop system. I think measuring stuff might confuse people. Better to try it and just see the difference. It's why I marked the howto as (Desktop). Much of this stuff would be counter productive or redundant on a server/console based system.

anticapitalista
Posts: 428
Joined: 2007-12-14 23:16
Has thanked: 11 times
Been thanked: 13 times

#4 Post by anticapitalista »

Nice info Julian67, though on my box some had already been implemented ie noatime, preload.

insserv made very little difference, but I remember initng making a very noticeable difference in the past when I tried it. (it is not in Testing or sid though).

IMO, what really does speed up boot time is the services loaded or not at boot. This is why Arch seems so fast at first as there are hardly any services running and slows down when you add more apps that need services started.

So, if you know which services to disable, you gain a lot of boot speed.

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

#5 Post by julian67 »

Thanks

I think insserv works best in conjunction with the concurrency value. I like insserv enough just for the fact it makes the boot process more coherent if you need to actually see what's happening at boot time.

Readahead has never done anything for me except add between 5 and 15 seconds (on different systems) to boot time but I've seen a combination of preload, noatime and the sysctl values make a very obvious and beneficial difference every time. Some distros do some or other of these by default. Zenwalk certainly sets noatime and I think (from memory) a low swapiness value. I think Ubuntu uses/used readahead by default and sets the relatime flag in fstab. gNewSense is about the fastest booting "big DE" based distro I've seen so it might be worth looking at that to see what they do. I have to admit that boot time is not a huge priority for me as long as it's not excessive, but most of the responsiveness tricks impact on boot time so I thought it should all be in there.

It's true about Arch. I like to remember that when someone tells us their PIII boots in 15 or 20 seconds that they're looking at a console with not a lot of useful activity going on......I'll take the extra minute and have internal caching DNS, full desktop environment, tor, privoxy, fuse, ssh-server, 3 instances of tilda+ncurses application, virtualbox services and so on :lol:

Mr B
Posts: 183
Joined: 2008-07-26 15:30

#6 Post by Mr B »

Thanks for this tuto - works great for my lenny desktop.

Boot up is faster and desktop feels faster and more responsive :D One difference I have noticed is that shut down is a little slower (preload??)

What's the difference between preload and prelink (if any)?? and is one better than the other or can they be used together??

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

#7 Post by julian67 »

Prelink is something I overlooked. You can read about it at http://en.wikipedia.org/wiki/Prelinking

I'm sure it wouldn't be useful on a rolling release like Debian Testing because it relies on libraries not changing too often. It looks like it would be extremely beneficial on a stable release but I don't have one installed, only Testing.

When Lenny becomes Stable I intend to continue to use it for a few months at least before thinking about dist-upgrade to the new testing. I guess I'll try it then and post if it's useful.

I can't see any reason why preload and prelink shouldn't work together very well on a stable release.

Meanwhile here are some useful links:

http://usr-share-man.org/man8/prelink.html

http://web.archive.org/web/200310101721 ... s/prelink/

http://ubuntuforums.org/showthread.php?t=1971

Shutdown times:

I don't know what might have happened because you don't say which of the changes you actually made.

Mr B
Posts: 183
Joined: 2008-07-26 15:30

#8 Post by Mr B »

Apart from "readahead" I've done it all.
I've tried changing the "swappiness" before without much noticeable effect, but configuring how the caching is handled and "noatime" seem to make a real difference.

At shutdown, there is a black screen with mouse pointer for a few seconds before the kdm closes... Not serious or a problem, just an observation. I assumed it was preload saving it's data?

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

#9 Post by julian67 »

Sorry, not sure. I don't notice this on my systems (no KDE).

didi
Posts: 901
Joined: 2007-12-04 16:26
Location: the Netherlands

#10 Post by didi »

Do the swappiness and vfs_cache_pressure settings have an effect if you're not using swap space, or only when you are using it?
I have 3GB RAM, so don't expect any swapping anytime soon.

I've only applied the preload thing thus far, but haven't yet noticed a difference, but it's only been a day now.

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

#11 Post by julian67 »

didi wrote:Do the swappiness and vfs_cache_pressure settings have an effect if you're not using swap space, or only when you are using it?
I have 3GB RAM, so don't expect any swapping anytime soon.

I've only applied the preload thing thus far, but haven't yet noticed a difference, but it's only been a day now.
Probably not but it depends what you do. I have a system with 768 MB RAM and another with 1 GB and another with 1.5 GB. Even the 1.5 GB system will occasionally swap to disk, usually if I'm doing multilayered graphics editing of large files. If you edit very large files like video files, .iso images etc then you might see the same.

The big differences on a system with plenty of RAM are going to come from the noatime flag and preload. If you apply the noatime flag and reboot you'll see the difference immediately. With preload a nice illustration might be to switch it off in a few weeks time and reboot. Any doubts about its effectiveness will vanish while you listen to your HDD seeking and watch the animated gif struggle slowly across the splash the first time you start up OOo.

You know how much faster applications load when they've already been opened before in the session? Like Iceweasel opening in 2 seconds instead of 15 for example? Preload will give you that snappy performance but on first time starts on all your commonly used applications. But it does take a little while. I guess the longer you use preload the more accurately it maps your habits and the more effective it is.

didi
Posts: 901
Joined: 2007-12-04 16:26
Location: the Netherlands

#12 Post by didi »

I want to try the noatime setting too, but not before I've figured out what the (negative) consequence of it is.
I guess there is a reason it's in there and still not removed from the kernel.
And I guess it needs some extra time for preload to get my habits and act on it. And it's time I start installing the programs still missing on my system, like OO, and start using them :lol:
One of the reasons I tried it, is because I think Iceweasel is taking too long to start up, although it surely isn't 15 secs on my machine. And I haven't noticed much/any difference in it's startup time, so I'm also not getting 2 secs.
But I'm pretty confident that preloading will improve the systems (perceived) performance, just like I noticed it when Mozilla (old suite) started doing preloading.

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

#13 Post by julian67 »

didi wrote:I want to try the noatime setting too, but not before I've figured out what the (negative) consequence of it is.
There's no negative consequence unless you have applications that depend on access times to work. This is unlikely on a server and on your desktop is not even worth worrying about.

The traditional default is atime, which means every instance of a file/directory (even from cache) being accessed = a write to disk. As long as there are writes in progress then reads are slowed, as well as writes that you actually want to make. That is dumb because it means your HDD is constantly being written to, it never spins down, it kills HDD performance, HDD lifespan, system responsiveness, negates the read/write performance of modern drives and their power management and if you're a laptop user it kills your battery too. It's just horribly stupid, a relic from the past.

Some distros use noatime by default and most have now moved to using relatime by default .

User avatar
MeanDean
Posts: 3866
Joined: 2007-09-01 01:14

#14 Post by MeanDean »

didi wrote:I want to try the noatime setting too, but not before I've figured out what the (negative) consequence of it is.
I guess there is a reason it's in there and still not removed from the kernel.
Actually, there was a discussion not long ago about it and I think the agreement was that it is truly a relic. I think it was concluded that there was one (or maybe two) software packages that expected atime to be used. They were obscure packages if I remember correctly. I have used noatime for about a year now - no problems here.

User avatar
MeanDean
Posts: 3866
Joined: 2007-09-01 01:14

#15 Post by MeanDean »

julian67 wrote: Like Iceweasel opening in 2 seconds instead of 15 for example?
I never seen much difference with preload but I have only tried it with my newer systems. Maybe on a older system??? Even openoffice and firefox start up in a couple seconds the first time, well openoffice may take a little longer but not much.

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

#16 Post by julian67 »

I think it's a large bookmarks file which kills start up times on browsers. My Epiphany and Iceweasel browsers have a similar bookmark list, somewhere between 1500 and 2000 entries. I no longer have any idea how Iceweasel handles bookmarks but I know it has to either load them or load a database containing them. I also noticed when I tried Icecat I was impressed with how fast it loaded. The I imported my bookmarks into it and it was the same as Iceweasel.... :oops:

Probably the extensions don't help but I don't have many.

Epiphany is the browser I use all the time, it definitely benefits from preload and starts near enough instantly but it was quite slow to load when i switched it off. I rarely use Iceweasel and I guess it doesn't get the benefit of preload. From a cold start it's 15 seconds minimum. I've read reviews where people found it took 30 seconds + to start.

I'm not complaining too much because the only fast to start browsers when you have 1000s of bookmarks are the text based ones. I use elinks with the same bookmark set and I guess it doesn't load bookmarks into memory, it waits for you to press 's' and then it parses the text file containing them.

Anyway I have enough RAM to allow preload to allocate a chunk of it at boot to all the stuff I always use and it works very nicely :-) At the moment I'm only using laptops and while this one has a Core Duo and plenty of RAM it's still bottlenecked for disk intensive operations by a typically slow laptop HDD. It's great for CPU intensive or RAM hungry tasks but when it comes to read/write performance my old self built desktop (in storage atm) with Athlon CPU and cheapest motherboard I could find 5 years ago is much superior. I have a lot of external USB storage and I always notice how much faster a 3.5" ATA drive in an enclose is than the 2.5" SATA drive in the laptop.

didi
Posts: 901
Joined: 2007-12-04 16:26
Location: the Netherlands

#17 Post by didi »

julian67 wrote:There's no negative consequence unless you have applications that depend on access times to work. This is unlikely on a server and on your desktop is not even worth worrying about.
I've read some stuff and indeed it has no use most of the time. So I thought, what the hell ... let's try it and if I feel uncomfortable about it for some reason, it's easily reversed.
And I have to say that the boot process seems to have speed up considerably :shock:

http://tinyurl.com/wurfw from Lou's guide has quite some interesting info about atime too.
MeanDean wrote:Actually, there was a discussion not long ago about it and I think the agreement was that it is truly a relic. I think it was concluded that there was one (or maybe two) software packages that expected atime to be used. They were obscure packages if I remember correctly. I have used noatime for about a year now - no problems here.
Good to have conformation from another experienced user :)
And it made me do the obvious thing (which I hadn't), search this forum about it and already found some interesting stuff. Thanks!

Among those was this post from eyelid about mlocate (which didn't get answered):
instead of re-reading all the contents of all directories each time the database is updated, mlocate keeps timestamp information in
its database and can know if the contents of a directory changed without reading them again. This makes updates much faster and less
demanding on the hard drive. This feature is only found in mlocate.
Since mlocate is the replacement of locate (on my system) I like to make sure noatime doesn't affect mlocate's behavior. It seems to look for write times. Will that still be updated regardless of noatime and hence keep mlocate working properly?

On to reading more about this stuff.
LOL, I feel like a kid in a candy shop :lol:

User avatar
julian67
Posts: 4633
Joined: 2007-04-06 14:39
Location: Just hanging around
Been thanked: 7 times

#18 Post by julian67 »

I use mlocate and use the locate command a lot. No problems at all.

If you look at man mlocate.db you can read

[quote]Directory time is the maximum of st_ctime and st_mtime of the directory. updatedb(8) uses the original data if the
directory time in the database and in the file system match exactly. Directory time equal to 0 always causes resâ€

vmclark
Posts: 186
Joined: 2008-07-30 15:16
Has thanked: 1 time

#19 Post by vmclark »

Thanks julian67 for this tutorial. I'll give it a go. I think outside swappiness, everything else is default on my system.

anticapitalista wrote:IMO, what really does speed up boot time is the services loaded or not at boot.
This is why Arch seems so fast at first as there are hardly any services running
and slows down when you add more apps that need services started.
So, if you know which services to disable, you gain a lot of boot speed.
I found this out also. Installed Arch , was amazed at the startup speed...until I added needed
services like Gnome. It ended up that Ubuntu was faster than Arch!

User avatar
craigevil
Posts: 5391
Joined: 2006-09-17 03:17
Location: heaven
Has thanked: 28 times
Been thanked: 39 times

#20 Post by craigevil »

Yes it always funny watching people in irc boast how fast their distro boots. Until you take a look at it and very few needed services like wifi, network, etc are started at boot and the fact that they boot into a terminal. Try comparing apples to apples and not apples to pumpkins.

Even on my Eee PC 701 with 1 gb of ram running Lenny I get to LXDE in less than 30 seconds from cold boot.

Some other tweaking ideas:
http://sidux.com/PNphpBB2-viewtopic-t-3 ... aking.html
http://forums.debian.net/viewtopic.php?t=14129
Raspberry PI 400 Distro: Raspberry Pi OS Base: Debian Sid Kernel: 5.15.69-v8+ aarch64 DE: MATE Ram 4GB
Debian - "If you can't apt install something, it isn't useful or doesn't exist"
My Giant Sources.list

Post Reply