Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #188930 > unrolled thread
| Started by | Dan Norton <dnorton@mindspring.com> |
|---|---|
| First post | 2017-11-13 04:50 +0100 |
| Last post | 2017-12-30 00:40 +0100 |
| Articles | 20 on this page of 62 — 9 participants |
Back to article view | Back to linux.debian.user
Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-13 04:50 +0100
Re: Debian 8 and Debian 9 Dual Boot David Christensen <dpchrist@holgerdanske.com> - 2017-11-13 07:20 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-13 16:30 +0100
Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-11-13 20:10 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-13 21:10 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-14 00:10 +0100
Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-11-14 01:50 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-14 03:40 +0100
Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-11-14 04:00 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-14 04:50 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-16 19:40 +0100
Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-11-16 20:10 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-16 23:40 +0100
Re: Debian 8 and Debian 9 Dual Boot Joe <joe@jretrading.com> - 2017-11-16 20:30 +0100
Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-11-16 21:20 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-29 19:10 +0100
Re: Debian 8 and Debian 9 Dual Boot Joe <joe@jretrading.com> - 2017-11-29 19:20 +0100
Re: Debian 8 and Debian 9 Dual Boot Joe <joe@jretrading.com> - 2017-11-29 19:50 +0100
Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-11-29 19:40 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-29 21:40 +0100
Re: Debian 8 and Debian 9 Dual Boot Joe <joe@jretrading.com> - 2017-11-29 22:00 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-29 22:40 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-30 03:20 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-29 22:10 +0100
Re: Debian 8 and Debian 9 Dual Boot Joe <joe@jretrading.com> - 2017-11-29 23:10 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-17 00:00 +0100
Re: Debian 8 and Debian 9 Dual Boot Jonathan Dowland <jmtd@debian.org> - 2017-11-29 10:10 +0100
Re: Debian 8 and Debian 9 Dual Boot David Christensen <dpchrist@holgerdanske.com> - 2017-11-13 20:20 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-14 00:30 +0100
Re: Debian 8 and Debian 9 Dual Boot David Christensen <dpchrist@holgerdanske.com> - 2017-11-14 00:40 +0100
Re: Debian 8 and Debian 9 Dual Boot Jochen Spieker <ml@well-adjusted.de> - 2017-11-13 10:00 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-13 17:00 +0100
Re: Debian 8 and Debian 9 Dual Boot Jochen Spieker <ml@well-adjusted.de> - 2017-11-13 21:30 +0100
Re: Debian 8 and Debian 9 Dual Boot Roberto C. Sánchez <roberto@debian.org> - 2017-11-13 13:00 +0100
Re: Debian 8 and Debian 9 Dual Boot Roberto C. Sánchez <roberto@debian.org> - 2017-11-13 17:10 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-13 18:10 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-13 17:10 +0100
Re: Debian 8 and Debian 9 Dual Boot Joe <joe@jretrading.com> - 2017-11-13 20:00 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-29 04:20 +0100
Re: Debian 8 and Debian 9 Dual Boot Michael Fothergill <michael.fothergill@gmail.com> - 2017-11-29 08:10 +0100
Re: Debian 8 and Debian 9 Dual Boot Joe <joe@jretrading.com> - 2017-11-29 10:10 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-11-29 19:00 +0100
Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-11-29 20:00 +0100
Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-11-29 20:40 +0100
Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-12-21 10:50 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-12-21 20:10 +0100
Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-12-21 21:00 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-12-21 23:00 +0100
Re: Debian 8 and Debian 9 Dual Boot Joe <joe@jretrading.com> - 2017-12-21 23:10 +0100
Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-12-21 23:20 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-12-23 21:20 +0100
Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-12-23 22:40 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-12-24 01:20 +0100
Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-12-24 05:40 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-12-28 01:00 +0100
Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-12-28 07:40 +0100
Re: Debian 8 and Debian 9 Dual Boot Felix Miata <mrmazda@earthlink.net> - 2017-12-28 07:50 +0100
Re: Debian 8 and Debian 9 Dual Boot Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-28 10:50 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-12-28 21:00 +0100
Re: Debian 8 and Debian 9 Dual Boot Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-29 15:00 +0100
Re: Debian 8 and Debian 9 Dual Boot Dan Norton <dnorton@mindspring.com> - 2017-12-29 23:50 +0100
Re: Debian 8 and Debian 9 Dual Boot Pascal Hambourg <pascal@plouf.fr.eu.org> - 2017-12-30 00:40 +0100
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Joe <joe@jretrading.com> |
|---|---|
| Date | 2017-11-29 10:10 +0100 |
| Message-ID | <uR6xs-7RM-27@gated-at.bofh.it> |
| In reply to | #189388 |
On Tue, 28 Nov 2017 22:15:22 -0500 Dan Norton <dnorton@mindspring.com> wrote: > On 11/13/2017 01:55 PM, Joe wrote: > > On Mon, 13 Nov 2017 11:01:27 -0500 > > Dan Norton <dnorton@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). # > # <file system> <mount point> <type> <options> <dump> <pass> > /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... -- Joe
[toc] | [prev] | [next] | [standalone]
| From | Dan Norton <dnorton@mindspring.com> |
|---|---|
| Date | 2017-11-29 19:00 +0100 |
| Message-ID | <uReOl-4nN-3@gated-at.bofh.it> |
| In reply to | #189396 |
On 11/29/2017 03:59 AM, Joe wrote: > On Tue, 28 Nov 2017 22:15:22 -0500 > Dan Norton <dnorton@mindspring.com> wrote: > >> On 11/13/2017 01:55 PM, Joe wrote: >>> On Mon, 13 Nov 2017 11:01:27 -0500 >>> Dan Norton <dnorton@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). # >> # <file system> <mount point> <type> <options> <dump> <pass> >> /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't get as far as grub. These are coming from bios(?) after POST: [...] DHCP... (spins for about a minute, then:) Realtek PCIe GBE Family Controller Series v2.38 (12/24/10) CLIENT MAC ADDR: <hex addr> GUID: <hex id> PXE-E53: No boot filename received PXE-MOF: Exiting PXE ROM. ERROR:No boot disk has been detected or the disk has failed. (full stop)
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2017-11-29 20:00 +0100 |
| Message-ID | <uRfKq-4YA-17@gated-at.bofh.it> |
| In reply to | #189388 |
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 to check whether there is a missing column. On DOS-partitioned disks, there is a column in between "Device" and "Start" labeled "Boot", where any boot flags that exist are shown. Since your HD is <2GB, one way to make all this trouble go away would be to start all over, selecting DOS as the partitioning type, make a primary as a home for Grub, keep LVM on logicals, and put swap either on primary or logical. The primary with Grub you would mount on /boot for your first installation, but until you understand better the foibles of multiboot, not those subsequent. -- "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/
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2017-11-29 20:40 +0100 |
| Message-ID | <uRgn7-5sT-13@gated-at.bofh.it> |
| In reply to | #189409 |
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 to check whether there is a > missing column. On DOS-partitioned disks, there is a column in between "Device" > and "Start" labeled "Boot", where any boot flags that exist are shown. > Since your HD is <2GB, one way to make all this trouble go away would be to > start all over, selecting DOS as the partitioning type, make a primary as a home > for Grub, keep LVM on logicals, and put swap either on primary or logical. The > primary with Grub you would mount on /boot for your first installation, but > until you understand better the foibles of multiboot, not those subsequent. Additional considerations that may be at work here: https://www.rodsbooks.com/gdisk/bios.html How old is the BIOS/Firmware on this HP PC? Is an upgrade available? -- "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/
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2017-12-21 10:50 +0100 |
| Message-ID | <uZ5Ed-PA-3@gated-at.bofh.it> |
| In reply to | #189409 |
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? -- "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/
[toc] | [prev] | [next] | [standalone]
| From | Dan Norton <dnorton@mindspring.com> |
|---|---|
| Date | 2017-12-21 20:10 +0100 |
| Message-ID | <uZeo9-6YN-9@gated-at.bofh.it> |
| In reply to | #190082 |
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
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2017-12-21 21:00 +0100 |
| Message-ID | <uZfax-7jv-1@gated-at.bofh.it> |
| In reply to | #190112 |
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 ## -- "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/
[toc] | [prev] | [next] | [standalone]
| From | Dan Norton <dnorton@mindspring.com> |
|---|---|
| Date | 2017-12-21 23:00 +0100 |
| Message-ID | <uZh2G-6s-19@gated-at.bofh.it> |
| In reply to | #190114 |
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: 0000 Timeout: 11 seconds # ... and the actual timeout is 3 BootOrder: 0003,0001,0000,0002,0006,0004,0005 Boot0000* 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: 0000 Timeout: 12 seconds BootOrder: 0003,0001,0000,0002,0006,0004,0005 Boot0000* 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
[toc] | [prev] | [next] | [standalone]
| From | Joe <joe@jretrading.com> |
|---|---|
| Date | 2017-12-21 23:10 +0100 |
| Message-ID | <uZhcn-qF-21@gated-at.bofh.it> |
| In reply to | #190119 |
On Thu, 21 Dec 2017 16:53:19 -0500 Dan Norton <dnorton@mindspring.com> wrote: > [1] "Insanity is doing the same thing over & over again and expecting > a different result." - Einstein > Probably the single most stupid thing he ever said, given that he also said 'God does not play dice', showing that he knew what dice were and what they were used for. He also presumably had never had to fix an intermittent fault... -- Joe
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2017-12-21 23:20 +0100 |
| Message-ID | <uZhm1-uG-1@gated-at.bofh.it> |
| In reply to | #190119 |
Dan Norton composed on 2017-12-21 16:53 (UTC-0500): > Felix Miata wrote: >> Dan Norton composed on 2017-12-21 14:07 (UTC-0500): >>> 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: 0000 > Timeout: 11 seconds # ... and the actual timeout is 3 > BootOrder: 0003,0001,0000,0002,0006,0004,0005 > Boot0000* 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: 0000 > Timeout: 12 seconds > BootOrder: 0003,0001,0000,0002,0006,0004,0005 > Boot0000* 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 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 ###". -- "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/
[toc] | [prev] | [next] | [standalone]
| From | Dan Norton <dnorton@mindspring.com> |
|---|---|
| Date | 2017-12-23 21:20 +0100 |
| Message-ID | <uZYqZ-3c8-1@gated-at.bofh.it> |
| In reply to | #190123 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2017-12-23 22:40 +0100 |
| Message-ID | <uZZGp-3Ys-5@gated-at.bofh.it> |
| In reply to | #190219 |
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?
NAICT, the first "if" is setting the timeout to infinite if there is nothing
found that could be booted. The next "if" is using 11 if some sort of optional
timeout indication feature is enabled. Otherwise, 11 is used as Grub's own
standard (invisible) timeout "indication".
Do you still have only Jessie installed? If so, maybe its grub-efi is broken,
and going ahead and installing Stretch will replace Jessie's with a working one.
Stretch's is working as expected here. Jessie's I've never had occasion to use.
Another thought is that if there is but one valid Grub stanza, the timeout
setting might be ignored.
--
"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/
[toc] | [prev] | [next] | [standalone]
| From | Dan Norton <dnorton@mindspring.com> |
|---|---|
| Date | 2017-12-24 01:20 +0100 |
| Message-ID | <v02bf-5Is-3@gated-at.bofh.it> |
| In reply to | #190227 |
[Multipart message — attachments visible in raw view] — view raw
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.
[...]
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2017-12-24 05:40 +0100 |
| Message-ID | <v06eR-7H-1@gated-at.bofh.it> |
| In reply to | #190232 |
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. 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. -- "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/
[toc] | [prev] | [next] | [standalone]
| From | Dan Norton <dnorton@mindspring.com> |
|---|---|
| Date | 2017-12-28 01:00 +0100 |
| Message-ID | <v1tM5-l7-3@gated-at.bofh.it> |
| In reply to | #190238 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2017-12-28 07:40 +0100 |
| Message-ID | <v1A1c-4HJ-1@gated-at.bofh.it> |
| In reply to | #190369 |
Dan Norton composed on 2017-12-27 18:59 (UTC-0500):
> Felix Miata wrote:
>> 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?
There's nothing to do with timeout in /etc/grub.d/ anyone but packager
owner and/or upstream should be touching. If you can't control timeout
exclusively via /etc/default/grub and update-grub, then it must be time to ask
grub people via
https://lists.gnu.org/mailman/listinfo/help-grub or report a bug.
--
"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/
[toc] | [prev] | [next] | [standalone]
| From | Felix Miata <mrmazda@earthlink.net> |
|---|---|
| Date | 2017-12-28 07:50 +0100 |
| Message-ID | <v1AaR-4LM-3@gated-at.bofh.it> |
| In reply to | #190369 |
Dan Norton composed on 2017-12-27 18:59 (UTC-0500): > Felix Miata wrote: >> 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? Indirectly, by having a POST-time (F12 menu) choice which installation's Grub to use. -- "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/
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2017-12-28 10:50 +0100 |
| Message-ID | <v1CZ3-6CC-5@gated-at.bofh.it> |
| In reply to | #190238 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Dan Norton <dnorton@mindspring.com> |
|---|---|
| Date | 2017-12-28 21:00 +0100 |
| Message-ID | <v1Mvo-4PI-25@gated-at.bofh.it> |
| In reply to | #190381 |
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/<VG UUID>/<LV UUID> 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.
[toc] | [prev] | [next] | [standalone]
| From | Pascal Hambourg <pascal@plouf.fr.eu.org> |
|---|---|
| Date | 2017-12-29 15:00 +0100 |
| Message-ID | <v23mx-k5-5@gated-at.bofh.it> |
| In reply to | #190112 |
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". > 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.
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | linux.debian.user
csiph-web