[GTALUG] Boot setup issues

Discussion:

o1bigtenor via talk

2018-09-14 14:22:20 UTC

Greetings

I have had it working before but I can't seem to get things right this time.

I want to have two different copies of debian on one box with the
choice of which when I boot in.
Wanting to have available both debian stable (9.5 at present) and
debian testing (10). This is so I can experiment with software - - -
adding it and if huge errors result or are caused - - - no real biggie
because its not a main working box (like the server or my main
computer). Doing this because I really have gotten to hate having a
main box down for even a few days because software that I loaded and
installed caused me to bork the system (I've done this more than a few
times!!! grin - - -but 'learning' isn't always a barrel of fun!!)

So I've installed both of these systems (more than once each) they
have their own partitions for everything but boot and efi yet I'm only
seeing one system available on grub (depending upon the last install
as to which). So I'm doing something wrong!! I tried using grub
updating tools (# os-prober) still no joy. The web pages that I'm
finding seem to be for an older version of grub and, as usual, I'm
finding man pages are like reading cuneiform (which I find
unintelligible).

This is likely something quite simple but I'm just not seeing it - - -
please - - - some ideas/pointers?

TIA

Dee
---
Talk Mailing List
***@gtalug.org
htt

Don Tai via talk

2018-09-14 14:27:13 UTC

Permalink

Have you tried the Ubuntu Boot Repair disk? That usually works for me.

Post by o1bigtenor via talk
Greetings
I have had it working before but I can't seem to get things right this time.
I want to have two different copies of debian on one box with the
choice of which when I boot in.
Wanting to have available both debian stable (9.5 at present) and
debian testing (10). This is so I can experiment with software - - -
adding it and if huge errors result or are caused - - - no real biggie
because its not a main working box (like the server or my main
computer). Doing this because I really have gotten to hate having a
main box down for even a few days because software that I loaded and
installed caused me to bork the system (I've done this more than a few
times!!! grin - - -but 'learning' isn't always a barrel of fun!!)
So I've installed both of these systems (more than once each) they
have their own partitions for everything but boot and efi yet I'm only
seeing one system available on grub (depending upon the last install
as to which). So I'm doing something wrong!! I tried using grub
updating tools (# os-prober) still no joy. The web pages that I'm
finding seem to be for an older version of grub and, as usual, I'm
finding man pages are like reading cuneiform (which I find
unintelligible).
This is likely something quite simple but I'm just not seeing it - - -
please - - - some ideas/pointers?
TIA
Dee
---
Talk Mailing List
https://gtalug.org/mailman/listinfo/talk

D. Joe via talk

2018-09-14 14:53:06 UTC

Permalink

Post by o1bigtenor via talk
Greetings
I want to have two different copies of debian on one box with the
choice of which when I boot in.

[...]

Post by o1bigtenor via talk
So I've installed both of these systems (more than once each) they
have their own partitions for everything but boot and efi yet I'm only
seeing one system available on grub (depending upon the last install
as to which).
So I'm doing something wrong!! I tried using grub
updating tools (# os-prober) still no joy. The web pages that I'm
finding seem to be for an older version of grub and, as usual, I'm
finding man pages are like reading cuneiform (which I find
unintelligible).
This is likely something quite simple but I'm just not seeing it - - -
please - - - some ideas/pointers?

To the best of my understanding, these tools are built with the assumption that one wants to run just the OS that invokes them.

Although the Debian wiki has some hints

https://wiki.debian.org/Grub

this seems to be more direct

https://askubuntu.com/questions/16042/how-to-get-to-the-grub-menu-at-boot-time

Are you hitting shift during boot time to get the grub menu, from which you might then be able to select amongst configured choices?

If your successful bringing up the boot-time menu, but it isn't configured to offer you the choices after holding down shift, you may have to muck around in /etc/default/grub from which update-grub et al seem to take their lead.

Take some care to dig into the boot time menu, I'm starting to see only the default (eg, the most recently installed OS) as the obvious choice at the grub top level menu during boot time, with other options buried in a submenu. (Sorry not to be more specific about how those appear--I'm favoring a quicker response over booting up a VM to see more exactly what the strings presented are).

hth,

D. Joe

---
Talk Mailing List
***@gtalug.org
https://gtalug.

o1bigtenor via talk

2018-09-14 16:24:43 UTC

Permalink

Post by D. Joe via talk

Post by o1bigtenor via talk
Greetings
I want to have two different copies of debian on one box with the
choice of which when I boot in.

[...]

To the best of my understanding, these tools are built with the assumption that one wants to run just the OS that invokes them.
Although the Debian wiki has some hints
https://wiki.debian.org/Grub

Looked at that page earlier - -- its about 7 to 9 years out of date at
this point. The information there is current for grub 0.97 and
I'm on 2.xx and there are enough differences so that I am not sure if
the ideas presented there wouldn't even make things worse.

Post by D. Joe via talk
this seems to be more direct
https://askubuntu.com/questions/16042/how-to-get-to-the-grub-menu-at-boot-time

Not really the issue - - - sorry.

Post by D. Joe via talk
Are you hitting shift during boot time to get the grub menu, from which you might then be able to select amongst configured choices?
If your successful bringing up the boot-time menu, but it isn't configured to offer you the choices after holding down shift, you may have to muck around in /etc/default/grub from which update-grub et al seem to take their lead.
Take some care to dig into the boot time menu, I'm starting to see only the default (eg, the most recently installed OS) as the obvious choice at the grub top level menu during boot time, with other options buried in a submenu. (Sorry not to be more specific about how those appear--I'm favoring a quicker response over booting up a VM to see more exactly what the strings presented are).

When you have multiple operating systems you get choices, even when
you have mutliple versions of one system you can have options.
I'm just not seeing the option(s) for the second system. Was told that
there is a grub.conf file so that's where I'm going to be looking pdq.

Thanks for the ideas.

Dee
---
Talk Mailing List
***@gtalug

Don Tai via talk

2018-09-14 16:52:13 UTC

Permalink

On a test machine I had installed Debian Enlightenment. first, and then
Manjaro second. Manjaro screwed up the booting. I repeatedly used the
Ubuntu Boot Repair disk to get me unstuck. The Boot Repair disk is Linux
agnostic.

Don

Post by D. Joe via talk

Post by o1bigtenor via talk
Greetings
I want to have two different copies of debian on one box with the
choice of which when I boot in.

[...]

To the best of my understanding, these tools are built with the

assumption that one wants to run just the OS that invokes them.

Post by D. Joe via talk
Although the Debian wiki has some hints
https://wiki.debian.org/Grub

Post by D. Joe via talk
this seems to be more direct

https://askubuntu.com/questions/16042/how-to-get-to-the-grub-menu-at-boot-time
Not really the issue - - - sorry.

Post by D. Joe via talk
Are you hitting shift during boot time to get the grub menu, from which

you might then be able to select amongst configured choices?

Post by D. Joe via talk
If your successful bringing up the boot-time menu, but it isn't

configured to offer you the choices after holding down shift, you may have
to muck around in /etc/default/grub from which update-grub et al seem to
take their lead.

Post by D. Joe via talk
Take some care to dig into the boot time menu, I'm starting to see only

the default (eg, the most recently installed OS) as the obvious choice at
the grub top level menu during boot time, with other options buried in a
submenu. (Sorry not to be more specific about how those appear--I'm
favoring a quicker response over booting up a VM to see more exactly what
the strings presented are).
When you have multiple operating systems you get choices, even when
you have mutliple versions of one system you can have options.
I'm just not seeing the option(s) for the second system. Was told that
there is a grub.conf file so that's where I'm going to be looking pdq.
Thanks for the ideas.
Dee
---
Talk Mailing List
https://gtalug.org/mailman/listinfo/talk

Lennart Sorensen via talk

2018-09-14 20:06:57 UTC

Permalink

Post by D. Joe via talk
To the best of my understanding, these tools are built with the assumption that one wants to run just the OS that invokes them.
Although the Debian wiki has some hints
https://wiki.debian.org/Grub
this seems to be more direct
https://askubuntu.com/questions/16042/how-to-get-to-the-grub-menu-at-boot-time
Are you hitting shift during boot time to get the grub menu, from which you might then be able to select amongst configured choices?
If your successful bringing up the boot-time menu, but it isn't configured to offer you the choices after holding down shift, you may have to muck around in /etc/default/grub from which update-grub et al seem to take their lead.
Take some care to dig into the boot time menu, I'm starting to see only the default (eg, the most recently installed OS) as the obvious choice at the grub top level menu during boot time, with other options buried in a submenu. (Sorry not to be more specific about how those appear--I'm favoring a quicker response over booting up a VM to see more exactly what the strings presented are).

Certainly OSs like Debian believe they own /boot and that packaged files
go in there. In general it is easiest to just keep it part of the root
filesystem. The EFI boot partition on the other hand is shared by all
OSs on the system. There is rarely a good reason to make a separate
partition for /boot these days. Encrypted rootfs is one case or root
on LVM, but other than that, not really.

--
Len Sorensen
---
Talk Mailing List
t

o1bigtenor via talk

2018-09-14 20:32:11 UTC

Permalink

On Fri, Sep 14, 2018 at 3:06 PM, Lennart Sorensen via talk

Post by Lennart Sorensen via talk

OK - - - good to know. For many years it was /boot, / (or /root),
/usr, /var, /tmp,
swap, /usr/local and /home. I've had enough issues because / was too small,
ditto for /usr.
So on a new system I can drop /boot and only add /efi or ????

Regards

Dee
---
Talk Mailing List

D. Hugh Redelmeier via talk

2018-09-15 04:10:07 UTC

Permalink

TL;DR: lots of history, some explanation of why things are done certain
ways.

| From: o1bigtenor via talk <***@gtalug.org>

| OK - - - good to know. For many years it was
| /boot,

Covered well by Lennart.

This first came up for me with UNIX System V release 2 on a PC. The
boot loader only understood a a special simple file system (BFS).
This file system was pretty useless for real work so only a minimal
set of stuff was held there. I *think* it was mounted as /boot. It
was a lot like the kernel + initrd.

There's an interesting bootstrap problem that it addresses: how simple
can you make the bootloader and still make it do what you need.

LILO was an elegantly simple solution but it pinched:

- It used BIOS for disk I/O. Eventually BIOSes could not address the
whole of a disk and this bizarre limitation bled into the
bootloader.

- The bootloader did not understand any filesystems so a tool was needed
to put absolute disk addresses into the bootloader whenever a kernel or
initrd was moved, added, or deleted. Forget to do this and your system
became unbootable.

- Secure Boot? I don't see how that could fit into the LILO
framework.

- UEFI? I think that a new bootloader, as simple as LILO, but a lot
better, could be written using the API provided by UEFI.

GRUB is quite complex. Among other things, it needs to understand any
filesystem from which it can boot. For another, it needs its own disk
device drivers so that it can get around the BIOS limitations
outlined above.

I have a little PC that has a too-small "disk" (eMMC) to hold Windows
and Linux. I wanted to use an SD card to hold Linux. The UEFI
firmware doesn't have a driver for the SD card. So the machine cannot
boot from the SD card. If GRUB had such a driver, then I could put
/boot on the SD card, but it doesn't. Still, it would be quite
reasonable for it to have such a driver.

| / (or /root),

Those are quite different.

/ is the root filesystem

/root is the home directory for user "root".
It is conveniently on / so the root user can be logged in
without /home being mounted.

| /usr, /var, /tmp,
| swap, /usr/local and /home. I've had enough issues because / was too small,
| ditto for /usr.

If you use LVM (I don't) you get a level of indirection that lets you
increase partition sizes pretty freely. So you don't have to get
allocations right at the beginning.

/tmp is quite reasonably on a separate special-purpose filesystem. On
Fedora 28, the default is to use the filesystem type "tempfs".

In the days of LILO, /boot needed to be addressable by LILO so it was
constrained. That was one reason to put /boot in a separate
filesystem.

Once upon a time, / was all you needed for single user mode. You kept
everything else in things like /var and /usr so that there was a great
chance that a broken system could still be booted in single user mode.
/ was almost, but not quite, read-only. Long gone.

Sometimes fleets of boxes shared, say, /usr, through NFS. This meant
some kinds of system administration were easier and disk resources
were less wasteful yet each machine was faster than a diskless
workstation.

Now /, /var, /usr/var, /local, /usr/local, /bin, /opt, might as well
be on one filesystem.

I keep /home separate so that my user data is mostly in its own
filesystem. Then replacing the OS is almost simple. Too bad the
dotfiles need to adjust for different OSes.

| So on a new system I can drop /boot and only add /efi or ????

/boot/efi, not /efi. Of course that isn't the name of the filesystem
it is the mount point.

(Some people insist on using BIOS, not UEFI. In that case, you probably
want a separate /boot and no /boot/efi. I think UEFI is a better choice.)
---
Talk Mailing List
talk@

o1bigtenor via talk

2018-09-15 11:21:51 UTC

Permalink

On Fri, Sep 14, 2018 at 11:10 PM, D. Hugh Redelmeier via talk

Post by D. Hugh Redelmeier via talk
TL;DR: lots of history, some explanation of why things are done certain
ways.
| OK - - - good to know. For many years it was
| /boot,
Covered well by Lennart.
This first came up for me with UNIX System V release 2 on a PC. The
boot loader only understood a a special simple file system (BFS).
This file system was pretty useless for real work so only a minimal
set of stuff was held there. I *think* it was mounted as /boot. It
was a lot like the kernel + initrd.
There's an interesting bootstrap problem that it addresses: how simple
can you make the bootloader and still make it do what you need.
- It used BIOS for disk I/O. Eventually BIOSes could not address the
whole of a disk and this bizarre limitation bled into the
bootloader.
- The bootloader did not understand any filesystems so a tool was needed
to put absolute disk addresses into the bootloader whenever a kernel or
initrd was moved, added, or deleted. Forget to do this and your system
became unbootable.

On my first iteration on linux I do remember lilo, vaguely (grin it is
a while ago!).

Post by D. Hugh Redelmeier via talk
- Secure Boot? I don't see how that could fit into the LILO
framework.
- UEFI? I think that a new bootloader, as simple as LILO, but a lot
better, could be written using the API provided by UEFI.
GRUB is quite complex. Among other things, it needs to understand any
filesystem from which it can boot. For another, it needs its own disk
device drivers so that it can get around the BIOS limitations
outlined above.
I have a little PC that has a too-small "disk" (eMMC) to hold Windows
and Linux. I wanted to use an SD card to hold Linux. The UEFI
firmware doesn't have a driver for the SD card. So the machine cannot
boot from the SD card. If GRUB had such a driver, then I could put
/boot on the SD card, but it doesn't. Still, it would be quite
reasonable for it to have such a driver.
| / (or /root),
Those are quite different.
/ is the root filesystem
/root is the home directory for user "root".
It is conveniently on / so the root user can be logged in
without /home being mounted.

Thank you very much - - - - had not ever seen an explanation of the whats and
whyfors on this. Kn ow for next time! (Installing that is)

Post by D. Hugh Redelmeier via talk
| /usr, /var, /tmp,
| swap, /usr/local and /home. I've had enough issues because / was too small,
| ditto for /usr.
If you use LVM (I don't) you get a level of indirection that lets you
increase partition sizes pretty freely. So you don't have to get
allocations right at the beginning.

I've never used LVM so that might be useful but I've been able to figure things
out so they've worked fairly well so I will look into LVM but I'm not
sure I will
be using it.

Post by D. Hugh Redelmeier via talk
/tmp is quite reasonably on a separate special-purpose filesystem. On
Fedora 28, the default is to use the filesystem type "tempfs".
In the days of LILO, /boot needed to be addressable by LILO so it was
constrained. That was one reason to put /boot in a separate
filesystem.
Once upon a time, / was all you needed for single user mode. You kept
everything else in things like /var and /usr so that there was a great
chance that a broken system could still be booted in single user mode.
/ was almost, but not quite, read-only. Long gone.
Sometimes fleets of boxes shared, say, /usr, through NFS. This meant
some kinds of system administration were easier and disk resources
were less wasteful yet each machine was faster than a diskless
workstation.
Now /, /var, /usr/var, /local, /usr/local, /bin, /opt, might as well
be on one filesystem.

One of my linux mentors, who calls himself a linux dinosaur (started on
a System V on a pc) even advocates for a separate partition for /var/log
to forestall any software issues choking off disk usage.

Post by D. Hugh Redelmeier via talk
I keep /home separate so that my user data is mostly in its own
filesystem. Then replacing the OS is almost simple. Too bad the
dotfiles need to adjust for different OSes.
| So on a new system I can drop /boot and only add /efi or ????
/boot/efi, not /efi. Of course that isn't the name of the filesystem
it is the mount point.

I was remembering it being called just EFI on the debian partitioning
setup pages in the install but wasn't sure of its name. Likely another of
those places where we are, as in English, divided by a common language.

Post by D. Hugh Redelmeier via talk
(Some people insist on using BIOS, not UEFI. In that case, you probably
want a separate /boot and no /boot/efi. I think UEFI is a better choice.)

As I have my main systems with more than 2 TB of hdds bios is no longer
an option.

I find when installing a new system that things go easier when I use my
CDResuceDisc and its copy of gparted to set up the partitions the way I
want and then mounting the install disc to effect the installation.

Thank you for the ideas and tips!! One of my frustrations with linux has
been that it can be very difficult to find clear understandable information
on many parts of the system. Much of the documentation seems to be
written for someone who is well versed in things and is looking for a clue
or a reminder on 'how things work'.
Your note is how I wish man pages were written. If only there were examples
of the command usage, happens rarely but is starting to happen, with what
to do when there are errors or problems would be wonderful but the assumption
always seems to be that the user just knows. My question is 'how does one
learn?' - - - even the Socratic method, which can be quite challenging for a
student works from what the student 'knows' to educating them in what they
'don't' know. I think that these lacunae in documentation are because its far
more fun to build things than it is to describe the hows and the whys and the
whatfors. So your explanations offered are very welcome!!!

Regards

Dee

D. Hugh Redelmeier via talk

2018-09-16 05:10:39 UTC

Permalink

| From: o1bigtenor via talk <***@gtalug.org>

Note: I am only an amateur sysadmin.

| One of my linux mentors, who calls himself a linux dinosaur (started on
| a System V on a pc)

Picky picky: System V isn't Linux. It's UNIX.

I first used UNIX seriously with 4th or 5th Edition in 1975. But I
first became strongly interested in 1974 from reading "The UNIX
Time-Sharing System" in the Communications of the ACM.

I think that a number of GTALUG folks used Linux before I did. I
switched my desktop from Solaris on SPARC to Linux about 1997 (I
played with Linux before that).

| even advocates for a separate partition for /var/log
| to forestall any software issues choking off disk usage.

Good point. What causes disk-full events for you? If you can isolate
them to separate filesystems, that's good.

Here are the ones that have hit me:

- too many log messages (/var/log). That can easily be cured by
log system settings.

- too much email (/var/spool)

- too many saved update packages (due to a PackageKit / dnf bug)
(/var/cache)

- too many packages installed (/)

- too many core dumps (/var/spool/abrt)
A firefox dump usually takes 4GiB or so on my system.

HDDs are so big and cheap these days that the simplest solution is to
wildly over-allocate for each partition.

Unfortunately, SSDs are so much faster that you ought to use them and
their capacity costs more. I use both. I haven't bothered to put any
problematic directories on the HDD.

| One of my frustrations with linux has
| been that it can be very difficult to find clear understandable information
| on many parts of the system. Much of the documentation seems to be
| written for someone who is well versed in things and is looking for a clue
| or a reminder on 'how things work'.

There are other challenges

- Linux is very large. Mostly things get added and very little gets
deleted.
(When I first used UNIX, the largest RAM was 256KiB. It ran
off a disk that was 2.5MB. You can bet is was simpler.)

- Documentation gets out of date.

- Linux is very general-purpose. How you should set it up depends on
many things. Consider the difference between Linux embedded in a
home router and Linux running a supercomputer. (Most routers,
smartphones, tablets, supercomputers, websites, cloud systems, etc.
run Linux.)

- each distro is a different. Each installation can be different.

One key to understanding Linux is to understand its anatomy. Then you
can study the organs of interest in isolation.
---
Talk Mailing List
***@gtalug.org
https://g

o1bigtenor via talk

2018-09-16 11:07:55 UTC

Permalink

On Sun, Sep 16, 2018 at 12:10 AM, D. Hugh Redelmeier via talk

Post by D. Hugh Redelmeier via talk
Note: I am only an amateur sysadmin.

And I am not even that good - - - grin but i'se a learning that too!

Post by D. Hugh Redelmeier via talk
| One of my linux mentors, who calls himself a linux dinosaur (started on
| a System V on a pc)
Picky picky: System V isn't Linux. It's UNIX.

Ja ja - - - got it. but it were unix before linux, although today one
might wonder
listening to some.

Post by D. Hugh Redelmeier via talk
I first used UNIX seriously with 4th or 5th Edition in 1975. But I
first became strongly interested in 1974 from reading "The UNIX
Time-Sharing System" in the Communications of the ACM.
I think that a number of GTALUG folks used Linux before I did. I
switched my desktop from Solaris on SPARC to Linux about 1997 (I
played with Linux before that).
| even advocates for a separate partition for /var/log
| to forestall any software issues choking off disk usage.
Good point. What causes disk-full events for you? If you can isolate
them to separate filesystems, that's good.

Well - - - its one thing I haven't done yet. Haven't been bit by it yet either.
Likely would do after the first instance - - - grin.

Post by D. Hugh Redelmeier via talk
- too many log messages (/var/log). That can easily be cured by
log system settings.

As I'm finding log message useful (strange for someone with a background
primarily as a 'user') I think I would rather have more here than less although
some of the messages are quite - - - -carefully now - - - useless (when there
are a few thousand lines exactly the same in a row) but none the less I would
rather enhance than truncate this function.

Post by D. Hugh Redelmeier via talk
- too much email (/var/spool)

Today I get maybe 30 to 75 emails. I remember a time when I could get over
a thousand. Today I would be quite a bit more into the deleting than I was
then too.

Post by D. Hugh Redelmeier via talk
- too many saved update packages (due to a PackageKit / dnf bug)
(/var/cache)
- too many packages installed (/)
- too many core dumps (/var/spool/abrt)
A firefox dump usually takes 4GiB or so on my system.
HDDs are so big and cheap these days that the simplest solution is to
wildly over-allocate for each partition.
Unfortunately, SSDs are so much faster that you ought to use them and
their capacity costs more. I use both. I haven't bothered to put any
problematic directories on the HDD.
| One of my frustrations with linux has
| been that it can be very difficult to find clear understandable information
| on many parts of the system. Much of the documentation seems to be
| written for someone who is well versed in things and is looking for a clue
| or a reminder on 'how things work'.
There are other challenges
- Linux is very large. Mostly things get added and very little gets
deleted.
(When I first used UNIX, the largest RAM was 256KiB. It ran
off a disk that was 2.5MB. You can bet is was simpler.)

In comparison to the dominant desktop I don't think that's true but I
do know that the economy of code AND logic that was used in coding
back then is in quite a different universe than the present iterations.

Post by D. Hugh Redelmeier via talk
- Documentation gets out of date.

One of the things that I have been finding very often - - - even with this
present search for answers. There is a lot of information out there that is
wildly out of date but there isn't even a date on the document to alert one
to its fossilization. I have taken to dating all of my documents for myself
to try and reduce the issue. Very seldom does information from the major
players get marked with a date. It is only with some experience that this
outdated stuff can be recognized. Finding information for current system
thinking is often almost impossible. (Coders hate documenting!)
Even more challenging is the all to common attitude that the newest is
the best stuff. I want stuff that works - - - not stuff that has not
been thrashed
so its flaws aren't known. For business use something that works is far more
important than stuff that is the newest (with huge bling).

Post by D. Hugh Redelmeier via talk
- Linux is very general-purpose. How you should set it up depends on
many things. Consider the difference between Linux embedded in a
home router and Linux running a supercomputer. (Most routers,
smartphones, tablets, supercomputers, websites, cloud systems, etc.
run Linux.)
- each distro is a different. Each installation can be different.

Even more challenging is that Linux appears to be tweaked for those where
the tweaking and working under the hood IS the object of the OS. There
doesn't seem to be that much that is just for the USE. There are mountains
of things that are cool from a developers point of view but for a 'users' - - -
well - - - its all to often not much use. IMO far too often change is done for
change's sake. Another issue is that there is a lot of behind the scenes
activity that is quite antithetical to the visible. It feels a lot
like the frog
swamp is being heated very carefully!

Post by D. Hugh Redelmeier via talk
One key to understanding Linux is to understand its anatomy. Then you
can study the organs of interest in isolation.

I'm a trying but finding good tools and guides is not very easy whereas
for the M$ world there is a plethora of tools and guides even if far
too many of
those are that good.

Thanks Hugh - - - appreciate the pointers and nudges!

Dee
---
Talk Mailing List
***@gtalug

Lennart Sorensen via talk

2018-09-17 15:35:01 UTC

Permalink

Post by o1bigtenor via talk
OK - - - good to know. For many years it was /boot, / (or /root),
/usr, /var, /tmp,
swap, /usr/local and /home. I've had enough issues because / was too small,
ditto for /usr.
So on a new system I can drop /boot and only add /efi or ????

/boot/EFI I think is the usual mount point for the EFI boot partition
(which has to be some kind of FAT filesystem).

And any modern distribution seems like it has a fit if /usr is split
from / so don't do that anymore. Disks aren't 20MB each anymore
after all.

/home split works well for some people. I rarely do it, although I have
at least one system where I did it.

/var split is handy for database heavy systems, and probably some other
server cases.

--
Len Sorensen
---
Talk Mailing List
***@gtalug.org
https://gtalug.org/mailman/lis

Jamon Camisso via talk

2018-09-14 17:00:54 UTC

Permalink

Post by o1bigtenor via talk
So I've installed both of these systems (more than once each) they
have their own partitions for everything but boot and efi yet I'm only
seeing one system available on grub (depending upon the last install
as to which). So I'm doing something wrong!! I tried using grub
updating tools (# os-prober) still no joy. The web pages that I'm
finding seem to be for an older version of grub and, as usual, I'm
finding man pages are like reading cuneiform (which I find
unintelligible).

Try installing refind - it is pretty good at detecting multiple OSes.

That said, if you have a shared boot partition between installations,
then you're going to have a much harder time detecting things, since
each OS will run update-grub, and clobber the other's grub.cfg entries.

You might be better off writing your own grub.cfg file or customizing
scripts in /etc/kernel to handle regenerating grub.cfg when there are
kernel updates.

Cheers, Jamon
---
Talk Mailing List
***@gt