Fresh "Alpha 3" ftp install

[jaywalker]

I'm taking the plunge. As discussed elsewhere on this forum I am now having problems getting my test installation to start properly. It is possible that all of the updating and testing of software and desktop utilities has made a mess of the system's configuration. It isn't hard to imagine when you consider how many updates there have been to systemd alone.

So as I write this I am waiting for a network install from an ftp server in France. If the estimate is anything to go by I have about an hour or so to wait. The system will be as bare as my courage would let me make it, I chose a custom installation with only the LXDE desktop and a few console tools for emergencies (the main one being mc of course). I deselected all other frippery. That can be added in piece by piece and the results properly(?) evaluated at each step.

The install is going on to a brand new drive I picked up tonight for £50 in Maplins (heads-up to all UK readers - a 320 G 2.5 inch portable drive - unfortunately it is white. It comes with a white USB Y cable for use with normal or power-starved USB sockets). I let the installer allocate the partitions; 12G for /, 4 G for swap and the rest for /home.

Question; Are we still barred from using /, /usr, /tmp and /var on separate partitions if we boot with systemd? It is an awful nuisance and will cause quite a few problems trying to update any of my Mandriva installations.

The install has been running for about half an hour now and the estimate has gone up from an hour to an hour and a half. Reckon I shouldn't hold my breath. With luck and network congestion allowing it should be finished by the morning....

[jaywalker]

Well that finished a lot quicker than I had a right to expect, despite the inexplicable dozens of kde libraries I saw being downloaded. You have to wonder where some of this stuff comes from. I had chosen the custom install and then with individual package selection I removed all of the remaining kde stuff. There must be more packages in the base install than are listed! Still, I can remove them post-install.

For now I am just marvelling at the way the boot was flawless! Not a single hiccup or quirk and no screens full of errors and warnings. I'm going to re-boot just to watch it again - it's almost beautiful.

[jaywalker]

OK, I have just hit two major problems. One is quite new to me, though I have read of it elsewhere in this forum.

First the easy one. I now know why I saw so many KDE libraries being installed. The installer ignored my desktop selection. So job number 1 is uninstall KDE.

That is under way at the moment so while we wait we can consider the second problem; unpredictable switching of the display away from the desktop to a vt. The first time it happened I was actually about to hit enter after entering my user logon password on the kdm dialog; yes, KDM was force-installed after I had deselected it in the installer in favour of GDM and XDM.

Funny thing is since I switched back to GDM the screen has not switched once. Yes, I think I can pronounce that a cure.

I have now stripped out all of the KDE packages which I could easily find, I'm sure others must be lurking as the orphans list now has 145 files in it but at first glance I cannot see ANY kde-related packages, apart from a significant number of Qt libraries.

[jaywalker]

I am now breaking an unspoken rule of this experiment by installing some new stuff, but it is only so that I can check out some of the hardware-related issues more carefully. I am installing kernel-rt-latest. I have already checked the grub setup to see what it made of the arrangement of discs, and yes, I did have to correct the drivemap file. If experience is anything to go by I will have to go on keeping an eye on that as both Mandriva and Mageia have had a nasty habit of messing with that stuff when you least expect it.

[wilcal]

I'm right along with you. I'm trying a fresh Vbox
install using the latest boot.iso every day.
I use my local repo mirrored from mirrors.kernel.org
I agree it looks like KDE is not being installed.
Or something is not getting installed so KDE does
not launch.

The cauldron repo(s) are moving at light speed. I
saw over 400 files get updated just a couple days
ago.

I'm crossing fingers we'll see a clean KDE install
by the time we get to the 20th and Beta 1 release.

As soon as I get a successful boot.iso install I'll
announce it. Do note that boot.iso is changing
often.

FWIW one of the reasons I use a local repo is that
it's not changing while I'm installing.

By contrast my local repo of Mageia 1 is very steady.
Every once in awhile there'll be a change. But
nothing like Cauldron.

[wilcal]

FWIW 466 files in Cauldron core and non-free repositories
have either changed or been added just in the last couple
days. This thing is still changing at light speed.

[jaywalker]

I agree it looks like KDE is not being installed.

You should try deselecting it during install, that way it will install and launch, whether you want it or not .

My plan to combat the "moving target" repo was to keep the install as small as absolutely possible and that pretty much ruled out both KDE and GNOME; they're just too big. I did want a gui though so LXDE got the nod as I have used it extensively for a couple or more years and I know it is fast and light.

The total time connected to the remote ftp site was at least an hour (thank goodness the worst estimate was wildly inaccurate) and when I got around to checking there were no updates pending, so I reckon I got a good snapshot. I reckon if it had been changing during the install then at least a few of the packages might end up past their bedtime, and that didn't happen, but then again, I took as few as possible.

Do note that boot.iso is changingoften.

A good point well made. That might explain why my configured grub boot commands omit the "init=/bin/systemd" stanza. It must have come from the boot iso I used. Strangely the install also announced itself as Cauldron Beta 1 Anyway, the trouble-free first boot, and all subsequent boots, are probably due to not using systemd. Shame, I thought I had cracked the unreliable boot problem.

I haven't had the courage to try it with systemd yet as I know it will likely distract me from the other less critical checks I want to make. I will be avoiding all unnecessary updates until I have finished the initial examination, but it is late now so that will have to wait until tomorrow evening.

By the way, are you getting the unexpected switching from desktop to vt which I experienced when I had the KDE stuff installed?

Richard

[wilcal]

The total time connected to the remote ftp site was at least an hour (thank goodness the worst estimate was wildly inaccurate) and when I got around to checking there were no updates pending, so I reckon I got a good snapshot.

My total time to install reboot ( Vbox install ) typically is around 10 minutes.
Gigabyte LAN to the local server with the repo.

I use my Video editing platform for Vbox:

Intel Core i7-2600K Sandy Bridge 3.4GHz overclocked to 3.8GHz LGA 1155 95W Quad-Core
GIGABYTE GA-Z68X-UD3-B3 LGA 1155 Intel Z68 SATA 6Gb/s USB 3.0 ATX Intel Motherboard
GIGABYTE GV-N440D3-1GI GeForce GT 440 (Fermi) 1GB 128-bit DDR3 PCI Express 2.0 x16
CORSAIR Vengeance 16GB (4 x 4GB) 240-Pin DDR3 SDRAM DDR3 1600 (PC3 12800)
running 64-bit Mageia 1

Gives the install a little giddy-up.

[doktor5000]

I'm crossing fingers we'll see a clean KDE install
by the time we get to the 20th and Beta 1 release.

As the repos got frozen yesterday and synced to an internal mirror, from which the beta 1 images
are produced, nothing will change for those images between the status quo of yesterday and the 20th
(or almost nothing) so it doesn't seem likely.
Also to note our main KDE maintainer is absent for at least the next two weeks.

[wilcal]

As the repos got frozen yesterday and synced to an internal mirror, from which the beta 1 images
are produced, nothing will change for those images between the status quo of yesterday and the 20th
(or almost nothing) so it doesn't seem likely.
Also to note our main KDE maintainer is absent for at least the next two weeks.

Yep my morning Cauldron repo update today was pretty quiet.

Kool, you think Gnome will be stable by the 20th?

[wobo]

As the repos got frozen yesterday and synced to an internal mirror, from which the beta 1 images
are produced, nothing will change for those images between the status quo of yesterday and the 20th

Kool, you think Gnome will be stable by the 20th?

May be you did not understand what the doctor wrote: if it is stable now it will be stable on 20th, if it is not stable now it will not be stable on 20th.
That's why I will have to postpone any tests until Beta 2. My system is totally messed up (bugs reported, partly still "NEW" after 3 weeks), so it's not likely to change soon.

BTW: except for one the issues are all non-KDE, so the absence of the KDE maintainer does not matter here.

[wilcal]

May be you did not understand what the doctor wrote: if it is stable now it will be stable on 20th, if it is not stable now it will not be stable on 20th.

Thanks, then we should see a usable Beta 1 for both KDE & Gnome.
I just need something to install to get back working with.

[wobo]

May be you did not understand what the doctor wrote: if it is stable now it will be stable on 20th, if it is not stable now it will not be stable on 20th.

Thanks, then we should see a usable Beta 1 for both KDE & Gnome.
I just need something to install to get back working with.

You still did not understand? Freeze has been yesterday and so the situation is not likely to change before Beta 1.
BTW: I can't remember having such a messed up Beta 1, not with Mageia and not in >10 years of Mandrake/Mandriva.
BBTW: Cauldron is not something you should work with, it's a system to work on.

[martinw]

By the way, are you getting the unexpected switching from desktop to vt which I experienced when I had the KDE stuff installed?

Sounds like https://bugs.mageia.org/show_bug.cgi?id=4170.

Martin

[jaywalker]

I can't remember having such a messed up Beta 1, not with Mageia and not in >10 years of Mandrake/Mandriva.

My what short memories we have I have been getting vivid flashbacks to 2009.0 (and to a lesser extent, 2009.1) That had a very similar alpha/beta history of breakages and instability which carried over into the actual release. That's one of the reasons I skipped it altogether. I jumped from 2008.1 to 2010.0 and never regretted it.

I've just booted after yesterday's install and I have 26 updates for the barest of bare systems! So, not quite frozen yet. I have no KDE and only a scattering of gnome packages, so it is no surprise that they are not on offer to me, apart from the gtk oxygen stuff (2 packages).

[Ken-Bergen]

I've just booted after yesterday's install and I have 26 updates for the barest of bare systems! So, not quite frozen yet.

If I understand correctly Cauldron never freezes, a snapshot is taken and used to build the install media.
It will be the same for Mageia2 release except that a media tree will be built from the snapshot as well as the install media.

[jaywalker]

Thanks for the detailed insight. That looks like a sensible way to go about it. But what do you think happens to the changes accumulating in Cauldron when Beta 1 is let loose? Do we get one big update on its first day out?

[Ken-Bergen]

Thanks for the detailed insight. That looks like a sensible way to go about it. But what do you think happens to the changes accumulating in Cauldron when Beta 1 is let loose? Do we get one big update on its first day out?

Yes.

[jaywalker]

The only reason for doing this "clean" install was to see how many of the bugs I was suffering would just go away, and then see what I could do about the remainder.

The good news is that I don't seem to have caught any new problems. Add to that the failure to boot with "init=/bin/systemd" has fixed itself, after a fashion, The systemd boot is quite a bit slower than without systemd. It looks like it is getting hung up waiting for something to complete and then times-out. Can't be certain if it's an error or some other issue, but I'll investigate the logs to see if I can find a reason. Other problems include open bugs on ntpd with drakclock and diskdrake. The ntpd problem looks like it has gone away, but the acid test will be to enable/disable/re-enable it with drakclock to be absolutely certain the "use ntpd" checkbox continues to truthfully reflect the state of ntpd. [Damn you Gene Roddenberry!]

As for diskdrake, on my first Cauldron disc the tabbed view in the MCC embedded version would not let you click on a partition tab to pick it to the top/make it current. The standalone diskdrake didn't have the problem. Well, yesterday the clean install still had that issue, today, after updates I suppose, it is working normally.

Now the bad news. Showstopper? Only if you intend to install Mageia 2 on an older machine where you need floppy disc support, 'cos guess what; it tries very hard to give the unwary user the impression that floppies don't work.

Although the filemanager (pcmanfm) displays a floppy icon in the same list with other mountable hard drive partitions, and appears to let you mount it from a context menu, or by double-clicking, it won't mount. To double check that I had a viable disc in the drive I mounted it in a root console and browsed it with mc. That was OK.

Here's what I get when I try the normal "dumb user" method;

Code: Select all

Feb 17 00:03:10 Teflon udisks-daemon[766]: **** /proc/self/mountinfo changed
Feb 17 00:03:10 Teflon udisks-daemon[766]: **** MOUNTED /sys/devices/platform/floppy.0/block/fd0
Feb 17 00:03:10 Teflon udisks-daemon[766]: **** CHANGING /sys/devices/platform/floppy.0/block/fd0
Feb 17 00:03:10 Teflon udisks-daemon[766]: **** UPDATING /sys/devices/platform/floppy.0/block/fd0
Feb 17 00:03:10 Teflon udisksd[2354]: Mounted /dev/fd0 (system) at /media/floppy on behalf of uid 501
Feb 17 00:03:10 Teflon udisks-daemon[766]: **** EMITTING CHANGED for /sys/devices/platform/floppy.0/block/fd0
Feb 17 00:03:10 Teflon udisks-daemon[766]: **** NOTE: Force unmounting device /dev/fd0
Feb 17 00:03:10 Teflon udisks-daemon[766]: **** EMITTING JOB-CHANGED for /sys/devices/platform/floppy.0/block/fd0
Feb 17 00:03:10 Teflon udisks-daemon[766]: helper(pid  5661): launched job umount on /dev/fd0
Feb 17 00:03:10 Teflon udisks-daemon[766]: **** CHANGED /sys/devices/platform/floppy.0/block/fd0
Feb 17 00:03:10 Teflon udisks-daemon[766]: **** /proc/self/mountinfo changed
Feb 17 00:03:10 Teflon udisks-daemon[766]: **** UNMOUNTED /sys/devices/platform/floppy.0/block/fd0
Feb 17 00:03:10 Teflon udisks-daemon[766]: **** CHANGING /sys/devices/platform/floppy.0/block/fd0
Feb 17 00:03:10 Teflon udisks-daemon[766]: **** UPDATING /sys/devices/platform/floppy.0/block/fd0
Feb 17 00:03:10 Teflon udisks-daemon[766]: **** EMITTING CHANGED for /sys/devices/platform/floppy.0/block/fd0
Feb 17 00:03:10 Teflon udisks-daemon[766]: **** CHANGED /sys/devices/platform/floppy.0/block/fd0
Feb 17 00:03:10 Teflon udisks-daemon[766]: helper(pid  5661): completed with exit code 0
Feb 17 00:03:10 Teflon udisks-daemon[766]: **** NOTE: Successfully force unmounted device /dev/fd0
Feb 17 00:03:10 Teflon udisks-daemon[766]: **** UPDATING /sys/devices/platform/floppy.0/block/fd0
Feb 17 00:03:10 Teflon udisks-daemon[766]: **** EMITTING JOB-CHANGED for /sys/devices/platform/floppy.0/block/fd0
Feb 17 00:03:10 Teflon udisksd[2354]: Cleaning up mount point /media/floppy (device 2:0 is not mounted)


All that from one attempt! Does anyone know what any of this means? Does it tell anyone what is going wrong for me?

UPDATE
I got a different error after a recent boot (I am switching between the current desktop and rt kernels), but I can't get it again, and now I have no idea what I had booted and how (desktop or rt kernel, with or without systemd);

Code: Select all

Error mounting system-managed device /dev/fd0: Command-line `mount "/media/floppy"' exited with non-zero exit status 32: mount: /dev/fd0 already mounted or /media/floppy busy

That was in a popup error message from pcmanfm (I think) and there was nothing in /var/log/messages.

Richard

[jaywalker]

Some small progress; I have got rid of the error messages (all of them) and I can now mount a floppy in pcmanfm. I can unmount too, though it causes the pcmanfm window to disappear. There is no crash report in /var/log/messages, but it sure feels like a crash. Time for bed now so the short version of the fix is to remove any fd0 lines in /etc/fstab.

I have no idea how it got there, but clearly it's a mistake. No other removable drive has an entry in fstab.

[doktor5000]

I've just booted after yesterday's install and I have 26 updates for the barest of bare systems! So, not quite frozen yet.

If I understand correctly Cauldron never freezes, a snapshot is taken and used to build the install media.
It will be the same for Mageia2 release except that a media tree will be built from the snapshot as well as the install media.

Well, sorta, the cauldron repo is frozen at some point, and then synced to a internal repo for producing the installation images.
It's not a real freeze, but there shouldn't be any big updates in between that timeframe.

[Ken-Bergen]

Well, sorta, the cauldron repo is frozen at some point, and then synced to a internal repo for producing the installation images.
It's not a real freeze, but there shouldn't be any big updates in between that timeframe.

Yes Cauldron would have to be locked while the snapshot is taken but I doubt that it would be noticed by anyone but packagers that would have to wait for a few hours before pushing new rpm's.

[doktor5000]

Well, we are not supposed to make any bigger changes, see for reference: https://www.zarb.org/pipermail/mageia-d ... 11914.html
But naturally packagers have a strong aversion to version freezes, so there will still be some updates slipping this "rule"

[jaywalker]

I have done some poking around to see if I could figure out what mechanism is used to mount the floppy drive, but with no luck yet. It is quite hard for me to follow a logical thread from so many different sources of information and especially so when so much seems contradictory.

For example, sometimes I find /media/floppy but when I mount the drive it appears at /media/disk.
There is a udev rule (50-udev-default.rules) which has:

Code: Select all

# floppy
SUBSYSTEM=="block", KERNEL=="fd[0-9]", GROUP="floppy"


There is another one called 60-floppy.rules which has:

Code: Select all

SUBSYSTEM=="block", KERNEL=="fd[0-9]", ACTION=="add", ATTRS{cmos}=="?*", ENV{CMOS_TYPE}="$attr{cmos}", \
  RUN+="create_floppy_devices -c -t $env{CMOS_TYPE} -m %M -M 0660 -G floppy $root/%k"


and yet another, 69-floppy-acl.rules, which does this:

Code: Select all

KERNEL=="fd[0-9]", ENV{ACL_MANAGE}="1"


That looks interesting as it seems to say that the floppy permissions will be implemented by acl. However, all this is from udev and it is only concerned with the creation of the device node and how it will be accessible. It would seem that the mounting of the drive is firmly under the control of HAL (unless I do it manually).

So how can I influence how HAL is mounting the floppy? It says it is doing it for me (user nnnn) but it is not letting me use it, except for reading. It is also ignoring the group assignment for the /dev/fd0 entry (which is :floppy) so it does me no good to join that group. The /media/disk mount point is root:root, not richard:floppy.

Does anyone know how to beat this system into submission? I just want to be able to click on a floppy drive to mount it, copy some files to it and unmount it. Doesn't seem hard and it is exactly what I would do with a USB stick, so any argument that there is a security reason must be ill thought out. I cannot immediately think of any other valid reason to deny me access to one of my resources, unless it is just an oversight.

Richard

[wobo]

Well, we are not supposed to make any bigger changes, see for reference: https://www.zarb.org/pipermail/mageia-d ... 11914.html
But naturally packagers have a strong aversion to version freezes, so there will still be some updates slipping this "rule"

Of course!
But as I understood this "Freeze" (where "snapshot" may be the better expression) was used for the Beta-1 isos, so
- everything which was introduced in Cauldron after this snapshot will not be in Beta-1.
- people who already installed updates after the snapshot would have to do updates right after installation of Beta-1 to be uptodate.
- you cant use the Beta-1 DVDs for updating an uptodate Cauldron.

Example: There was a kernel panic with the previous kernel - which may be the kernel for Beta-1. The fix (rather workaround") for this bug was found only yesterday, so it will not be in the Beta-1 ISO. Correct or not?