Bug 27638 - Mageia 7 i586 Live persistent boots OK, but after full update no write access, fail booting. Mageia 8-beta1 i586 Live persistent fails the same way (without updates)
Summary: Mageia 7 i586 Live persistent boots OK, but after full update no write access...
Status: NEW
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: Cauldron
Hardware: All Linux
Priority: Normal major
Target Milestone: ---
Assignee: Martin Whitaker
QA Contact:
URL:
Whiteboard: MGA7TOO
Keywords:
: 27629 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-11-19 23:28 CET by Morgan Leijström
Modified: 2020-11-26 22:30 CET (History)
1 user (show)

See Also:
Source RPM: dracut-050-2.mga8, dracut-046-11.mga7
CVE:
Status comment: mga7 fix: for wiki. mga8 to become OK


Attachments
journalctl -b from failed boot (16.70 KB, application/x-xz)
2020-11-19 23:28 CET, Morgan Leijström
Details
Update for dracut mgalive module (5.24 KB, text/plain)
2020-11-20 02:35 CET, Martin Whitaker
Details

Description Morgan Leijström 2020-11-19 23:28:57 CET
Created attachment 12008 [details]
journalctl -b from failed boot

I made a bootable USB stick with persistence.

It booted OK, but after full update booting visually seem OK with our bubbling logo but ends with black screen and blinking cursor instead of login.

Lots of errors in journal, attached, indicates write problems.


__Machine
IBM Thinkpad T43: one core i586, 2GB RAM


__USB stick
Two different tested see https://bugs.mageia.org/show_bug.cgi?id=27580#c28 the log is from using the fast one.


__Stick content
Mageia 7.1 i586 xfce live, written by isodumper-1.27-1.mga7, with persistence.



__Procedure

1. Let it boot per default, but choose Swedish choices

2. Removed unused localisations per https://wiki.mageia.org/en/Removing_packages#Removing_unused_localisation_and_hardware_support

3. I am pretty sure i tested it rebooted OK

4. Configured wifi, urpmi.removemedia -a, urpmi.addmedia --distrib myfavouritemirror

5. urpmi --auto-up  and confirmed.  No errors.

6. Failed reboot.

7. put in yet a stick and journalctl -b > file_attached_here
Morgan Leijström 2020-11-19 23:30:05 CET

Severity: normal => major
Version: Cauldron => 7

Comment 1 Martin Whitaker 2020-11-20 01:02:51 CET
This is bug 27629. Either a kernel or a systemd update has changed the behaviour of udev, causing the mgalive dracut module to fail to correctly mount the partitions.
Comment 2 Martin Whitaker 2020-11-20 02:35:29 CET
Created attachment 12009 [details]
Update for dracut mgalive module

To fix, select the option to boot using the original kernel (F1 in the GRUB menu). Assuming that works (it should!), copy the attached file to /usr/lib/dracut/modules.d/90mgalive (overwriting the existing file), then run

  dracut -f /boot/initrd-5.7.19-desktop586-3.mga7.img 5.7.19-desktop586-3.mga7
Comment 3 Morgan Leijström 2020-11-20 14:38:41 CET
I will test this.

So this will hit any user who updates their live Mageia 7?

Is it possible to include the fix as an update?
Comment 4 Martin Whitaker 2020-11-20 18:42:34 CET
It will affect anyone updating a 32-bit Live with persistence. Given thelackof complaints, seems like you are the only one!

We could issue an update if there's demand, but I need to get it into cauldron and more widely tested first.
Comment 5 Morgan Leijström 2020-11-20 21:17:56 CET
(In reply to Martin Whitaker from comment #2)
> select the option to boot using the original kernel (F1 in the GRUB
> menu). Assuming that works (it should!)

Unfortunately it just flash a big black square on top of the main screen. There should probably be the alternatives but no text shows up, and it close immediately within a fraction of a second.

I am now renaming the memory directory on the stick to store current status plus try again, this time I will do the modification before reboot.

For them who get stuck in unbootable system, can they press key e in grub and modify boot parameters to boot old kernel?  I can get back and try suggestion by swapping back memory directory.

--------

(In reply to Martin Whitaker from comment #4)
> It will affect anyone updating a 32-bit Live with persistence.

Thanks for info.

> Given the lack of complaints, seems like you are the only one!

We have not advertised it much but i have been putting in wiki here and there lately...
 
> We could issue an update if there's demand, 

If we know how to fix it i will note in wiki how.
I think that is enough for mga7.

> but I need to get it into cauldron and more widely tested first.

Yes, that is the goal :)

And until mga8 is out it would be nice to be able to update the mga 7 live ;)
Comment 6 Lewis Smith 2020-11-20 21:34:29 CET
[Collided]
Thank you Martin for taking this on without being asked.
Changing you from CC to Assigned, hoping you will not mind.

(In reply to Martin Whitaker from comment #1)
> This is bug 27629. Either a kernel or a systemd update has changed the
> behaviour of udev, causing the mgalive dracut module to fail to correctly
> mount the partitions.
Should this bug be marked a duplicate of that one?

(In reply to Martin Whitaker from comment #4)
> It will affect anyone updating a 32-bit Live with persistence. Given
> thelackof complaints, seems like you are the only one!
> We could issue an update if there's demand, but I need to get it into
> cauldron and more widely tested first
If it would apply to Mageia 8, I think we ought to. Morgan will test it...

Assignee: bugsquad => mageia
CC: mageia => lewyssmith

Comment 7 Martin Whitaker 2020-11-20 22:17:53 CET
@Morgan, F1 just toggles which kernel is selected, because there are only two alternatives, "original" and "latest". The current selection is displayed in square brackets, e.g.

  F1: Kernel [original]

Having made your choice, you then need to select the "Boot Mageia Live" menu entry as normal.

You can of course press 'e' to edit the boot command line and change it manually.

I tested the procedure myself, after duplicating the fault, and it worked for me.
Martin Whitaker 2020-11-20 22:42:10 CET

Source RPM: (none) => dracut-050-2.mga8, dracut-046-11.mga7
Version: 7 => Cauldron
Summary: Mageia 7 64 live persistent boots OK, but after full update no write access, fail booting. => Mageia 7 i586 Live persistent boots OK, but after full update no write access, fail booting. Mageia 8-beta1 i586 Live persistent fails the same way (without updates)
Whiteboard: (none) => MGA7TOO

Comment 8 Martin Whitaker 2020-11-20 22:43:40 CET
*** Bug 27629 has been marked as a duplicate of this bug. ***
Comment 9 Morgan Leijström 2020-11-21 23:45:12 CET
* I confirm the solution is working  :) *


> F1 just toggles which kernel is selected

Ah, correct.  That big black flash distracted me.
Thought it was a failed dialogue...


For the rest of instruction, I failed on first attempt.
Then i realised i had to chmod +x the downloaded mgalive-root.sh  :)

I intend to put together a wiki page with tips and tricks on persistent live, and reference it from other wiki pages.  This fix will be there, thanks!

Keep this bug open, and i will post a link to that page for review in a few days.



Of course i will test mga8 lives :)
But i will be a bit less frequent here than i have been this last week.

Status comment: (none) => mga7 fix: for wiki. mga8 to become OK

Comment 10 Morgan Leijström 2020-11-25 03:09:53 CET
Page in progress:
https://wiki.mageia.org/en/User:Morgano/Persistent_live_systems
Comment 11 Morgan Leijström 2020-11-25 03:11:37 CET
Do my tests correspond to known status?:

§ 8b1 64 bit xfce works with persistence with or without encryption.
- is that true also for Plasma and Gnome variants?

§ 8b1 32 bit xfce do not work with persistence at all

§ 7.1 32 and 64 bit works with persistence

§ 7.1 32 bit is the only one that need fixing after updating.


( I also tested 6.1 xfce 32 bit with persistence as i read it works unoficially - do not unmount cleanly but flushed.  But fail on my test.  Dont care. )


-----

As the experts are here I ask:

There are two repositories default registered.  Why?
They seem local and not containing anything?  I can remove packages, but not install anything until i configure other repos.

I suspect they are a redundant relic from classic installer, when they were supposed to point to repos on DVD or USB if plugged in?
Comment 12 Martin Whitaker 2020-11-25 09:59:02 CET
(In reply to Morgan Leijström from comment #11)
> Do my tests correspond to known status?:

Yes, incl. GNOME and Plasma.

> As the experts are here I ask:
> 
> There are two repositories default registered.  Why?
> They seem local and not containing anything?  I can remove packages, but not
> install anything until i configure other repos.

They contain the necessary packages to install proprietary drivers and bootloaders. Try

  urpmq --list -u
Comment 13 Lewis Smith 2020-11-26 19:21:47 CET
I am having second thoughts, seeing the 32-bit problems.

I believe that this affair of Live USB 'persistence' is very voluntary on the part of the two who have worked on it, papoteur & Martin. It is not an integral part of what Mageia is committed to deliver, but a given 'extra'. If it does not work for 32-bit, that is unfortunate; but easy to declare.

> 8b1 64 bit xfce works with persistence with or without encryption.
> - is that true also for Plasma and Gnome variants?
Easy enough (with the experience) to test, but Martin confirms 'yes'.
Comment 14 Morgan Leijström 2020-11-26 21:22:13 CET
Yes.

This persistence is great!

It saves time.  Just not having to select language etc every boot - just plug in the stick, power on, and after a while it is at desktop, autostarted Firefox, and my login to my cloud or other stuff.

The ability to easily save stuff. Encrypted. Incl logs for debug...

Added programs I need

And updated system, browsers and other stuff for security.


Mga8 32 bit problem is presumably fixed fro next ISO spin.
How to fix updated 7.1 32 bit is documented in the wiki page mentioned.
Comment 15 Lewis Smith 2020-11-26 22:19:29 CET
> Mga8 32 bit problem is presumably fixed for next ISO spin
(In reply to Martin Whitaker from comment #4)
> We could issue an update if there's demand, but I need to get it into
> cauldron and more widely tested first.
It is up to Martin whether he applies it to Cauldron; if that is done (please say so here), it should be picked up by anybody doing a NetInstall from there.
Then Morgan can test that.

>How to fix updated 7.1 32-bit is documented in the wiki page mentioned
seems a good outcome.
Comment 16 Morgan Leijström 2020-11-26 22:23:54 CET
I thought he meant to not respin 7.1 32 bit, but get it into cauldron whose 32 bit can not be user repaired.
Comment 17 Martin Whitaker 2020-11-26 22:30:52 CET
Yes, will be fixed in 8-beta2 ISOs.

Note You need to log in before you can comment on or make changes to this bug.