Please note: Starting with Debian 7, the minor number is not part of the Debian release number, and numbers with a minor component like 9.4 or 9.7 now indicate a point release. Basically, only security updates and major bug fixes, with new updated installation media images. This, 10.3, is not a new major release of Debian.
Yup this is basically a cumulative update to Debian 10 buster. apt update && apt upgrade picks it up just fine, and there are no obvious performance issues.
> Basically, only security updates and major bug fixes, with new updated installation media images.
With a tiny exception for the two most complex packages, Chromium and Firefox, which have different support cycles from Debian plus different levels of arch support. For those you get a wholesale application upgrade which may or may not work given your arch and version of stable.
Not a big deal atm, but if the web or the arm architecture ever takes off this may become an issue.
Did you know that Debian releases are named after characters from the Toy Story films? I began using it with Debian 4 (Etch) in 2007. It was named after Etch A Sketch[1], one of Andy's toys. The latest release, Debian 10 (Buster), is named after Andy's pet puppy[2].
The name Debian itself is a portmanteau of the names Ian Murdock (the creator of Debian) and Debra Lynn (his then-girlfriend, later ex-wife). As a result, this name has been called a curiously personal name for such a community-oriented project.[3]
I was using Fedora and Ubuntu in 2007 when a member of a local Linux User Group (LUG) introduced me to Debian. Its simplicity and elegance, its vast package repository, and its stability and robustness made me an ardent user of this distribution pretty quickly. Thirteen years later, I still use Debian on my laptops, Linode servers, and virtual machines. I run my personal website[4] on Debian too. I have got so used to "apt-get install" and the large number of tools available in the Debian repositories that I keep a Debian VM or a remote shell handy when I am working on a non-Debian system. Over these years, I have gradually moved from GNOME 2 to GNOME 3 and then to Xfce 4. It really helps that Debian provides an installation CD with Xfce as the default[5]. In case anyone is interested, I have documented and shared my Debian setup notes on GitHub[6].
My first Debian install was 2.0. I ordered the CD's (there were 2, as I remember) from an on-line shop that sold burned CDRs with linux images. I wish I could remember their name...
From Ian Murdock's wikipedia page, the debian's founder: "He named Debian after his then-girlfriend (later wife) Debra Lynn, and himself (Deb and Ian).[3] They later married, had three children, and divorced in January 2008.[4]"
Sadly, Ian committed suicide in late 2015. It's great to see that the distro is still going strong.
I remember back around 2005, I missed meeting him by a ~week. My college Linux users group was having a birthday party for Debian, and Ian was an alumnus of that school, so he was going to attend. It was right before the semester started, so I was out of town.
Yup. I don't have the pleasure of working with Linux at my current job nearly as much as the last one, but Debian was (and still is) my preferred distro for running servers
> I was using Fedora and Ubuntu in 2007 when a member of a local Linux User Group (LUG) introduced me to Debian. Its simplicity and elegance, its vast package repository, and its stability and robustness made me an ardent user of this distribution pretty quickly.
I'm curious why were you so impressed by Debian in comparison to Ubuntu? Ubuntu is based on Debian and shares most of the mentioned features, yet your observation sounds like you experienced them as two very different systems.
That would explain why my PXE installs broke yet again (with that oh so familiar error message about a mismatch between the kernel and modules versions)!
Fortunately, it only takes a minute to grab the latest mini.iso, mount it, grab the kernel and initial ramdisk images (and "cat" the non-free/unofficial firmware to the end of the ramdisk), push 'em up to the TFTP server, and be right back in business.
Yep, but the TFTP server doesn't run Debian so this is the easiest "solution" for me.
When it does break, it literally takes less than five minutes to get it working again. Looks like I'd been using the previous kernel and initramfs since 2019-09-05 and, well, I can deal with spending five minutes on an issue once every five months -- especially considering all the time that it saves me!
(At one point, I insisted -- for some unknown reason! -- on using the weekly "unstable" images so the breakage was much, much more frequent. Fortunately for my sanity, I finally gave up and went back to just using the latest "stable" mini.iso.)
Thanks for the suggestion but, no, this won't work for me.
---
Long answer:
Unfortunately, no, that doesn't help me as I don't really even need an ISO image at all. What I really need is just the new version of the kernel ("linux") and initial ramdisk ("initrd.gz") files.
I don't need the regular ("cdrom") ones (like you might find on a regular ISO image), though. I need the "netboot" ones -- yes, they're different! Well, the kernel is usually the same but the initrd.gz is different.
When a new version of the kernel and modules show up on the servers (and once my local "cache/proxy" notices them and downloads the newer version of the modules), my network installs will start failing. See, a host PXE boots the existing version of the kernel but when debian-installer launches and starts downloading the modules it needs, it finds that they were built for a different version of the kernel than what it booted from. This causes "that oh so familiar error message" to be thrown [0] and the installation to fail.
The "fix", obviously, is to boot the new kernel instead of the old one.
As I mentioned, all that I really need to do is replace the existing versions of the linux and initrd.gz files on my TFTP server with the new ones. In theory, I could just SSH into the TFTP server, "cd" to the appropriate directory, fire off a single "wget" (the URLs for those two files don't even change!), and be done; real life is, however, (only slightly) more difficult!
Now, once in a very great while, I will actually do an installation on a VM where I do use an ISO image instead of performing a network install. That's why I just go ahead and grab the ("netboot") "mini.iso" file and extract the linux and initrd.gz files out of it instead of downloading just those files in the first place.
The other thing has to do with the "non-free" firmware. Although they provide ISO images that include it, it was easier for me to just do it myself. Once I've got the linux and initrd.gz files downloaded, all that is needed is to download the "firmware.cpio.gz" file if I don't already have it (or if a newer version is available or something) and (literally) "cat" initrd.gz and firmware.cpio.gz together.
Then, I replace the existing linux and initrd.gz files on my TFTP server with these two new files and reboot the host so that it restarts the network install! Depending on the hardware, it sometimes takes the server longer to POST and get to the point where it actually starts booting than it takes for the actual OS installation (I'm looking at you, Dell PowerEdge servers!).
It may sound like a fustercluck but it's actually pretty simple (just a few commands) and from "uh oh, the install failed" to "okay, it's working again" is almost always less than five minutes (well, it is now that I switched back to using the "stable" mini.iso images instead of the daily or weekly "unstable" ones!). I could write a script to automate it, I suppose, but it doesn't seem worth it as it only happens two or three times a year.
(That's a rather long way of saying "no, that doesn't help" but since you offered a suggestion I wanted to explain why and not simply dismiss it with a "no, that doesn't help"!)
23 comments
[ 1.6 ms ] story [ 68.6 ms ] threadWith a tiny exception for the two most complex packages, Chromium and Firefox, which have different support cycles from Debian plus different levels of arch support. For those you get a wholesale application upgrade which may or may not work given your arch and version of stable.
Not a big deal atm, but if the web or the arm architecture ever takes off this may become an issue.
The name Debian itself is a portmanteau of the names Ian Murdock (the creator of Debian) and Debra Lynn (his then-girlfriend, later ex-wife). As a result, this name has been called a curiously personal name for such a community-oriented project.[3]
I was using Fedora and Ubuntu in 2007 when a member of a local Linux User Group (LUG) introduced me to Debian. Its simplicity and elegance, its vast package repository, and its stability and robustness made me an ardent user of this distribution pretty quickly. Thirteen years later, I still use Debian on my laptops, Linode servers, and virtual machines. I run my personal website[4] on Debian too. I have got so used to "apt-get install" and the large number of tools available in the Debian repositories that I keep a Debian VM or a remote shell handy when I am working on a non-Debian system. Over these years, I have gradually moved from GNOME 2 to GNOME 3 and then to Xfce 4. It really helps that Debian provides an installation CD with Xfce as the default[5]. In case anyone is interested, I have documented and shared my Debian setup notes on GitHub[6].
[1]: https://pixar.fandom.com/wiki/Etch_A_Sketch
[2]: https://pixar.fandom.com/wiki/Buster
[3]: https://archive.org/download/lud098mag/LU%26D098%20-%20Andro...
[4]: https://susam.in/
[5]: https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/#i...
[6]: https://github.com/susam/dotfiles/blob/master/docs/debian-se...
My first was Debian 4. Ran it on a 550mhz PIII.
The client went away, and so did I.
Then some month ago, the client came back. The Debian 5 is still online and still running (but we plan to move on a new infra with a Buster soon).
> Debian releases
Not Debian itself.
From "A Brief History of Debian, Chapter 3 - Debian Releases" [0]:
> This was the first Debian release with a code name. It was taken, like all others so far, from a character in one of the Toy Story movies...
"Bo" was the first version of Debian that I played with. I switched to Debian "full-time" shortly after "Hamm" came about.
[0]: https://www.debian.org/doc/manuals/project-history/ch-releas...
I remember back around 2005, I missed meeting him by a ~week. My college Linux users group was having a birthday party for Debian, and Ian was an alumnus of that school, so he was going to attend. It was right before the semester started, so I was out of town.
I'm curious why were you so impressed by Debian in comparison to Ubuntu? Ubuntu is based on Debian and shares most of the mentioned features, yet your observation sounds like you experienced them as two very different systems.
Fortunately, it only takes a minute to grab the latest mini.iso, mount it, grab the kernel and initial ramdisk images (and "cat" the non-free/unofficial firmware to the end of the ramdisk), push 'em up to the TFTP server, and be right back in business.
When it does break, it literally takes less than five minutes to get it working again. Looks like I'd been using the previous kernel and initramfs since 2019-09-05 and, well, I can deal with spending five minutes on an issue once every five months -- especially considering all the time that it saves me!
(At one point, I insisted -- for some unknown reason! -- on using the weekly "unstable" images so the breakage was much, much more frequent. Fortunately for my sanity, I finally gave up and went back to just using the latest "stable" mini.iso.)
Thanks for the suggestion but, no, this won't work for me.
---
Long answer:
Unfortunately, no, that doesn't help me as I don't really even need an ISO image at all. What I really need is just the new version of the kernel ("linux") and initial ramdisk ("initrd.gz") files.
I don't need the regular ("cdrom") ones (like you might find on a regular ISO image), though. I need the "netboot" ones -- yes, they're different! Well, the kernel is usually the same but the initrd.gz is different.
When a new version of the kernel and modules show up on the servers (and once my local "cache/proxy" notices them and downloads the newer version of the modules), my network installs will start failing. See, a host PXE boots the existing version of the kernel but when debian-installer launches and starts downloading the modules it needs, it finds that they were built for a different version of the kernel than what it booted from. This causes "that oh so familiar error message" to be thrown [0] and the installation to fail.
The "fix", obviously, is to boot the new kernel instead of the old one.
As I mentioned, all that I really need to do is replace the existing versions of the linux and initrd.gz files on my TFTP server with the new ones. In theory, I could just SSH into the TFTP server, "cd" to the appropriate directory, fire off a single "wget" (the URLs for those two files don't even change!), and be done; real life is, however, (only slightly) more difficult!
Now, once in a very great while, I will actually do an installation on a VM where I do use an ISO image instead of performing a network install. That's why I just go ahead and grab the ("netboot") "mini.iso" file and extract the linux and initrd.gz files out of it instead of downloading just those files in the first place.
The other thing has to do with the "non-free" firmware. Although they provide ISO images that include it, it was easier for me to just do it myself. Once I've got the linux and initrd.gz files downloaded, all that is needed is to download the "firmware.cpio.gz" file if I don't already have it (or if a newer version is available or something) and (literally) "cat" initrd.gz and firmware.cpio.gz together.
Then, I replace the existing linux and initrd.gz files on my TFTP server with these two new files and reboot the host so that it restarts the network install! Depending on the hardware, it sometimes takes the server longer to POST and get to the point where it actually starts booting than it takes for the actual OS installation (I'm looking at you, Dell PowerEdge servers!).
It may sound like a fustercluck but it's actually pretty simple (just a few commands) and from "uh oh, the install failed" to "okay, it's working again" is almost always less than five minutes (well, it is now that I switched back to using the "stable" mini.iso images instead of the daily or weekly "unstable" ones!). I could write a script to automate it, I suppose, but it doesn't seem worth it as it only happens two or three times a year.
(That's a rather long way of saying "no, that doesn't help" but since you offered a suggestion I wanted to explain why and not simply dismiss it with a "no, that doesn't help"!)
---
[0]: https://i.imgur.com/3cB5LC3g.jpg