Re: How stable is the frozen stretch?
My 2 cents: If you're used to Debian Stable level stability, then
Testing might get on your nerves with its tiny little paper cuts
(Firefox crashing, Thunderbird not knowing what to do with your Icedove
profile, KDE having GUI elements that follow your set theme, but then
also others that don't, KDE PIM being crashy as ever,...). Of course,
the less complicated your system, the fewer bugs you'll have. So, while
Openbox, a panel and a terminal won't drive your crazy even on Sid, KDE
or Gnome might.
On 16.05.2017 13:17, Richard Owlett wrote:
On 05/15/2017 02:06 PM, deloptes wrote:
Richard Owlett wrote:
On 05/14/2017 06:46 AM, David Wright wrote:
On Sun 14 May 2017 at 04:57:07 (-0500), Richard Owlett wrote:
On 05/14/2017 02:40 AM, Joe wrote:
On Sat, 13 May 2017 20:54:04 -0400
RavenLX <firstname.lastname@example.org> wrote:
On 05/13/2017 12:40 PM, Richard Owlett wrote:
I have a partition whose label is "common".
I could almost smack myself in the head. I had done that when I
to dual-boot Windows / Linux (now you can see why I'm not a fan of
dual-boot, I guess! LOL!). I also used to dual boot SolydX and
In my VMs, I do use the guest additions and have a shared directory
(necessity for what I need to do as well).
But that was one way I had shared data.
However, I still balk at dual-booting (like you balk at VMs :) )
Another option I've used for some years: a pocket-sized USB hard
with an i386 all-modules installation, which boots on practically
anything that isn't an ARM.
Can you clarify what you mean by the phrase "i386 all-modules
Recall this d-i screen?
I do now ;)
Actually initrd and initramfs and were on my "google today" list.
That may that may explain something I've recently noticed.
As I experiment with many Debian versions and configurations I
can multi-boot among a a half dozen (or more) choices.
As I've had some spectacularly failed installs, my practice is to
install Grub *ONLY* with the *FIRST* install. That way the default
action is to boot a known good system and the questionable one will
generally be last on the list (Grub insists on listing /dev/sda10
What I'm investigating is an apparent anomaly:
1. My primary machine had Jessie installed first with Squeeze
and Stretch later. It happily will boot all.
2. I've set up a designated EXPERIMENTAL machine. Squeeze was
installed first and thus Grub is associated with it.
Wheezy and Jessie were installed without Grub.
Squeeze runs fine and will browse the web.
However, update-grub does not recognize either Wheezy or Jessie.
Also, a netinst of Stretch failed at the network setup step -
haven't done any trouble shooting yet.
1. Can I retroactively choose "include all available drivers" and
if so, how?
2. How much free space would be required? As I was already planning
on some Grub experiments, I had left 10 MB un-partitioned before
/dev/sda1. That can easily be expanded.
If you like hacking the initrd
Not one of my life goals <chuckle>
mkdir test && cd test && zcat /boot/initrd.img-`uname -r` | cpio
I may not be "prophet or son of a prophet", but I see a "lab
practical" on parsing in my future.
find . ! -name *~ | cpio -H newc --create | gzip -9
I foundthisvery useful over the years, especially for testing things
out 10MB would be enough for 1 kernel+initrd & co
While I was tweaking my "EXPERIMENTAL machine" partitioning for
unrelated reasons, left the first GB unallocated.
I wouldn't use dedicated boot partition in your case. For testing
you can leave all on one partition. If you use dedicated boot
partition and want to share it among different installs - watch out
to not format it ... and you must keep all your kernels+initrd there.
I'm unclear as to "dedicated boot partition" above.
My typical install procedure results in a directory structure as below:
bin etc initrd.img.old media proc sbin tmp vmlinuz
boot home lib mnt root srv usr vmlinuz.old
dev initrd.img lost+found opt run sys var
Are you referring to the "boot" in that list?
I've may have been a computer *user* for a half-century.
But I have little formal background ;}