Discussion:
V6 release update?
(too old to reply)
Vince Coen
2017-02-13 14:17:38 UTC
Permalink
Hello All!

Any one have any idea when the next release is due out even if its in
quarters.


Vince
Doug Laidlaw
2017-02-13 14:38:49 UTC
Permalink
Post by Vince Coen
Hello All!
Any one have any idea when the next release is due out even if its in
quarters.
Vince
A big release blocker has gone, with the fix for mariadb. I am finding
a lot of low-priority bugs, which the team hasn't time to look at. If I
can fix them for myself, I do, but I am not in good enough health to be
a maintainer. For example, the RPM for Tvheadend is stale, and Kodi
won't look at it. But there aren't many programmers using it. I am
trying to update the RPM, but really, it is beyond me.

Doug.
TJ
2017-02-13 15:58:28 UTC
Permalink
Post by Vince Coen
Hello All!
Any one have any idea when the next release is due out even if its in
quarters.
Vince
The biggest problem holding back the release of the sta2 version has
been a troublesome partitioning bug in the installers. It is believed
that it has been fixed, and we are hopeful that sta2 will be released
very soon.

Unless, of course, some new release-blocker problem shows up during testing.

TJ
Bit Twister
2017-02-13 17:11:47 UTC
Permalink
Post by Vince Coen
Hello All!
Any one have any idea when the next release is due out even if its in
quarters.
Big hangup was disk partitioning tool which was clobbering the drive
partition table. Last weeks estimate was generate/deliver new sta2
isos to QA for test by tomorrow.

Feel free to speculate by moving the
https://wiki.mageia.org/en/Mageia_6_Development
schedule based on a blue sky estimate of next week sta2 release. :)

Going to guess big complaints from Radeon video card users being stuck
with generic low speed video driver.

No telling how many NVIDIA video card users will have problems.

https://wiki.mageia.org/en/Mageia_6_Release_Notes and
https://wiki.mageia.org/en/Mageia_6_Errata
are a bit behind/sparse.

MythTV users need to check mthtv bug reports for tips on migration.

I am not sure if it is possible to get a mga5 to mga6 upgrade to run
flawlessly.

I have abandoned Plasma for Xfce as my Desktop Environment (DE). I can
recommend users need to test the apps they normally use under their DE.

I have been using mga6 as my "Production" install since sta1 was
released 30-Jun-2016 and just happened to find k3b was broke last week.

As a power user, I do not use very many gui apps and I script anything
that is repetitive. Other than MythTv, basic usage is slrn for Usenet,
Thunderbird, Firefox, VirtualBox vendor installs, cdrtools, xterm and using
systemd-networkd to manage my network cards which makes me a poor
gauge as to how well mga6 is going to work for anyone else.

My current open bug count is 42 out of the 87+ I had open at start of year.

Only real show stopper I have at the moment is getting pulseaudio to
run as a system wide daemon/service.

You may also want to read up on grub2 since that will be the boot
loader for mga6.

Menu presentation is rather poor if you have several installs of the
same release or have a large selection of installs.

Rolled my own menu to boot by labels made it much easier to pick
desired install. Also modified it to be able to set which install is
to be default.
TJ
2017-02-13 22:01:16 UTC
Permalink
On 02/13/2017 12:11 PM, Bit Twister wrote:
(snip)
Post by Bit Twister
I have abandoned Plasma for Xfce as my Desktop Environment (DE). I can
recommend users need to test the apps they normally use under their DE.
FWIW, I've found that Mageia's Plasma implementation has come a long way
from the sta1 isos. True, it still has its problems. If migrating from
KDE4 most if not all settings will have to be re-made, but then the same
was true when we migrated from KDE3.x to KDE4, IIRC.
Post by Bit Twister
I have been using mga6 as my "Production" install since sta1 was
released 30-Jun-2016 and just happened to find k3b was broke last week.
Interesting. I stopped using optical media in favor of usb flash drives
some time ago, so I don't use k3b much any more, and don't bother with
installing cdrtools, either. But, just a few days ago I used k3b to burn
an iso onto a DVD-RW. It worked perfectly, except for the old, ongoing
bug where it reports that formatting failed when it really didn't.
Post by Bit Twister
As a power user, I do not use very many gui apps and I script anything
that is repetitive. Other than MythTv, basic usage is slrn for Usenet,
Thunderbird, Firefox, VirtualBox vendor installs, cdrtools, xterm and using
systemd-networkd to manage my network cards which makes me a poor
gauge as to how well mga6 is going to work for anyone else.
My current open bug count is 42 out of the 87+ I had open at start of year.
Only real show stopper I have at the moment is getting pulseaudio to
run as a system wide daemon/service.
You may also want to read up on grub2 since that will be the boot
loader for mga6.
Menu presentation is rather poor if you have several installs of the
same release or have a large selection of installs.
Rolled my own menu to boot by labels made it much easier to pick
desired install. Also modified it to be able to set which install is
to be default.
Yeah, I don't much like the grub2 menu, either. I'll have to read up on
it as you suggest. For those of us who are non-power-users, you can do
some of what you describe with the grub-customizer gui, but I haven't
yet discovered how to get more descriptive labels from the os-prober app
it uses. Then again, I haven't yet spent much time looking for the
information, either. Guess I should fire up Google once more...

TJ
Bit Twister
2017-02-13 23:01:25 UTC
Permalink
Post by TJ
FWIW, I've found that Mageia's Plasma implementation has come a long way
from the sta1 isos. True, it still has its problems. If migrating from
KDE4 most if not all settings will have to be re-made, but then the same
was true when we migrated from KDE3.x to KDE4, IIRC.
Very true. I always do clean installs with empty /home/$USER then run
a install_links script to link /accounts/$USER/* directory/files in /home/$USER
Post by TJ
Yeah, I don't much like the grub2 menu, either. I'll have to read up on
it as you suggest. For those of us who are non-power-users, you can do
some of what you describe with the grub-customizer gui,
Yep, tried it once to re-arrange menu order. Never again will I do that.
Post by TJ
but I haven't
yet discovered how to get more descriptive labels from the os-prober app
it uses.
Tried modifying os-prober script but that was a little too complex for
a quick hack and you would have to make your mods upon new os-prober updates.
Post by TJ
Then again, I haven't yet spent much time looking for the
information, either. Guess I should fire up Google once more...
My solution was a down and dirty hack to put my menu in front of
os-prober and requires you to have a media label on each install.
It will only pick up installs with /boot/vmlinuz-desktop files on ext4
partitions.

It also does not pick up different kernel boot parameters like os-prober.


While doing any research you might look at what else I did to /etc/default/grub.

$ dif /var/local/vorig/etc/default/grub_vinstall /etc/default/grub
1,2c1,3
< GRUB_CMDLINE_LINUX_DEFAULT=" splash quiet noiswmd resume=UUID=59620762-ed08-4206-b6f4-6a76d65deccb audit=0 vga=788"
< GRUB_DEFAULT=saved
---
Post by TJ
GRUB_CMDLINE_LINUX_DEFAULT="noiswmd"
GRUB_CMDLINE_LINUX="ipv6.disable=1 audit=0 vga=795"
GRUB_DEFAULT="saved"
8c9
< GRUB_GFXMODE=1024x768x32
---
Post by TJ
GRUB_GFXMODE="1280x1024x24"
10c11
< GRUB_SAVEDEFAULT=true
---
Post by TJ
GRUB_SAVEDEFAULT="false"
13c14
< GRUB_TIMEOUT=10
---
Post by TJ
GRUB_TIMEOUT="5"
-----8<-----8<-----8<-cut below this line----8<-----8<-----8<-----8<
#! /bin/sh
set -e
#*******************************************************************************
#* 10a_label_xx__grub - grub2 script to generate menu entries using partition label
#*
#* Install Procedure
#* save as 10a_label_xx__grub
#* chmod +x 10a_label_xx__grub
#* cp 10a_label_xx__grub /etc/grub.d or create a link in /etc/grub.d
#* and run update-grub2
#*
#* Assumptions:
#* All partitions containing /boot/vmlinuz-desktop have a label
#* and are ext4
#*
#*
#*
#*******************************************************************************
#
#
# grub-mkconfig helper script.
# Copyright (C) 2006,2007,2008,2009,2010 Free Software Foundation, Inc.
#
# GRUB is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# GRUB is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with GRUB. If not, see <http://www.gnu.org/licenses/>.

prefix="/usr"
exec_prefix="/usr"
datarootdir="/usr/share"

. "/usr/share/grub/grub-mkconfig_lib"

device=""
line=""
label=""
_label_fn="/tmp/10a_label.lst"

export TEXTDOMAIN=grub
export TEXTDOMAINDIR="${datarootdir}/locale"


#****************************************************
#* create grub2 menu stanza. arg 1 is partition label
#* GRUB_CMDLINE_* are found in /etc/default/grub
#****************************************************

menu_stanza () {
cat << EOF
menuentry "$1" {
set gfxpayload=text
insmod part_gpt
insmod gzio
insmod ext2
search --no-floppy --label --set=root $1
linux /boot/vmlinuz-desktop root=LABEL=$1 ${GRUB_CMDLINE_LINUX_DEFAULT} ${GRUB_CMDLINE_LINUX}
initrd /boot/initrd-desktop.img
}
EOF

}
#*********************************************
#* create current mount as first menu entry
#*********************************************

mkdir -p /mnt/10a_label
set -- $(mount | grep ' / ')
device=$1
label=$(e2label ${device} 2>/dev/null)
menu_stanza $label

#***********************************************************
#* look through other partitions for /boot/vmlinuz-desktop
#* and create a menu entry using its label.
#***********************************************************

lsblk -lno NAME,LABEL,FSTYPE | grep -v "$label " | grep ext4 > $_label_fn
while read -r line; do
set -- $line
mount -t auto /dev/$1 /mnt/10a_label
if [ -e /mnt/10a_label/boot/vmlinuz-desktop ] ; then
menu_stanza "$2"
fi
umount /mnt/10a_label
done < $_label_fn

rmdir /mnt/10a_label
rm -f $_label_fn
#***************** end /etc/grub.d/10a_label_xx__grub *************************
Doug Laidlaw
2017-02-14 02:37:14 UTC
Permalink
Post by Bit Twister
No telling how many NVIDIA video card users will have problems.
The return of the GL bug making VLC crash may hold things up as well. I
am running an nVidia card. I can't make the generic driver run.
Doug Laidlaw
2017-02-14 03:42:43 UTC
Permalink
Post by Doug Laidlaw
Post by Bit Twister
No telling how many NVIDIA video card users will have problems.
The return of the GL bug making VLC crash may hold things up as well. I
am running an nVidia card. I can't make the generic driver run.
I need to install "devel" packages for OpenGL in Cauldron. None will
install. All are "dependent on packages that are older than the
installed ones." Is this a known issue? I can't imagine that I am the
first to face it. Should I just reinstall Cauldron from scratch?

Doug.
Bit Twister
2017-02-14 04:47:14 UTC
Permalink
Post by Doug Laidlaw
Post by Doug Laidlaw
Post by Bit Twister
No telling how many NVIDIA video card users will have problems.
The return of the GL bug making VLC crash may hold things up as well. I
am running an nVidia card. I can't make the generic driver run.
I need to install "devel" packages for OpenGL in Cauldron. None will
install. All are "dependent on packages that are older than the
installed ones." Is this a known issue? I can't imagine that I am the
first to face it. Should I just reinstall Cauldron from scratch?
My guess it would not help because it will pull in the 11-Jan-2017 release.
Assuming you have tainted media enabled.

vlc runs on my radeon setup
$ get_src_rpm /usr/bin/vlc

Using : /usr/bin/vlc
Installed rpm : vlc-2.2.4-9.mga6.tainted
Source rpm : vlc-2.2.4-9.mga6.tainted.src.rpm
Information : http://www.videolan.org/
Doug Laidlaw
2017-02-14 07:06:27 UTC
Permalink
Post by Bit Twister
Post by Doug Laidlaw
Post by Doug Laidlaw
Post by Bit Twister
No telling how many NVIDIA video card users will have problems.
The return of the GL bug making VLC crash may hold things up as well. I
am running an nVidia card. I can't make the generic driver run.
I need to install "devel" packages for OpenGL in Cauldron. None will
install. All are "dependent on packages that are older than the
installed ones." Is this a known issue? I can't imagine that I am the
first to face it. Should I just reinstall Cauldron from scratch?
My guess it would not help because it will pull in the 11-Jan-2017 release.
Assuming you have tainted media enabled.
vlc runs on my radeon setup
$ get_src_rpm /usr/bin/vlc
Using : /usr/bin/vlc
Installed rpm : vlc-2.2.4-9.mga6.tainted
Source rpm : vlc-2.2.4-9.mga6.tainted.src.rpm
Information : http://www.videolan.org/
Two separate issues here:
The VLC bug: https://bugs.mageia.org/show_bug.cgi?id=20248

and the Kodi bug, that requires OpenGL.

https://bugs.mageia.org/show_bug.cgi?id=14939

Doug.
TJ
2017-02-14 12:49:58 UTC
Permalink
Post by Bit Twister
vlc runs on my radeon setup
$ get_src_rpm /usr/bin/vlc
Using : /usr/bin/vlc
Installed rpm : vlc-2.2.4-9.mga6.tainted
Source rpm : vlc-2.2.4-9.mga6.tainted.src.rpm
Information : http://www.videolan.org/
Running just fine here too, on two sets of onboard Intel graphics. One
an old Dell Dimension E310, the other a somewhat newer HP Probook 6550b.

Also running fine on my nvidia setup, but mine uses a no-doubt older
card that uses the nvidia 340 driver. I believe the people seeing the
problem are using nvidia-current on newer cards than mine.

Begin rant: It annoys me that people assume that all models of a certain
brand of computer hardware will act the same. They don't. Why should
they, any more than any other type of hardware? I've personally seen it
with nvidia graphics, Broadcom wifi, and HP printers. And maybe one or
two other brands that I've forgotten I've also seen it with cars, pickup
trucks, tractors, and more farm equipment than I like to think of. Same
brand, different characters. I've even seen differences between two
individuals of the same model. End of rant.

Those seeing the problem are probably also using Intel processors, where
my nvidia setup is using a probably-older Athlon X2. I doubt that's
relevant, but I suppose it could be.

TJ
TJ
2017-02-14 15:01:01 UTC
Permalink
Post by TJ
Post by Bit Twister
vlc runs on my radeon setup
$ get_src_rpm /usr/bin/vlc
Using : /usr/bin/vlc
Installed rpm : vlc-2.2.4-9.mga6.tainted
Source rpm : vlc-2.2.4-9.mga6.tainted.src.rpm
Information : http://www.videolan.org/
Running just fine here too, on two sets of onboard Intel graphics. One
an old Dell Dimension E310, the other a somewhat newer HP Probook 6550b.
Also running fine on my nvidia setup, but mine uses a no-doubt older
card that uses the nvidia 340 driver. I believe the people seeing the
problem are using nvidia-current on newer cards than mine.
Forgot to mention, I've been running an informal test of the nouveau
driver for the last week or so on a different install on the same Athlon
X2/nvidia hardware. My production install, in fact.

VLC is doing fine there, too. Except for a very minor and temporary
glitch here or there, the nouveau driver is trouble-free on that setup.
If for some reason the proprietary nvidia driver no longer worked,
nouveau makes a more-than-adequate substitute for me.

TJ
Daniel60
2017-02-14 10:28:19 UTC
Permalink
Post by Bit Twister
Post by Vince Coen
Hello All!
Any one have any idea when the next release is due out even if its in
quarters.
Big hangup was disk partitioning tool which was clobbering the drive
partition table.
Bit Twister, I've used the disk partitioning tool that came with MGA 3
and 5 (I think) and they, apparently, worked.

What "improvements" were being made to the disk partitioning tool that
has now got it "clobbering the drive partition table"??

And would it have been possible, in order to get MGA 6 out and about, to
just re-instate the old disk partitioning tool from 5/5.1 and keep the
newer version for MGA 7??

Daniel
Doug Laidlaw
2017-02-14 11:22:13 UTC
Permalink
Post by Daniel60
Post by Bit Twister
Post by Vince Coen
Hello All!
Any one have any idea when the next release is due out even if its in
quarters.
Big hangup was disk partitioning tool which was clobbering the drive
partition table.
Bit Twister, I've used the disk partitioning tool that came with MGA 3
and 5 (I think) and they, apparently, worked.
What "improvements" were being made to the disk partitioning tool that
has now got it "clobbering the drive partition table"??
And would it have been possible, in order to get MGA 6 out and about, to
just re-instate the old disk partitioning tool from 5/5.1 and keep the
newer version for MGA 7??
Daniel
In other words, "If it ain't broken, don't fix it" (?). BT asked
them to do that
with the mariadb bug, but there was a flurry of activity, they
went back to
the drawing board, and found a better solution.

That was a case of inadequate testing, and upgrading Kodi without
upgrading
related RPMs, sounds much the same. I don't know enough about it, but
I would have expected the installer to remain the same, and only
the content
to be new.

Doug.
--
Bit Twister
2017-02-14 13:15:27 UTC
Permalink
Post by Doug Laidlaw
In other words, "If it ain't broken, don't fix it" (?).
Well, grub legacy was no longer supported and grub2 forced the Mageia team
to move forward.
Post by Doug Laidlaw
BT asked
them to do that
with the mariadb bug, but there was a flurry of activity, they
went back to
the drawing board, and found a better solution.
Grub2 and an updated mariadb are completely two different types of problems.
My mariadb suggestion was just to get back to fast reboot time.
Post by Doug Laidlaw
That was a case of inadequate testing,
You owe a great deal of thanks for all the QA testing of the installer
which prevented sta2 release with such a nasty bug.
Post by Doug Laidlaw
and upgrading Kodi without
upgrading
related RPMs, sounds much the same.
I want you to scroll to the bottom of http://pkgsubmit.mageia.org/
and get the number of Contributors pushing packages through the
build system.

Now, I want you to total the number of rpms that they have to manage:
$ while read -r line; do wc -l $line; done < <(ls -1 *-0006*)
27696 core-0006.0.x86_64.idx
27628 core32-0006.0.x86_64.idx
149 nonfree-0006.0.x86_64.idx
141 nonfree32-0006.0.x86_64.idx
372 tainted-0006.0.x86_64.idx
373 tainted32-0006.0.x86_64.idx

and divide that by Contributors to see just how much test time they
can spend per rpm testing.

Do keep in mind those people have family and jobs to attend to and in
their _spare_ time, provide you with Mageia Linux.

You have a choice to make,
[ ] Become a Contributor
[ ] just STFU about the Mageia staff
[ ] or change to a different distribution.
Post by Doug Laidlaw
I don't know enough about it, but
I would have expected the installer to remain the same, and only
the content
to be new.
Yep, and from the comments you have made to problems, I do not see you
making any headway in learning to help improve Mageia Linux. :-(
blind Pete
2017-02-18 03:15:20 UTC
Permalink
Post by Bit Twister
Post by Doug Laidlaw
In other words, "If it ain't broken, don't fix it" (?).
Well, grub legacy was no longer supported and grub2 forced the Mageia team
to move forward.
Hard question; will it be sane, or even possible, to use LiLo on
a BIOS system? It will require an ext3 boot partition and probably
compiling from source. I usually move EFI systems to rEFInd as
soon as I can. For some reason Grub2 has never grown on me.
Post by Bit Twister
Post by Doug Laidlaw
BT asked
them to do that
with the mariadb bug, but there was a flurry of activity, they
went back to
the drawing board, and found a better solution.
Grub2 and an updated mariadb are completely two different types of
problems. My mariadb suggestion was just to get back to fast reboot time.
Post by Doug Laidlaw
That was a case of inadequate testing,
You owe a great deal of thanks for all the QA testing of the installer
which prevented sta2 release with such a nasty bug.
Post by Doug Laidlaw
and upgrading Kodi without
upgrading
related RPMs, sounds much the same.
I want you to scroll to the bottom of http://pkgsubmit.mageia.org/
and get the number of Contributors pushing packages through the
build system.
$ while read -r line; do wc -l $line; done < <(ls -1 *-0006*)
27696 core-0006.0.x86_64.idx
27628 core32-0006.0.x86_64.idx
149 nonfree-0006.0.x86_64.idx
141 nonfree32-0006.0.x86_64.idx
372 tainted-0006.0.x86_64.idx
373 tainted32-0006.0.x86_64.idx
and divide that by Contributors to see just how much test time they
can spend per rpm testing.
Do keep in mind those people have family and jobs to attend to and in
their _spare_ time, provide you with Mageia Linux.
You have a choice to make,
[ ] Become a Contributor
[ ] just STFU about the Mageia staff
[ ] or change to a different distribution.
Post by Doug Laidlaw
I don't know enough about it, but
I would have expected the installer to remain the same, and only
the content
to be new.
Yep, and from the comments you have made to problems, I do not see you
making any headway in learning to help improve Mageia Linux. :-(
--
blind Pete
Sig goes here...
Aragorn
2017-02-18 07:06:57 UTC
Permalink
On Saturday 18 February 2017 04:15, blind Pete conveyed the following to
alt.os.linux.mageia...
Post by blind Pete
Post by Bit Twister
Post by Doug Laidlaw
In other words, "If it ain't broken, don't fix it" (?).
Well, grub legacy was no longer supported and grub2 forced the Mageia
team to move forward.
Hard question; will it be sane, or even possible, to use LiLo on
a BIOS system?
LILO is no longer being maintained, but it /should/ still work on MBR
systems. I wouldn't advise it on GPT systems, though.
Post by blind Pete
It will require an ext3 boot partition and probably compiling from
source.
LILO does not care about the filesystem that /boot is on ─ or for that
matter, whether /boot is a distinct filesystem or simply on the root
filesystem ─ because it uses logical block offsets to find the kernel
image and the initrd.
Post by blind Pete
I usually move EFI systems to rEFInd as soon as I can. For some
reason Grub2 has never grown on me.
I don't like grub2 either ─ it's needlessly complex in comparison to
grub-legacy and LILO ─ but on a GPT system with BIOS firmware instead of
EFI, there's no alternative that I know of.

There's also an additional complication when compiling grub-legacy on a
64-bit system. For some reason ─ I've known why but I've forgotten ─
grub-legacy must then be compiled statically with a 32-bit compiler, I
believe. This was discussed on the Gentoo mailing list at the time, but
like I said, I've forgotten about the details.

grub-legacy also doesn't support a boot disk of 2 GiB in size, and it
also doesn't support /boot on btrfs or LVM.

Note that for EFI systems, the Linux kernel supports booting without an
external boot loader such as GRUB, i.e. via the in-kernel EFI stub
loader (if compiled in).
--
= Aragorn =
blind Pete
2017-02-19 00:09:50 UTC
Permalink
Post by Aragorn
On Saturday 18 February 2017 04:15, blind Pete conveyed the following to
alt.os.linux.mageia...
Post by blind Pete
Post by Bit Twister
Post by Doug Laidlaw
In other words, "If it ain't broken, don't fix it" (?).
Well, grub legacy was no longer supported and grub2 forced the Mageia
team to move forward.
Hard question; will it be sane, or even possible, to use LiLo on
a BIOS system?
LILO is no longer being maintained, but it /should/ still work on MBR
systems. I wouldn't advise it on GPT systems, though.
The biggest problem - that I know about - is that ext4 has been
enhanced since development of LiLo and Legacy Grub ceased. Legacy
Grub follows the filesystem at boot time, so it is completely
stuffed by newer ext4 filesystems. LiLo uses block addresses at
boot time, so that is OK, but it has to get those block addresses
at configuration time. Can it rely on the OS to get those, or
does it need to use its own code? An older filesystem should be
safe.
Post by Aragorn
Post by blind Pete
It will require an ext3 boot partition and probably compiling from
source.
LILO does not care about the filesystem that /boot is on ─ or for that
matter, whether /boot is a distinct filesystem or simply on the root
filesystem ─ because it uses logical block offsets to find the kernel
image and the initrd.
Post by blind Pete
I usually move EFI systems to rEFInd as soon as I can. For some
reason Grub2 has never grown on me.
I don't like grub2 either ─ it's needlessly complex in comparison to
grub-legacy and LILO ─ but on a GPT system with BIOS firmware instead of
EFI, there's no alternative that I know of.
Most BIOS computers would not be able to interpret a GPT disk, until
after boot up. Are you using hybrid disks that have a Gnu Partition
Table and a traditional Master Boot Record partition table? It is
supposed to be a nightmare to keep them consistent. Booting from
an MBR disk and then reading a second disk with a GPT is not a
problem.

Are you using an EFI machine in legacy mode? It be would be
able, and maybe willing, to boot from a GPT disk.
Post by Aragorn
There's also an additional complication when compiling grub-legacy on a
64-bit system. For some reason ─ I've known why but I've forgotten ─
grub-legacy must then be compiled statically with a 32-bit compiler, I
believe. This was discussed on the Gentoo mailing list at the time, but
like I said, I've forgotten about the details.
grub-legacy also doesn't support a boot disk of 2 GiB in size, and it
also doesn't support /boot on btrfs or LVM.
Note that for EFI systems, the Linux kernel supports booting without an
external boot loader such as GRUB, i.e. via the in-kernel EFI stub
loader (if compiled in).
--
blind Pete
Sig goes here...
Aragorn
2017-02-19 07:42:32 UTC
Permalink
On Sunday 19 February 2017 01:09, blind Pete conveyed the following to
alt.os.linux.mageia...
Post by blind Pete
Post by Aragorn
On Saturday 18 February 2017 04:15, blind Pete conveyed the following
to alt.os.linux.mageia...
Post by blind Pete
Hard question; will it be sane, or even possible, to use LiLo on
a BIOS system?
LILO is no longer being maintained, but it /should/ still work on MBR
systems. I wouldn't advise it on GPT systems, though.
The biggest problem - that I know about - is that ext4 has been
enhanced since development of LiLo and Legacy Grub ceased.
That was already the case with ext3, and while grub-legacy was still
being developed. Even though I'm not using ext3/ext4 on this machine ─
I'm a fan of the XFS filesystem ─ I am running PCLinuxOS 2014.04 here,
which already features those enhancements, and it's still using grub-
legacy. PCLinuxOS 2016.x uses grub2.

On the other hand, LILO has still been maintained for quite a while
after by the Debian people, who took custody of the project. At present
time, it is no longer under active development, but the userspace tools
to write LILO to the MBR will have been updated to keep track of the
changes to ext3/ext4. For that matter, LILO is still the default boot
loader in Slackware. ;)
Post by blind Pete
Legacy Grub follows the filesystem at boot time, so it is completely
stuffed by newer ext4 filesystems.
No, not quite. grub-legacy does have an ext4 driver, and ext4 only came
out after the changes to ext3 had already been implemented.
Post by blind Pete
LiLo uses block addresses at boot time, so that is OK, but it has to
get those block addresses at configuration time.
Correct.
Post by blind Pete
Can it rely on the OS to get those, or does it need to use its own
code? An older filesystem should be safe.
As I wrote higher up, the userspace tools of LILO have been adapted to
keep the changes to the ext3 filesystem into account.
Post by blind Pete
Post by Aragorn
I don't like grub2 either ─ it's needlessly complex in comparison to
grub-legacy and LILO ─ but on a GPT system with BIOS firmware instead
of EFI, there's no alternative that I know of.
Most BIOS computers would not be able to interpret a GPT disk, until
after boot up.
Well, that is rather irrelevant, really. So long as the BIOS can find a
boot loader in the MBR, the machine will boot, and you can have a GPT-
partitioned disk with a protective MBR.
Post by blind Pete
Are you using hybrid disks that have a Gnu Partition Table [...
Um, GPT stands for GUID Partition Table, and GUID stands for "Global
Unique IDentifier", not for GNU. :p
Post by blind Pete
...] and a traditional Master Boot Record partition table?
Not at present time, no. This here is a refurbished computer with BIOS
firmware, and the hard disk I'm currently using came from a similar
machine that broke down. I've repurposed the existing partitions on it,
and it's still set up with an DOS-style partition table.
Post by blind Pete
It is supposed to be a nightmare to keep them consistent. Booting from
an MBR disk and then reading a second disk with a GPT is not a
problem.
I don't see why it would be a nightmare. Tools like gdisk, parted and
gparted can partition a drive with a GUID partition table and create a
protective MBR.

All you then still need to do in order to use that disk in a non-EFI
machine is create a small partition ─ about 2 MiB should suffice ─ of
the type "BIOS" as the first partition, and you don't need to create any
filesystem on it. This partition will then be used to house the
core.img stage of the GRUB boot loader.
Post by blind Pete
Are you using an EFI machine in legacy mode? It be would be able, and
maybe willing, to boot from a GPT disk.
Nope, no EFI here. EFI in and of itself was a good idea, and a
necessity on non-x86 hardware. But UEFI is a whole different beast.
UEFI has been co-opted by Microsoft and has Microsoftisms all over it,
not to mention that dreaded (and pretty pointless) Secure Boot feature.

As I see it, there isn't anything that UEFI brings to the x86
architecture which couldn't also already be taken care of before by the
Linux kernel itself.

Linux doesn't use the BIOS at runtime, but the real mode bootstrap code
in the on-disk kernel image makes sure that information about the
hardware is read from the BIOS and then copied to a write-protected
location in protected mode memory before the actual runtime kernel ─
which is itself an image within the on-disk kernel image ─ is
decompressed and activated, and from that moment on, the kernel takes
care of initializing and handling all hardware access.

Everybody knows that the only reason why they've pushed UEFI into
adoption was because of the monopolistic strategy of Microsoft. UEFI
has Secure Boot, and Secure Boot forces operating system vendors to buy
a key from Microsoft, which effectively puts Microsoft in charge of what
was up until then a free and open hardware platform.
--
= Aragorn =
Maurice
2017-02-19 13:37:29 UTC
Permalink
... UEFI has Secure Boot, and Secure Boot forces operating system
vendors to buy a key from Microsoft, which effectively puts Microsoft
in charge of what was up until then a free and open hardware
platform.
Which is good reason for keeping well away from computers whose UEFI
settings do not allow Secure Boot to be disabled.
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
blind Pete
2017-02-20 02:03:59 UTC
Permalink
Post by Aragorn
On Sunday 19 February 2017 01:09, blind Pete conveyed the following to
alt.os.linux.mageia...
Post by blind Pete
Post by Aragorn
On Saturday 18 February 2017 04:15, blind Pete conveyed the following
to alt.os.linux.mageia...
Post by blind Pete
Hard question; will it be sane, or even possible, to use LiLo on
a BIOS system?
LILO is no longer being maintained, but it /should/ still work on MBR
systems. I wouldn't advise it on GPT systems, though.
The biggest problem - that I know about - is that ext4 has been
enhanced since development of LiLo and Legacy Grub ceased.
That was already the case with ext3, and while grub-legacy was still
being developed. Even though I'm not using ext3/ext4 on this machine ─
I'm a fan of the XFS filesystem ─ I am running PCLinuxOS 2014.04 here,
which already features those enhancements, and it's still using grub-
legacy. PCLinuxOS 2016.x uses grub2.
On the other hand, LILO has still been maintained for quite a while
after by the Debian people, who took custody of the project. At present
time, it is no longer under active development, but the userspace tools
to write LILO to the MBR will have been updated to keep track of the
changes to ext3/ext4. For that matter, LILO is still the default boot
loader in Slackware. ;)
There are new features in ext4 like "64bit" which will confuse older
kernels and user space programs, even if they run perfectly with
older versions of ext4. Filesystems can be created without it.
e.g. "mke2fs -O ^64bit -t ext4 device"

Unfortunately you can not expect other installations to not use
new features. Your choices are; say "sorry can't do that", or look
for the partition boot record and let the other installation go from
there.

Worse, some features might have been backported to ext3 or even ext2.
All you can do is reopen development of your old boot loader or
format your own boot partition (be that a separate boot partition or
the root partition) without any "new" features.

Maybe I should have a look at Slackware.
Post by Aragorn
Post by blind Pete
Legacy Grub follows the filesystem at boot time, so it is completely
stuffed by newer ext4 filesystems.
No, not quite. grub-legacy does have an ext4 driver, and ext4 only came
out after the changes to ext3 had already been implemented.
Until it runs across an ext4 feature that is newer than its ext4 driver.
Post by Aragorn
Post by blind Pete
LiLo uses block addresses at boot time, so that is OK, but it has to
get those block addresses at configuration time.
Correct.
Post by blind Pete
Can it rely on the OS to get those, or does it need to use its own
code? An older filesystem should be safe.
As I wrote higher up, the userspace tools of LILO have been adapted to
keep the changes to the ext3 filesystem into account.
Post by blind Pete
Post by Aragorn
I don't like grub2 either ─ it's needlessly complex in comparison to
grub-legacy and LILO ─ but on a GPT system with BIOS firmware instead
of EFI, there's no alternative that I know of.
Does a protective MBR get it code cleared? Or could it find a LiLo
map file? It only needs Logical Block Addresses, although the block
size of new disks is greater than that of old disks.
Post by Aragorn
Post by blind Pete
Most BIOS computers would not be able to interpret a GPT disk, until
after boot up.
Well, that is rather irrelevant, really. So long as the BIOS can find a
boot loader in the MBR, the machine will boot, and you can have a GPT-
partitioned disk with a protective MBR.
Post by blind Pete
Are you using hybrid disks that have a Gnu Partition Table [...
Um, GPT stands for GUID Partition Table, and GUID stands for "Global
Unique IDentifier", not for GNU. :p
Post by blind Pete
...] and a traditional Master Boot Record partition table?
Not at present time, no. This here is a refurbished computer with BIOS
firmware, and the hard disk I'm currently using came from a similar
machine that broke down. I've repurposed the existing partitions on it,
and it's still set up with an DOS-style partition table.
Post by blind Pete
It is supposed to be a nightmare to keep them consistent. Booting from
an MBR disk and then reading a second disk with a GPT is not a
problem.
I don't see why it would be a nightmare. Tools like gdisk, parted and
gparted can partition a drive with a GUID partition table and create a
protective MBR.
I was thinking of real partition information in the MBR, which must
be consistent with the GPT, rather than a protective MBR.
Post by Aragorn
All you then still need to do in order to use that disk in a non-EFI
machine is create a small partition ─ about 2 MiB should suffice ─ of
the type "BIOS" as the first partition, and you don't need to create any
filesystem on it. This partition will then be used to house the
core.img stage of the GRUB boot loader.
That should work, but I don't know where you would put Partition
Boot Records if you wanted to chain boot loaders. Perhaps
multiple "BIOS" partitions?
Post by Aragorn
Post by blind Pete
Are you using an EFI machine in legacy mode? It be would be able, and
maybe willing, to boot from a GPT disk.
Nope, no EFI here. EFI in and of itself was a good idea, and a
necessity on non-x86 hardware. But UEFI is a whole different beast.
UEFI has been co-opted by Microsoft and has Microsoftisms all over it,
not to mention that dreaded (and pretty pointless) Secure Boot feature.
As I see it, there isn't anything that UEFI brings to the x86
architecture which couldn't also already be taken care of before by the
Linux kernel itself.
Linux doesn't use the BIOS at runtime, but the real mode bootstrap code
in the on-disk kernel image makes sure that information about the
hardware is read from the BIOS and then copied to a write-protected
location in protected mode memory before the actual runtime kernel ─
which is itself an image within the on-disk kernel image ─ is
decompressed and activated, and from that moment on, the kernel takes
care of initializing and handling all hardware access.
Everybody knows that the only reason why they've pushed UEFI into
adoption was because of the monopolistic strategy of Microsoft. UEFI
has Secure Boot, and Secure Boot forces operating system vendors to buy
a key from Microsoft, which effectively puts Microsoft in charge of what
was up until then a free and open hardware platform.
That is probably the result, but the stated intent was a last ditch
attempt to run a trusted OS (even if it was only trusted by Bill Gates)
on untrusted hardware. Try to build a computer that could not have been
"enhanced" by some non-obvious gift from a hardware manufacturer on the
other side of the world.
--
blind Pete
Sig goes here...
Aragorn
2017-02-20 04:47:35 UTC
Permalink
On Monday 20 February 2017 03:03, blind Pete conveyed the following to
alt.os.linux.mageia...
Post by blind Pete
Post by Aragorn
On Sunday 19 February 2017 01:09, blind Pete conveyed the following
to alt.os.linux.mageia...
Post by blind Pete
The biggest problem - that I know about - is that ext4 has been
enhanced since development of LiLo and Legacy Grub ceased.
That was already the case with ext3, and while grub-legacy was still
being developed. Even though I'm not using ext3/ext4 on this machine
─ I'm a fan of the XFS filesystem ─ I am running PCLinuxOS 2014.04
here, which already features those enhancements, and it's still using
grub-legacy. PCLinuxOS 2016.x uses grub2.
On the other hand, LILO has still been maintained for quite a while
after by the Debian people, who took custody of the project. At
present time, it is no longer under active development, but the
userspace tools to write LILO to the MBR will have been updated to
keep track of the changes to ext3/ext4. For that matter, LILO is
still the default boot loader in Slackware. ;)
There are new features in ext4 like "64bit" which will confuse older
kernels and user space programs, even if they run perfectly with
older versions of ext4. Filesystems can be created without it.
e.g. "mke2fs -O ^64bit -t ext4 device"
Well, one should always check for what's supported, of course.
Officially, grub-legacy is deprecated and no longer supported. grub2 is
the recommended approach now.
Post by blind Pete
Post by Aragorn
Post by blind Pete
Legacy Grub follows the filesystem at boot time, so it is completely
stuffed by newer ext4 filesystems.
No, not quite. grub-legacy does have an ext4 driver, and ext4 only
came out after the changes to ext3 had already been implemented.
Until it runs across an ext4 feature that is newer than its ext4 driver.
Well, grub-legacy is at least still supported by the ext4 driver up
until kernel 3.18, because that's the one I'm running here in PCLinuxOS
2014.04, and I'm still using grub-legacy.

Mind you, I'm not using ext4 ─ I'm using XFS all across the board on
this machine ─ but I only have that kernel version to compare with,
given that grub-legacy was still the default in this distro.
Post by blind Pete
Does a protective MBR get it code cleared? Or could it find a LiLo
map file? It only needs Logical Block Addresses, although the block
size of new disks is greater than that of old disks.
Um, I'm afraid I don't understand what you're getting at. A protective
MBR is simply an MBR-style partition entry which marks the whole hard
disk as having a single primary partition.

The LILO map file resides in /boot, and when running /sbin/lilo, the
logical block offset to this file is written into the MBR. The second
stage of LILO takes it from there.
Post by blind Pete
Post by Aragorn
Post by blind Pete
Are you using hybrid disks that have a Gnu Partition Table [...
Um, GPT stands for GUID Partition Table, and GUID stands for "Global
Unique IDentifier", not for GNU. :p
Post by blind Pete
...] and a traditional Master Boot Record partition table?
Not at present time, no. This here is a refurbished computer with
BIOS firmware, and the hard disk I'm currently using came from a
similar machine that broke down. I've repurposed the existing
partitions on it, and it's still set up with an DOS-style partition
table.
Post by blind Pete
It is supposed to be a nightmare to keep them consistent. Booting
from an MBR disk and then reading a second disk with a GPT is not a
problem.
I don't see why it would be a nightmare. Tools like gdisk, parted
and gparted can partition a drive with a GUID partition table and
create a protective MBR.
I was thinking of real partition information in the MBR, which must
be consistent with the GPT, rather than a protective MBR.
Ah yes, I see what you mean now. Well, I don't see any need for such a
hybrid partitioning, given that I don't use Microsoft Windows.

Either way, all computers I currently have here have BIOS firmware, not
UEFI, and if I ever do buy an UEFI machine, then I'll probably have it
boot up in legacy mode, but with a GPT layout.
Post by blind Pete
Post by Aragorn
All you then still need to do in order to use that disk in a non-EFI
machine is create a small partition ─ about 2 MiB should suffice ─ of
the type "BIOS" as the first partition, and you don't need to create
any filesystem on it. This partition will then be used to house the
core.img stage of the GRUB boot loader.
That should work, but I don't know where you would put Partition
Boot Records if you wanted to chain boot loaders. Perhaps
multiple "BIOS" partitions?
Well no, there is no need for that. That "type BIOS" partition is only
there as a placeholder for the core.img of GRUB on a GPT disk, so that
it wouldn't overwrite the boot sectors or any individual partitions.

When installing GRUB to a _partition_ boot sector, GRUB does not require
an intermediate "stage 1.5".
Post by blind Pete
Post by Aragorn
Everybody knows that the only reason why they've pushed UEFI into
adoption was because of the monopolistic strategy of Microsoft. UEFI
has Secure Boot, and Secure Boot forces operating system vendors to
buy a key from Microsoft, which effectively puts Microsoft in charge
of what was up until then a free and open hardware platform.
That is probably the result, but the stated intent was a last ditch
attempt to run a trusted OS (even if it was only trusted by Bill
Gates) on untrusted hardware.
More often than not, stated intents and actual intents differ
significantly in scope.

Microsoft's stated intent was only a smokescreen. And they knew that
everybody else knew as well. They just didn't want to admit it. ;)

--
TJ
2017-02-20 14:27:13 UTC
Permalink
Post by Aragorn
Well, grub-legacy is at least still supported by the ext4 driver up
until kernel 3.18, because that's the one I'm running here in PCLinuxOS
2014.04, and I'm still using grub-legacy.
That's a pretty old kernel. I can't help but wonder how many unpatched
security holes it has, how many types of newer hardware it fails to support.

The Mageia 5 maintainers are looking to update soon to kernel 4.4.49 or
perhaps a higher 4.4. It supports booting with grub-legacy on MBR
systems, last time I checked. (I switched to grub2 when I started
testing Cauldron.) It does not support EFI or GPT, as far as I know.

Cauldron just updated to 4.9.11 a couple of days ago. I haven't checked
yet today, but as fast as they've been coming there may be another
waiting for me in Cauldron Updates now. I've been informed that Cauldron
requires grub2 on all systems, but I don't have the knowledge to debate
the point intelligently.

Both of those kernels almost have to be safer and more capable than the
3.18 you're using. Many Linux users consider the 4.4 kernel outdated,
let alone 3.18.

TJ
Aragorn
2017-02-20 15:16:14 UTC
Permalink
On Monday 20 February 2017 15:27, TJ conveyed the following to
alt.os.linux.mageia...
Post by TJ
Post by Aragorn
Well, grub-legacy is at least still supported by the ext4 driver up
until kernel 3.18, because that's the one I'm running here in
PCLinuxOS 2014.04, and I'm still using grub-legacy.
That's a pretty old kernel. I can't help but wonder how many unpatched
security holes it has, how many types of newer hardware it fails to support.
The hardware support is irrelevant, given that this is a refurbished
machine, and everything in it is supported by the current kernel.

The security holes are another issue, but if everyone were to secure
their systems the way I do, then the attack vector suddenly becomes a
lot smaller. ;)

This PCLinuxOS installation dates back to December 2016. Before that, I
was still running Mageia 1 with a 2.6 kernel on hardware of the same
generation as this machine.

There are more recent kernels in the repository, but I haven't had a
chance to test them yet. I don't want to introduce any breakage due to
some incompatibility between the kernel and something like glibc.

Other than that, the system is fully patched, though. ;)
--
= Aragorn =
blind Pete
2017-02-23 06:24:12 UTC
Permalink
Post by Aragorn
On Monday 20 February 2017 03:03, blind Pete conveyed the following to
alt.os.linux.mageia...
Post by blind Pete
Post by Aragorn
On Sunday 19 February 2017 01:09, blind Pete conveyed the following
to alt.os.linux.mageia...
Post by blind Pete
The biggest problem - that I know about - is that ext4 has been
enhanced since development of LiLo and Legacy Grub ceased.
That was already the case with ext3, and while grub-legacy was still
being developed. Even though I'm not using ext3/ext4 on this machine
─ I'm a fan of the XFS filesystem ─ I am running PCLinuxOS 2014.04
here, which already features those enhancements, and it's still using
grub-legacy. PCLinuxOS 2016.x uses grub2.
According to the release notes for the upcoming Mageia 6
<https://wiki.mageia.org/en/Mageia_6_Release_Notes>
grub legacy does not support ext4 file systems formatted with
e2fsprogs 1.43 or XFS V5 format.
Post by Aragorn
Post by blind Pete
Post by Aragorn
On the other hand, LILO has still been maintained for quite a while
after by the Debian people, who took custody of the project. At
present time, it is no longer under active development, but the
userspace tools to write LILO to the MBR will have been updated to
keep track of the changes to ext3/ext4. For that matter, LILO is
still the default boot loader in Slackware. ;)
There are new features in ext4 like "64bit" which will confuse older
kernels and user space programs, even if they run perfectly with
older versions of ext4. Filesystems can be created without it.
e.g. "mke2fs -O ^64bit -t ext4 device"
Well, one should always check for what's supported, of course.
Officially, grub-legacy is deprecated and no longer supported. grub2 is
the recommended approach now.
And when you want to boot an OS that is already installed on a
filesystem that is newer than anything that your boot loader
knows about, what do you do? Print a polite error message and
go away?
Post by Aragorn
Post by blind Pete
Post by Aragorn
Post by blind Pete
Legacy Grub follows the filesystem at boot time, so it is completely
stuffed by newer ext4 filesystems.
No, not quite. grub-legacy does have an ext4 driver, and ext4 only
came out after the changes to ext3 had already been implemented.
Until it runs across an ext4 feature that is newer than its ext4 driver.
Well, grub-legacy is at least still supported by the ext4 driver up
until kernel 3.18, because that's the one I'm running here in PCLinuxOS
2014.04, and I'm still using grub-legacy.
Mind you, I'm not using ext4 ─ I'm using XFS all across the board on
this machine ─ but I only have that kernel version to compare with,
given that grub-legacy was still the default in this distro.
Post by blind Pete
Does a protective MBR get it code cleared? Or could it find a LiLo
map file? It only needs Logical Block Addresses, although the block
size of new disks is greater than that of old disks.
Um, I'm afraid I don't understand what you're getting at. A protective
MBR is simply an MBR-style partition entry which marks the whole hard
disk as having a single primary partition.
The tiny amount of space before the partition table of sector zero
is still available for code?
Post by Aragorn
The LILO map file resides in /boot, and when running /sbin/lilo, the
logical block offset to this file is written into the MBR. The second
stage of LILO takes it from there.
That is normal, but other arrangements are possible.

I have a 5 MB partition with a lilo.conf, a message.txt, and a map
file on it. All it is for it jump to various partition boot records,
where each of those jumps to an installation's map file on that
installation's /boot, which then loads that installation's initrd.img.
Each installation's /etc/lilo.conf has a line like, "boot = /dev/sda6",
but other weird things are possible.

Traditional hard disk layouts have a "spare" sector between partitions,
for the partition boot record, but GPT layouts allow the partitions
to be hard up against each other, and if there is a gap the trim
function might make use of it.

The other problem with LiLo is that modern filesystem house keeping
functions can silently move files. Even an old defrag will change
the sector numbers that need to be in the map file to make it all
work. So, all of your boot files want to be on a "quiet" partition.
There is no way to lock the position of files - that I know of -
hence the desirability of the old rescue boot floppy.
Post by Aragorn
Post by blind Pete
Post by Aragorn
Post by blind Pete
Are you using hybrid disks that have a Gnu Partition Table [...
Um, GPT stands for GUID Partition Table, and GUID stands for "Global
Unique IDentifier", not for GNU. :p
That would be a much more marketable term in Redmond.
Post by Aragorn
Post by blind Pete
Post by Aragorn
Post by blind Pete
...] and a traditional Master Boot Record partition table?
Not at present time, no. This here is a refurbished computer with
BIOS firmware, and the hard disk I'm currently using came from a
similar machine that broke down. I've repurposed the existing
partitions on it, and it's still set up with an DOS-style partition
table.
Post by blind Pete
It is supposed to be a nightmare to keep them consistent. Booting
from an MBR disk and then reading a second disk with a GPT is not a
problem.
I don't see why it would be a nightmare. Tools like gdisk, parted
and gparted can partition a drive with a GUID partition table and
create a protective MBR.
I was thinking of real partition information in the MBR, which must
be consistent with the GPT, rather than a protective MBR.
Ah yes, I see what you mean now. Well, I don't see any need for such a
hybrid partitioning, given that I don't use Microsoft Windows.
Either way, all computers I currently have here have BIOS firmware, not
UEFI, and if I ever do buy an UEFI machine, then I'll probably have it
boot up in legacy mode, but with a GPT layout.
Post by blind Pete
Post by Aragorn
All you then still need to do in order to use that disk in a non-EFI
machine is create a small partition ─ about 2 MiB should suffice ─ of
the type "BIOS" as the first partition, and you don't need to create
any filesystem on it. This partition will then be used to house the
core.img stage of the GRUB boot loader.
That should work, but I don't know where you would put Partition
Boot Records if you wanted to chain boot loaders. Perhaps
multiple "BIOS" partitions?
Well no, there is no need for that. That "type BIOS" partition is only
there as a placeholder for the core.img of GRUB on a GPT disk, so that
it wouldn't overwrite the boot sectors or any individual partitions.
There are no PBRs on a GPT disk. Perhaps if you had a single sector
partition without a filesystem on it immediately before, say, /dev/sda6
then telling LiLo to write to sda6's PBR might do what I want. Then
again, it might just refuse because it's a stupid thing to do.

The grub developers have tried very hard to put critical files out
of the reach of idiots, preferring a BIOS partition over files in
/boot. But they forgot that there is nowhere that you can hide stuff
that is out of reach of a determined idiot. As for an idiot with
the root password or a live CD, I don't know why they bothered.
Post by Aragorn
When installing GRUB to a _partition_ boot sector, GRUB does not require
an intermediate "stage 1.5".
Are you using just the one boot loader, GRUB legacy, for all of your
OSes?
Post by Aragorn
Post by blind Pete
Post by Aragorn
Everybody knows that the only reason why they've pushed UEFI into
adoption was because of the monopolistic strategy of Microsoft. UEFI
has Secure Boot, and Secure Boot forces operating system vendors to
buy a key from Microsoft, which effectively puts Microsoft in charge
of what was up until then a free and open hardware platform.
That is probably the result, but the stated intent was a last ditch
attempt to run a trusted OS (even if it was only trusted by Bill
Gates) on untrusted hardware.
More often than not, stated intents and actual intents differ
significantly in scope.
Microsoft's stated intent was only a smokescreen. And they knew that
everybody else knew as well. They just didn't want to admit it. ;)
--
blind Pete
Sig goes here...
Aragorn
2017-02-23 07:46:51 UTC
Permalink
On Thursday 23 February 2017 07:24, blind Pete conveyed the following to
alt.os.linux.mageia...
Post by blind Pete
Post by Aragorn
On Monday 20 February 2017 03:03, blind Pete conveyed the following
to alt.os.linux.mageia...
Post by blind Pete
Post by Aragorn
On Sunday 19 February 2017 01:09, blind Pete conveyed the following
to alt.os.linux.mageia...
Post by blind Pete
The biggest problem - that I know about - is that ext4 has been
enhanced since development of LiLo and Legacy Grub ceased.
That was already the case with ext3, and while grub-legacy was
still being developed. Even though I'm not using ext3/ext4 on this
machine ─ I'm a fan of the XFS filesystem ─ I am running PCLinuxOS
2014.04 here, which already features those enhancements, and it's
still using grub-legacy. PCLinuxOS 2016.x uses grub2.
According to the release notes for the upcoming Mageia 6
<https://wiki.mageia.org/en/Mageia_6_Release_Notes>
grub legacy does not support ext4 file systems formatted with
e2fsprogs 1.43 or XFS V5 format.
Well, I guess that this is still the old XFS format then, because I use
XFS for all of my partitions. Well, minus swap, of course. ;)
Post by blind Pete
Post by Aragorn
Post by blind Pete
Post by Aragorn
On the other hand, LILO has still been maintained for quite a while
after by the Debian people, who took custody of the project. At
present time, it is no longer under active development, but the
userspace tools to write LILO to the MBR will have been updated to
keep track of the changes to ext3/ext4. For that matter, LILO is
still the default boot loader in Slackware. ;)
There are new features in ext4 like "64bit" which will confuse older
kernels and user space programs, even if they run perfectly with
older versions of ext4. Filesystems can be created without it.
e.g. "mke2fs -O ^64bit -t ext4 device"
Well, one should always check for what's supported, of course.
Officially, grub-legacy is deprecated and no longer supported. grub2
is the recommended approach now.
And when you want to boot an OS that is already installed on a
filesystem that is newer than anything that your boot loader
knows about, what do you do? Print a polite error message and
go away?
It would be pretty silly to create such a setup in the first place,
wouldn't it? ;)
Post by blind Pete
Post by Aragorn
Post by blind Pete
Does a protective MBR get it code cleared? Or could it find a LiLo
map file? It only needs Logical Block Addresses, although the block
size of new disks is greater than that of old disks.
Um, I'm afraid I don't understand what you're getting at. A
protective MBR is simply an MBR-style partition entry which marks the
whole hard disk as having a single primary partition.
The tiny amount of space before the partition table of sector zero
is still available for code?
Yes, it is.
Post by blind Pete
[...]
The other problem with LiLo is that modern filesystem house keeping
functions can silently move files. Even an old defrag will change
the sector numbers that need to be in the map file to make it all
work. So, all of your boot files want to be on a "quiet" partition.
Of course. LILO does not support large hard disks over 2 TiB either ─
it has the same limitations in that regard as grub-legacy ─ so it is
always advisable to have a separate /boot partition.
Post by blind Pete
There is no way to lock the position of files - that I know of -
hence the desirability of the old rescue boot floppy.
A read-only filesystem wouldn't be subjected to file relocation. I
always have /boot mounted read-only, unless I'm installing a new kernel.
And then I remount it read-only again afterwards. ;)
Post by blind Pete
Post by Aragorn
Post by blind Pete
Post by Aragorn
Post by blind Pete
Are you using hybrid disks that have a Gnu Partition Table [...
Um, GPT stands for GUID Partition Table, and GUID stands for
"Global Unique IDentifier", not for GNU. :p
That would be a much more marketable term in Redmond.
Well, other partitioning formats have already long existed before MS-DOS
came along, and the Intel-based Macintosh uses an EFI, just as has
already long been the case on Intel Itanium and RISC-based machines.

The successor to EFI ─ and specifically intended for x86-64 ─ is UEFI,
but the problem there is that Microsoft is a very influential member of
the UEFI committee. By consequence, a lot of Microsoftisms have crept
into the UEFI specifications.

For instance, the UEFI normally has a built-in command line, but the
syntax of this command line, its volume-oriented approach to storage and
its use of a backslash as a directory separator, are all taken straight
out of Microsoft Windows.

So yes, UEFI has been usurped by Microsoft, and therefore the partition
table format will also have a typical "Microsoftized" name. ;)
Post by blind Pete
The grub developers have tried very hard to put critical files out
of the reach of idiots, preferring a BIOS partition over files in
/boot. But they forgot that there is nowhere that you can hide stuff
that is out of reach of a determined idiot. As for an idiot with
the root password or a live CD, I don't know why they bothered.
IDIOT, n.:

A member of a large tribe whose influences in the affairs of
mankind have always been domineering.

(Ambrose Bierce - "The Devil's Dictionary")

:p
Post by blind Pete
Post by Aragorn
When installing GRUB to a _partition_ boot sector, GRUB does not
require an intermediate "stage 1.5".
Are you using just the one boot loader, GRUB legacy, for all of your
OSes?
I use whatever is the default choice, but I only have one OS per
computer anyway. I don't do multi-boot, and I don't do Microsoft
Windows. ;)

So far, the only boot loaders I've ever had on my computers have been
LILO and grub-legacy. I haven't had any first-hand experience with
grub2 yet.
--
= Aragorn =
blind Pete
2017-02-24 05:15:19 UTC
Permalink
Post by Aragorn
On Thursday 23 February 2017 07:24, blind Pete conveyed the following to
alt.os.linux.mageia...
Post by blind Pete
Post by Aragorn
On Monday 20 February 2017 03:03, blind Pete conveyed the following
to alt.os.linux.mageia...
Post by blind Pete
Post by Aragorn
On Sunday 19 February 2017 01:09, blind Pete conveyed the following
to alt.os.linux.mageia...
Post by blind Pete
The biggest problem - that I know about - is that ext4 has been
enhanced since development of LiLo and Legacy Grub ceased.
That was already the case with ext3, and while grub-legacy was
still being developed. Even though I'm not using ext3/ext4 on this
machine ─ I'm a fan of the XFS filesystem ─ I am running PCLinuxOS
2014.04 here, which already features those enhancements, and it's
still using grub-legacy. PCLinuxOS 2016.x uses grub2.
According to the release notes for the upcoming Mageia 6
<https://wiki.mageia.org/en/Mageia_6_Release_Notes>
grub legacy does not support ext4 file systems formatted with
e2fsprogs 1.43 or XFS V5 format.
Well, I guess that this is still the old XFS format then, because I use
XFS for all of my partitions. Well, minus swap, of course. ;)
Post by blind Pete
Post by Aragorn
Post by blind Pete
Post by Aragorn
On the other hand, LILO has still been maintained for quite a while
after by the Debian people, who took custody of the project. At
present time, it is no longer under active development, but the
userspace tools to write LILO to the MBR will have been updated to
keep track of the changes to ext3/ext4. For that matter, LILO is
still the default boot loader in Slackware. ;)
There are new features in ext4 like "64bit" which will confuse older
kernels and user space programs, even if they run perfectly with
older versions of ext4. Filesystems can be created without it.
e.g. "mke2fs -O ^64bit -t ext4 device"
Well, one should always check for what's supported, of course.
Officially, grub-legacy is deprecated and no longer supported. grub2
is the recommended approach now.
And when you want to boot an OS that is already installed on a
filesystem that is newer than anything that your boot loader
knows about, what do you do? Print a polite error message and
go away?
It would be pretty silly to create such a setup in the first place,
wouldn't it? ;)
Yes, but most installers behave as if their OS is in charge of
everything - if not the only OS. Then, quite reasonably, they know
that if the new installation is going to be bootable then somebody
will have to write something to the MBR - so they do it. The
annoyance comes if there are other installations already there that
the new one does not know how to deal with.
Post by Aragorn
Post by blind Pete
Post by Aragorn
Post by blind Pete
Does a protective MBR get it code cleared? Or could it find a LiLo
map file? It only needs Logical Block Addresses, although the block
size of new disks is greater than that of old disks.
Um, I'm afraid I don't understand what you're getting at. A
protective MBR is simply an MBR-style partition entry which marks the
whole hard disk as having a single primary partition.
The tiny amount of space before the partition table of sector zero
is still available for code?
Yes, it is.
Post by blind Pete
[...]
The other problem with LiLo is that modern filesystem house keeping
functions can silently move files. Even an old defrag will change
the sector numbers that need to be in the map file to make it all
work. So, all of your boot files want to be on a "quiet" partition.
Of course. LILO does not support large hard disks over 2 TiB either ─
it has the same limitations in that regard as grub-legacy ─ so it is
always advisable to have a separate /boot partition.
Post by blind Pete
There is no way to lock the position of files - that I know of -
hence the desirability of the old rescue boot floppy.
A read-only filesystem wouldn't be subjected to file relocation. I
always have /boot mounted read-only, unless I'm installing a new kernel.
And then I remount it read-only again afterwards. ;)
Ah yes, mount it read only. Do you even have to mount /boot at all
during normal operation? The EFI boot partition is often not mounted
on UEFI machines and my first LiLo map file is on a partition that is
usually not mounted.
Post by Aragorn
Post by blind Pete
Post by Aragorn
Post by blind Pete
Post by Aragorn
Post by blind Pete
Are you using hybrid disks that have a Gnu Partition Table [...
Um, GPT stands for GUID Partition Table, and GUID stands for
"Global Unique IDentifier", not for GNU. :p
That would be a much more marketable term in Redmond.
Well, other partitioning formats have already long existed before MS-DOS
came along, and the Intel-based Macintosh uses an EFI, just as has
already long been the case on Intel Itanium and RISC-based machines.
The successor to EFI ─ and specifically intended for x86-64 ─ is UEFI,
but the problem there is that Microsoft is a very influential member of
the UEFI committee. By consequence, a lot of Microsoftisms have crept
into the UEFI specifications.
For instance, the UEFI normally has a built-in command line, but the
syntax of this command line, its volume-oriented approach to storage and
its use of a backslash as a directory separator, are all taken straight
out of Microsoft Windows.
So yes, UEFI has been usurped by Microsoft, and therefore the partition
table format will also have a typical "Microsoftized" name. ;)
Post by blind Pete
The grub developers have tried very hard to put critical files out
of the reach of idiots, preferring a BIOS partition over files in
/boot. But they forgot that there is nowhere that you can hide stuff
that is out of reach of a determined idiot. As for an idiot with
the root password or a live CD, I don't know why they bothered.
A member of a large tribe whose influences in the affairs of
mankind have always been domineering.
(Ambrose Bierce - "The Devil's Dictionary")
:p
Post by blind Pete
Post by Aragorn
When installing GRUB to a _partition_ boot sector, GRUB does not
require an intermediate "stage 1.5".
Are you using just the one boot loader, GRUB legacy, for all of your
OSes?
I use whatever is the default choice, but I only have one OS per
computer anyway. I don't do multi-boot, and I don't do Microsoft
Windows. ;)
Nice and simple. The occasional virtual machine for test installations?
If you can put your hand on a rescue CD one OS per machine is good.
Post by Aragorn
So far, the only boot loaders I've ever had on my computers have been
LILO and grub-legacy. I haven't had any first-hand experience with
grub2 yet.
With just one OS it will probably work without any trouble.
--
blind Pete
Sig goes here...
Aragorn
2017-02-24 07:01:44 UTC
Permalink
On Friday 24 February 2017 06:15, blind Pete conveyed the following to
alt.os.linux.mageia...
Post by blind Pete
Post by Aragorn
On Thursday 23 February 2017 07:24, blind Pete conveyed the following
to alt.os.linux.mageia...
Post by blind Pete
And when you want to boot an OS that is already installed on a
filesystem that is newer than anything that your boot loader
knows about, what do you do? Print a polite error message and
go away?
It would be pretty silly to create such a setup in the first place,
wouldn't it? ;)
Yes, but most installers behave as if their OS is in charge of
everything - if not the only OS. Then, quite reasonably, they know
that if the new installation is going to be bootable then somebody
will have to write something to the MBR - so they do it. The
annoyance comes if there are other installations already there that
the new one does not know how to deal with.
Well, in that case, the new OS will usually also attempt to supplant the
existing boot loader with its own boot loader, so then the problem is
solved. :)
Post by blind Pete
Post by Aragorn
A read-only filesystem wouldn't be subjected to file relocation. I
always have /boot mounted read-only, unless I'm installing a new
kernel. And then I remount it read-only again afterwards. ;)
Ah yes, mount it read only. Do you even have to mount /boot at all
during normal operation?
No, not at all. In fact, it has already long been somewhat of a
cultural tradition among Gentoo users to not have /boot mounted at all,
unless they're installing a new kernel. :)
Post by blind Pete
The EFI boot partition is often not mounted on UEFI machines and my
first LiLo map file is on a partition that is usually not mounted.
Yes, the EFI boot partition is also not required during normal system
operation, so it can safely be left unmounted ─ unless you're going to
do maintenance on it, of course.
Post by blind Pete
Post by Aragorn
Post by blind Pete
Post by Aragorn
When installing GRUB to a _partition_ boot sector, GRUB does not
require an intermediate "stage 1.5".
Are you using just the one boot loader, GRUB legacy, for all of your
OSes?
I use whatever is the default choice, but I only have one OS per
computer anyway. I don't do multi-boot, and I don't do Microsoft
Windows. ;)
Nice and simple. The occasional virtual machine for test
installations?
Not even that. Just the occasional live CD/DVD session for testing, and
I'm also a firm believer in "If it ain't broke, don't fix it."

So I will check out other distributions via their live media, but even
if I like them, I will not necessarily decide to install them in the
place of the distribution I've already got on my hard disk, unless I'd
have a compelling reason.

But that kind of scenario doesn't normally occur, because I am very
conscientious about the distribution I choose for installation. And at
present time, with this machine here being a refurbished PC that I
bought for 150 Euro after my previous machine had died, and with Mageia
having succumbed to the systemd Borg, I chose PCLinuxOS for this
installation. I had had very good experiences with PCLinuxOS in the
past, and it's still free of systemd. ;)

One thing I should also mention is that PCLinuxOS also does a fantastic
job at tuning the permissions. In my old (and yet fully updated) Mageia
installation, there were several security escalations that I had to work
around ─ probably all dbus-related ─ but PCLinuxOS seems immune to those
flaws.

If I had to use a single word to describe PCLinuxOS as a distribution,
then I would say "dependable". Not perfect ─ there are a few bugs still
here and there, and possibly some sloppiness ─ but definitely
dependable.
Post by blind Pete
If you can put your hand on a rescue CD one OS per machine is good.
I always keep several live CD/DVD media around, just in case. ;)

--
blind Pete
2017-02-27 03:38:50 UTC
Permalink
Post by Aragorn
On Friday 24 February 2017 06:15, blind Pete conveyed the following to
alt.os.linux.mageia...
Post by blind Pete
Post by Aragorn
On Thursday 23 February 2017 07:24, blind Pete conveyed the following
to alt.os.linux.mageia...
We are a bit off topic, but I think that this train of thought
is nearly done.
Post by Aragorn
Post by blind Pete
Post by Aragorn
Post by blind Pete
And when you want to boot an OS that is already installed on a
filesystem that is newer than anything that your boot loader
knows about, what do you do? Print a polite error message and
go away?
It would be pretty silly to create such a setup in the first place,
wouldn't it? ;)
Yes, but most installers behave as if their OS is in charge of
everything - if not the only OS. Then, quite reasonably, they know
that if the new installation is going to be bootable then somebody
will have to write something to the MBR - so they do it. The
annoyance comes if there are other installations already there that
the new one does not know how to deal with.
Well, in that case, the new OS will usually also attempt to supplant the
existing boot loader with its own boot loader, so then the problem is
solved. :)
No. When the first OSes boot loader can't handle the second OS, and
the second OSes boot loader can't handle the third OS, and the third
OSes boot loader can't handle the first OS, problem created.
Post by Aragorn
Post by blind Pete
Post by Aragorn
A read-only filesystem wouldn't be subjected to file relocation. I
always have /boot mounted read-only, unless I'm installing a new
kernel. And then I remount it read-only again afterwards. ;)
Ah yes, mount it read only. Do you even have to mount /boot at all
during normal operation?
No, not at all. In fact, it has already long been somewhat of a
cultural tradition among Gentoo users to not have /boot mounted at all,
unless they're installing a new kernel. :)
[snip]

I might do that in future, but to do it properly I'd have to find the
kernel upgrade script and modify it to mount /boot.
--
blind Pete
Sig goes here...
William Unruh
2017-02-27 09:14:36 UTC
Permalink
Post by blind Pete
Post by Aragorn
On Friday 24 February 2017 06:15, blind Pete conveyed the following to
alt.os.linux.mageia...
Post by blind Pete
Post by Aragorn
On Thursday 23 February 2017 07:24, blind Pete conveyed the following
to alt.os.linux.mageia...
We are a bit off topic, but I think that this train of thought
is nearly done.
Post by Aragorn
Post by blind Pete
Post by Aragorn
Post by blind Pete
And when you want to boot an OS that is already installed on a
filesystem that is newer than anything that your boot loader
knows about, what do you do? Print a polite error message and
go away?
It would be pretty silly to create such a setup in the first place,
wouldn't it? ;)
Yes, but most installers behave as if their OS is in charge of
everything - if not the only OS. Then, quite reasonably, they know
that if the new installation is going to be bootable then somebody
will have to write something to the MBR - so they do it. The
annoyance comes if there are other installations already there that
the new one does not know how to deal with.
Well, in that case, the new OS will usually also attempt to supplant the
existing boot loader with its own boot loader, so then the problem is
solved. :)
No. When the first OSes boot loader can't handle the second OS, and
the second OSes boot loader can't handle the third OS, and the third
OSes boot loader can't handle the first OS, problem created.
Post by Aragorn
Post by blind Pete
Post by Aragorn
A read-only filesystem wouldn't be subjected to file relocation. I
always have /boot mounted read-only, unless I'm installing a new
kernel. And then I remount it read-only again afterwards. ;)
Ah yes, mount it read only. Do you even have to mount /boot at all
during normal operation?
No, not at all. In fact, it has already long been somewhat of a
cultural tradition among Gentoo users to not have /boot mounted at all,
unless they're installing a new kernel. :)
[snip]
I might do that in future, but to do it properly I'd have to find the
kernel upgrade script and modify it to mount /boot.
Or, when you want to update the kernel, mount /boot first.
Bobbie Sellers
2017-12-15 20:46:18 UTC
Permalink
Post by blind Pete
Post by Aragorn
On Thursday 23 February 2017 07:24, blind Pete conveyed the following to
alt.os.linux.mageia...
Post by blind Pete
Post by Aragorn
On Monday 20 February 2017 03:03, blind Pete conveyed the following
to alt.os.linux.mageia...
Post by blind Pete
Post by Aragorn
On Sunday 19 February 2017 01:09, blind Pete conveyed the following
to alt.os.linux.mageia...
Post by blind Pete
The biggest problem - that I know about - is that ext4 has been
enhanced since development of LiLo and Legacy Grub ceased.
That was already the case with ext3, and while grub-legacy was
still being developed. Even though I'm not using ext3/ext4 on this
machine ─ I'm a fan of the XFS filesystem ─ I am running PCLinuxOS
2014.04 here, which already features those enhancements, and it's
still using grub-legacy. PCLinuxOS 2016.x uses grub2.
According to the release notes for the upcoming Mageia 6
<https://wiki.mageia.org/en/Mageia_6_Release_Notes>
grub legacy does not support ext4 file systems formatted with
e2fsprogs 1.43 or XFS V5 format.
Well, I guess that this is still the old XFS format then, because I use
XFS for all of my partitions. Well, minus swap, of course. ;)
Post by blind Pete
Post by Aragorn
Post by blind Pete
Post by Aragorn
On the other hand, LILO has still been maintained for quite a while
after by the Debian people, who took custody of the project. At
present time, it is no longer under active development, but the
userspace tools to write LILO to the MBR will have been updated to
keep track of the changes to ext3/ext4. For that matter, LILO is
still the default boot loader in Slackware. ;)
There are new features in ext4 like "64bit" which will confuse older
kernels and user space programs, even if they run perfectly with
older versions of ext4. Filesystems can be created without it.
e.g. "mke2fs -O ^64bit -t ext4 device"
Well, one should always check for what's supported, of course.
Officially, grub-legacy is deprecated and no longer supported. grub2
is the recommended approach now.
And when you want to boot an OS that is already installed on a
filesystem that is newer than anything that your boot loader
knows about, what do you do? Print a polite error message and
go away?
It would be pretty silly to create such a setup in the first place,
wouldn't it? ;)
Yes, but most installers behave as if their OS is in charge of
everything - if not the only OS. Then, quite reasonably, they know
that if the new installation is going to be bootable then somebody
will have to write something to the MBR - so they do it. The
annoyance comes if there are other installations already there that
the new one does not know how to deal with.
Post by Aragorn
Post by blind Pete
Post by Aragorn
Post by blind Pete
Does a protective MBR get it code cleared? Or could it find a LiLo
map file? It only needs Logical Block Addresses, although the block
size of new disks is greater than that of old disks.
Um, I'm afraid I don't understand what you're getting at. A
protective MBR is simply an MBR-style partition entry which marks the
whole hard disk as having a single primary partition.
The tiny amount of space before the partition table of sector zero
is still available for code?
Yes, it is.
Post by blind Pete
[...]
The other problem with LiLo is that modern filesystem house keeping
functions can silently move files. Even an old defrag will change
the sector numbers that need to be in the map file to make it all
work. So, all of your boot files want to be on a "quiet" partition.
Of course. LILO does not support large hard disks over 2 TiB either ─
it has the same limitations in that regard as grub-legacy ─ so it is
always advisable to have a separate /boot partition.
Post by blind Pete
There is no way to lock the position of files - that I know of -
hence the desirability of the old rescue boot floppy.
A read-only filesystem wouldn't be subjected to file relocation. I
always have /boot mounted read-only, unless I'm installing a new kernel.
And then I remount it read-only again afterwards. ;)
Ah yes, mount it read only. Do you even have to mount /boot at all
during normal operation? The EFI boot partition is often not mounted
on UEFI machines and my first LiLo map file is on a partition that is
usually not mounted.
Post by Aragorn
Post by blind Pete
Post by Aragorn
Post by blind Pete
Post by Aragorn
Post by blind Pete
Are you using hybrid disks that have a Gnu Partition Table [...
Um, GPT stands for GUID Partition Table, and GUID stands for
"Global Unique IDentifier", not for GNU. :p
That would be a much more marketable term in Redmond.
Well, other partitioning formats have already long existed before MS-DOS
came along, and the Intel-based Macintosh uses an EFI, just as has
already long been the case on Intel Itanium and RISC-based machines.
The successor to EFI ─ and specifically intended for x86-64 ─ is UEFI,
but the problem there is that Microsoft is a very influential member of
the UEFI committee. By consequence, a lot of Microsoftisms have crept
into the UEFI specifications.
For instance, the UEFI normally has a built-in command line, but the
syntax of this command line, its volume-oriented approach to storage and
its use of a backslash as a directory separator, are all taken straight
out of Microsoft Windows.
So yes, UEFI has been usurped by Microsoft, and therefore the partition
table format will also have a typical "Microsoftized" name. ;)
Post by blind Pete
The grub developers have tried very hard to put critical files out
of the reach of idiots, preferring a BIOS partition over files in
/boot. But they forgot that there is nowhere that you can hide stuff
that is out of reach of a determined idiot. As for an idiot with
the root password or a live CD, I don't know why they bothered.
A member of a large tribe whose influences in the affairs of
mankind have always been domineering.
(Ambrose Bierce - "The Devil's Dictionary")
:p
Post by blind Pete
Post by Aragorn
When installing GRUB to a _partition_ boot sector, GRUB does not
require an intermediate "stage 1.5".
Are you using just the one boot loader, GRUB legacy, for all of your
OSes?
I use whatever is the default choice, but I only have one OS per
computer anyway. I don't do multi-boot, and I don't do Microsoft
Windows. ;)
Nice and simple. The occasional virtual machine for test installations?
If you can put your hand on a rescue CD one OS per machine is good.
Post by Aragorn
So far, the only boot loaders I've ever had on my computers have been
LILO and grub-legacy. I haven't had any first-hand experience with
grub2 yet.
With just one OS it will probably work without any trouble.
I have Grub2 working fine on my legacy Dell E6520 booting
both Windows 7 and PCLinuxOS64. I have had several other Linux
distros installed on my Dell E6420 systems and booting. But many
OSes will take over the whole system and where you were booting
from a PCLinux installed Grub one day it may be from a Debian
install the next day. Some installers seem to give a great deal
of trouble about multiple boot situations.

bliss
--
bliss dash SF 4 ever at dslextreme dot com
Bit Twister
2017-02-18 08:39:59 UTC
Permalink
Post by blind Pete
Post by Bit Twister
Well, grub legacy was no longer supported and grub2 forced the Mageia team
to move forward.
Hard question; will it be sane, or even possible, to use LiLo on
a BIOS system? It will require an ext3 boot partition and probably
compiling from source.
Seems like that would be up to you and your expertise.

Then there is possibility of all that work downing down the drain when
you get a new system. :(
Post by blind Pete
I usually move EFI systems to rEFInd as
soon as I can. For some reason Grub2 has never grown on me.
Personally I believe if the grub2/os_prober maintainers were to add
any media label to the menu title, lots of power users would have less
complaints about grub2.

What would remain is complaints about setting the default menu for
boot and menu ordering.

grub-customizer is not the way to go in a highly dynamic environment.

It took me about 50 lines of scripting to get the menu selections I wanted
and a copula of lines in /etc/default/grub to allow me to do a
grub2-set-default label_of_choice__here
to set default selection for boot.
blind Pete
2017-02-19 00:23:04 UTC
Permalink
Post by Bit Twister
Post by blind Pete
Post by Bit Twister
Well, grub legacy was no longer supported and grub2 forced the Mageia
team to move forward.
Hard question; will it be sane, or even possible, to use LiLo on
a BIOS system? It will require an ext3 boot partition and probably
compiling from source.
Seems like that would be up to you and your expertise.
Then there is possibility of all that work downing down the drain when
you get a new system. :(
It is probably not going to be worth it, but I am thinking about it.
There are a couple of workarounds that I might do.
Post by Bit Twister
Post by blind Pete
I usually move EFI systems to rEFInd as
soon as I can. For some reason Grub2 has never grown on me.
Personally I believe if the grub2/os_prober maintainers were to add
any media label to the menu title, lots of power users would have less
complaints about grub2.
My personal hate is that it does not want to be installed to a
partition boot record. That would allow each installation to
do its own thing and not upset other installations, or be upset
by other installations. It would also negate the need for
os_prober. One Grub2 per computer means that every installation
has to attempt to get it right for itself and all other
installations every time - a tall order. If for some reason you
want to reinstall a year old OS but there is an installation
on your computer that uses a filesystem that did not exist a year
ago, then it is not going to work.
Post by Bit Twister
What would remain is complaints about setting the default menu for
boot and menu ordering.
grub-customizer is not the way to go in a highly dynamic environment.
It took me about 50 lines of scripting to get the menu selections I wanted
and a copula of lines in /etc/default/grub to allow me to do a
grub2-set-default label_of_choice__here
to set default selection for boot.
--
blind Pete
Sig goes here...
Bit Twister
2017-02-14 15:28:51 UTC
Permalink
Post by Doug Laidlaw
That was a case of inadequate testing, and upgrading Kodi without
upgrading
related RPMs, sounds much the same.
Just now noticed kodi-17.0-3.mga6 released ~40 minutes ago.
Bit Twister
2017-02-14 12:26:20 UTC
Permalink
Post by Daniel60
Bit Twister, I've used the disk partitioning tool that came with MGA 3
and 5 (I think) and they, apparently, worked.
And I have always used a partitioning tool other than
Mandriva/Mandrake/Mageia's to create my partitions.
Post by Daniel60
What "improvements" were being made to the disk partitioning tool that
has now got it "clobbering the drive partition table"??
Automation code to automagically create needed partition for grub2 and
manage UEFI, non-UEFI, GPT/MSDOS partition tabled drives in a systemd
environment plus all the different install methods provided during the
partitioning phase of install.
Post by Daniel60
And would it have been possible, in order to get MGA 6 out and about, to
just re-instate the old disk partitioning tool from 5/5.1 and keep the
newer version for MGA 7??
The Mageia team sets down and decide what features are to be included
in each new release and decide what can no longer be supported by the
available human resources.

Up line grub organization no longer supported grub legacy quite awhile
back so it makes sense to run with grub2.

That and with all the new hardware using EFI and users needing to be
able to dual boot required the changes.

What is your rush to get Mga6 installed?

Offhand I can not think of any new features over and above Mga5
current software selection.

I saw that Release 6 was going with grub2 and was seeing warnings that
my disk drives were starting to show faults so I went ahead and
installed new drives, used a rescue cd to set them as GPT,
formatted/labeled and restored mga3, mga4, mga5. then installed mga6
(cauldron). Once that worked, I went back and converted mga5 from grub
legacy to grub2.

It also did not hurt that I had written scripts to convert fstab and whatnot
from using UUID to using labels.
Daniel60
2017-02-14 13:28:06 UTC
Permalink
Post by Bit Twister
Post by Daniel60
Bit Twister, I've used the disk partitioning tool that came with MGA 3
and 5 (I think) and they, apparently, worked.
And I have always used a partitioning tool other than
Mandriva/Mandrake/Mageia's to create my partitions.
I usually just created the required partition as part of the install!
Post by Bit Twister
Post by Daniel60
What "improvements" were being made to the disk partitioning tool that
has now got it "clobbering the drive partition table"??
Automation code to automagically create needed partition for grub2 and
manage UEFI, non-UEFI, GPT/MSDOS partition tabled drives in a systemd
environment plus all the different install methods provided during the
partitioning phase of install.
Good! Should save me time and trouble!
Post by Bit Twister
Post by Daniel60
And would it have been possible, in order to get MGA 6 out and about, to
just re-instate the old disk partitioning tool from 5/5.1 and keep the
newer version for MGA 7??
The Mageia team sets down and decide what features are to be included
in each new release and decide what can no longer be supported by the
available human resources.
So "they" have been working on this for some time then. O.K.
Post by Bit Twister
Up line grub organization no longer supported grub legacy quite awhile
back so it makes sense to run with grub2.
Yeap!
Post by Bit Twister
That and with all the new hardware using EFI and users needing to be
able to dual boot required the changes.
What is your rush to get Mga6 installed?
No great rush. One day, I'll find a Linux distro that will connect to
Internet via my Haiwea USB 3G Dongle on this HP 6730b laptop. Not
Mandriva 2009 (natively), not MGA 2, 3, 4 or 5 .... so, maybe, maybe MGA 6!!

Or, maybe, I'll get off my butt and install some of the other half dozen
or so distro's I've d/l'ed and one of them will connect!!
Post by Bit Twister
Offhand I can not think of any new features over and above Mga5
current software selection.
I saw that Release 6 was going with grub2 and was seeing warnings that
my disk drives were starting to show faults so I went ahead and
installed new drives, used a rescue cd to set them as GPT,
formatted/labeled and restored mga3, mga4, mga5. then installed mga6
(cauldron). Once that worked, I went back and converted mga5 from grub
legacy to grub2.
It also did not hurt that I had written scripts to convert fstab and whatnot
from using UUID to using labels.
Daniel
William Unruh
2017-02-14 17:04:34 UTC
Permalink
Post by Bit Twister
What is your rush to get Mga6 installed?
Offhand I can not think of any new features over and above Mga5
current software selection.
Well mga5 did not work well at all on my Dell xps13 (9360 -- Kaby Lake
processor) so I had to go to Mga6. The mga6 kernels, which might have
helped in mga5, did not install at all properly and completely messed up
the graphics. Dependencies for the graphics ran away, making installing
in mga5 impossible.
Post by Bit Twister
I saw that Release 6 was going with grub2 and was seeing warnings that
my disk drives were starting to show faults so I went ahead and
installed new drives, used a rescue cd to set them as GPT,
Had to do that anyway because the Dell really only uses GPT.
Post by Bit Twister
formatted/labeled and restored mga3, mga4, mga5. then installed mga6
(cauldron). Once that worked, I went back and converted mga5 from grub
legacy to grub2.
It also did not hurt that I had written scripts to convert fstab and whatnot
from using UUID to using labels.
Maurice
2017-02-14 11:57:23 UTC
Permalink
Post by Bit Twister
I have abandoned Plasma for Xfce as my Desktop Environment (DE).
I would be interested to see what steps you advise to give that a try!
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Bit Twister
2017-02-14 14:03:58 UTC
Permalink
Post by Maurice
Post by Bit Twister
I have abandoned Plasma for Xfce as my Desktop Environment (DE).
I would be interested to see what steps you advise to give that a try!
For me it was pretty straight forward. clean Cauldron install and I
pick Plasma, Gnome, and Xfce desktop.
http://doc.mageia.org/installer/5/en/content/choosePackageGroups.html

You should be able to add it via
mcc->Software Management->Install & Remove Software
Graphical Desktop
Xfce

Went back to Mga5 and tried it and it was a very poor experience.
Much better on Mga6.

After boot/updates, create a user, say xfce, enter xfce in user name,
xfce's password, and select xfce as desktop, click OK.

To save you some time, you need to put the "Xfce control center" app
in Panel 1 (top task bar).

Click Menu Icon top left, Settings, click/drag "Settings manager" up into
Panel 1. When you make selections they are done on the spot.

For Appearance, picked Aurora, icons Oxygen.

Single click/icon size.... can be found
with Right click on desktop->Desktop settings

For number of rows for Workspace Switcher,
bottom panel, Right click in boxes, Properties

I run with 8 virtual desktops so I have lots of my scripts switch to
desired desktop and run application if not already running.

For Xfce you can install/use xdotool to get scripts to move to
different desktops.
Maurice
2017-02-14 15:29:14 UTC
Permalink
For me it was pretty straight forward. clean Cauldron install and I pick
Plasma, Gnome, and Xfce desktop.
Interesting! Puzzled about picking Plasma & Gnome as well as Xfce.
You should be able to add it via mcc->Software Management->Install &
Remove Software
Graphical Desktop
Xfce
You mean add it to a straight Plasma install (instead of the top
sequence)?
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Bit Twister
2017-02-14 16:22:59 UTC
Permalink
Post by Maurice
For me it was pretty straight forward. clean Cauldron install and I pick
Plasma, Gnome, and Xfce desktop.
Interesting! Puzzled about picking Plasma & Gnome as well as Xfce.
Hehe, using apps from different DEs. Using kwrite as my coding editor,
gnucash for my expenses, .... for example. Just did not want to mess
with getting just specifics.
Post by Maurice
You should be able to add it via mcc->Software Management->Install &
Remove Software
Graphical Desktop
Xfce
You mean add it to a straight Plasma install (instead of the top
sequence)?
I do not understand the question. Plasma is a Display Environment and
so is Xfce.

You want to run a DE, it has to be installed.
The plymouth login screen allows you to pick an installed DE to be
used upon login.

For testing DEs I just create that DE user account and boot it. Example:
$ grep kde /etc/passwd
kde:x:1002:1002:Kde Test Account:/home/kde:/bin/bash

All though it seems possible to run dual DEs in the same account, I
would not want the possibility of something from one causing problems
in the other DE.

Do keep in mind, Mga6 (Cauldron) is order of magnitude better than
what runs on Mga5.
Maurice
2017-02-14 17:14:02 UTC
Permalink
I do not understand the question. Plasma is a Display Environment and so
is Xfce.
You should be able to add it via mcc->Software Management->Install &
Remove Software
Graphical Desktop
Xfce
you simply meant as an *alternative* to 'clean Cauldron install and pick
Plasma, Gnome, and Xfce desktop'...

I take your later point about not mixing DE's in same user account,
which I would want to avoid if changing over to Xfce.
Perhaps I need to try a Cauldron install of just Xfce as DE, and see
how much function I would need to find an alternative for...
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
TJ
2017-02-14 15:37:18 UTC
Permalink
Post by Maurice
Post by Bit Twister
I have abandoned Plasma for Xfce as my Desktop Environment (DE).
I would be interested to see what steps you advise to give that a try!
If you just want to try it out without actually installing it, the
upcoming Mageia 6 sta2 LiveDVDs may be the way to go.

Because Plasma 5 won't run on older 32-bit-only processors that don't
support sse2, which is most of them, The 32-bit Plasma LiveDVD has been
dropped and is being replaced by a 32-bit Xfce version.

This has other advantages, too. Because many if not most of those older
machines are unable to boot from usb, the lighter Xfce desktop is more
desirable because it comes up MUCH faster from a DVD than either Plasma
or Gnome. That makes it nice for people who want to use a LiveDVD for
system maintenance purposes.

After looking at the first test 32-bit Xfce LiveDVD, it was decided that
it would be a good idea to drop the 32-bit Gnome LiveDVD as well, to be
replaced by a 64-bit Xfce LiveDVD, one that might work better with UEFI
machines. Those are what's being worked on now.

32-bit Gnome users have not been abandoned, and neither have those
32-bit users that have the sse2 support needed to run Plasma. Those
options are still to be a part of the 32-bit Classical DVD iso.

Personally, I prefer installing from the Classicals, because of all the
extra options they provide. But for those who just want to give
something a try, the LiveDVDs aren't a bad choice.

TJ
Maurice
2017-02-14 17:16:58 UTC
Permalink
Post by TJ
If you just want to try it out without actually installing it, the
upcoming Mageia 6 sta2 LiveDVDs may be the way to go.
I was just homing in on that when I noticed your posting!

Will give it a try when latest LiveDVD is available.
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Doug Laidlaw
2017-02-18 13:38:01 UTC
Permalink
Post by Maurice
Post by TJ
If you just want to try it out without actually installing it, the
upcoming Mageia 6 sta2 LiveDVDs may be the way to go.
I was just homing in on that when I noticed your posting!
Will give it a try when latest LiveDVD is available.
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Whenever that is!
--
TJ
2017-02-18 14:07:25 UTC
Permalink
Post by Doug Laidlaw
Post by Maurice
Post by TJ
If you just want to try it out without actually installing it, the
upcoming Mageia 6 sta2 LiveDVDs may be the way to go.
I was just homing in on that when I noticed your posting!
Will give it a try when latest LiveDVD is available.
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Whenever that is!
Maurice is one of the QA iso testers. He will see it sooner than the
general public, so he can help look for bugs.

All are welcome to join the QA team. We test proposed isos and package
updates before they are released to the public, so the more varied the
hardware configurations available as test beds the better.

See https://wiki.mageia.org/en/QA_Team for more details.

TJ
Maurice
2017-02-25 19:50:42 UTC
Permalink
Post by TJ
good idea to drop the 32-bit Gnome LiveDVD as well, to be
replaced by a 64-bit Xfce LiveDVD, one that might work better with UEFI
machines. Those are what's being worked on now.
Just had first try of that LiveDVD on UEFI/GPT laptop; booted fine.
Had a bit of a struggle with the limitations of the setup (e.g.
/home/live not big enough to receive clone of some normal /home files),
but began to get the feel of it.

Still to check which of the Gnome/KDE apps can coexist; found gparted
would. Will try Gwenview for the photography things. Any that will not?
As a Kmail user I imagine Thunderbird would be OK, as I'm on the brink
of giving up with Kmail.
But need a proper install to really get to grips with it...
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
TJ
2017-02-26 15:05:19 UTC
Permalink
Post by Maurice
Post by TJ
good idea to drop the 32-bit Gnome LiveDVD as well, to be
replaced by a 64-bit Xfce LiveDVD, one that might work better with UEFI
machines. Those are what's being worked on now.
Just had first try of that LiveDVD on UEFI/GPT laptop; booted fine.
Had a bit of a struggle with the limitations of the setup (e.g.
/home/live not big enough to receive clone of some normal /home files),
but began to get the feel of it.
Still to check which of the Gnome/KDE apps can coexist; found gparted
would. Will try Gwenview for the photography things. Any that will not?
As a Kmail user I imagine Thunderbird would be OK, as I'm on the brink
of giving up with Kmail.
But need a proper install to really get to grips with it...
I don't know much about it as a DE. I haven't used it, except for
testing the Live iso to see if it would install and appear to work on my
machine.

I've always favored KDE. I didn't really care for Plasma 5 at first, but
now that the Mageia developers have had a chance to work on it, and I've
had a chance to work with it and learn its idiosyncrasies, it's grown on
me. The sta2 installs I have done (and there have been SO many) have
been much more pleasant to work with than sta1 was. I admit I've been
lucky in that I've missed the worst of the bugs, and have been able to
learn how to work around the bigger ones I've run into.

But then, I'm not a power user. My needs in day-to-day usage are modest,
by today's standards.

I must admit, though, that I was VERY impressed with how fast the Xfce
Live desktop came up from a usb stick on my old Dell Dimension E310.
(P4, 2GB RAM, onboard Intel graphics) MUCH faster than Live KDE ever was.

TJ
Maurice
2017-02-27 12:52:47 UTC
Permalink
Post by TJ
I've always favored KDE.
Me too, all the way from my 1st Linux distro (SuSe). Looked at Gnome.
Post by TJ
I didn't really care for Plasma 5 at first, but
now that the Mageia developers have had a chance to work on it, and I've
had a chance to work with it and learn its idiosyncrasies, it's grown on
me.
It was quite a mess to start with nearly a year ago) but it is much more
civilised now.
Problem is, I have my own 'change to Mageia-6' blockers, e.g.

https://bugs.mageia.org/show_bug.cgi?id=18384
https://bugs.mageia.org/show_bug.cgi?id=20182

- although I'm told the first will be fixed in KMail 5.4.2 in KDE
18.387 (any signs of that coming down the 'pike?!), but - as I
said earlier - Kmail is in a bit of a mess, which is why I have been
trialling T'bird for several months, using a 2nd POP3 copy stream to
check out its handling of maildir.
(Quite good, though not as good an general options GUI as Kmail.)
--
/\/\aurice
(Replace "nomail.afraid" by "bcs" to reply by email)
Loading...