First Release Candidate of Grml version 2017.05 available
Hi,
so *finally* we did it again, jey! The first release candidate of the upcoming Grml version 2017.05, code-named 'Freedatensuppe' is available.
This Grml release provides fresh software packages from Debian testing (AKA stretch). As usual it also incorporates current hardware support and fixes known bugs from the previous Grml release.
For detailed information about the changes between 2014.11 and 2017.05 have a look at the official release announcement:
http://grml.org/changelogs/README-grml-2017.05-rc1/
Please test the ISOs and everything you usually use and rely on, and report back so we can complete the stable release soon. If no major problems come up, the next iteration will be the stable release, which is scheduled for the end of May (2017 *cough* :)).
Thanks to all contributors!
regards, -mika- - for the Grml.org project
Michael Prokop wrote...
so *finally* we did it again, jey!
\o/
The first release candidate of the upcoming Grml version 2017.05, code-named 'Freedatensuppe' is available.
The Swiss edition will be sold as Flätlisuppe, I guess?
For detailed information about the changes between 2014.11 and 2017.05 have a look at the official release announcement:
So I guess this release will, like Debian, no longer support older i386 CPUs? Then the release notes should mention that on some place. I'll try to test on K6 and C3 systems these days, this should fail, and hopefully in a sane way. Also, no worries, they are at least 15 years old now and demand a tremendous amount of pocket money.
A visual: At least the small i386 image prints a "[ FAIL ] amixer binary not availble" warning during boot. If it's easy to avoid that, please do so.
Cheers, Christoph
* Christoph Biedl [Mon May 08, 2017 at 11:41:26PM +0200]:
Michael Prokop wrote...
The first release candidate of the upcoming Grml version 2017.05, code-named 'Freedatensuppe' is available.
The Swiss edition will be sold as Flätlisuppe, I guess?
Hehe
For detailed information about the changes between 2014.11 and 2017.05 have a look at the official release announcement:
So I guess this release will, like Debian, no longer support older i386 CPUs? Then the release notes should mention that on some place. I'll try to test on K6 and C3 systems these days, this should fail, and hopefully in a sane way. Also, no worries, they are at least 15 years old now and demand a tremendous amount of pocket money.
Yeah, we don't modify/rebuild Debian's userspace tools and our kernel is based on Debian's. I don't have any such old systems though and don't know which CPUs are exactly unsupported now. So whoever knows what we should write in our release notes, please just create a PR or patch against https://github.com/grml/grml.org/blob/master/changelogs/README-grml-2017.05-... :)
A visual: At least the small i386 image prints a "[ FAIL ] amixer binary not availble" warning during boot. If it's easy to avoid that, please do so.
amixer is coming from alsa-utils, which would pull in ~8MB of additional disk space usage on grml-small, so probably not worth it. Should we just make it a warning instead of an error message, or do you suggest something else?
regards, -mika-
On Tue, May 09, 2017 at 01:44:35PM +0200, Michael Prokop wrote:
A visual: At least the small i386 image prints a "[ FAIL ] amixer binary not availble" warning during boot. If it's easy to avoid that, please do so.
amixer is coming from alsa-utils, which would pull in ~8MB of additional disk space usage on grml-small, so probably not worth it. Should we just make it a warning instead of an error message, or do you suggest something else?
Try not starting the service in the first place?
Greetings Marc
Michael Prokop wrote...
- Christoph Biedl [Mon May 08, 2017 at 11:41:26PM +0200]:
So I guess this release will, like Debian, no longer support older i386 CPUs? Then the release notes should mention that on some place. I'll try to test on K6 and C3 systems these days, this should fail, and hopefully in a sane way. Also, no worries, they are at least 15 years old now and demand a tremendous amount of pocket money.
Yeah, we don't modify/rebuild Debian's userspace tools and our kernel is based on Debian's. I don't have any such old systems though and don't know which CPUs are exactly unsupported now. So whoever knows what we should write in our release notes, please just create a PR or patch against https://github.com/grml/grml.org/blob/master/changelogs/README-grml-2017.05-... :)
Just borrow from the stretch release notes[1]? With some changes and also an addition:
| Following Debian's switch, the 32-bit PC support (known as the | architecture "i386") now no longer covers a plain i586 processor. The | new baseline is the i686, although some i586 processors (e.g. the "AMD | Geode") will remain supported. | | Systems that do not provide the required features will fail to boot with | a distinctive error message. | | The following shell script may be a useful indicator (assuming only one | processor is installed in the machine): | | if grep -q '^flags.*\bfpu\b.*\btsc\b.*\bcx8\b.*\bcmov\b' /proc/cpuinfo; then | echo "OK (assuming all CPUs are of the same type)" | else | echo "NOT OK: Missing one or more of the required CPU extensions" | fi
[1] https://www.debian.org/releases/stretch/i386/release-notes/ch-information.en...
A visual: At least the small i386 image prints a "[ FAIL ] amixer binary not availble" warning during boot. If it's easy to avoid that, please do so.
amixer is coming from alsa-utils, which would pull in ~8MB of additional disk space usage on grml-small, so probably not worth it. Should we just make it a warning instead of an error message, or do you suggest something else?
Drop the init script or whatever causes this from -small. If this means too much work, rather focus on other issues.
Christoph
* Christoph Biedl [Wed May 10, 2017 at 12:02:21AM +0200]:
Michael Prokop wrote...
- Christoph Biedl [Mon May 08, 2017 at 11:41:26PM +0200]:
So I guess this release will, like Debian, no longer support older i386 CPUs? Then the release notes should mention that on some place. I'll try to test on K6 and C3 systems these days, this should fail, and hopefully in a sane way. Also, no worries, they are at least 15 years old now and demand a tremendous amount of pocket money.
Yeah, we don't modify/rebuild Debian's userspace tools and our kernel is based on Debian's. I don't have any such old systems though and don't know which CPUs are exactly unsupported now. So whoever knows what we should write in our release notes, please just create a PR or patch against https://github.com/grml/grml.org/blob/master/changelogs/README-grml-2017.05-... :)
Just borrow from the stretch release notes[1]? With some changes and also an addition:
[...]
[1] https://www.debian.org/releases/stretch/i386/release-notes/ch-information.en...
Good idea, thx :)
A visual: At least the small i386 image prints a "[ FAIL ] amixer binary not availble" warning during boot. If it's easy to avoid that, please do so.
amixer is coming from alsa-utils, which would pull in ~8MB of additional disk space usage on grml-small, so probably not worth it. Should we just make it a warning instead of an error message, or do you suggest something else?
Drop the init script or whatever causes this from -small. If this means too much work, rather focus on other issues.
I did take care already: https://github.com/grml/grml/issues/24
regards, -mika-
On Mon, May 08, 2017 at 11:11:05PM +0200, Michael Prokop wrote:
Please test the ISOs and everything you usually use and rely on, and report back so we can complete the stable release soon. If no major problems come up, the next iteration will be the stable release, which is scheduled for the end of May (2017 *cough* :)).
Well done! grml has been and will be an indispensable tool.
Here are the results of the Badenian jury for grml-small.
(1) boots fine on Dell Server hardware that used to need the mgag200.modeset=0 in the past. Cosmetic output issues are persent (github issue #23).
(2) boots fine on VMware
(3) boots fine on KVM (with and without nodhcp)
(4) boots fine on KVM with serial console (modulo #21)
(5) boots fine from CD toram on Dell Server and KVM
(6) boots fine via PXE to KVM (with and without serial console)
(7) unfortunately, I botched up when booting an APU (forgot to start grml with serial, therefore machine unaccessible and cannot reboot from remote). I will report back if it doesn't work fine. my bad.
(8) grml-rescueboot works fine (on KVM)
(9) Zg-grml-boot (see http://blog.zugschlus.de/archives/825-grml-als-eigenes-Rescuesystem.html) works fine, up to the network script (on KVM)
Solid work! Thanks! Please release.
Grüße Marc
* Marc Haber [Tue May 09, 2017 at 03:32:56PM +0200]:
On Mon, May 08, 2017 at 11:11:05PM +0200, Michael Prokop wrote:
Please test the ISOs and everything you usually use and rely on, and report back so we can complete the stable release soon. If no major problems come up, the next iteration will be the stable release, which is scheduled for the end of May (2017 *cough* :)).
Well done! grml has been and will be an indispensable tool.
Here are the results of the Badenian jury for grml-small.
(1) boots fine on Dell Server hardware that used to need the mgag200.modeset=0 in the past. Cosmetic output issues are persent (github issue #23).
Jey!
(2) boots fine on
[...]
(8) grml-rescueboot works fine (on KVM)
(9) Zg-grml-boot (see http://blog.zugschlus.de/archives/825-grml-als-eigenes-Rescuesystem.html) works fine, up to the network script (on KVM)
Great, thanks for all the tests and reporting back, this is great!
Solid work! Thanks! Please release.
Will do as soon as we successfully fought against the known bugs. :)
regards, -mika-
On Tue, May 09, 2017 at 03:32:56PM +0200, Marc Haber wrote:
(7) unfortunately, I botched up when booting an APU (forgot to start grml with serial, therefore machine unaccessible and cannot reboot from remote). I will report back if it doesn't work fine. my bad.
The reason for grml not booting on the APU was that /boot is an LV on this box and grml still doesn't grok this and still isn't quite helpful with its error messages in this case. The result is issue #40, please don't hold the release for that.
Greetings Marc
Hi,
On Mon, May 08, 2017 at 11:11:05PM +0200, Michael Prokop wrote:
so *finally* we did it again, jey! The first release candidate of the upcoming Grml version 2017.05, code-named 'Freedatensuppe' is available.
Yay! :-)
Please test the ISOs and everything you usually use and rely on, and report back so we can complete the stable release soon.
Tested it on a rather new Lenovo ThinkPad X470s. In general, it worked fine both with booting the amd64 bit version off
a) the grml64-full ISO via grml-rescueboot b) the grml96-full ISO via USB 3.0 stick
Unless mentioned otherwise I only tried the "copy grml to RAM" and "copy whole medium to RAM" options. Noticed no differences between those two, especially not wrt. to the issues reported below.
The following issues showed up:
* In all cases it showe (with the bootloader background screen still shown if booted via grml-rescueboot, otherwise still with the bootloader resolution and font) an error message "error: null src bitmap on grub_video_bitmap_create_scaled.", then "Loading kernel" + "Loading initrd" and strangely also "Press any key to continue". Strangely because:
+ Pressing any key does not cause any immediate change or reaction. + Leaving this screen without pressing any key shows grml booting after maybe 15 to 30 seconds anyways.
So this is primarily confusing. Some "Loading medium into memory, please wait" message or so and maybe getting rid of that "error: null src bitmap on grub_video_bitmap_create_scaled." message which doesn't seem to be relevant would greatly improve the user experience. :-)
(This issue does not happen if I use the default boot method without loading anything into memory in advance.)
* X does _not_ start if I press "x" but throws some error messages including some "permission denied" and "cannot connect to X server".
Similar if not identical errors show up when trying to run "startx" as user "grml".
The boot loader menu item "Start X by default" does not work either with similar error messages.
(Will try to the X.org logs off the machine later.)
X does though start up without issues if I use "startx" as root.
* If I try to connect to an WPA 2 Enterprise wifi I just get the prompt for a normal WPA 1/2 Personal (Shared Secret) network and hence don't get any network. (That's also the reason why I couldn't quickly get the X logs off that machine.)
I don't seem to be able to use 802.1X for authenticating the machine on the network either. At least I haven't found an according menu point in grml-network.
I'm not sure if I tried that before, so the chances that this is not a regression but just a missing feature. :-)
Kind regards, Axel
Hi,
an addition:
On Tue, May 09, 2017 at 07:12:23PM +0200, Axel Beckert wrote:
Please test the ISOs and everything you usually use and rely on, and report back so we can complete the stable release soon.
Tested it on a rather new Lenovo ThinkPad X470s. In general, it worked fine both with booting the amd64 bit version off
a) the grml64-full ISO via grml-rescueboot b) the grml96-full ISO via USB 3.0 stick
c) Failed to load the grml boot menu when selecting the grml64-full ISO via grub-imageboot.
The screen gets grid-arranged black, rectangular dots and then slowly the background image starts to scroll upwards (for many minutes) while the black dots stay at their place.
Kind regards, Axel
Hi,
some more observations from booting the 32 bit part of the grml96-full image on an EeePC 900A via USB stick:
Of course the boot process is slower on a nearly 10 years old EeePC than with a 2-year old ThinkPad, but this showed at least one issue with the move to systemd and its parallel booting. When finished booting, the grml-quickconfig box already partially scrolled off the screen and quite some boot messages were only shown after the grml-quickconfig box:
=========================================================================== │ Welcome to grml-quickconfig │ │ Press a highlighted key to perform an action, or press │ │ Return or q to go back to the shell. │ ├────────────────────────────────────────────────────────────┤ │ Set keyboard layout (grml-lang): de at ch es us │ │ Configure network (grml-network) │ │ -> Configure ethernet card directly (netcardconfig) │ ├────────────────────────────────────────────────────────────┤ │ Show information about Grml (grml-info) │ │ Start x (grml-x) │ │ Install Debian to hard disk (grml-debootstrap) │ └────────────────────────────────────────────────────────────┘
Press a key: [ OK ] Setting kernel ring buffer to level 2. [ OK ] Starting rsyslog in background. [ OK ] Activating language settings: [ OK ] Writing language settings (en) to /etc/default/locale was successful. [ OK ] Setting up unicode environment. [ OK ] Running loadkeys for us in background [ OK ] Setting font to Uni3-Terminus16 [ OK ] Running Linux Kernel 4.9.0-1-grml-686 [ OK ] Creating /etc/mdadm/mdadm.conf for use with mdadm. [ OK ] Just run 'Start mdmonitor' to assemble md arrays or boot using 'swraid' as bootoption for autostart. [ OK ] Searching for any present dmraid sets: [ OK ] No active dmraid devices found [ OK ] You seem to have logical volumes (LVM) on your system. [ OK ] Just run 'Start lvm2-lvmetad' to activate them or boot using 'lvm' as bootoption for autostart. [ OK ] Found CPU: Processor 0 is Intel(R) Atom(TM) CPU N270 @ 1.60GHz 1600MHz, 512 KB Cache Processor 1 is Intel(R) Atom(TM) CPU N270 @ 1.60GHz 800MHz, 512 KB Cache [ OK ] Trying to set up cpu frequency scaling: [ OK ] Setting ondemand governor [ OK ] Searching for device(s) labeled with GRMLCFG. (Disable this via boot option: noautoconfig) [ OK ] Configuring soundcard "Intel" [ OK ] Setting mixer volumes to level 75. [ OK ] Starting gpm in background. _ ===========================================================================
The cursor blinks at the last line where the underscore is.
Another strange error message popped up when connecting to my home wifi after DHCP has succeeded:
=========================================================================== Internet Systems Consortium DHCP Client 4.3.5 Copyright 2004-2016 Internet Systems Consortium. All rights reserved. For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/wlan0/00:22:43:2d:7d:97 Sending on LPF/wlan0/00:22:43:2d:7d:97 Sending on Socket/fallback DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on wlan0 to 255.255.255.255 port 67 interval 4 DHCPREQUEST of 192.168.1.227 on wlan0 to 255.255.255.255 port 67 DHCPOFFER of 192.168.1.227 from 192.168.1.1 DHCPACK of 192.168.1.227 from 192.168.1.1 smbd.service is not active, cannot reload. invoke-rc.d: initscript smbd, action "reload" failed. Error: invalid characters specified in hostname: '...' can not be used inside hostnames. bound to 192.168.1.227 -- renewal in 18283 seconds. ===========================================================================
Note the "invalid characters specified in hostname" error in the second-last line and especially that it's saying "..." would be part of the hostname. (Since I never saw that error message on other hosts in the same network, I assume it's not a misconfiguration on the DHCP server -- which is a Turris Omnia running dnsmasq.)
Then I noticed that the grml96-full image has at least one different text inside the "Additional boot entries for:" menus compared to the grml64-full image (for the same functionality):
grml96: "Graphical Mode" (both, for grml32 and grml64) grml64: "Start X by default" (or similar)
Additionally, grml64-full has two menu entries "Load grml to RAM" and "Load whole medium to RAM" while grml96-full only has "Load to RAM".
I would have expected that the submenus on grml96 are identical to those of grml64.
On Tue, May 09, 2017 at 07:12:23PM +0200, Axel Beckert wrote:
X does _not_ start if I press "x" but throws some error messages including some "permission denied" and "cannot connect to X server".
Similar if not identical errors show up when trying to run "startx" as user "grml".
The boot loader menu item "Start X by default" does not work either with similar error messages.
This does not work either on the EeePC. Similar error messages, so I assume it's not hardware specific but a real bug. (modern Nvidia graphics card vs. nearly 10 years old Intel graphics card)
Kind regards, Axel
On Wed, May 10, 2017 at 01:33:33AM +0200, Axel Beckert wrote:
=========================================================================== │ Welcome to grml-quickconfig │ │ Press a highlighted key to perform an action, or press │ │ Return or q to go back to the shell. │ ├────────────────────────────────────────────────────────────┤ │ Set keyboard layout (grml-lang): de at ch es us │ │ Configure network (grml-network) │ │ -> Configure ethernet card directly (netcardconfig) │ ├────────────────────────────────────────────────────────────┤ │ Show information about Grml (grml-info) │ │ Start x (grml-x) │ │ Install Debian to hard disk (grml-debootstrap) │ └────────────────────────────────────────────────────────────┘
Press a key: [ OK ] Setting kernel ring buffer to level 2. [ OK ] Starting rsyslog in background. [ OK ] Activating language settings: [ OK ] Writing language settings (en) to /etc/default/locale was successful. [ OK ] Setting up unicode environment. [ OK ] Running loadkeys for us in background [ OK ] Setting font to Uni3-Terminus16 [ OK ] Running Linux Kernel 4.9.0-1-grml-686 [ OK ] Creating /etc/mdadm/mdadm.conf for use with mdadm.
That is the behavior I had on the Dell server as well.
Greetings Marc
* Axel Beckert [Wed May 10, 2017 at 01:33:33AM +0200]:
some more observations from booting the 32 bit part of the grml96-full image on an EeePC 900A via USB stick:
Of course the boot process is slower on a nearly 10 years old EeePC than with a 2-year old ThinkPad, but this showed at least one issue with the move to systemd and its parallel booting. When finished booting, the grml-quickconfig box already partially scrolled off the screen and quite some boot messages were only shown after the grml-quickconfig box:
[...]
This was https://github.com/grml/grml/issues/19 and is fixed now.
Another strange error message popped up when connecting to my home wifi after DHCP has succeeded:
[...]
invoke-rc.d: initscript smbd, action "reload" failed. Error: invalid characters specified in hostname: '...' can not be used inside hostnames. bound to 192.168.1.227 -- renewal in 18283 seconds. ===========================================================================
Note the "invalid characters specified in hostname" error in the second-last line and especially that it's saying "..." would be part of the hostname. (Since I never saw that error message on other hosts in the same network, I assume it's not a misconfiguration on the DHCP server -- which is a Turris Omnia running dnsmasq.)
As written on IRC (IIRC) grml-hostname expects hostnames following RFC 952, so we'd need to know what hostname you're getting here.
Then I noticed that the grml96-full image has at least one different text inside the "Additional boot entries for:" menus compared to the grml64-full image (for the same functionality):
grml96: "Graphical Mode" (both, for grml32 and grml64) grml64: "Start X by default" (or similar)
Additionally, grml64-full has two menu entries "Load grml to RAM" and "Load whole medium to RAM" while grml96-full only has "Load to RAM".
I would have expected that the submenus on grml96 are identical to those of grml64.
Have to verify that yet, thanks for reporting.
regards, -mika-
* Axel Beckert [Tue May 09, 2017 at 07:12:23PM +0200]:
On Mon, May 08, 2017 at 11:11:05PM +0200, Michael Prokop wrote:
Please test the ISOs and everything you usually use and rely on, and report back so we can complete the stable release soon.
Tested it on a rather new Lenovo ThinkPad X470s. In general, it worked fine both with booting the amd64 bit version off
a) the grml64-full ISO via grml-rescueboot b) the grml96-full ISO via USB 3.0 stick
Unless mentioned otherwise I only tried the "copy grml to RAM" and "copy whole medium to RAM" options. Noticed no differences between those two, especially not wrt. to the issues reported below.
"copy grml to RAM" = only squashfs, "copy whole medium to RAM" = all files on ISO, not really much of a difference for a normal ISO, but relevant if you've custom files on your ISO
The following issues showed up:
- In all cases it showe (with the bootloader background screen still shown if booted via grml-rescueboot, otherwise still with the bootloader resolution and font) an error message "error: null src bitmap on grub_video_bitmap_create_scaled.", then "Loading kernel" + "Loading initrd" and strangely also "Press any key to continue". Strangely because:
- Pressing any key does not cause any immediate change or reaction.
- Leaving this screen without pressing any key shows grml booting after maybe 15 to 30 seconds anyways.
This is https://github.com/grml/grml/issues/16 and fixed now.
- X does _not_ start if I press "x" but throws some error messages including some "permission denied" and "cannot connect to X server".
[...]
This is https://github.com/grml/grml/issues/20 and under debugging by Darshaka right *now*.
- If I try to connect to an WPA 2 Enterprise wifi I just get the prompt for a normal WPA 1/2 Personal (Shared Secret) network and hence don't get any network. (That's also the reason why I couldn't quickly get the X logs off that machine.)
This is https://github.com/grml/grml/issues/28 and we'd need help from someone implementing this feature.
I don't seem to be able to use 802.1X for authenticating the machine on the network either. At least I haven't found an according menu point in grml-network.
https://github.com/grml/grml/issues/29 and same as above :)
I'm not sure if I tried that before, so the chances that this is not a regression but just a missing feature. :-)
Indeed :)
regards, -mika-
Teilnehmer (4)
-
Axel Beckert -
Christoph Biedl -
Marc Haber -
Michael Prokop