from:"norton"

On Mon, 7 May 2018 18:24:04 -0400
Felix Miata <mrma...@earthlink.net> wrote:

> Dan Norton composed on 2018-05-07 18:04 (UTC-0400):
> 
> > On Mon, 7 May 2018 10:42:17 -0400 Felix Miata  wrote:  
> 
> >> IME, virtually any distro's installation media when its presence
> >> first appears on screen allows for some method of appending
> >> parameters to the kernel cmdline  
> 
> > That "kernel cmdline" phrase is a point of confusion.  
> 
> It shouldn't be. The kernel cmdline is the starting element of every
> Linux boot. The kernel may go by various names in different
> environments and distros, but it's still the Linux kernel that
> originates from the kernel.org project whether named linux or
> vmlinuz-numericalgobbledegook or some random string (here, every most
> recently installed kernel prior to first use acquires two
> symlinks: /boot/vmlinuz, and /boot/vmlinuz-cur).
> 
> > By editing
> > the "Install" item in the netinst menu, I can change:  
> 
> >   linux   /install.amd/vmlinuz vga=788 --- quiet  
> 
> > ...to this, all on one line:  
> 
> >   linux   /install.amd/vmlinuz vga=788 --- tasks=standard
> >   base-installer/install-recommends=false  
> 
> > Is that going to result in a minimum installation?  
> 
> Other than the .amd part, it's what happens here. It should for you
> too. :-)
> 
> A n00b might rather leave off
> base-installer/install-recommends=false. I don't think I've ever
> tried it that way. I'd be leery of something from Gnome getting
> installed. ;-)

Yeah, that would be at cross purposes, wouldn't it?

Re: minimal installation (was: A long rant on Debian 9)

On Mon, 7 May 2018 23:22:46 +0100
Brian <a...@cityscape.co.uk> wrote:

> On Mon 07 May 2018 at 18:04:47 -0400, Dan Norton wrote:
> 
> > On Mon, 7 May 2018 10:42:17 -0400
> > Felix Miata <mrma...@earthlink.net> wrote:
> >   
> > > jpff composed on 2018-05-07 12:34 (UTC+0100):
> > >   
> > > > Felix Miata wrote:
> > >   
> > > >> My Debian installations are all net installs that include
> > >   
> > > >>tasks=standard
> > > >> base-installer/install-recommends=false
> > >   
> > > >> on the kernel cmdline. I get nothing I don't need installed
> > > >> that way. Xorg and whatever else I need I get with apt* once
> > > >> booted normally.
> > >   
> > > > That looks interesting; it attemts to answer my deep problem
> > > > about no X, xdm, xterm etc.
> > >   
> > > > My problem nowis I do not know where/how to apply this.  I have
> > > > not seen any mention of a kernel command line in the net
> > > > install.  More please!
> > > 
> > > I'm not up to speed on the conventional HOWTO for answering this.
> > > I rarely use conventional installation boot media. Virtually all
> > > my installs are in multiboot environments. This enables
> > > installation booting by using a bootloader already present on the
> > > system, by loading an installation kernel and initrd, complete
> > > with the parameters mentioned, plus several others, such as
> > > network configuration, and leaving off quiet and splash=silent.
> > > 
> > > IME, virtually any distro's installation media when its presence
> > > first appears on screen allows for some method of appending
> > > parameters to the kernel cmdline. It may be an "e" key, or an ESC
> > > key, or an up or down arrow key, or a function key, and likely
> > > will suggest how when its screen first paints.  
> > 
> > That "kernel cmdline" phrase is a point of confusion. By editing
> > the "Install" item in the netinst menu, I can change:
> > 
> >   linux   /install.amd/vmlinuz vga=788 --- quiet
> > 
> > ...to this, all on one line:
> > 
> >   linux   /install.amd/vmlinuz vga=788 --- tasks=standard
> >   base-installer/install-recommends=false
> > 
> > Is that going to result in a minimum installation?  
> 
> Leave off tasks=standard for more minimalness.
> 

This is getting exciting. Will I still get a command line?

> (base-installer/install-recommends=false doesn't do anything. The base
> system is always installed without Recommends:).
>

Re: minimal installation (was: A long rant on Debian 9)

On Mon, 7 May 2018 10:42:17 -0400
Felix Miata  wrote:

> jpff composed on 2018-05-07 12:34 (UTC+0100):
> 
> > Felix Miata wrote:  
> 
> >> My Debian installations are all net installs that include  
> 
> >>tasks=standard base-installer/install-recommends=false  
> 
> >> on the kernel cmdline. I get nothing I don't need installed that
> >> way. Xorg and whatever else I need I get with apt* once booted
> >> normally.  
> 
> > That looks interesting; it attemts to answer my deep problem about
> > no X, xdm, xterm etc.  
> 
> > My problem nowis I do not know where/how to apply this.  I have not
> > seen any mention of a kernel command line in the net install.  More
> > please!  
> 
> I'm not up to speed on the conventional HOWTO for answering this. I
> rarely use conventional installation boot media. Virtually all my
> installs are in multiboot environments. This enables installation
> booting by using a bootloader already present on the system, by
> loading an installation kernel and initrd, complete with the
> parameters mentioned, plus several others, such as network
> configuration, and leaving off quiet and splash=silent.
> 
> IME, virtually any distro's installation media when its presence
> first appears on screen allows for some method of appending
> parameters to the kernel cmdline. It may be an "e" key, or an ESC
> key, or an up or down arrow key, or a function key, and likely will
> suggest how when its screen first paints.

That "kernel cmdline" phrase is a point of confusion. By editing
the "Install" item in the netinst menu, I can change:

  linux   /install.amd/vmlinuz vga=788 --- quiet

...to this, all on one line:

  linux   /install.amd/vmlinuz vga=788 --- tasks=standard
  base-installer/install-recommends=false

Is that going to result in a minimum installation?

 - Dan

Re: A long rant on Debian 9

On Mon, 7 May 2018 15:30:54 + (UTC)
Curt <cu...@free.fr> wrote:

> On 2018-05-07, Curt <cu...@free.fr> wrote:
> > On 2018-05-07, Dan Norton <dnor...@mindspring.com> wrote:  
> >>> 
> >>> on the kernel cmdline. I get nothing I don't need installed that
> >>> way. Xorg and whatever else I need I get with apt* once booted
> >>> normally. 
> >>
> >> How do you get that on the kernel cmdline? My guess is that when
> >> the net-install medium boots, showing the menu which grub
> >> displays, you edit and append "tasks=..." to the line that starts
> >> "linux" right?  
> >
> > Inside the installer (I booted with kvm this outdated? one I had
> > hanging around--'firmware-stretch-DI-rc3-amd64-netinst.iso') if you
> > press tab rather than enter on "Graphical Install" or "Install",
> > you get the kernel command line (to which you can append your extra
> > parameter(s)).
> >
> > If you press escape, you get a prompt that looks like this:
> >
> >  boot:
> >  
> 
> I should have just referred you to the Debian Handbook here:
> 
> https://debian-handbook.info/browse/stable/sect.installation-steps.html
> 
>  Each menu entry hides a specific boot command line, which can be
> configured as needed by pressing the TAB key before validating the
> entry and booting. The “Help” menu entry displays the old command
> line interface, where the F1 to F10 keys display different help
> screens detailing the various options available at the prompt. You
> will rarely need to use this option except in very specific cases. 
> 

Unfortunately, that does not work. The Boot Screen does not look like
"Figure 4.1. Boot screen" and more to the point, tab has no effect. One
can move selection up or down, enter to select, E to edit, or C for
a GRUB command line. Boot a Debian 9.4 netinst iso and you'll see
what I mean. 

Felix wrote:
"My Debian installations are all net installs that include

tasks=standard base-installer/install-recommends=false

on the kernel cmdline."

What's the kernel here? The one for the installer, right? We need to
pass the above parms to the installer at boot time. Selecting "Install"
and typing "E" we see the following: 

setparams 'Install'
  set background_color=black
  linux   /install.amd/vmlinuz vga=788 --- quiet
  initrd  /install.amd/initrd.gz

So, do Felix's parms get appended to the end of the linux line or
where? 

 - Dan

Re: Backup problem using "cp"

On Mon, 7 May 2018 09:59:01 -0400
Bob Weber  wrote:

> On 5/7/18 9:28 AM, Thomas Schmitt wrote:
> > Hi,
> >
> > Richard Owlett wrote:  
> >> My goal was to copy root and its sub-directory to a directory on
> >> another physical device.  
> > Well understood.
> > In a slightly different scenario (backup on Blu-ray) i do this
> > several times per day.
> >
> > But i would not dare to give the whole root tree as input to any
> > copying program or backup archiver. Not only because of the risk of
> > stepping on my own foot but also because there are several trees
> > which do not deserve backup or could even make trouble when being
> > fully read.
> >
> > In my root directory that would be: /dev /mnt /proc /run /sys
> > E.g. because of
> >$ ls -l /proc/kcore
> >-r 1 root root 140737477877760 May  7 15:22 /proc/kcore
> >
> > (Somebody else shall try whether it's really readable and what
> > comes out. The announced size is nearly 128 TiB.)
> >
> >
> > Have a nice day :)
> >
> > Thomas
> >
> >  
> There is a program called rsnapshot that uses rsync for the actual
> work of copying but has a config file where you can supply exclude
> directories (like /media).  I just run "rsnapshot hourly" to copy my
> root file system before an apt upgrade command just in case a major
> problem occurs with the update.  The /proc /sys and /dev directories
> are not copied since they are "mounted" system directories.
> rsnapshot uses hard links between backups so only the changed files
> are actually copied.  The number of versions to keep is configured
> in /etc/rsnapshot.conf.
> 
> In using your cp command, rsync or rsnapshot it is very important
> that the destination filesystem be able to handle hard links and all
> the file attributes of a linux file system.  So make sure that at
> least there is an ext3 or ext4 type file system on the destination
> drive.  If you are not sure what file system is in use for the backup
> destination just run the mount command (as root) without any
> arguments and it will print out all the mounted file systems and
> types.

Another way to show fs type, without showing so much system stuff:

$ lsblk -f

This also shows labels (if any) and mount points.

 - Dan

Re: A long rant on Debian 9

2018-05-06 Thread Dan Norton

On Sun, 6 May 2018 18:09:12 -0400
Felix Miata  wrote:

> John composed on 2018-05-06 21:51 (UTC+0100):
> 
> > How do I get a working computer?  I can ssh in from elsewhere but
> > that is not what I need.  And I need wifi.  
> 
> My Debian installations are all net installs that include
> 
>   tasks=standard base-installer/install-recommends=false
> 
> on the kernel cmdline. I get nothing I don't need installed that way.
> Xorg and whatever else I need I get with apt* once booted normally.
> 

How do you get that on the kernel cmdline? My guess is that when the
net-install medium boots, showing the menu which grub displays, you
edit and append "tasks=..." to the line that starts "linux" right?

 - Dan

Re: Debian 9 rocks, really

2018-03-24 Thread Dan Norton

On Sat, 24 Mar 2018 22:31:11 +
Andre Rodier  wrote:

> Hello all,
> 
> I have been using Linux since more than 20 years, and Debian Linux
> since Potato. I even remember the time when you had to carefully read
> the documentation of your monitor to avoid damaging it, by choosing
> the wrong frequencies for the X server.
> 
> I am using a lot of computers, from small workstations to big servers
> in data centres or in the clouds, like Rackspace, AWS or Google
> cloud. If you are a little bit careful with the question asked, and
> have a minimum of IT knowledge, the Debian installer is wonderful. It
> always give you the control if something goes wrong, for instance by
> activating another console.
> 
> The task selection concept is great, for those who want to install
> their favourite desktop environment easily. I love the fact that
> multiple DE are given, and I can install and try more than one.
> 
> I recently re-discovered preseed, and I really enjoy it as well.
> 
> Thank you for making my life easier, and my work so beneficial.
> Debian people are really a great team !!!
> 

Indeed they are, and patient, by and large. Amazing - considering they
have to put up with people like me :-)

I don't even want to think about having to run my desktop without
Debian.
 
 - Dan

Re: Missing Shared Object File for ffmpeg

2018-03-22 Thread Dan Norton

On Wed, 21 Mar 2018 12:46:06 -0500
David Wright <deb...@lionunicorn.co.uk> wrote:

> On Tue 20 Mar 2018 at 21:29:49 (-0400), Dan Norton wrote:
> > On Tue, 20 Mar 2018 18:35:48 -0500
> > David Wright <deb...@lionunicorn.co.uk> wrote:
> >   
> > > On Tue 20 Mar 2018 at 18:41:55 (-0400), Dan Norton wrote:  
> > > > On Tue, 20 Mar 2018 13:42:24 -0500
> > > > David Wright <deb...@lionunicorn.co.uk> wrote:
> > > > 
> > > > > On Tue 20 Mar 2018 at 13:47:42 (-0400), Dan Norton wrote:
> > > > > > On Tue, 20 Mar 2018 12:59:21 -0400
> > > > > > Greg Wooledge <wool...@eeg.ccf.org> wrote:
> > > > > >   
> > > > > > > On Tue, Mar 20, 2018 at 12:18:05PM -0400, Dan Norton
> > > > > > > wrote:  
> > > > > > > > >  * The output of "apt policy ffmpeg".
> > > > > > > > 
> > > > > > > > ffmpeg:
> > > > > > > >   Installed: 7:3.2.10-1~deb9u1
> > > > > > > >   Candidate: 7:3.2.10-1~deb9u1
> > > > > > > >   Version table:
> > > > > > > >  *** 7:3.2.10-1~deb9u1 500
> > > > > > > > 500 http://debian.gtisc.gatech.edu/debian
> > > > > > > > stretch/main amd64 Packages 
> > > > > > > > 500 http://security.debian.org/debian-security
> > > > > > > > stretch/updates/main amd64 Packages 
> > > > > > > > 100 /var/lib/dpkg/status
> > > > > > > > 
> > > > > > > > >  * The output of "aptitude why libopenal1".
> > > > > > > > 
> > > > > > > > i   ffmpegDepends libavdevice57 (>= 7:3.2.10)
> > > > > > > > i A libavdevice57 Depends libopenal1 (>=
> > > > > > > > 1.14)   
> > > > > > >   
> > > > > > > >From these, it looks like you have the stretch version of
> > > > > > > >ffmpeg, and
> > > > > > > a libopenal1 dependency that can be satisfied by the
> > > > > > > stretch version of libopenal1.
> > > > > > > 
> > > > > > > If libopenal1 is not actually installed, then something is
> > > > > > > very wrong. Is it possible that you have the package
> > > > > > > "installed", but something else removed the library
> > > > > > > file?  In that case, just reinstall the package:
> > > > > > > 
> > > > > > > apt-get --reinstall install libopenal1
> > > > > > >   
> > > > > > 
> > > > > > That did it - thanks, Greg! 
> > > > > > 
> > > > > > But what does this do that apt purge/install of ffmpeg does
> > > > > > not?  
> > > > > 
> > > > > You posted:
> > > > > 
> > > > > # apt purge ffmpeg
> > > > > # apt autoremove
> > > > > # apt install ffmpeg
> > > > > 
> > > > > but you didn't show your working. You should check out what
> > > > > happened by looking at /var/log/apt/history.log to see if
> > > > > libopenal1 was affected by this command sequence. For a start,
> > > > > other packages might depend on libopenal1, preventing its
> > > > > auto-removal.   
> > > > 
> > > > The broken system was installed in December 2017. Looking at
> > > > all the logs in /var/log/apt/history* (extracting the ones that
> > > > were archived) and running:
> > > > dan@deb9:~/apt.logs$ grep -rnw '.' -e 'libopenal1' | less
> > > > ...there is one hit, other than today's --reinstall and that is
> > > > an install:
> > > > 
> > > > Start-Date: 2017-12-17  21:29:03
> > > > Commandline: /usr/sbin/synaptic
> > > > Requested-By: dan (1200)
> > > > Install: [...]
> > > > libopenal1:amd64 (1:1.17.2-4+b2, automatic),  # e pluribus unum
> > > > [...]
> > > > 
> > > > > Then of course there's the investigation of why it wasn't
> > > > > installed correctly in the first place, and what was happening
> > > > > during the "several attemp

Re: Missing Shared Object File for ffmpeg

On Tue, 20 Mar 2018 18:35:48 -0500
David Wright <deb...@lionunicorn.co.uk> wrote:

> On Tue 20 Mar 2018 at 18:41:55 (-0400), Dan Norton wrote:
> > On Tue, 20 Mar 2018 13:42:24 -0500
> > David Wright <deb...@lionunicorn.co.uk> wrote:
> >   
> > > On Tue 20 Mar 2018 at 13:47:42 (-0400), Dan Norton wrote:  
> > > > On Tue, 20 Mar 2018 12:59:21 -0400
> > > > Greg Wooledge <wool...@eeg.ccf.org> wrote:
> > > > 
> > > > > On Tue, Mar 20, 2018 at 12:18:05PM -0400, Dan Norton
> > > > > wrote:
> > > > > > >  * The output of "apt policy ffmpeg".  
> > > > > > 
> > > > > > ffmpeg:
> > > > > >   Installed: 7:3.2.10-1~deb9u1
> > > > > >   Candidate: 7:3.2.10-1~deb9u1
> > > > > >   Version table:
> > > > > >  *** 7:3.2.10-1~deb9u1 500
> > > > > > 500 http://debian.gtisc.gatech.edu/debian
> > > > > > stretch/main amd64 Packages 
> > > > > > 500 http://security.debian.org/debian-security
> > > > > > stretch/updates/main amd64 Packages 
> > > > > > 100 /var/lib/dpkg/status
> > > > > >   
> > > > > > >  * The output of "aptitude why libopenal1".  
> > > > > > 
> > > > > > i   ffmpegDepends libavdevice57 (>= 7:3.2.10)
> > > > > > i A libavdevice57 Depends libopenal1 (>= 1.14) 
> > > > > 
> > > > > >From these, it looks like you have the stretch version of
> > > > > >ffmpeg, and  
> > > > > a libopenal1 dependency that can be satisfied by the stretch
> > > > > version of libopenal1.
> > > > > 
> > > > > If libopenal1 is not actually installed, then something is
> > > > > very wrong. Is it possible that you have the package
> > > > > "installed", but something else removed the library file?  In
> > > > > that case, just reinstall the package:
> > > > > 
> > > > > apt-get --reinstall install libopenal1
> > > > > 
> > > > 
> > > > That did it - thanks, Greg! 
> > > > 
> > > > But what does this do that apt purge/install of ffmpeg does
> > > > not?
> > > 
> > > You posted:
> > > 
> > > # apt purge ffmpeg
> > > # apt autoremove
> > > # apt install ffmpeg
> > > 
> > > but you didn't show your working. You should check out what
> > > happened by looking at /var/log/apt/history.log to see if
> > > libopenal1 was affected by this command sequence. For a start,
> > > other packages might depend on libopenal1, preventing its
> > > auto-removal. 
> > 
> > The broken system was installed in December 2017. Looking at all the
> > logs in /var/log/apt/history* (extracting the ones that were
> > archived) and running:
> > dan@deb9:~/apt.logs$ grep -rnw '.' -e 'libopenal1' | less
> > ...there is one hit, other than today's --reinstall and that is an
> > install:
> > 
> > Start-Date: 2017-12-17  21:29:03
> > Commandline: /usr/sbin/synaptic
> > Requested-By: dan (1200)
> > Install: [...]
> > libopenal1:amd64 (1:1.17.2-4+b2, automatic),  # e pluribus unum
> > [...]
> >   
> > > Then of course there's the investigation of why it wasn't
> > > installed correctly in the first place, and what was happening
> > > during the "several attempts" at installing ffmpeg.
> > >   
> > 
> > Apparently nothing during these attempts involved libopenal1,
> > according to the logs in /var/log/apt/ - is there anywhere else
> > that could shed light on this?  
> 
> Is it still marked as Automatic? Particularly if you try to install
> it, it will lose that flag (all this is IIRC). Further use of that
> command sequence would have no effect in that case.
> 

root@deb9:~# apt search libopenal1
Sorting... Done
Full Text Search... Done
libopenal1/stable,now 1:1.17.2-4+b2 amd64 [installed,automatic]
[...]

> The dependency is via another package. I've found that removing a
> package doesn't always reach down to all the Automatic packages
> beneath it. This is easily demonstrated by installing a package
> with multiple dependencies (in depth) and then immediately purging
> it.
> 
> But none of this gets down to the root of the problem (why the
> installed package didn't provide the library). Perhaps it might
> be worth occasionally running
> # debsums -l
> # debsums -ca
> to check things over. There's also dpkg -V.
> 

root@deb9:~# debsums -l
root@deb9:~# 

root@deb9:~# debsums -ca 2>/home/dan/debsums.out
/etc/lvm/lvm.conf
...producing 958.9 kB of missing file messages in debsums.out, none
mention libopenal1.

root@deb9:~# dpkg -V >/home/dan/dpkg.out
...producing 590.2 kB of text lines, none mention libopenal1.

Now that libopenal1 has been reinstalled and ffmpeg runs this is
probably to be expected, right? It would have been more interesting if
done when deb9 was broken WRT ffmpeg.

 - Dan

Re: Missing Shared Object File for ffmpeg

On Tue, 20 Mar 2018 13:42:24 -0500
David Wright <deb...@lionunicorn.co.uk> wrote:

> On Tue 20 Mar 2018 at 13:47:42 (-0400), Dan Norton wrote:
> > On Tue, 20 Mar 2018 12:59:21 -0400
> > Greg Wooledge <wool...@eeg.ccf.org> wrote:
> >   
> > > On Tue, Mar 20, 2018 at 12:18:05PM -0400, Dan Norton wrote:  
> > > > >  * The output of "apt policy ffmpeg".
> > > > 
> > > > ffmpeg:
> > > >   Installed: 7:3.2.10-1~deb9u1
> > > >   Candidate: 7:3.2.10-1~deb9u1
> > > >   Version table:
> > > >  *** 7:3.2.10-1~deb9u1 500
> > > > 500 http://debian.gtisc.gatech.edu/debian stretch/main
> > > > amd64 Packages 
> > > > 500 http://security.debian.org/debian-security
> > > > stretch/updates/main amd64 Packages 
> > > > 100 /var/lib/dpkg/status
> > > > 
> > > > >  * The output of "aptitude why libopenal1".
> > > > 
> > > > i   ffmpegDepends libavdevice57 (>= 7:3.2.10)
> > > > i A libavdevice57 Depends libopenal1 (>= 1.14)   
> > >   
> > > >From these, it looks like you have the stretch version of ffmpeg,
> > > >and
> > > a libopenal1 dependency that can be satisfied by the stretch
> > > version of libopenal1.
> > > 
> > > If libopenal1 is not actually installed, then something is very
> > > wrong. Is it possible that you have the package "installed", but
> > > something else removed the library file?  In that case, just
> > > reinstall the package:
> > > 
> > > apt-get --reinstall install libopenal1
> > >   
> > 
> > That did it - thanks, Greg! 
> > 
> > But what does this do that apt purge/install of ffmpeg does not?  
> 
> You posted:
> 
> # apt purge ffmpeg
> # apt autoremove
> # apt install ffmpeg
> 
> but you didn't show your working. You should check out what happened
> by looking at /var/log/apt/history.log to see if libopenal1 was
> affected by this command sequence. For a start, other packages might
> depend on libopenal1, preventing its auto-removal.
> 

The broken system was installed in December 2017. Looking at all the
logs in /var/log/apt/history* (extracting the ones that were
archived) and running:
dan@deb9:~/apt.logs$ grep -rnw '.' -e 'libopenal1' | less
...there is one hit, other than today's --reinstall and that is an
install:

Start-Date: 2017-12-17  21:29:03
Commandline: /usr/sbin/synaptic
Requested-By: dan (1200)
Install: [...]
libopenal1:amd64 (1:1.17.2-4+b2, automatic),  # e pluribus unum
[...]

> Then of course there's the investigation of why it wasn't
> installed correctly in the first place, and what was happening
> during the "several attempts" at installing ffmpeg.
> 

Apparently nothing during these attempts involved libopenal1, according
to the logs in /var/log/apt/ - is there anywhere else that could shed
light on this?

 - Dan

Re: Missing Shared Object File for ffmpeg

On Tue, 20 Mar 2018 19:02:23 +0100
<to...@tuxteam.de> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> On Tue, Mar 20, 2018 at 01:47:42PM -0400, Dan Norton wrote:
> 
> [...]
> 
> > > apt-get --reinstall install libopenal1
> > >   
> > 
> > That did it - thanks, Greg!   
> 
> My guess would be that libopenal1 (the package) was installed,
> but the library (the file) has been somehow deleted.
>
> The --reinstall forces apt to install the package even if it
> thinks it's already there (quite useful in such a case :)
> 

"--reinstall install" - that's strange and unusual :)
but I'm glad it worked.

 - Dan

> Cheers
> - -- t
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> 
> iEYEARECAAYFAlqxTK8ACgkQBcgs9XrR2kbmSgCffJO16KsjvSFiI144dqzK0+Ip
> vEgAn124eKQhe4hESe71CJ0avU+jOh+P
> =GtAc
> -END PGP SIGNATURE-
>

Re: Missing Shared Object File for ffmpeg

On Tue, 20 Mar 2018 12:59:21 -0400
Greg Wooledge <wool...@eeg.ccf.org> wrote:

> On Tue, Mar 20, 2018 at 12:18:05PM -0400, Dan Norton wrote:
> > >  * The output of "apt policy ffmpeg".  
> > 
> > ffmpeg:
> >   Installed: 7:3.2.10-1~deb9u1
> >   Candidate: 7:3.2.10-1~deb9u1
> >   Version table:
> >  *** 7:3.2.10-1~deb9u1 500
> > 500 http://debian.gtisc.gatech.edu/debian stretch/main amd64
> > Packages 
> > 500 http://security.debian.org/debian-security
> > stretch/updates/main amd64 Packages 
> > 100 /var/lib/dpkg/status
> >   
> > >  * The output of "aptitude why libopenal1".  
> > 
> > i   ffmpegDepends libavdevice57 (>= 7:3.2.10)
> > i A libavdevice57 Depends libopenal1 (>= 1.14) 
> 
> >From these, it looks like you have the stretch version of ffmpeg,
> >and  
> a libopenal1 dependency that can be satisfied by the stretch version
> of libopenal1.
> 
> If libopenal1 is not actually installed, then something is very wrong.
> Is it possible that you have the package "installed", but something
> else removed the library file?  In that case, just reinstall the
> package:
> 
> apt-get --reinstall install libopenal1
> 

That did it - thanks, Greg! 

But what does this do that apt purge/install of ffmpeg does not?

Re: Missing Shared Object File for ffmpeg

On Tue, 20 Mar 2018 08:41:40 -0400
Greg Wooledge  wrote:

> On Tue, Mar 20, 2018 at 10:12:41AM +, Curt wrote:
> > On 2018-03-20,   wrote:  
> > > Now the interesting question would be: in *both* your stretches?  
> > 
> > It is interesting maybe. I don't understand it, though.   
> 
> Basically, you're not supplying enough information to diagnose the
> problem.  We would need some or all of:
> 
(from the non-working system)

>  * Your /etc/apt/sources.list file.

deb http://debian.gtisc.gatech.edu/debian/ stretch main contrib non-free
deb-src http://debian.gtisc.gatech.edu/debian/ stretch main contrib
non-free

deb http://security.debian.org/debian-security stretch/updates main
contrib non-free 
deb-src http://security.debian.org/debian-security stretch/updates main
contrib non-free

deb http://debian.gtisc.gatech.edu/debian/ stretch-updates main contrib
non-free 
deb-src http://debian.gtisc.gatech.edu/debian/ stretch-updates main
contrib non-free

deb http://debian.gtisc.gatech.edu/debian/ stretch-backports main
contrib non-free

>  * The exact version of the ffmpeg package (dpkg -l ffmpeg | cat).

ii  ffmpeg 7:3.2.10-1~deb9u1 amd64

>  * The output of "apt policy ffmpeg".

ffmpeg:
  Installed: 7:3.2.10-1~deb9u1
  Candidate: 7:3.2.10-1~deb9u1
  Version table:
 *** 7:3.2.10-1~deb9u1 500
500 http://debian.gtisc.gatech.edu/debian stretch/main amd64
Packages 
500 http://security.debian.org/debian-security
stretch/updates/main amd64 Packages 
100 /var/lib/dpkg/status

>  * The output of "aptitude why libopenal1".

i   ffmpegDepends libavdevice57 (>= 7:3.2.10)
i A libavdevice57 Depends libopenal1 (>= 1.14)   

>  * Any interesting files in /etc/apt/apt.conf.d/ which may affect
>package selection (especially the treament of Suggests and
> Recommends).

root@deb9:~# egrep -wr 'Suggests|Recommends' /etc/apt/apt.conf.d/
/etc/apt/apt.conf.d/99synaptic:APT::Install-Recommends "true";

> 
> >From the non-working system, of course.  Though you may find the  
> output of "aptitude why libopenal1" to be informative on the working
> system.
> 

i   ffmpegDepends libavdevice57 (>= 7:3.2.10)
i A libavdevice57 Depends libopenal1 (>= 1.14)   

A thought: The working system is little changed from the installed
state, so it has mozilla. However, on the non-working system, mozilla is
purged and palemoon installed. The name "ffmpeg"...
 ^^ ...any relation to firefox?

Missing Shared Object File for ffmpeg

2018-03-19 Thread Dan Norton

I have two stretch systems, named deb4 and deb9. Both were installed
via netinst, have the latest apt update; apt upgrade, and report:

$ uname -v
#1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02)

Several attempts to install ffmpeg on deb9 have appeared to succeed,
but ffmpeg with various options consistently reports:

ffmpeg: error while loading shared libraries: libopenal.so.1: cannot
open shared object file: No such file or directory

On the other system, deb4, ffmpeg installed and ran immediately and was
successfully used to split a .mov file into two parts.

/etc/apt/sources.list is the same on deb4 and deb9. I have compared the
package versions on deb9 with those on deb4 and they are the same.
Before reinstalling ffmpeg on deb9 I ran:

# apt purge ffmpeg
# apt autoremove
# apt install ffmpeg

I've run ldconfig and repeated the above. STW, I've set
LD_LIBRARY_PATH=/usr/local/lib and repeated. Also tried:
# apt search openal
...and saw that it contains libopenal.so.1 but:
# apt install openal
E: Unable to locate package openal

What do I need to do to figure out what's wrong with deb9?

 - Dan

Re: Boot Order Change

2018-03-01 Thread Dan Norton

On Thu, 22 Feb 2018 16:41:42 -0500
Felix Miata <mrma...@earthlink.net> wrote:

> Dan Norton composed on 2018-02-22 16:05 (UTC-0500):
> 
> > Installs of both stretch and buster modify the boot order such that
> > "debian" is first under "UEFI Boot Sources". After installation, the
> > bios menu has to be edited in order to boot from DVD or CD or USB
> > drive. Also "Hard Drive" has been replaced with "debian".  
> 
> > The PC is:
> > Hewlett-Packard HP Pro 3400 Series MT/2ABF, BIOS 7.16 03/23/2012  
> 
> > Apparently it is deliberate, so what is the reason for this?  
> 
> AFAICT, it depends on the particular BIOS design and settings
> therein, how it's designed to react to what it finds in the EFI
> partition, particularly if there is more than one entry there. Brand
> name PCs tend to offer fewer BIOS options.

In case someone finds this thread in the archives; finally the reason
got through to me over on debian-boot[1]. Unlike the primary/logical
scheme with an mbr, where an installer can just write a new mbr, in the
UEFI scheme the grub code is *added* to the EFI system partition with
nothing pointing to it until the UEFI menu is changed.

[1]
https://lists.debian.org/debian-boot/2018/02/msg00460.html

Boot Order Change

2018-02-22 Thread Dan Norton

Installs of both stretch and buster modify the boot order such that
"debian" is first under "UEFI Boot Sources". After installation, the
bios menu has to be edited in order to boot from DVD or CD or USB
drive. Also "Hard Drive" has been replaced with "debian".

The PC is:
Hewlett-Packard HP Pro 3400 Series MT/2ABF, BIOS 7.16 03/23/2012

Apparently it is deliberate, so what is the reason for this?

 - Dan

Re: BIOS Can Not Find Disk

2018-02-21 Thread Dan Norton

On Wed, 21 Feb 2018 23:19:04 +0100
Pascal Hambourg <pas...@plouf.fr.eu.org> wrote:

> Le 21/02/2018 à 03:53, Dan Norton a écrit :
> > 
> > In contrast, with GPT and LVM, for the second and subsequent
> > installations, the partitioning and defining of PVs, VGs, and LVs
> > needs to be done before installation using gdisk and the LVM tools
> > in /sbin. Then, the installer with manual partitioning can succeed
> > by defining the mount points of the various LVs.  
> 
> No, all this can be done during the installation.
> 

Interesting. Via manual partitioning? Changing what's there? Bare disk?

Re: BIOS Can Not Find Disk

2018-02-20 Thread Dan Norton

As the OP, I want to try to clear up some of the confusion. I have
caused plenty of it. :-)

I drop-kicked the partitions I had set up and started over with a bare
(nothing but free space) sda block device. At some point I have
expressed doubt that my PC could handle UEFI correctly. This is not
true. I have been able to install multiple Debian systems (jessie,
stretch, and sid) using GPT and LVM. These same systems have also been
installed on this PC using the old primary/logical (dos) scheme with
LVM, starting with a bare disk. This desktop PC, according to dmesg is:

HP Pro 3400 Series MT/2ABF, BIOS 7.16 03/23/2012

Placing faith in the installer and letting it do as much of the work as
it will seems to be a good approach. YMMV. Also be unafraid to
power-off and re-boot the installer if you can't figure a way out of
some difficulty. Hey, after a few dozen of these, you may even start to
relax! The backup (/home and /var) has definitely been tested.

IIRC, the installer handles a greater proportion of the job in the
primary/logical LVM scheme and manual partitioning. 

In contrast, with GPT and LVM, for the second and subsequent
installations, the partitioning and defining of PVs, VGs, and LVs needs
to be done before installation using gdisk and the LVM tools in /sbin.
Then, the installer with manual partitioning can succeed by defining
the mount points of the various LVs.

 - Dan

Re: Debian 8 and Debian 9 Dual Boot

2017-12-29 Thread Dan Norton


On 12/29/2017 08:52 AM, Pascal Hambourg wrote:

Le 21/12/2017 à 20:07, Dan Norton a écrit :



Disklabel type: gpt
Disk identifier: A615A904-0620-459F-BF44-5E53E54FDF24
Device Start    End    Sectors   Size Type
/dev/sda1   2048 411647 409600   200M BIOS boot

(...)

Is there a problem here?


Yes. /dev/sda1 has the type "BIOS boot" but is actually used as an EFI 
system partition, according to df and /etc/fstab. So it should have 
the type "EFI system".




Ah. Getting this right is a problem for me, but when the installer does 
all the partitioning, the right choices seem to be made.


Before moving on to multiboot with LVM and GPT, I'd like to change 
the menu entries to something more consistent. The last install is 
referred to as "Debian GNU/Linux" but that's ambiguous. Which Debian 
GNU/Linux? If each entry was in the form "Debian GNU/Linux 9 
(stretch) (on /dev/mapper/vol2-root)" that would really be explicit. 
Also I want some more time to mull over which to boot.


The details for other detected OSes are provided by os-prober. The 
entry title for the main OS is derived from the GRUB_DISTRIBUTOR 
variable in /etc/default/grub. You can tweak it to fit your needs. If 
lsb-release is installed, changing -i to -d will provide more details 
such as the Debian version and codename.




Very helpful. Actually the name is "lsb_release". I need to study the 
shell - not sure about that GRUB_DISTRIBUTOR statement. Will definitely 
change the -i to -d. Why isn't -ds needed?

Re: Debian 8 and Debian 9 Dual Boot

2017-12-28 Thread Dan Norton


On 12/28/2017 04:48 AM, Pascal Hambourg wrote:

Le 24/12/2017 à 05:36, Felix Miata a écrit :

Dan Norton composed on 2017-12-23 19:15 (UTC-0500):


The menu inside the box is:
Debian GNU/Linux
Advanced options for Debian GNU/Linux
Debian GNU/Linux 8 (jessie) (on /dev/mapper/vol1-root)
Advanced options for Debian GNU/Linux 8 (jessie) (on 
/dev/mapper/vol1-root)

Debian GNU/Linux buster/sid (on /dev/mapper/vol3-root)
Advanced options for Debian GNU/Linux buster/sid (on 
/dev/mapper/vol3-root)



The first two boot stretch, so they will eventually have "9 (stretch)
(on /dev/mapper/vol2-root)" appended, once the timeout is under 
control.


Based on what I see and what you say, it seems you are modifying the 
timeout for
Stretch (/etc/default/grub on vol2), but actually booting Stretch 
from Jessie's
grub.cfg (/etc/default/grub on vol1), which remains configured to 3 
seconds.


Based on what I see and what Dan wrote, I'd rather say the other way 
around : Dan edited /etc/default/grub in Jessie (update-grub showed 
the system kernel was Jessie's 3.16 and found stretch/9.3 as a foreign 
system) but the GRUB loading at boot time is the one from stretch (the 
first entries boot stretch). So the time-out must be changed from 
stretch.


You can check the result of /etc/default/grub parameters in 
/boot/grub/grub.cfg after running update-grub.
You can also check GRUB variables at boot time in GRUB's shell (press 
"c" to spawn the shell) with the command "set". It will also display 
value of the "prefix" variable which contains the device and path to 
the used /boot/grub directory.




We have a winner! Thanks Pascal.

I checked the GRUB variables for each installation: jessie, stretch, and 
buster. The prefix was identical for all - a hairy, hard to read, 
touch-typing exercise of the form:


lvmid//

Of course, the UUIDs were immediately recognizable ;-) as belonging to 
volume group "vol2" and logical volume "root" where stretch was 
installed. I changed the time-out in /etc/default/grub and ran 
update-grub from stretch and it *changed* .


The old /etc/default/grub was like this (excluding comments):

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet"
GRUB_CMDLINE_LINUX=""

...so the 3 seconds I was seeing was probably due to a run-off of the 5. 
Anyway, I changed 5 to 12 arbitrarily and that was effective.


Thank you, Pascal.

Re: Saving Sent Messages with Thunderbird

2017-12-28 Thread Dan Norton


On 12/28/2017 09:45 AM, The Wanderer wrote:

On 2017-12-28 at 09:37, Dan Norton wrote:


On 12/22/2017 08:46 PM, The Wanderer wrote:

On 2017-12-22 at 20:25, Dan Norton wrote:

Interesting. You're not going to see Edit however unless you have
a Write in progress.

Eh? In the main Thunderbird or Firefox window - with the folder
list, message list, and (in my preferred layout) selected message -
I most certainly do see an Edit menu; it's right next to the File
menu.

No File or Edit menu in the main window here.


 From the window where you read email, you can get to Preferences
via some mouse gymnastics and then to Account settings. This
window could use a tool bar.

No complicated gymnastics are required; it's simply Edit ->
Preferences. (I don't even know what gymnastics you're proposing.)

I installed Thunderbird on a netinst of Debian 8 and 9 using
synaptic. Same result for both: no File or Edit menu.

What version of Thunderbird are you using? How did you install it?

(I replied to your off-list response before seeing this one. Sorry.)

I'd forgotten that apparently Thunderbird now ships with the menu bar
disabled by default, for the same (IMO wrongheaded) reasons as Firefox
does.

https://support.mozilla.org/en-US/kb/display-thunderbird-menus-and-toolbar
explains how to turn it back on; it's been so long since I did so that
I'd forgotten that having it off was even an option, especially since I
don't understand (on any but an intellectual level) why anyone would
want to have it off.



Thank you! The default is wrongheaded for sure. I started using Palemoon 
because of that. Even the way to get the toolbar back is weird: 
"right-click on an empty section of the Tab Strip..."

Re: Saving Sent Messages with Thunderbird

2017-12-28 Thread Dan Norton


On 12/22/2017 08:46 PM, The Wanderer wrote:


Is there a reason why you replied off-list?


Unintentional.



On 2017-12-22 at 20:25, Dan Norton wrote:


On 12/22/2017 02:23 PM, The Wanderer wrote:


On 2017-12-22 at 13:59, Joe wrote:

I don't go back far enough with either Debian or Thunderbird to
know why...

Unless I'm much mistaken, it's a Windows/Linux difference.

For obscure and probably-mostly-historical reasons, Linux versions
of Thunderbird and Firefox use "Preferences" under "Edit" as the
way to open the program's main configuration window, and Windows
ones use "Options" under "Tools".

"Account Settings" apparently follows the other menu option.

I vaguely seem to recall that once upon a time the Windows version
of the program(s) - possibly back in the days before Firefox, when
the unified suite was all there was - used "Preferences" under
"Edit" as well, and that they changed at some point for some
reason.


Interesting. You're not going to see Edit however unless you have a
Write in progress.

Eh? In the main Thunderbird or Firefox window - with the folder list,
message list, and (in my preferred layout) selected message - I most
certainly do see an Edit menu; it's right next to the File menu.


No File or Edit menu in the main window here.




 From the window where you read email, you can get to Preferences via
some mouse gymnastics and then to Account settings. This window
could use a tool bar.

No complicated gymnastics are required; it's simply Edit -> Preferences.
(I don't even know what gymnastics you're proposing.)



I installed Thunderbird on a netinst of Debian 8 and 9 using synaptic. 
Same result for both: no File or Edit menu.


What version of Thunderbird are you using? How did you install it?

Re: Debian 8 and Debian 9 Dual Boot

2017-12-27 Thread Dan Norton


On 12/23/2017 11:36 PM, Felix Miata wrote:


Dan Norton composed on 2017-12-23 19:15 (UTC-0500):


Felix Miata wrote:
The menu inside the box is:
Debian GNU/Linux
Advanced options for Debian GNU/Linux
Debian GNU/Linux 8 (jessie) (on /dev/mapper/vol1-root)
Advanced options for Debian GNU/Linux 8 (jessie) (on /dev/mapper/vol1-root)
Debian GNU/Linux buster/sid (on /dev/mapper/vol3-root)
Advanced options for Debian GNU/Linux buster/sid (on /dev/mapper/vol3-root)
The first two boot stretch, so they will eventually have "9 (stretch)
(on /dev/mapper/vol2-root)" appended, once the timeout is under control.

Based on what I see and what you say, it seems you are modifying the timeout for
Stretch (/etc/default/grub on vol2), but actually booting Stretch from Jessie's
grub.cfg (/etc/default/grub on vol1), which remains configured to 3 seconds.


That seems reasonable, but I've tried modifying the timeout after 
booting each of the installations. The timeout remains immutable. It's 
as if update-grub is not using what is in grub.d for timeout value. But 
where does 3s come from?




Is there more than one directory in /boot/efi/EFI/? If not, it's likely time for
you to explore using /etc/default/grub's GRUB_DISTRIBUTOR= option. I need to
(only one Debian, but 3 openSUSEs installed), but have been putting it off,
using Stretch's menu for all.


There is only onedirectory in /boot/efi/EFI/ :

root@BR914:/# ls -la /boot/efi/EFI
total 12
drwx-- 3 root root 4096 Dec  4 22:11 .
drwx-- 3 root root 4096 Dec 31  1969 ..
drwx-- 2 root root 4096 Dec  4 22:11 debian

How would GRUB_DISTRIBUTOR=help the timeout= problem? OTOH, to change 
the wording of menu entries, I can edit grub.d files.

Re: Debian 8 and Debian 9 Dual Boot

2017-12-23 Thread Dan Norton


On 12/23/2017 04:35 PM, Felix Miata wrote:


Dan Norton composed on 2017-12-23 15:12 (UTC-0500):


Felix Miata wrote:

[...]
It's not so easy to figure out when POST is over with UEFI. Here, it seems
efibootmgr -t provides extra delay beyond what the BIOS defines for you to make
a selection from its own boot device selection menu, which requires an F12
keystroke here to see.
The timeout after appearance of Grub's menu is supposed to be controlled by
/etc/default/grub's GRUB_TIMEOUT=, which shows up here in Stretch's grub.cfg
first on line 86, a few lines before "### END /etc/grub.d/00_header ###".

Edited /etc/default/grub to change GRUB_TIMEOUT to 11:
root@BR914:/etc/default# nano grub
Observed "If you change this file, run 'update-grub' afterwards..." :
root@BR914:/etc/default# update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-3.16.0-4-amd64
Found initrd image: /boot/initrd.img-3.16.0-4-amd64
Found Debian GNU/Linux (9.3) on /dev/mapper/vol2-root
Found Debian GNU/Linux (buster/sid) on /dev/mapper/vol3-root
done
Looking at /boot/grub/grub.cfg, timeout is mentioned as follows:
if [ "${recordfail}" = 1 ] ; then
    set timeout=-1
else
    if [ x$feature_timeout_style = xy ] ; then
      set timeout_style=menu
      set timeout=11
    # Fallback normal timeout code in case the timeout_style feature is
    # unavailable.
    else
      set timeout=11
    fi
fi
...but there is no effect. The timeout when rebooting is still 3
seconds. I'm no shell expert so I don't know how to interpret the above.

What exactly is on the screen during those 3 seconds?



The menu inside the box is:
Debian GNU/Linux
Advanced options for Debian GNU/Linux
Debian GNU/Linux 8 (jessie) (on /dev/mapper/vol1-root)
Advanced options for Debian GNU/Linux 8 (jessie) (on /dev/mapper/vol1-root)
Debian GNU/Linux buster/sid (on /dev/mapper/vol3-root)
Advanced options for Debian GNU/Linux buster/sid (on /dev/mapper/vol3-root)

The first two boot stretch, so they will eventually have "9 (stretch) 
(on /dev/mapper/vol2-root)" appended, once the timeout is under control.


[...]

Re: Debian 8 and Debian 9 Dual Boot

2017-12-23 Thread Dan Norton


On 12/21/2017 05:13 PM, Felix Miata wrote:

[...]
It's not so easy to figure out when POST is over with UEFI. Here, it seems
efibootmgr -t provides extra delay beyond what the BIOS defines for you to make
a selection from its own boot device selection menu, which requires an F12
keystroke here to see.

The timeout after appearance of Grub's menu is supposed to be controlled by
/etc/default/grub's GRUB_TIMEOUT=, which shows up here in Stretch's grub.cfg
first on line 86, a few lines before "### END /etc/grub.d/00_header ###".


Edited /etc/default/grub to change GRUB_TIMEOUT to 11:
root@BR914:/etc/default# nano grub

Observed "If you change this file, run 'update-grub' afterwards..." :
root@BR914:/etc/default# update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-3.16.0-4-amd64
Found initrd image: /boot/initrd.img-3.16.0-4-amd64
Found Debian GNU/Linux (9.3) on /dev/mapper/vol2-root
Found Debian GNU/Linux (buster/sid) on /dev/mapper/vol3-root
done

Looking at /boot/grub/grub.cfg, timeout is mentioned as follows:
if [ "${recordfail}" = 1 ] ; then
  set timeout=-1
else
  if [ x$feature_timeout_style = xy ] ; then
    set timeout_style=menu
    set timeout=11
  # Fallback normal timeout code in case the timeout_style feature is
  # unavailable.
  else
    set timeout=11
  fi
fi

...but there is no effect. The timeout when rebooting is still 3 
seconds. I'm no shell expert so I don't know how to interpret the above.

Re: Migrate an old debian to a new machine

2017-12-23 Thread Dan Norton


On 12/23/2017 07:21 AM, Pascal Hambourg wrote:


Le 23/12/2017 à 12:10, Georgi Naplatanov a écrit :


  - connect new disk to old computer and boot from your old disk
  - partition your new disk with your favorite program. I like cgdisk
from gdisk package


gdisk and cgdisk handle only GPT. For DOS/MBR, you'll need another 
program such as fdisk or (g)parted.


How about partitioning a new disk using the installer itself - would 
that work?

Re: Saving Sent Messages with Thunderbird

2017-12-22 Thread Dan Norton


On 12/22/2017 06:34 AM, Richard Owlett wrote:


On 12/21/2017 08:31 PM, Dan Norton wrote:

By default, Thunderbird saves copies of sent emails in your email
account with the ISP. You can to save them instead to a local folder by
right-clicking on Local Folders and selecting "settings -> Copies and
Folders -> When sending messages, automatically:". You can also make the
reverse choice in this dialog.

Currently, web searches seem to turn up some out-dated info on how to do
this.

 - Dan




mozilla.support.thunderbird is an active support list

That list refers to a different version of Thunderbird - one that has a 
"Tools > Account Settings" menu. Debian 8 has access to Thunderbird 
52.5.0 (64-bit) which has no such menu.

Saving Sent Messages with Thunderbird

2017-12-21 Thread Dan Norton

By default, Thunderbird saves copies of sent emails in your email 
account with the ISP. You can to save them instead to a local folder by 
right-clicking on Local Folders and selecting "settings -> Copies and 
Folders -> When sending messages, automatically:". You can also make the 
reverse choice in this dialog.


Currently, web searches seem to turn up some out-dated info on how to do 
this.


 - Dan

Re: Debian 8 and Debian 9 Dual Boot

2017-12-21 Thread Dan Norton


On 12/21/2017 02:54 PM, Felix Miata wrote:

Dan Norton composed on 2017-12-21 14:07 (UTC-0500):


2. You will make extra work for yourself by having a common swap
partition for all installations. With the common swap, each new
installation gave rise to these messages:
    a. "gave up waiting for suspend/resume device"
    b. "a start job is running for dev-disk-by\..."
    c. "failed to connect to lvmetad"
STW can reveal ways to avoid these messages, but they are a PITA and
avoidable by each volume group having its own swap.

Except with a first Linux installation, I tell the partitioner not to use swap,
then add it by LABEL to fstab after installing. The problem is that the
installer insists that the swap partition needs to be formatted, destroying the
validity of swap's UUID in the fstabs of the previous installations.


There are still mysteries I have not solved. For some reason, GRUB has
decided that after POST, you only need 3 seconds to choose which
installation to boot. GRUB has resisted my efforts to change that
timeout value. I've been able to change the boot order in NVRAM, but not
the timeout.

efibootmgr -t ##


Yes, it seems like that should work, but currently:

# efibootmgr
BootCurrent: 
Timeout: 11 seconds  # ... and the actual timeout is 3
BootOrder: 0003,0001,,0002,0006,0004,0005
Boot* debian
Boot0001* USB Floppy/CD
Boot0002* USB Hard Drive
Boot0003* ATAPI CD-ROM Drive
Boot0004* Unknown Device
Boot0005* USB Floppy/CD
Boot0006* Hard Drive

Doing it again (See definition of insanity [1])
# efibootmgr -t 12
BootCurrent: 
Timeout: 12 seconds
BootOrder: 0003,0001,,0002,0006,0004,0005
Boot* debian
Boot0001* USB Floppy/CD
Boot0002* USB Hard Drive
Boot0003* ATAPI CD-ROM Drive
Boot0004* Unknown Device
Boot0005* USB Floppy/CD
Boot0006* Hard Drive


Well, that changed it from 3 to 4 (!?). Strange.

[1] "Insanity is doing the same thing over & over again and expecting a 
different result." - Einstein

Re: Debian 8 and Debian 9 Dual Boot

2017-12-21 Thread Dan Norton


On 12/21/2017 04:36 AM, Felix Miata wrote:

Felix Miata composed on 2017-11-29 13:55 (UTC-0500):


Dan Norton composed on 2017-11-28 22:15 (UTC-0500):

dan@debian8:~$ sudo fdisk /dev/sda
Command (m for help): p
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A615A904-0620-459F-BF44-5E53E54FDF24
Device Start    End    Sectors   Size Type
/dev/sda1   2048 411647 409600   200M BIOS boot
/dev/sda2 411648   16783359   16371712   7.8G Linux swap
/dev/sda3   16783360  151001087  134217728    64G Linux LVM
/dev/sda4  151001088  285218815  134217728    64G Linux LVM
/dev/sda5  285218816  419436543  134217728    64G Linux LVM
/dev/sda6  419436544  553654271  134217728    64G Linux LVM
/dev/sda7  553654272 1953525134 1399870863 667.5G Linux filesystem
Is there a problem here?

Maybe. I don't have any GPT-partitioned disks...

No longer the case. I bought a G250 Kaby Lake Intel motherboard. I currently
have Stretch, openSUSE Tumbleweed and openSUSE 15.0 Alpha installed. openSUSE
42.3's installer hangs in the bootloader configuration step.
https://bugzilla.opensuse.org/show_bug.cgi?id=1073201

http://fm.no-ip.com/Tmp/Dfsee/gb250L02.txt  is my partition log. The upper part
is generated by the partitioner I use. The bottom is gpart -l output for 
comparison.

I haven't seen you post the debian-user list in a while. How's multiboot going
for you?


Not bad, actually. I'm nearly ready to try multiboot with GPT again on 
my (elderly) HP desktop machine. It only has a 1T sda, but that seems 
like wretched excess.


Currently jessie, stretch, and buster are installed with primary/logical 
partitioning. Each is in a separate volume group, with logical volumes 
for /, /var, /tmp, /home, and swap. IMHO, the following guidelines are 
helpful:


1. Do all partitioning with the installer. Don't try to prepare the EFI 
for example with other partitioners. Partitioning can be daunting, but 
if you patiently and sometimes repeatedly use the installer UI, you can 
set up the desired partitioning. The installer UI could be improved. :-)


2. You will make extra work for yourself by having a common swap 
partition for all installations. With the common swap, each new 
installation gave rise to these messages:


  a. "gave up waiting for suspend/resume device"

  b. "a start job is running for dev-disk-by\..."

  c. "failed to connect to lvmetad"

STW can reveal ways to avoid these messages, but they are a PITA and 
avoidable by each volume group having its own swap.


There are still mysteries I have not solved. For some reason, GRUB has 
decided that after POST, you only need 3 seconds to choose which 
installation to boot. GRUB has resisted my efforts to change that 
timeout value. I've been able to change the boot order in NVRAM, but not 
the timeout.


Before moving on to multiboot with LVM and GPT, I'd like to change the 
menu entries to something more consistent. The last install is referred 
to as "Debian GNU/Linux" but that's ambiguous. Which Debian GNU/Linux? 
If each entry was in the form "Debian GNU/Linux 9 (stretch) (on 
/dev/mapper/vol2-root)" that would really be explicit. Also I want some 
more time to mull over which to boot.


 - Dan

Re: BIOS Can Not Find Disk

2017-12-05 Thread Dan Norton

On 12/04/2017 12:17 AM, David Christensen wrote:

On 12/03/17 13:44, Dan Norton wrote:

On 12/02/2017 02:35 PM, David Christensen wrote:
I'm not making progress with this PC so I'll probably abandon GPT.
The disk is 1T and it was handled by the extended partition scheme
before this experiment and it probably can again. I still want to do
LVM and multiboot a few systems though.

[...]

When I mount /dev/sda1, I see:

# mount -o ro /dev/sda1 /mnt/sda1

# mount | grep /mnt/sda1
/dev/sda1 on /mnt/sda1 type vfat
(ro,relatime,fmask=0022,dmask=0022,codepage=437,iocharset=ascii,shortname=mixed,utf8,errors=remount-ro)

# df /dev/sda1
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda1 973952 188 973764 1% /mnt/sda1

# tree -a /mnt/sda1
/mnt/sda1
`-- EFI
`-- debian
`-- grubx64.efi

# ls -l /mnt/sda1/EFI/debian/grubx64.efi
-rwxr-xr-x 1 root root 178688 Dec 2 23:33
/mnt/sda1/EFI/debian/grubx64.efi

# file /mnt/sda1/EFI/debian/grubx64.efi
/mnt/sda1/EFI/debian/grubx64.efi: PE32+ executable (EFI application)
x86-64 (stripped to external PDB), for MS Windows

I can run various LVM commands to confirm that d-i/partman did what I
told it to do.

The next time I try this, I think I'll go the opposite extreme, feed a
blank disk to d-i, let partman automagically format the whole disk,
and see if GRUB installs, if the installation completes without error,
if the disk boots, and what the SSD contains.

This post is being sent from a fresh netinst:

dan@mydeb:~$ uname -v
#1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19)

root@mydeb:/# fdisk -l

Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x29f6f73a

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 976895 974848 476M ef EFI (FAT-12/16/32)
/dev/sda2 976896 16601087 15624192 7.5G 83 Linux
/dev/sda3 16603134 532223999 515620866 245.9G 5 Extended
/dev/sda5 16603136 141600767 124997632 59.6G 8e Linux LVM
/dev/sda6 141602816 266600447 124997632 59.6G 83 Linux
/dev/sda7 266602496 391600127 124997632 59.6G 83 Linux
/dev/sda8 391602176 516599807 124997632 59.6G 83 Linux
/dev/sda9 516601856 532223999 15622144 7.5G 82 Linux swap / Solaris

[...]

As you can see, the partitioning scheme is primary/logical. Needed to
get some work done. I'm in the process of restoring stuff from backup,
but at least the saved emails are OK.

The installer was involved in all partitioning. At the start of this
thread and another, fdisk had been used to define sda1 and sda2. This
time I tried not to over-think it.

First, manual partitioning in the installer was used to remove the LVs
and VGs. Then the physical partitions were removed, resulting in 1TB
free space (the whole disk). There were lots of false starts, but I
learned that you can reboot the installer and run it repeated through
partitioning and eventually get things corrected. I lost count.
Partitioning dread subsided and I began to relax.

Next, primary partitions were defined for sda1 and sda2. Logical
partitions for sda5-9. The installer automagically did sda3 Extended.
When it complained that there was no EFI, sda1 was removed and the EFI
put in its place.

Now you are looking at this and thinking, "Boy, that is really sloppy.
Wasting disk space like that." That's OK, I don't mind. Obviously sda1
is much bigger than needed and sda2 is not used at all but it boots
*normally* at last. Onward to installing another Debian and I may try
GPT again, too.

Many thanks for your help, everyone.

- Dan

My name, Norton Cater, email address: norton.ca...@gmail.com, is on your mailing list in error- Please remove it

2017-12-05 Thread Norton Caterq1qb

Thank you

Sent from my iPad

Re: BIOS Can Not Find Disk

2017-12-04 Thread Dan Norton


On 12/04/2017 12:27 AM, David Christensen wrote:

On 12/03/17 21:17, David Christensen wrote:

But, it was not a total loss -- I can now dissect the SSD.


More info:

# lsblk /dev/sda
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda  8:0    0 14.9G  0 disk
|-sda1   8:1    0  953M  0 part
`-sda2   8:2    0  4.7G  0 part

# parted /dev/sda u s p free
Model: ATA SAMSUNG SSD UM41 (scsi)
Disk /dev/sda: 31277232s
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:

Number  Start  End    Size   File system  Name Flags
    34s    2047s  2014s  Free Space
 1  2048s  1953791s   1951744s   fat32    ESP boot, esp
 2  1953792s   11718655s  9764864s    stretch  lvm
    11718656s  31277198s  19558543s  Free Space


Are there any other commands that readers might find interesting 
(before I wipe the SSD)?




Just out of curiosity, lvdisplay?

 - Dan

Re: BIOS Can Not Find Disk


On 12/02/2017 02:35 PM, David Christensen wrote:

[...]


Where is /boot?



Possibly, this is a better answer:

$ df -Th
Filesystem   Type  Size  Used Avail Use% Mounted on
[...]
/dev/sda1    vfat  992K  855K  138K 87% /boot/efi
/dev/mapper/debian8--vg-tmp  ext4  268M  2.1M  247M 1% /tmp
/dev/mapper/debian8--vg-home ext4  9.1G  616M  8.0G 8% /home
/dev/mapper/debian8--vg-var  ext4  8.2G  1.4G  6.4G 17% /var
[...]

 - Dan

Re: BIOS Can Not Find Disk


On 12/03/2017 02:04 PM, Felix Miata wrote:

Dan Norton composed on 2017-12-04 08:00 (UTC-0500):


Felix Miata wrote:

Dan Norton composed on 2017-12-03 16:44 (UTC-0500):
Note the above is currently from the future. Apparently the PC you are emailing
from is advanced one day.

Must be a result of my Setup menu activities. Debian says it is 07:48 AM
(5 hours late) but I put in the local time from my cell phone in Setup
this morning. Maybe I need to set the HW to UTC?

  That's the preferred time for *nix installations. Check what's in /etc/adjtime
to confirm. HW clock needs to match it. Now you're showing 5 hours late.


I've been wondering what you do with all those
systems, too. It would be much more productive if we worked together.
I'm pretty much self-taught.

  Mostly I try to replicate reported problems and assist in finding solutions,
identifying bugs, and doing bug QA. It's getting harder because my supply of
free PCs to use for the purpose dried up before UEFI started to show up.


Do you ever come to Atlanta? I'm North of it, in Roswell.

  I've never stopped there except to fuel passing through between here and
Wisconsin or Nashville. Last such trip was probably around 25 years ago.


Before you give up, it might be worth more investigation of GPT boot foibles
outside the Debian zone. Archlinux docs are consistently among the best
regardless of distro in use. You might yet have a solution using a simple
procedure applied to what you have already done, if only it can be identified.
http://www.lightofdawn.org/wiki/wiki.cgi/BIOSBootGPT

!!!


After reading this again, did this:

# gdisk /dev/sda
[...]
Command (? for help): x

Expert command (? for help): p
[...]
Number  Start (sector)    End (sector)  Size   Code Name
   1    2048  411647   200.0 MiB   EF00
   2  411648    16783359   7.8 GiB 8200
   3    16783360   151001087   64.0 GiB    8E00
   4   151001088   285218815   64.0 GiB    8E00
   5   285218816   419436543   64.0 GiB    8E00
   6   419436544   553654271   64.0 GiB    8E00
   7   553654272  1953525134   667.5 GiB   8300

[...]

Expert command (? for help): a
Partition number (1-7): 3
[...]
Attribute value is . Set fields are:
  No fields set

Toggle which attribute field (0-63, 64 or  to exit): 2
Have enabled the 'legacy BIOS bootable' attribute.
Attribute value is 0004. Set fields are:
2 (legacy BIOS bootable)

Toggle which attribute field (0-63, 64 or  to exit): w


I know this needs to be followed by more steps... the reference refers 
to Syslinux but we're using GRUB. It says:


2. Next, mount the partition somewhere, say in /mnt/data
3. Use [GRUB2] to install the boot loader, pretending that it is a 
regular partition:

4. Copy [ ? ] which is capable of booting GPT partition to the disk's MBR.

What is needed to fill the two [...]?

The mbr's first 446 bytes are non-empty, but possibly incompatible with 
bios.

Re: BIOS Can Not Find Disk




On 12/03/2017 02:16 PM, Pascal Hambourg wrote:

Le 04/12/2017 à 13:32, Dan Norton a écrit :

On 12/03/2017 06:49 AM, Felix Miata wrote:


Pascal Hambourg composed on 2017-12-03 10:49 (UTC+0100):


Felix Miata composed:

...
So I guess that the OP means that the core image of GRUB is in 
sda1, and

the boot image of GRUB is in the MBR of sda.

(...)
I'm pretty sure that was not OP's intent, i.e., none of Grub at all 
in MBR.


Yes, no grub in mbr - unless installer insists.


Then what you wrote earlier was wrong : GRUB is not installed in 
/dev/sda1, and this partition is useless. As I wrote earlier, a BIOS 
boot partition is used by GRUB to store its core image only when 
installing its boot image in the MBR of the disk. This partition 
replaces the unallocated "embedded area" located between the MBR and 
the first partition on MSDOS disks.




Then, to proceed, remove /dev/sda1 partition followed by grub-install?

Re: BIOS Can Not Find Disk


On 12/03/2017 01:04 PM, Felix Miata wrote:

Dan Norton composed on 2017-12-04 07:32 (UTC-0500):

  Note your posts are still coming from the future. Today ATM in zone -0500 it 
is
still the 3rd of December.


Felix Miata wrote:

I'm pretty sure that was not OP's intent, i.e., none of Grub at all in MBR.

Yes, no grub in mbr - unless installer insists.

...

FWIW, this done just now:
# gdisk /dev/sda
GPT fdisk (gdisk) version 0.8.10
Partition table scan:
    MBR: protective
    BSD: not present
    APM: not present
    GPT: present
Found valid GPT with protective MBR; using GPT.
Command (? for help): b
Enter backup filename to save: mbrforgpt
The operation has completed successfully.
Command (? for help): q

  I don't see anything above to indicate a boot flag has been set anywhere. That
HP might have firmware that insists one exists.
http://www.lightofdawn.org/wiki/wiki.cgi/BIOSBootGPT


# ls -l mbr*
-rw-r--r-- 1 root root 17920 Dec  4 05:47 mbrforgpt
# mc -v mbrforgpt
The above shows 0x55AA at +0x1FE (Boot signature [1]).

  That proves a partition table exists, not whether there is requisite code in
the 446 bytes preceding the table.


Also, the search for 'ERROR:' is not found in the entire 17920 bytes of
file mbrforgpt.

  'ERROR: ' you are encountering is coming from the BIOS/firmware, not anything
on the disk.


+1



[1] https://en.wikipedia.org/wiki/Master_boot_record
Apparently, all is in readiness. It's simply that this PC is not loading
the mbr or anything else from sda. Any other opinions?

  <all, or you wouldn't be getting the ERROR: message. :-p


True, that! :-) There's that business about the pesky bit again. One in 1T.

Re: BIOS Can Not Find Disk


On 12/03/2017 06:49 AM, Felix Miata wrote:


Pascal Hambourg composed on 2017-12-03 10:49 (UTC+0100):


Felix Miata composed:

...

So I guess that the OP means that the core image of GRUB is in sda1, and
the boot image of GRUB is in the MBR of sda.

  Based on OP's response to

https://lists.debian.org/debian-user/2017/11/msg00563.html

in

https://lists.debian.org/debian-user/2017/11/msg00935.html

I'm pretty sure that was not OP's intent, i.e., none of Grub at all in MBR.


Yes, no grub in mbr - unless installer insists.



...

The option the OP chose is to intervene ab initio. When Grub is installed to an
MBR primary partition, and the MBR contains legacy boot code, and a boot flag is
appropriately set, and the same policy is maintained, a subsequent installation
makes no attempt to usurp control from the first.

That does not match my experience. A subsequent installation does not
care about what kind of boot code is in the MBR nor whether a boot flag
is set

  Grub does not care about boot flags, but when depending on legacy (neutral[1])
MBR code to locate the partition from which to boot, as was the apparent plan by
the OP, it's crucial.

The installers of most Linux distros default to installing Grub to the MBR. Some
make it difficult to determine whether any other option even exists. It's been
several months since I last installed Stretch. I don't remember how it presents
bootloader installation location, or more importantly, if when partition is
selected on a device with no installed operating systems, a separate action is
required to ensure the MBR contains any boot code at all.

[1]



FWIW, this done just now:

# gdisk /dev/sda
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.

Command (? for help): b
Enter backup filename to save: mbrforgpt
The operation has completed successfully.

Command (? for help): q

# ls -l mbr*
-rw-r--r-- 1 root root 17920 Dec  4 05:47 mbrforgpt

# mc -v mbrforgpt
The above shows 0x55AA at +0x1FE (Boot signature [1]).
Also, the search for 'ERROR:' is not found in the entire 17920 bytes of 
file mbrforgpt.


[1] https://en.wikipedia.org/wiki/Master_boot_record

Apparently, all is in readiness. It's simply that this PC is not loading 
the mbr or anything else from sda. Any other opinions?

Re: BIOS Can Not Find Disk

2017-12-02 Thread Dan Norton


On 12/02/2017 02:35 PM, David Christensen wrote:

On 12/01/17 20:07, Dan Norton wrote:

On 12/01/2017 08:54 PM, David Christensen wrote:
On 12/01/17 10:50, Dan Norton wrote: >>> Maybe this is the wrong 
forum, but please bear with me a little bit.
This post was sent from a desktop with jessie installed. The 
problem is it will not boot normally. Network booting has been 
disabled in the NVRAM setup. After POST there is a one-liner which 
says it can not find disk. 


Please post the *exact* contents of the console screen.


ERROR:No boot disk has been detected or the disk has failed.


It can be booted with a supergrub2 cd, however.

# fdisk -l

Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A615A904-0620-459F-BF44-5E53E54FDF24

Device Start    End    Sectors   Size Type
/dev/sda1   2048 411647 409600   200M BIOS boot
/dev/sda2 411648   16783359   16371712   7.8G Linux swap
/dev/sda3   16783360  151001087  134217728    64G Linux LVM
/dev/sda4  151001088  285218815  134217728    64G Linux LVM
/dev/sda5  285218816  419436543  134217728    64G Linux LVM
/dev/sda6  419436544  553654271  134217728    64G Linux LVM
/dev/sda7  553654272 1953525134 1399870863 667.5G Linux filesystem


This post is being written with Debian 8 installed on /dev/sda3, 
above.


How did you create the contents of this disk?


fdisk for sda1 and sda2, then installer for sda3 through sda7. The 
installer was from Debian 8.9 netinst on cd.


Does the disk have the original GPT partition table created by HP, or 
did you overwrite it?


It had no GPT until I put  one on it. Previous scheme was 4 primaries 
and 1 extended. The extended had logicals for /, /home, /tmp, and /var.







What are your LVM PV's, VG's, and LV's?


# lvm pvdisplay
   --- Physical volume ---
   PV Name   /dev/sda3
   VG Name   debian8-vg
   PV Size   64.00 GiB / not usable 4.00 MiB
   Allocatable   yes
   PE Size   4.00 MiB
   Total PE  16383
   Free PE   9399
   Allocated PE  6984
   PV UUID vyN3Lt-vGyw-lVZi-RDBG-NoXL-nqlH-k9eolf

   "/dev/sda4" is a new physical volume of "64.00 GiB"
   --- NEW Physical volume ---
   PV Name   /dev/sda4
   VG Name
   PV Size   64.00 GiB
   Allocatable   NO
   PE Size   0
   Total PE  0
   Free PE   0
   Allocated PE  0
   PV UUID QqDROv-x2rg-3C3z-Lkdw-U95u-86BT-Jzrc6O

   "/dev/sda5" is a new physical volume of "64.00 GiB"
   --- NEW Physical volume ---
   PV Name   /dev/sda5
   VG Name
   PV Size   64.00 GiB
   Allocatable   NO
   PE Size   0
   Total PE  0
   Free PE   0
   Allocated PE  0
   PV UUID oOQuaB-qAIu-q3DW-1h0B-rKA0-q1Z4-oznScr

   "/dev/sda6" is a new physical volume of "64.00 GiB"
   --- NEW Physical volume ---
   PV Name   /dev/sda6
   VG Name
   PV Size   64.00 GiB
   Allocatable   NO
   PE Size   0
   Total PE  0
   Free PE   0
   Allocated PE  0
   PV UUID hHiVce-cC0V-u7zz-tqjU-5Rdd-nPza-BlPMQz


# lvm vgdisplay
   --- Volume group ---
   VG Name   debian8-vg
   System ID
   Format    lvm2
   Metadata Areas    1
   Metadata Sequence No  17
   VG Access read/write
   VG Status resizable
   MAX LV    0
   Cur LV    4
   Open LV   4
   Max PV    0
   Cur PV    1
   Act PV    1
   VG Size   64.00 GiB
   PE Size   4.00 MiB
   Total PE  16383
   Alloc PE / Size   6984 / 27.28 GiB
   Free  PE / Size   9399 / 36.71 GiB
   VG UUID   lfqcVE-yP6G-IeYF-zHYt-jc60-Jzas-c1fr5p


# lvm lvdisplay
   --- Logical volume ---
   LV Path    /dev/debian8-vg/root
   LV Name    root
   VG Name    debian8-vg
   LV UUID    Eh9QwL-dTlm-s8H5-5FYN-CxBl-wnvn-om3Pbx
   LV Write Access    read/write
   LV Creation host, time debian8, 2017-11-20 12:32:12 -0500
   LV Status  available
   # open 1
   LV Size    9.31 GiB
   Current LE 2384
   Segments   1
   Allocation inherit
   Read ahead sectors auto
   - currently set to 256
   Block device   254:0

   --- Logical volume ---
   LV Path    /dev/debian8-vg/home
   LV Name    home
   VG Name    debian8-vg
   LV UUID    NugOd8-PRZM-9B1e-n0Ut-MWuB-Svso-Cfyxoe
   LV Write Access    read/write
   LV Creation host, time d

Re: BIOS Can Not Find Disk

2017-12-02 Thread Dan Norton


On 12/01/2017 02:58 PM, Thomas Schmitt wrote:

Hi,

Dan Norton wrote:

# fdisk -l
...
Disklabel type: gpt
In the dim past, fdisk
could set a partition as "active", which was its euphemism for "bootable".

I guess, this applies only to MBR partition tables, not to GPT as on your
disk.

As Pascal stated, there is a bit defined in GPT to be the equivalent of
the "active" bit in MBR partitions. But it looks like "BIOS boot" in the
output of fdisk indicates a particular GPT partition type GUID.
Line 164 and 165 in
   https://github.com/karelzak/util-linux/blob/master/libfdisk/src/gpt.c
say
/* Hah!IdontneedEFI */
DEF_GUID("21686148-6449-6E6F-744E-656564454649", N_("BIOS boot")),

Probably MBR code which will look for a boot indicator is not able to
interpret GPT.

Nevertheless, afaik GRUB installs an MBR which knows from where to get
its next program. So the question is rather how to install GRUB or repair
the existing installation. (Beyond my experience, i fear.)


Pascal Hambourg wrote:

- Partition attribute bit 2 = legacy BIOS bootable.
...
I just wonder how a BIOS would use that, though.

It's not the BIOS which reacts on the "active" bit. It's the MBR program
code which may or may not look for the bit. If it does, then it runs the
program code at the start of the partition.
Package "syslinux" has "mbr.bin" which is supposed to act that way:
   http://git.zytor.com/syslinux/syslinux.git/tree/mbr/mbr.S



OK, the syslinux and syslinux-efi packages are now installed and I'm 
studying man grub-install to see how to get the right mbr installed. It 
appears to be in /usr/lib/SYSLINUX-EFI/efi64. It is called syslinux.efi. 
Not sure this will cure the "ERROR:No boot disk..." problem tho.


 - Dan

Re: BIOS Can Not Find Disk

2017-12-01 Thread Dan Norton


On 12/01/2017 08:54 PM, David Christensen wrote:


On 12/01/17 10:50, Dan Norton wrote:
Maybe this is the wrong forum, but please bear with me a little bit. 
This post was sent from a desktop with jessie installed. The problem 
is it will not boot normally. Network booting has been disabled in 
the NVRAM setup. After POST there is a one-liner which says it can 
not find disk. 


Please post the *exact* contents of the console screen.



ERROR:No boot disk has been detected or the disk has failed.





It can be booted with a supergrub2 cd, however.


# fdisk -l

Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A615A904-0620-459F-BF44-5E53E54FDF24

Device Start    End    Sectors   Size Type
/dev/sda1   2048 411647 409600   200M BIOS boot
/dev/sda2 411648   16783359   16371712   7.8G Linux swap
/dev/sda3   16783360  151001087  134217728    64G Linux LVM
/dev/sda4  151001088  285218815  134217728    64G Linux LVM
/dev/sda5  285218816  419436543  134217728    64G Linux LVM
/dev/sda6  419436544  553654271  134217728    64G Linux LVM
/dev/sda7  553654272 1953525134 1399870863 667.5G Linux filesystem


This post is being written with Debian 8 installed on /dev/sda3, above.


How did you create the contents of this disk?


fdisk for sda1 and sda2, then installer for sda3 through sda7. The 
installer was from Debian 8.9 netinst on cd.






What are your LVM PV's, VG's, and LV's?


# lvm pvdisplay
  --- Physical volume ---
  PV Name   /dev/sda3
  VG Name   debian8-vg
  PV Size   64.00 GiB / not usable 4.00 MiB
  Allocatable   yes
  PE Size   4.00 MiB
  Total PE  16383
  Free PE   9399
  Allocated PE  6984
  PV UUID vyN3Lt-vGyw-lVZi-RDBG-NoXL-nqlH-k9eolf

  "/dev/sda4" is a new physical volume of "64.00 GiB"
  --- NEW Physical volume ---
  PV Name   /dev/sda4
  VG Name
  PV Size   64.00 GiB
  Allocatable   NO
  PE Size   0
  Total PE  0
  Free PE   0
  Allocated PE  0
  PV UUID QqDROv-x2rg-3C3z-Lkdw-U95u-86BT-Jzrc6O

  "/dev/sda5" is a new physical volume of "64.00 GiB"
  --- NEW Physical volume ---
  PV Name   /dev/sda5
  VG Name
  PV Size   64.00 GiB
  Allocatable   NO
  PE Size   0
  Total PE  0
  Free PE   0
  Allocated PE  0
  PV UUID oOQuaB-qAIu-q3DW-1h0B-rKA0-q1Z4-oznScr

  "/dev/sda6" is a new physical volume of "64.00 GiB"
  --- NEW Physical volume ---
  PV Name   /dev/sda6
  VG Name
  PV Size   64.00 GiB
  Allocatable   NO
  PE Size   0
  Total PE  0
  Free PE   0
  Allocated PE  0
  PV UUID hHiVce-cC0V-u7zz-tqjU-5Rdd-nPza-BlPMQz


# lvm vgdisplay
  --- Volume group ---
  VG Name   debian8-vg
  System ID
  Format    lvm2
  Metadata Areas    1
  Metadata Sequence No  17
  VG Access read/write
  VG Status resizable
  MAX LV    0
  Cur LV    4
  Open LV   4
  Max PV    0
  Cur PV    1
  Act PV    1
  VG Size   64.00 GiB
  PE Size   4.00 MiB
  Total PE  16383
  Alloc PE / Size   6984 / 27.28 GiB
  Free  PE / Size   9399 / 36.71 GiB
  VG UUID   lfqcVE-yP6G-IeYF-zHYt-jc60-Jzas-c1fr5p


# lvm lvdisplay
  --- Logical volume ---
  LV Path    /dev/debian8-vg/root
  LV Name    root
  VG Name    debian8-vg
  LV UUID    Eh9QwL-dTlm-s8H5-5FYN-CxBl-wnvn-om3Pbx
  LV Write Access    read/write
  LV Creation host, time debian8, 2017-11-20 12:32:12 -0500
  LV Status  available
  # open 1
  LV Size    9.31 GiB
  Current LE 2384
  Segments   1
  Allocation inherit
  Read ahead sectors auto
  - currently set to 256
  Block device   254:0

  --- Logical volume ---
  LV Path    /dev/debian8-vg/home
  LV Name    home
  VG Name    debian8-vg
  LV UUID    NugOd8-PRZM-9B1e-n0Ut-MWuB-Svso-Cfyxoe
  LV Write Access    read/write
  LV Creation host, time debian8, 2017-11-20 12:33:08 -0500
  LV Status  available
  # open 1
  LV Size    9.31 GiB
  Current LE 2384
  Segments   1
  Allocation inherit
  Read ahead sectors auto
  - currently set to 256
  Block device   254:1

  --- Logical volume ---
  LV Path    /dev/debian8-vg/tmp
  LV Name    tmp
  VG Name

Re: BIOS Can Not Find Disk

2017-12-01 Thread Dan Norton


On 12/01/2017 02:29 PM, Pascal Hambourg wrote:

Le 01/12/2017 à 19:57, Greg Wooledge a écrit :

On Fri, Dec 01, 2017 at 01:50:12PM -0500, Dan Norton wrote:

Disklabel type: gpt



Apparently, BIOS does not see a bootable device. In the dim past, fdisk
could set a partition as "active", which was its euphemism for 
"bootable".

However now:


GPT disk labels don't have active/bootable partitions.


Yes they do. They even have two kinds of them.

- Partition attribute bit 2 = legacy BIOS bootable.
It is supposed to be equivalent to the boot/active flag in partition 
entries of the MBR. I just wonder how a BIOS would use that, though.


- The good old boot/active flag of the GPT protective partition entry 
in the MBR. Some BIOSes require it to boot a drive regardless of the 
presence of a GPT disk label. It can be set with parted which 
considers it as a disk flag (disk_set pmbr_boot on), or by fdisk by 
forcing it to use the protective DOS/MBR disk label (-t dos).




This really sounds good. I could not figure out how to get at the 
protective mbr and turn on that bit. Here's what I tried, after doing a 
backup:


# fdisk -t dos /dev/sda

...

Command (m for help): m

Help:

  DOS (MBR)
   a   toggle a bootable flag
   b   edit nested BSD disklabel
   c   toggle the dos compatibility flag

...

Command (m for help): a
Selected partition 1
The bootable flag on partition 1 is enabled now.

Command (m for help): p
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x3f90eec3

Device Boot Start    End    Sectors   Size Id Type
/dev/sda1  *    1 1953525167 1953525167 931.5G ee GPT


Command (m for help): w
The partition table has been altered.
Calling ioctl() to re-read partition table.
Re-reading the partition table failed.: Device or resource busy

The kernel still uses the old table. The new table will be used at the 
next reboot or after you run partprobe(8) or kpartx(8).


# partprobe -s /dev/sda

After removing the cd and shutting down, re-booted from power-off state, 
but unfortunately still got the "disk not found" message on a black screen.


The PC is simply not seeing the 1T sda, which is the only disk. It's not 
even getting as far as the mbr/grub. The PC appears to be no more than 5 
years old, based on the BIOS date, but it may be old enough to have a 
flaky UEFI. Should I abandon the use of GPT?

BIOS Can Not Find Disk

2017-12-01 Thread Dan Norton

Maybe this is the wrong forum, but please bear with me a little bit. 
This post was sent from a desktop with jessie installed. The problem is 
it will not boot normally. Network booting has been disabled in the 
NVRAM setup. After POST there is a one-liner which says it can not find 
disk. It can be booted with a supergrub2 cd, however.



# fdisk -l

Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A615A904-0620-459F-BF44-5E53E54FDF24

Device Start    End    Sectors   Size Type
/dev/sda1   2048 411647 409600   200M BIOS boot
/dev/sda2 411648   16783359   16371712   7.8G Linux swap
/dev/sda3   16783360  151001087  134217728    64G Linux LVM
/dev/sda4  151001088  285218815  134217728    64G Linux LVM
/dev/sda5  285218816  419436543  134217728    64G Linux LVM
/dev/sda6  419436544  553654271  134217728    64G Linux LVM
/dev/sda7  553654272 1953525134 1399870863 667.5G Linux filesystem


This post is being written with Debian 8 installed on /dev/sda3, above.


Apparently, BIOS does not see a bootable device. In the dim past, fdisk 
could set a partition as "active", which was its euphemism for 
"bootable". However now:



# fdisk /dev/sda

Welcome to fdisk (util-linux 2.25.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): a
a: unknown command


Additional info:

# uname -v
#1 SMP Debian 3.16.43-2+deb8u5 (2017-09-19)


HP Pro 3400 Series MT

BIOS version 7.16 dated 03/23/2012 with no update found.


How can /dev/sda1 be defined so that the bios will see it as bootable?


Thanks,

 - Dan

Re: Debian 8 and Debian 9 Dual Boot


On 11/29/2017 04:29 PM, Dan Norton wrote:



On 11/29/2017 03:57 PM, Joe wrote:

On Wed, 29 Nov 2017 15:37:46 -0500
Dan Norton <dnor...@mindspring.com> wrote:


On 11/29/2017 01:36 PM, Felix Miata wrote:

Dan Norton composed on 2017-11-29 13:07 (UTC-0500):

After POST, the following appears:
[...]
PXE-E53: No boot filename received
PXE-MOF: Exiting PXE ROM.
ERROR:No boot disk has been detected or the disk has failed.

It tries to PXE boot because it finds no bootable storage device:
there is no active partition, or no boot code in the MBR sector of
the device that you expect to boot. Installing Grub to a partition
leaves the MBR untouched, so it might not yet contain anything
other than partition data. The partitioner I use installs MBR code
automatically. The one in the installer may have needed to have
this step explicitly asked for. It can be added post-install
manually. 'man install-mbr'.

Isn't that because the primary is not mounted to /boot?

Mounting happens well after the point you have reached.

Nothing found for "man install-mbr" but web search yields "How to
Install Grub Onto Your MBR [1] which I will try.

[1] http://www.av8n.com/computer/htm/grub-reinstall.htm


You've said that you can boot your system with the aid of a boot
utility disc: that bypasses a lot of trouble, and you should be able to
go directly to step 8 from within your working system. It's harder to
do if you have to work from a different environment.


Good. Actually, I started the procedure on my booted jessie system but 
stopped and booted the live cd when I re-read [1].

As I said, I believe you should also do update-grub, which will
certainly do no harm. You don't yet know that grub is configured with
the necessary information for an unaided boot.


I ran update-grub recently but will be glad to do it again.


dan@debian8:~$ sudo update-grub
[sudo] password for dan:
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-3.16.0-4-amd64
Found initrd image: /boot/initrd.img-3.16.0-4-amd64
done

Re: Debian 8 and Debian 9 Dual Boot




On 11/29/2017 03:57 PM, Joe wrote:

On Wed, 29 Nov 2017 15:37:46 -0500
Dan Norton <dnor...@mindspring.com> wrote:


On 11/29/2017 01:36 PM, Felix Miata wrote:

Dan Norton composed on 2017-11-29 13:07 (UTC-0500):

After POST, the following appears:
[...]
PXE-E53: No boot filename received
PXE-MOF: Exiting PXE ROM.
ERROR:No boot disk has been detected or the disk has failed.

It tries to PXE boot because it finds no bootable storage device:
there is no active partition, or no boot code in the MBR sector of
the device that you expect to boot. Installing Grub to a partition
leaves the MBR untouched, so it might not yet contain anything
other than partition data. The partitioner I use installs MBR code
automatically. The one in the installer may have needed to have
this step explicitly asked for. It can be added post-install
manually. 'man install-mbr'.

Isn't that because the primary is not mounted to /boot?

Mounting happens well after the point you have reached.
  

Nothing found for "man install-mbr" but web search yields "How to
Install Grub Onto Your MBR [1] which I will try.

[1] http://www.av8n.com/computer/htm/grub-reinstall.htm


You've said that you can boot your system with the aid of a boot
utility disc: that bypasses a lot of trouble, and you should be able to
go directly to step 8 from within your working system. It's harder to
do if you have to work from a different environment.


Good. Actually, I started the procedure on my booted jessie system but 
stopped and booted the live cd when I re-read [1].

As I said, I believe you should also do update-grub, which will
certainly do no harm. You don't yet know that grub is configured with
the necessary information for an unaided boot.


I ran update-grub recently but will be glad to do it again.



Note that grub2 is still a work in progress, and many of the boot
problem tutorials you find on the Net are no longer completely
accurate. This one should be OK, I think. It's usually worth adding
'debian' to your search keywords, if you turn up something on the
debian.org site there's a good chance it's up to date.

Re: Debian 8 and Debian 9 Dual Boot




On 11/29/2017 03:37 PM, Dan Norton wrote:



On 11/29/2017 01:36 PM, Felix Miata wrote:

Dan Norton composed on 2017-11-29 13:07 (UTC-0500):

After POST, the following appears:
[...]
PXE-E53: No boot filename received
PXE-MOF: Exiting PXE ROM.
ERROR:No boot disk has been detected or the disk has failed.
It tries to PXE boot because it finds no bootable storage device: 
there is no
active partition, or no boot code in the MBR sector of the device 
that you
expect to boot. Installing Grub to a partition leaves the MBR 
untouched, so it
might not yet contain anything other than partition data. The 
partitioner I use
installs MBR code automatically. The one in the installer may have 
needed to
have this step explicitly asked for. It can be added post-install 
manually. 'man

install-mbr'.


Isn't that because the primary is not mounted to /boot?

Mounting happens well after the point you have reached.



Nothing found for "man install-mbr" but web search yields "How to 
Install Grub Onto Your MBR [1] which I will try.


[1] http://www.av8n.com/computer/htm/grub-reinstall.htm


Well that won't fly. Booted Debian-Live 8.8.0 amd64 Standard and reached 
Step 8 in section 1.1 of [1] which called for "grub-install 
--root-directory=/x $drive" but grub-install is not found.

Re: Debian 8 and Debian 9 Dual Boot




On 11/29/2017 01:36 PM, Felix Miata wrote:

Dan Norton composed on 2017-11-29 13:07 (UTC-0500):

After POST, the following appears:
[...]
PXE-E53: No boot filename received
PXE-MOF: Exiting PXE ROM.
ERROR:No boot disk has been detected or the disk has failed.

It tries to PXE boot because it finds no bootable storage device: there is no
active partition, or no boot code in the MBR sector of the device that you
expect to boot. Installing Grub to a partition leaves the MBR untouched, so it
might not yet contain anything other than partition data. The partitioner I use
installs MBR code automatically. The one in the installer may have needed to
have this step explicitly asked for. It can be added post-install manually. 'man
install-mbr'.


Isn't that because the primary is not mounted to /boot?

Mounting happens well after the point you have reached.



Nothing found for "man install-mbr" but web search yields "How to 
Install Grub Onto Your MBR [1] which I will try.


[1] http://www.av8n.com/computer/htm/grub-reinstall.htm

Re: Debian 8 and Debian 9 Dual Boot


On 11/16/2017 03:13 PM, Felix Miata wrote:

Joe composed on 2017-11-16 19:27 (UTC):


I see the date of the page is 2015,

IIRC, that 2015 update was all about updating and/or replacing broken links.


Multiple OSes will still use one overall bootloader, which may or may
not redirect to other bootloaders. It is common, therefore, to use a
single physical partition for /boot, common to all *nix OSes

Mounting the same single primary partition as /boot to all *nix OSes invites
virtually the same trouble that installing Grub to MBR causes. Absent user
intervention, each OS thinks it owns the space, so at updates times, each stomps
on whatever is there at the time, eventually exhausting its freespace with a
multitude of diverse kernels and initrds. Only one OS, or no OS, should mount
the bootable physical partition to /boot. Others can either have their own
bootloader installed to their own / filesystem, or be used without their own
bootloader.

On most of my PCs, the bootable primary is never mounted to /boot. I manage it
manually myself, providing direct loading of kernels and initrds, as well as
chainloading entries, and configfile entries, the latter two used primarily when
prior kernels are to be booted, the former for most booting.

For someone doing multiboot the first time, it's easiest, if not a requirement,
for the first installation to have the primary mounted to /boot. The subsequent
installations either need to have no bootloader or bootloader only installed to
/; or, the newer can be configured to mount the primary on /boot, and the
original, prior to its next boot, preferably immediately prior to starting the
new installation, reconfigured to not mount the primary on /boot, not manage the
bootloader installed there, and relocate its content to its own / filesystem.


After POST, the following appears:

[...]
PXE-E53: No boot filename received
PXE-MOF: Exiting PXE ROM.
ERROR:No boot disk has been detected or the disk has failed.

Isn't that because the primary is not mounted to /boot?

Sorry to be so dense, but how do I "have the primary mounted to /boot?"



Multiboot setup is complex, one of the reasons why virtualization became
popular. There is no single right way to get where you want to go. For a
beginner it helps a lot to have an extra PC to do the learning, and for doc
access while doing the installations and configurations on the other. :-)

Re: Debian 8 and Debian 9 Dual Boot



On 11/29/2017 03:59 AM, Joe wrote:

On Tue, 28 Nov 2017 22:15:22 -0500
Dan Norton <dnor...@mindspring.com> wrote:


On 11/13/2017 01:55 PM, Joe wrote:

On Mon, 13 Nov 2017 11:01:27 -0500
Dan Norton <dnor...@mindspring.com> wrote:

  

Although I didn't say so, each install would have its own set of
directories. Please say more about how to mount the other
installation and share data. How to mount things in another volume
group?
  

Good advice so far, but to add a bit: all LVM groups will be seen at
boot, and /dev will know about them. See man lvm2 and also here:

https://wiki.debian.org/LVM  for complete information about the
commands you have available. There are also numerous tutorials on
the Net which show basic usage of the simpler commands. It's worth
having a look when you have some spare time, as one day you'll need
to know some of this and won't have any spare time.

Reading the wiki reveals "Grub and ?
<https://wiki.debian.org/LiLo>LiLo are not compatible with LVM,
so /bootshould be outside the storage disk managed by LVM."

Not many people are using lilo today, and a recent grub2 should have no
problem at all with lvm. But there's no harm in a separate /boot, and
I've always done it that way.


Here's
what I have:

Attempts to boot normally do not work. But using Super Grub2 on a
bootable cd and selecting "Boot manually" and picking the hd1 entry
brings up the jessie system that the installer reports as
successfully installed on sda3. Using fdisk to take a look:

dan@debian8:~$ sudo fdisk /dev/sda
Command (m for help): p
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A615A904-0620-459F-BF44-5E53E54FDF24

Device Start    End    Sectors   Size Type
/dev/sda1   2048 411647 409600   200M BIOS boot
/dev/sda2 411648   16783359   16371712   7.8G Linux swap
/dev/sda3   16783360  151001087  134217728    64G Linux LVM
/dev/sda4  151001088  285218815  134217728    64G Linux LVM
/dev/sda5  285218816  419436543  134217728    64G Linux LVM
/dev/sda6  419436544  553654271  134217728    64G Linux LVM
/dev/sda7  553654272 1953525134 1399870863 667.5G Linux filesystem

Is there a problem here?

Not obviously so. But you know that you have a working installation,
just one with a booting problem, which suggests this is all plausible.


dan@debian8:~$ df -h
Filesystem    Size  Used Avail Use% Mounted on
/dev/dm-0 9.1G  3.0G  5.7G  35% /
udev   10M 0   10M   0% /dev
tmpfs 775M  9.0M  766M   2% /run
tmpfs 1.9G   68K  1.9G   1% /dev/shm
tmpfs 5.0M  4.0K  5.0M   1% /run/lock
tmpfs 1.9G 0  1.9G   0% /sys/fs/cgroup
/dev/sda1 992K  142K  851K  15% /boot/efi
/dev/mapper/debian8--vg-var   8.2G  1.3G  6.4G  17% /var
/dev/mapper/debian8--vg-home  9.1G  356M  8.3G   5% /home
/dev/mapper/debian8--vg-tmp   268M  2.1M  247M   1% /tmp
tmpfs 388M  4.0K  388M   1% /run/user/115
tmpfs 388M   12K  388M   1% /run/user/1000


Doesn't this satisfy the statement that "/boot should be outside the
storage disk managed by LVM" since it is on sda1?


Look in /etc/fstab for lines beginning /dev/mapper/[volume] which
will be the volumes mounted in the running installation. The
'mapper' is turning LVM volumes into things which look like
partitions for many purposes.

Here is fstab:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name
devices # that works even if disks are added and removed. See
fstab(5). #
#           
/dev/mapper/debian8--vg-root /  ext4 errors=remount-ro
0   1 # /boot/efi was on /dev/sda1 during installation
UUID=B07E-1F0B  /boot/efi   vfat    umask=0077  0   1
/dev/mapper/debian8--vg-home /home  ext4 defaults
0   2 /dev/mapper/debian8--vg-tmp /tmp    ext4
defaults    0   2 /dev/mapper/debian8--vg-var /var
ext4 defaults    0   2 # swap was on /dev/sda2 during
installation UUID=6aa1846f-34dd-424d-b02c-dbd0af037a23
none    swap sw  0   0
/dev/sr0    /media/cdrom0   udf,iso9660 user,noauto 0   0


Why won't it boot normally, that is without using the bootable Grub2
cd?


I've had enormous amounts of trouble with grub/grub2 over the years.
Could be anything.

We have to start from the exact screen messages you get when you try
booting. There are different classes of grub problem, and it will drop
you in different shells depending on what it has found.

Please, the error messages, word for word...



It doesn'

Re: Debian 8 and Debian 9 Dual Boot

2017-11-28 Thread Dan Norton



On 11/13/2017 01:55 PM, Joe wrote:

On Mon, 13 Nov 2017 11:01:27 -0500
Dan Norton <dnor...@mindspring.com> wrote:



Although I didn't say so, each install would have its own set of
directories. Please say more about how to mount the other
installation and share data. How to mount things in another volume
group?


Good advice so far, but to add a bit: all LVM groups will be seen at
boot, and /dev will know about them. See man lvm2 and also here:

https://wiki.debian.org/LVM  for complete information about the
commands you have available. There are also numerous tutorials on the
Net which show basic usage of the simpler commands. It's worth having a
look when you have some spare time, as one day you'll need to know some
of this and won't have any spare time.


Reading the wiki reveals "Grub and ? <https://wiki.debian.org/LiLo>LiLo 
are not compatible with LVM, so /bootshould be outside the storage disk 
managed by LVM." Here's what I have:


Attempts to boot normally do not work. But using Super Grub2 on a 
bootable cd and selecting "Boot manually" and picking the hd1 entry 
brings up the jessie system that the installer reports as successfully 
installed on sda3. Using fdisk to take a look:


dan@debian8:~$ sudo fdisk /dev/sda
Command (m for help): p
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: A615A904-0620-459F-BF44-5E53E54FDF24

Device Start    End    Sectors   Size Type
/dev/sda1   2048 411647 409600   200M BIOS boot
/dev/sda2 411648   16783359   16371712   7.8G Linux swap
/dev/sda3   16783360  151001087  134217728    64G Linux LVM
/dev/sda4  151001088  285218815  134217728    64G Linux LVM
/dev/sda5  285218816  419436543  134217728    64G Linux LVM
/dev/sda6  419436544  553654271  134217728    64G Linux LVM
/dev/sda7  553654272 1953525134 1399870863 667.5G Linux filesystem

Is there a problem here?

dan@debian8:~$ df -h
Filesystem    Size  Used Avail Use% Mounted on
/dev/dm-0 9.1G  3.0G  5.7G  35% /
udev   10M 0   10M   0% /dev
tmpfs 775M  9.0M  766M   2% /run
tmpfs 1.9G   68K  1.9G   1% /dev/shm
tmpfs 5.0M  4.0K  5.0M   1% /run/lock
tmpfs 1.9G 0  1.9G   0% /sys/fs/cgroup
/dev/sda1 992K  142K  851K  15% /boot/efi
/dev/mapper/debian8--vg-var   8.2G  1.3G  6.4G  17% /var
/dev/mapper/debian8--vg-home  9.1G  356M  8.3G   5% /home
/dev/mapper/debian8--vg-tmp   268M  2.1M  247M   1% /tmp
tmpfs 388M  4.0K  388M   1% /run/user/115
tmpfs 388M   12K  388M   1% /run/user/1000


Doesn't this satisfy the statement that "/boot should be outside the 
storage disk managed by LVM" since it is on sda1?



Look in /etc/fstab for lines beginning /dev/mapper/[volume] which will
be the volumes mounted in the running installation. The 'mapper' is
turning LVM volumes into things which look like partitions for many
purposes.


Here is fstab:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
#           
/dev/mapper/debian8--vg-root /  ext4 errors=remount-ro 0   1
# /boot/efi was on /dev/sda1 during installation
UUID=B07E-1F0B  /boot/efi   vfat    umask=0077  0   1
/dev/mapper/debian8--vg-home /home  ext4 defaults    0   2
/dev/mapper/debian8--vg-tmp /tmp    ext4 defaults    0   2
/dev/mapper/debian8--vg-var /var    ext4 defaults    0   2
# swap was on /dev/sda2 during installation
UUID=6aa1846f-34dd-424d-b02c-dbd0af037a23 none    swap 
sw  0   0

/dev/sr0    /media/cdrom0   udf,iso9660 user,noauto 0   0


Why won't it boot normally, that is without using the bootable Grub2 cd?

 - Dan

Re: Wild cursor, was Re: OT plain text missing from web mail

2017-11-28 Thread Dan Norton


On 11/24/2017 10:08 AM, David Wright wrote:

Dan Norton composed on 2017-11-22 19:09 (UTC-0500):
...

4. This laptop I'm borrowing is notorious for having a hyper-sensitive touch
pad. You can be typing along in the spot you have chosen for input and suddenly
it gets a wild hair and relocates the cursor to somewhere else. As a hunt and
peck typist, I've been victimized many times by this and had to undo and start
over. The new insertion point is unpredictable AFAICT.

Perhaps you need to investigate syndaemon. This disables the Synaptics
touchpad whenever a key is struck. The disabled period is configurable,
so if I type
$ syndaemon -i 1
into any old Xterm, the cursor will be dead for one second after any
key is struck. You can set it up in the background with   -d   and
put it in .xsession or equivalent.

The only downside is if you're adept at two-handed work with cursor
and keystrokes, but bear in mind that any attached mouse is unaffected.
Thanks for the reference, however I've stopped trying to use that 
ThinkPad and am writing this from Thunderbird on jessie. Found more than 
one place to set touchpad sensitivity so I changed both of them to low 
or the equivalent. So far, the ThinkPad owner has experienced no wild 
excursions of the text cursor. I, as the cursor curser, want to avoid 
any spurious html, so I'm staying on jessie. :-)


 - Dan

Re: OT plain text missing from web mail (was: Installer Can Not Find Root"

2017-11-22 Thread Dan Norton

-Original Message->From: mrma...@earthlink.net>Sent: Nov 21, 2017 3:37 PM>To: debian-user@lists.debian.org>Subject: Re: OT plain text missing from web mail (was: Installer Can Not Find Root">>Tom Furie composed:>>> On Mon, Nov 20, 2017 at 05:47:55PM -0500, Cindy-Sue Causey wrote: That's weird. I don't see that on my end. The original email looks as>>> normally expected from Debian lists. :)>>> That's weird. The original mail, and all of Dan's mails to the list, have>> only a single html part. An incredibly badly constructed html part at>> that.>>As this will be, it was sent using>>		X-Mailer: EarthLink Zoo Mail 1.0>>with>>		Content-Type: text/html; charset=UTF-8>>The string "Content-Type: multipart" is absent from his message. The only place on Earthlink's web mail site I can find that addresses HTML vs. plain text is in the "Message Display" section of "Preferences", where the label is>>		HTML Message View>>with description>>		" Choose 'off' to view HTML messages as text. ">>which I have set to "off". That said, the page I'm composing on has a link>>		"Use the new WebMail">>I'm not going to click on it and risk not being able to get back to using plain text. I suppose that may be what Dan's using and he hasn't figured out how to not send in HTML.>First, let me apologize to everyone who received some kind of HTML fragment from me simply because they are subscribed to Debian User. I am very sorry to have posted that junk on Debian User. I'm still studying how it happened. Here's what I know so far:1. The preference is still set to use plain text in emails. 2. Going through the archives, my posts appear devoid of html junk. However,3. Looking at the lone entry in my Sent folder I see that it begins "body{font-size:10pt;font-family:arial" ! Where did that come from? Doing a search of the archives for this turns up the following in the thread:/debian-user/2017/11/msg00672.html/debian-user/2017/11/msg00644.html/debian-user/2017/11/msg00633.htmlNot one of these displays junk when I clicking on them.4. This laptop I'm borrowing is notorious for having a hyper-sensitive touch pad. You can be typing along in the spot you have chosen for input and suddenly it gets a wild hair and relocates the cursor to somewhere else. As a hunt and peck typist, I've been victimized many times by this and had to undo and start over. The new insertion point is unpredictable AFAICT.5. Anything in the clipboard can be pasted, preferences for no HTML not withstanding. If there is an html fragment in the clipboard6. This list proscribes top posting and often I place replies within or at the end, then hit send (webmail has a button at the bottom as well as the top) without looking at the beginning text. The html-like garbage is at the beginning.Currently, my theory is that somehow(tm) due to 4, *IT JUST DID IT. I AM NOT KIDDING*"body{font-size:10pt;font-family:arial,sans-serif;background-color:#ff;color:black;}p{margin:0px;}"was inserted at the beginning of this text when I pressed the space bar. I cut it out and pasted it above. The mouse was unresponsive to clicks and I had to use the arrow keys to position the pastedue to 4, 5, and 6 the garbage is being copied to the clipboard and pasted to the bogus insertion point. How this occurs, I don't know.>I can't imagine Dan continuing to choose to use Earthlink web mail once the problems this thread is about have been solved. It's a poor UI, like Yahoo and all other web mail I've ever had to fall back on."Desperate men do desperate deeds." :-) - Dan

Re: Installer Can Not Find Root

2017-11-22 Thread Dan Norton




-Original Message-
>From: Tom Furie <t...@furie.org.uk>
>Sent: Nov 22, 2017 5:48 AM
>To: debian-user@lists.debian.org
>Subject: Re: Installer Can Not Find Root
>
>On Tue, Nov 21, 2017 at 09:28:55PM -0500, Dan Norton wrote:
>
>> > ...and all of Dan's mails to the list...
>
>> All? How far back?
>
>That was my error, somehow my fingers typed "list" when my brain was
>thinking "thread".
>

THAT's a relief :-) I will search for the culprits when I get a little more 
time.
Thanks for letting me know.

>Cheers,
>Tom
>
>-- 
>BOFH excuse #185:
>
>system consumed all the paper for paging

Re: Installer Can Not Find Root

2017-11-21 Thread Dan Norton

-Original Message-
>From: Tom Furie 
>Sent: Nov 21, 2017 3:25 AM
>To: debian-user@lists.debian.org
>Subject: Re: Installer Can Not Find Root
>
>On Mon, Nov 20, 2017 at 05:47:55PM -0500, Cindy-Sue Causey wrote:
>
>> That's weird. I don't see that on my end. The original email looks as
>> normally expected from Debian lists. :)
>
>That's weird. The original mail, and all of Dan's mails to the list, have
>only a single html part. An incredibly badly constructed html part at
>that.
>

All? How far back?

>Cheers,
>Tom
>

I *thought* it was fixed. If this one exhibits some kind of html, let me know. 
This should not occur, even on my wife's lappy, which I'm borrowing until I get 
debian re-installed on my desktop. This being written using Earthlink Webmail 
on 'Doze 10.

 - Dan

Re: Installer Can Not Find Root

2017-11-20 Thread Dan Norton

-Original Message->From: Tom Dial <tdd...@comcast.net>>Sent: Nov 19, 2017 6:44 PM>To: "debian-user@lists.debian.org" <debian-user@lists.debian.org>>Subject: Re: Installer Can Not Find Root>>>>On 11/18/2017 07:26 PM, Dan Norton wrote:>> While trying to netinst Debian 8.9 into an LVM physical volume I keep>> running into "installer can not find root" or words to that effect. This>> is a dead end in the installer AFAICT.>> OK I found what I was doing wrong and am now more familiar with the installer UI.>> I have tried GPT but this HP UEFI does not play nicely with it. So,>> reverting to Disklabel type: dos, and using fdisk, I re-partitioned.>> >> fdisk -l reports this snippet (paraphrased):>> >> /dev/sda1  1M 83 Linux>> /dev/sda2  8G 82 Linux swap>> /dev/sda4  923.5G  5 Extended>> /dev/sda5 64G 8e Linux LVM>> /dev/sda6     64G 8e Linux LVM>> /dev/sda7     64G 8e Linux LVM>> /dev/sda8     64G 8e Linux LVM>> /dev/sda9  667.5G 83 Linux>> >> The aim here is to have a multiboot system with Debian 8, Debian 9, and>> so forth.>> I've reverted the partitioning scheme back to GPT. Using fdisk I defined the primary partitions sda1 and 2 as EFI and Swap respectively. The remaining partitioning was done within the installer. Thanks Pascal.[snip]>>Installing to a PV is a fairly straightforward matter. Here is a worked>out example of installing to a microSD. It should work pretty much the>same for any other type of block device.>>Manual partitioning (done on an existing Stretch installation with>gparted) shows the following from fdisk -l:>>Device Boot Start   End   Sectors  Size Id Type>/dev/mmcblk0p1   2048  4095  20481M 83 Linux>/dev/mmcblk0p2   4096   4198399   41943042G 82 Linux swap />Solaris>/dev/mmcblk0p34198400 124735487 120537088 57.5G  5 Extended>/dev/mmcblk0p54200448  54532095  50331648   24G 8e Linux LVM>/dev/mmcblk0p6   54534144 121643007  67108864   32G 8e Linux LVM>/dev/mmcblk0p7  121645056 124735487   3090432  1.5G 83 Linux>>Partitions p5 and p6 are lvm physical volumes.>>I also, in emulation, created volume group "debian9-vg" on p5 and a>logical volume "root" on debian9-vg and formatted it as ext4. It mounts>normally on the host and (from a shell prompt) with the installer. I did>not leave it mounted.>>The view from the installer partitioner shows essentially the same>thing. From an installer root prompt, lvm commands appear to work>normally, and I created additional LVs swap_1 (2G), tmp (512M), var>(2G), and home (4G), leaving 7.5G free.>>>From the installer (partitioner):>>All disk partitions, and all LVM logical volumes are shown.>>Choosing "Configure the Logical Volume Manager leads to the choice to>format p2 as swap; I did that, and got a frame showing the two PVs (one>used and 1 free), 1 VG, and the 5 LVs and options to "Display>configuration details," "Create volume group," "Create logical volume,">"Delete logical volume," "Extend volume group," and "Finish.">>Display showed the unallocated PV and the debian9-vg with its 5 LVs.>Creating a VG (debian9t) and LVs on partition p6 with the installer>partitioner also works. However, the LVs are created with sizes powers>of 10 instead of 2 (e. g., 1M=1000K=100 bytes instead of>1M=1048K=1048576 bytes). I prefer the powers of two, so from a shell>prompt I removed and recreated the LVs on debian9t to match those on the>debian9-vg created earlier.>>Note that the partitioning can be done from either another (reasonably>up to date) debian system, including a live CD, I expect, or the>installer, and using either the partitioner or lvm commands from an>installer shell prompt. The partitioner then showed and allowed>configuration of all volume groups and logical volumes. It is necessary>to be careful to not use any partitions, volume groups, or logical>volumes that contain data you want to keep, although the partitioner>will warn about using existing resources.>>>From this point, I used the installer partitioner to configure, format,>and specify mount points for LVs associated with the debian9-vg volume>group. The installer correctly identified the root LV, already formatted>as ext4, and offered the option of not reformatting it.>>The installation went forward normally, and at stage 1 completion I>chose a relatively local mirror. I did not see the deb.debian.org>redirector listed, which might be a nice thing.>>Tom Dial>Finishing with the installer, the GPT scheme looks like this:NAME

Re: Installer Can Not Find Root

2017-11-20 Thread Dan Norton

-Original Message->From: Pascal Hambourg <pas...@plouf.fr.eu.org>>Sent: Nov 19, 2017 3:26 PM>To: "debian-user@lists.debian.org" <debian-user@lists.debian.org>>Subject: Re: Installer Can Not Find Root>>Le 19/11/2017 à 20:02, Dan Norton a écrit :>>-Original Message->>>From: Pascal Hambourg>>>Sent: Nov 19, 2017 11:03 AM>>>To: "debian-user@lists.debian.org">>>Subject: Re: Installer Can Not Find Root>>>>>>Le 19/11/2017 à 03:26, Dan Norton a écrit :>>>>>>> user@debian:/$ sudo mount /dev/debian-vg/root>>>>>>The mount point is missing. Besides, why did you mount the filesystem ?>>No reply to this question ?>Unintentional. This was to try to define root.>>>> #the "/root" was dropped apparently>>>>>>What do you mean ?>>>>> >> Simply that>> sudo mount /dev/debian-vg/root>> was processed as>> sudo mount /dev/debian-vg>>No it wasn't. Unless a mount point was defined for /dev/debian-vg/root >in /etc/fstab, this command is invalid and had no effect except to print >an error message.>The effect was that I could cd to it and ls it.>>>> There they are. All the logical volumes.>>/dev/debian-vg is a directory created by LVM when the volume group >debian-vg is activated. What you see in this directory is not a mounted >filesystem but device nodes for its logical volumes (actually, symbolic >links pointing to the real device nodes /dev/dm-*).>>> OK, in the installer, logical volumes selected and mount points defined for /,>> /home, swap, /tmp, and /var.>> Thank you, Pascal. That's progress.>> >> Now I have a problem with the EFI partition. I made several attempts with>> primary partitions. The last is:>> >> #1  primary  1.0MB F  fat32  /dos>>What is the purpose of this partition ?>>> #2  primary  8.6GB  B  K  ESP>> >> "The attempt to mount a file system with type vfat in SCSI1 (0,0,0), partition>> #2(sda) at /boot/efi failed.">>In your original post, partition #2 was identified as a swap. Allocating >8 GB to an EFI system partition which must contain less than 1 MB of >files is just a waste.>OK. This size was copied from a previous installation.>What is the contents type of this partition ? You can check with blkid.>An EFI system partition should contain a FAT filesystem and be mounted >on /boot/efi.>>> The goal is to multiboot with grub among several Debian partitions.>>You're going into trouble installing several instances of Debian in EFI >mode. They will all install their own GRUB EFI in the same place in the >EFI system partition and overwrite the previous one. AFAIK, only manual >GRUB installation can avoid this by forcing a different identifier for >each instance. Or you must not install GRUB with the other instances.>OK, I see your point. The option to install GRUB or not is in the installer? I'd like to try gpt again, if the following is still valid:https://lists.debian.org/debian-user/2014/03/msg01376.html

Re: Installer Can Not Find Root

2017-11-19 Thread Dan Norton

 -Original Message->From: Pascal Hambourg <pas...@plouf.fr.eu.org>>Sent: Nov 19, 2017 11:03 AM>To: "debian-user@lists.debian.org" <debian-user@lists.debian.org>>Subject: Re: Installer Can Not Find Root>>Le 19/11/2017 à 03:26, Dan Norton a écrit :>> >> Using LVM, one physical volume is defined on the entire sda5 partition. A volume>> group named "debian8-vg" is defined as the only vg in that pv. Five logical>> volumes have been defined in the vg. One lv intended as root was defined like>> this with a Debian Live CD:>> >> user@debian:/$ sudo lvm lvcreate -n root --size 8G debian8-vg  #define lv named root>> user@debian:/$ sudo mkfs.ext4 /dev/debian-vg/root  #make a file system in lv root>>You did not have to do this with a live CD command line. You could have >done it with the Debian installer partitioning interface.>>> user@debian:/$ sudo mount /dev/debian-vg/root>>The mount point is missing. Besides, why did you mount the filesystem ?>>>  #the "/root" was dropped apparently>>What do you mean ?> Simply thatsudo mount /dev/debian-vg/rootwas processed assudo mount /dev/debian-vg>> There they are. All the logical volumes. Am I getting close? How can I "mkdir /">> on root and succeed with netinst? BTW I did choose Manual partitioning in the>> installer. :-(>>You do not have to do anything with the command line. In the manual >partitioning main panel showing all disks, partitions and volumes, just >select a logical volume, edit its settings and select a mount point.>OK, in the installer, logical volumes selected and mount points defined for /, /home, swap, /tmp, and /var.Thank you, Pascal. That's progress.Now I have a problem with the EFI partition. I made several attempts with primary partitions. The last is:#1  primary  1.0MB F  fat32  /dos#2  primary  8.6GB  B  K  ESP "The attempt to mount a file system with type vfat in SCSI1 (0,0,0), partition #2(sda) at /boot/efi failed."The goal is to multiboot with grub among several Debian partitions. I've been reading [1] and [2]. Are there better references for me to study?[1] <pas...@plouf.fr.eu.org><debian-user@lists.debian.org>https://www.debian.org/releases/jessie/installmanual[2] https://www.debian.org/releases/jessie/amd64/

Installer Can Not Find Root

2017-11-18 Thread Dan Norton

While trying to netinst Debian 8.9 into an LVM physical volume I keep running into "installer can not find root" or words to that effect. This is a dead end in the installer AFAICT.I have tried GPT but this HP UEFI does not play nicely with it. So, reverting to Disklabel type: dos, and using fdisk, I re-partitioned.fdisk -l reports this snippet (paraphrased):/dev/sda1 1M 83 Linux/dev/sda2 8G 82 Linux swap/dev/sda4 923.5G 5 Extended/dev/sda5 64G 8e Linux LVM/dev/sda6 64G 8e Linux LVM/dev/sda7 64G 8e Linux LVM/dev/sda8 64G 8e Linux LVM/dev/sda9 667.5G 83 LinuxThe aim here is to have a multiboot system with Debian 8, Debian 9, and so forth. Using LVM, one physical volume is defined on the entire sda5 partition. A volume group named "debian8-vg" is defined as the only vg in that pv. Five logical volumes have been defined in the vg. One lv intended as root was defined like this with a Debian Live CD:user@debian:/$ sudo lvm lvcreate -n root --size 8G debian8-vg #define lv named rootuser@debian:/$ sudo mkfs.ext4 /dev/debian-vg/root #make a file system in lv rootuser@debian:/$ sudo mount /dev/debian-vg/root #the "/root" was dropped apparentlyI was able to cd as follows:user@debian:/$ cd /dev/debian8-vgand to see the logical volumes:user@debian:/dev/debian8-vg$ lshome root swap_1 tmp varThere they are. All the logical volumes. Am I getting close? How can I "mkdir /" on root and succeed with netinst? BTW I did choose Manual partitioning in the installer. :-( - Dan

Re: Debian 8 and Debian 9 Dual Boot

2017-11-16 Thread Dan Norton




On 11/16/2017 02:27 PM, Joe wrote:

On Thu, 16 Nov 2017 13:34:52 -0500
Dan Norton <dnor...@mindspring.com> wrote:


On 11/13/2017 09:52 PM, Felix Miata wrote:

Dan Norton composed on 2017-11-13 21:38 (UTC-0500):
  

How do you set up LVM so that install does not clobber one of the
siblings? During installation, for partitioning, do you pick
"Manual" or "Guided -*" ?

I don't think I've ever used Debian's, or any Debian derivative's,
"guided". I can't remember the last time I didn't pick manual,
after *fully* preparing in advance to my specifications.

Manual will list what partitions and volumes exist, so if you've
fully prepared logical volumes in advance, all that should need to
be done within manual is select mount points and mount options for
those you wish used. If volumes exist but are not formatted, then
formatting would be a third selection using manual.

A better description of what I want is "multiboot", instead of "dual
boot" in this thread. I can see having up to 4 systems installed, all
Debians, on one disk drive. There is an item in [1] which I see that
reads:

    6. Disable LVM support

which is puzzling. Can multiboot be set up within LVM on one disk
drive? Or, is it necessary to disable  LVM, define multiple logical
partitions with fdisk or parted for example, install in these
partitions, and then set up LVM separately on each system?

I see the date of the page is 2015, but to be honest, a lot of this
page is completely obsolete, even more so if you're not using DOS, OS/2
or early Windows. I would not even swear that item 6, LVM, even refers
to the Linux system. There's certainly no problem about mixing multiple
booting with lvm.


Glad to hear it!



A volume group would normally be declared within a single old-style IBM
partition, but doesn't have to be. Think of multiple hard drives, each
containing multiple old-style partitions, then think of multiple lvm
volume groups, each with multiple volumes, roughly overlaid on the
drives and partitions but not physically matching them. A volume group
can consist of multiple complete partitions on different drives, and
the volumes it contains need not bear any relationship to the
underlying partitions.

Multiple OSes will still use one overall bootloader, which may or may
not redirect to other bootloaders. It is common, therefore, to use a
single physical partition for /boot, common to all *nix OSes, but by no
means necessary. /boot can be an LVM volume if you wish, but a booting
problem is slightly easier to deal with if the kernel and grub stuff is
in a standard partition, you don't need to worry about looking up the
lvm commands in addition to the grub set.

My workstation, for example, has a 1GB primary partition for /boot, and
the rest of the drive is a second primary partition which maps exactly
to a volume group. The volume group is then divided into volumes, which
mostly act like old-style partitions, at least as far as mounting goes.
You can have a lot of them.
Apparently there are many ways to do multiboot in LVM. Is it practical 
to, on one fairly large (1TB) disk, [I can hear the snickers when 
someone reads this when 1TB is puny in a year or two] do the following:


1. Enlarge the volume group to span the entire disk (it's currently 40G).
2. Define a number of additional logical volumes, say 3.
3. Install stable in one of the lv's and have install treat it like a 
standard *partition* (logical) and have within it separate root, swap, 
/var, /tmp, and /home?


 - Dan

  


I have two drives set up the same, as I migrated from one to a newer
one. After adjustment, the grub installation of the new drive handles
the boot, and the kernel used by the old system lives in the /boot
partition of the old drive. All of this could have been integrated into
one volume group, but it's two because that's how the system evolved. I
could pull the old drive, which I hardly ever touch now, plonk it into
another PC and boot it with minimal fiddling about.

So you have a common grub, basically from the latest installation
unless you tell the installer otherwise, and before the installation is
finished it should have detected any other bootable OSes anywhere in
the hardware. You've been advised not to share other partitions, even
/home, but several /homes can live in differently-named lvm volumes in
the same volume group. Or not, by your preference. You can, for the
most part, treat volumes as partitions, and not worry about whether
they are primary or logical.

You should probably track down a few tutorials on multiboot and lvm,
read through them to get a feel for what needs doing. It's always
difficult reading a manual for something and working out from that what
steps you need to take to do something. Things like UEFI boot and disc
encryption complicate things, so probably best to avoid them on your
first attempt(s) if the hardware allows. If you're starting with a bare
drive and your BIOS

Re: Debian 8 and Debian 9 Dual Boot

2017-11-16 Thread Dan Norton




On 11/16/2017 02:06 PM, Felix Miata wrote:

Dan Norton composed on 2017-11-16 13:34 (UTC-0500):


A better description of what I want is "multiboot", instead of "dual
boot" in this thread. I can see having up to 4 systems installed, all
Debians, on one disk drive. There is an item in [1] which I see that reads:
    6. Disable LVM support

If you look farther down your cite you'll find "What is LVM?". "Disabling LVM"
is only applicable to the OS/2 type of LVM. It causes the OS/2 kernel to use
native DOS-style FIFO assignment of drive letters.


which is puzzling. Can multiboot be set up within LVM on one disk drive?

Yes!



OK, great!

Now I'll try to figure out whether each system should have its own 
volume group or its own logical volume within one vg. Would install go 
easier one way or the other?

Re: Debian 8 and Debian 9 Dual Boot

2017-11-16 Thread Dan Norton




On 11/13/2017 09:52 PM, Felix Miata wrote:

Dan Norton composed on 2017-11-13 21:38 (UTC-0500):


How do you set up LVM so that install does not clobber one of the
siblings? During installation, for partitioning, do you pick "Manual" or
"Guided -*" ?

I don't think I've ever used Debian's, or any Debian derivative's, "guided". I
can't remember the last time I didn't pick manual, after *fully* preparing in
advance to my specifications.

Manual will list what partitions and volumes exist, so if you've fully prepared
logical volumes in advance, all that should need to be done within manual is
select mount points and mount options for those you wish used. If volumes exist
but are not formatted, then formatting would be a third selection using manual.


A better description of what I want is "multiboot", instead of "dual 
boot" in this thread. I can see having up to 4 systems installed, all 
Debians, on one disk drive. There is an item in [1] which I see that reads:


  6. Disable LVM support

which is puzzling. Can multiboot be set up within LVM on one disk drive? 
Or, is it necessary to disable  LVM, define multiple logical partitions 
with fdisk or parted for example, install in these partitions, and then 
set up LVM separately on each system?


[1] http://fm.no-ip.com/PC/partitioningindex.html

Re: Debian 8 and Debian 9 Dual Boot




On 11/13/2017 09:52 PM, Felix Miata wrote:

Dan Norton composed on 2017-11-13 21:38 (UTC-0500):


How do you set up LVM so that install does not clobber one of the
siblings? During installation, for partitioning, do you pick "Manual" or
"Guided -*" ?

I don't think I've ever used Debian's, or any Debian derivative's, "guided". I
can't remember the last time I didn't pick manual, after *fully* preparing in
advance to my specifications.

Manual will list what partitions and volumes exist, so if you've fully prepared
logical volumes in advance, all that should need to be done within manual is
select mount points and mount options for those you wish used. If volumes exist
but are not formatted, then formatting would be a third selection using manual.


OK, I may be able to do that. Thanks for your help.

 - Dan

Re: Debian 8 and Debian 9 Dual Boot




On 11/13/2017 07:42 PM, Felix Miata wrote:

Dan Norton composed on 2017-11-13 18:04 (UTC-0500):


Felix Miata wrote:

There's no need for separate home file systems to keep one installation from
causing corruption to another's user settings. Simply do not reuse UIDs[1].
On your first, your Jessie probably has a user dan with UID 1000. On the next,
don't use 1000 for user dan. Pick any other number, e.g. 1200 for user dan in
Stretch. During Stretch installation make the initial user dan8 or dan01 using
Jessie's UID (probably 1000) for dan.

Do you pick a UID during install somehow or do you login as root before
anything else and edit /etc/passwd?

I could have been clearer. "During installation" isn't necessarily the correct
time for user management. I don't remember whether Stretch forces ordinary user
creation at installation time, or leaves it up to the admin to do when he 
chooses.

With installers that force creation of an ordinary user in addition to providing
a root password, or that don't permit UID selection for an ordinary user, create
a throwaway user. On first boot after installation, login as root and use ls -n,
groupadd, useradd, userdel, etc. to delete the throwaway, and manage users as
you wish. Editing /etc/passwd should not be necessary, but is an option
available to the adventurous.


Gee, I had it bracketed :-)
I'll gladly refrain from editing /etc/passwd thank you.

How do you set up LVM so that install does not clobber one of the 
siblings? During installation, for partitioning, do you pick "Manual" or 
"Guided -*" ?


 - Dan



In Jessie, create a new user dan2 or dan09 using the UID you picked for Stretch.
Booted to either, the homedir of the other can optionally be bind mounted as a
subdir of the current dan for more convenient data access without interference
with settings of the other. Either way you boot, you'll be user "dan", but
without risk of settings corruption.
[1] https://en.wikipedia.org/wiki/User_identifier--

"Wisdom is supreme; therefore get wisdom. Whatever else you
get, get wisdom." Proverbs 4:7 (New Living Translation)

  Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata  ***  http://fm.no-ip.com/

Re: Debian 8 and Debian 9 Dual Boot




On 11/13/2017 02:14 PM, David Christensen wrote:

[...]
Disk space is far cheaper than data loss.  Don't make the mistake of 
trying to save money through partition, LVM, file system, etc., 
gymnastics rather than simply buying another drive and doing it the 
KISS way.




Well I'm much in favor of the KISS principle, it's just that there is 
too much PC equipment lying around here doing nothing. I haul away, 
donate from time to time but it simply accumulates. I hate the thought 
of buying more when there is 900g unused on sda. :-)


 - Dan

Re: Debian 8 and Debian 9 Dual Boot




On 11/13/2017 02:08 PM, Felix Miata wrote:

Dan Norton composed on 2017-11-13 10:26 (UTC-0500):


David Christensen wrote:

Dan Norton wrote:

My first Linux install was about one year ago. After some missteps, I
have used Debian 8 in reasonable satisfaction on the desktop during
that year. Now I want to leave 8 in place and do a network install
for Debian 9 on the same disk and switch back and forth at boot time.

I think your best bet is to migrate from Debian 8 to Debian 9:
1.  Image, backup, and/or archive everything.  You will especially
want to get a copy of the /etc tree onto a USB flash drive so you can
see LVM, fstab, etc., configuration settings for mounting the Debian 8
disk under Debian 9.

Please say more about the configuration settings.

All my machines are multiboot. Few have as few as 4 operating system
installations, most have more than 12, and most of those not running RAID use
only one disk.

There's no need for separate home file systems to keep one installation from
causing corruption to another's user settings. Simply do not reuse UIDs[1].

On your first, your Jessie probably has a user dan with UID 1000. On the next,
don't use 1000 for user dan. Pick any other number, e.g. 1200 for user dan in
Stretch. During Stretch installation make the initial user dan8 or dan01 using
Jessie's UID (probably 1000) for dan.


Do you pick a UID during install somehow or do you login as root before 
anything else and edit /etc/passwd?


 - Dan


In Jessie, create a new user dan2 or dan09 using the UID you picked for Stretch.

Booted to either, the homedir of the other can optionally be bind mounted as a
subdir of the current dan for more convenient data access without interference
with settings of the other. Either way you boot, you'll be user "dan", but
without risk of settings corruption.

[1] https://en.wikipedia.org/wiki/User_identifier

Re: Debian 8 and Debian 9 Dual Boot




On 11/13/2017 02:08 PM, Felix Miata wrote:

Dan Norton composed on 2017-11-13 10:26 (UTC-0500):


David Christensen wrote:

Dan Norton wrote:

My first Linux install was about one year ago. After some missteps, I
have used Debian 8 in reasonable satisfaction on the desktop during
that year. Now I want to leave 8 in place and do a network install
for Debian 9 on the same disk and switch back and forth at boot time.

I think your best bet is to migrate from Debian 8 to Debian 9:
1.  Image, backup, and/or archive everything.  You will especially
want to get a copy of the /etc tree onto a USB flash drive so you can
see LVM, fstab, etc., configuration settings for mounting the Debian 8
disk under Debian 9.

Please say more about the configuration settings.

All my machines are multiboot. Few have as few as 4 operating system
installations, most have more than 12, and most of those not running RAID use
only one disk.


Excellent. You have my undivided attention :-)


There's no need for separate home file systems to keep one installation from
causing corruption to another's user settings. Simply do not reuse UIDs[1].

On your first, your Jessie probably has a user dan with UID 1000. On the next,
don't use 1000 for user dan. Pick any other number, e.g. 1200 for user dan in
Stretch. During Stretch installation make the initial user dan8 or dan01 using
Jessie's UID (probably 1000) for dan.

In Jessie, create a new user dan2 or dan09 using the UID you picked for Stretch.


Interesting.



Booted to either, the homedir of the other can optionally be bind mounted as a
subdir of the current dan for more convenient data access without interference
with settings of the other. Either way you boot, you'll be user "dan", but
without risk of settings corruption.
[1] https://en.wikipedia.org/wiki/User_identifier


I'm going to study this and I may have questions later.

Thanks, Felix

 - Dan

Re: Debian 8 and Debian 9 Dual Boot




On 11/13/2017 11:07 AM, Roberto C. Sánchez wrote:

On Mon, Nov 13, 2017 at 11:01:27AM -0500, Dan Norton wrote:

Although I didn't say so, each install would have its own set of
directories. Please say more about how to mount the other installation and
share data. How to mount things in another volume group?


That would be as simple as creating a logical volume, call it "data,"
and then configuring it to mount in each installation with a line in
/etc/fstab:

/dev/vg00/data /data .
Ah. OK. If each installation is in its own volume group, then vg00 above 
would be replaced with the actual vg.


Since you are talking about installing more than one version of Debian
and switching back and forth between them I assume that you are the only
user of the machine.

Yes.

You would need to make sure that the assigned user
ID for your username matches in both installations and then just make
sure that /data has the appropriate permissions for your user account to
be able to write to it.

OK.


This is generally preferrable to directly mounting directories of the
other installation just to share data, as the dedicated data sharing
directory approach reduces the likelihood that a mistake will cause
problems in the other installation.

Great. If there's a mistake to be made ...

Thanks, Roberto.

 - Dan

Re: Debian 8 and Debian 9 Dual Boot




On 11/13/2017 06:56 AM, Roberto C. Sánchez wrote:

On Sun, Nov 12, 2017 at 10:27:36PM -0500, Dan Norton wrote:

My first Linux install was about one year ago. After some missteps, I have
used Debian 8 in reasonable satisfaction on the desktop during that year.
Now I want to leave 8 in place and do a network install for Debian 9 on the
same disk and switch back and forth at boot time.


If you use a desktop environment (e.g., GNOME or KDE) and want to share
the /home directory between both installations, you might encounter some
problems.  In particular, the desktop environments are known for not
behaving well when a newer version updates all the user-specific files
and then an older version tries to access them.


Xfce is what I use and it would surely encounter the same kinds of problems.



For example, the first time you boot to Debian 9 and log in (assume
GNOME for moment), files under ~/.config, ~/.gnome*, and possibly other
places will be modified by the new version of GNOME in Debian 9.  There
is no guarantee that when you go back to Debian 8 that the version of
GNOME there will cope will at all with the changed files under ~/.config
and ~/.gnome*.  In fact, it is quite likely that it will encounter some
sort of significant problem.

Your safest bet if you really intend to dual-boot in this way is to have
separate /home directories for each install and then use something like
/data to mount into both installations in order to share documents and
data between sessions.


Although I didn't say so, each install would have its own set of 
directories. Please say more about how to mount the other installation 
and share data. How to mount things in another volume group?


Thanks, Roberto.

 - Dan

Re: Debian 8 and Debian 9 Dual Boot




On 11/13/2017 03:53 AM, Jochen Spieker wrote:

Dan Norton:
henny|i

My first Linux install was about one year ago. After some missteps, I have
used Debian 8 in reasonable satisfaction on the desktop during that year.
Now I want to leave 8 in place and do a network install for Debian 9 on the
same disk and switch back and forth at boot time.

Your disk setup allows to do this comparably easy, but I would think
twice whether that is actually what I want to do. You end up with two
systems which you have to maintain and, most importantly, you cannot
properly share your /home. Most programs that save their settings to
$HOME will automatically upgrade their configuration files on first
start with a new version and after that you have to assume that the
older version cannot read it anymore. I realize that this is part of
your disk space calculation but I want to stress that the result is
probably not something that you will want to use for an extended period
of time.


Indeed, I had thought to have 9 with a complete set of partitions as if 
8 didn't exist, but I did not say so.





LVM reports as follows:

dan@debian:/$ sudo vgdisplay -C
   VG   #PV #LV #SN AttrVSize  VFree
   debian-vg   1 5 0wz--n- 976.56g 938.20g

You can vgreduce debian-vg easily to make room for your planned
debian9-vg.


So this must mean that VFree above is bound to debian-vg currently. I 
had not recognized the need to vgreduce. Thanks.





So there is plenty of disk space for the two Debians and more besides. The
question is how to prepare to install 9? My guess is to define another
volume group called debian9-vg perhaps but how will this be recognized
during network install?

Yes, it will. It should also be possible to vgreduce debian.vg and
vgcreate debian9-vg inside the installer, but I would be more
comfortable doing that from the running system, using the regular tools.


For sure. Trying to do things within the installer has been the source 
of a lot of my problems.




During installation, you just have to make sure that all LVs in
debian-vg are marked as "Do not use".


Good. This is the kind of information I need.




I've clobbered stuff before during installs and I'm
gun shy. Maybe there is a better way. Any thoughts on this will be
appreciated.

It happens to everybody. The only things that help are a good plan and
concentration on the task at hand. :)


+1 and thank you, Jochen.

 - Dan

Re: Debian 8 and Debian 9 Dual Boot