Please bear in mind that simply symlinking/copying /usr/riscv64-linux-
gnu/include/gnu/stubs-lp64d.h as /usr/riscv64-linux-
gnu/include/gnu/stubs-lp64.h does solve the compilation issues.
Right now, and for the past couple of years, people compiling EDK2
projects for RISC-V on Ubuntu (which includ
This is what worked for me, to build x86_32, x86_64, ARM and ARM64 UEFI
drivers from a single Ubuntu 20.04 platform (which is actually an
AppVeyor build environment):
sudo update-alternatives --remove-all gcc
sudo update-alternatives --remove-all g++
sudo update-alternatives --install /usr/bin/gcc
@sudodus, you're right. I just tested the 2020.10.04 daily build and, as
opposed to the beta, it does contain a /efi/ directory at root level
with all the relevant files.
If this is carried out into the release, then, as far as I am concerned,
this bug can be closed.
--
You received this bug not
Any update on this?
As a reminder, ALL that is being asked from this bug is to duplicate the
files and directories currently found in /boot/grub/efi.img to the root
level of the ISO. That's it.
It's a very straightforward fix, and, with the beta now being out, the
need to fix this becomes slightl
Just going to point out that I was NOT talking about limiting file names
to 8.3.
FAT32/vfat does has LFN support, and the UEFI FAT driver supports LFN as
well, so, NO, what I was talking about was not about suddenly asking
distro maintainers to use 8.3 names.
It's only about case sensitivity (sin
Hi Thomas. Glad to see you onboard here as well. ;)
First of all, I guess I should point out that UEFI bootloader boot from
non ESP partitions is hardly a "trick". It is de-facto. That behaviour
comes from the EDK2 source itself and, as my recent dealings with EDK2
indicate (in [1]) that the EDK2/
Public bug reported:
As opposed to 20.04, Groovy Desktop decided to do away with the EFI boot
files that used to reside in `/EFI/BOOT/` on the ISO, and instead moved
them away into a FAT image located at /boot/grub/efi.img.
While this works fine when writing the image in DD mode, it completely
**
Hi Dimitry, I appreciate the reply.
Looks like I stand corrected.
I am finding some evidence, as you indicate, that "writable" has been
previously used independently of casper (with initramfs it seems) as a
label to decide whether a partition should be mounted rw or ro. Maybe I
missed something,
Can someone please look at it with a little bit of urgency?
The release date for 20.04 is approaching fast, and no action means
Ubuntu maintainers are going to do a major disservice to persistence
users, by confusing the persistent landscape further, even as it already
is a complete mess.
The tim
> So is there still a bug with 20.04 as you suggest?
At the time I posted my comment, yes there absolutely was.
A regression had been introduced in the daily 20.04 builds, that made
persistence consistently fail on some machines. This was confirmed by
other people too.
Now, since I added my repo
> Making a Grub2 booter that uses Persistent partitions is not a problem
[if you create 4 partitions in a very specific way and with this
specific file system for the content extracted from the ISO]
I hope you can see the issue with the above because then I could add:
As demonstrated above, makin
Since there has been no follow up from Michael on this critical
question, I have opened a request to drop or alter 'writable' as a new
persitent label in
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1872065.
--
You received this bug notification because you are a member of Ubuntu
Bugs, w
Public bug reported:
This is a follow up on
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1863672 since a
handful of Ubuntu users and software developers do have a valid concern
that a change, that could have very negative consequences, is being
introduced in 20.04 with little or not overs
So it seems our request not to use 'writable' is being ignored still,
and that Ubuntu is just going to go ahead and introduce support for a
completely new label that, not only no other distro appears to be using,
but also nobody has really been asking for:
https://launchpadlibrarian.net/473795039/
> If it ain't broke, don't fix it.
Then that makes 3 of us making that point now. ;)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1863672
Title:
The 'new' persistent live method starting in 19.10
> However home-rw partitions still work when the other persistent
file/partition is named writable.
Again, why would this not work when the other partition is named
'persistence' instead of 'writable'?
I still fail to see the point you are trying to make. Can you please
elaborate on the issue you
I'll let Michael elaborate but I really don't see how that wouldn't
work.
20.04 is introducing *NEW* alternative 'writable' label for persistent
partitions. This is a brand new label that is being introduced.
So my take on this is that, if we are introducing a brand new label for
persistent parti
Completed my testing on the 3 UEFI machines I have that were displaying
the symptoms before (2 intel NUCs and one ASUS based UEFI PCs, ranging
from 2-cores to 6-cores, and ranging from 2010 to 2020), and I am happy
to report that, no matter how many times I boot the system, the 'casper-
rw' labelle
Public bug reported:
The current (2020.04.07) daily build of Ubuntu 20.04 (focal-desktop-
amd64.iso) appears to consistently produce errors on reboot/powerdown
when a partition is in use. Occasionally, power down appears to fail
after these errors are being displayed altogether.
This was tested o
Thanks for the update.
Initial testing seems to indicate that the extra delaying appears to
work, but I still need to check this out a bit more.
I will point out that during one boot (after rebooting the same machine
a few times), I got the following fatal error:
ln: /tmp/mountroot-fail-hooks.d/
Here you go. If you really need the full content of /run let me know.
** Attachment added: "udev-files-nuc10i7-20200406-3.zip"
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1863672/+attachment/5348128/+files/udev-files-nuc10i7-20200406-3.zip
--
You received this bug notification beca
Oh, and since I managed to get one occurrence where persistence worked
with the same drive (all I did was reboot a few times), I'm attaching
the same data from a session where 'casper-rw' was mounted. The most
obvious difference I can see is that this time, udev-ls.txt was not
empty.
** Attachmen
Thanks Michael.
As you know, I would strongly favour reverting the problematic changes
so that everybody has more time to analyse where the issue lies (and
especially why some machines don't seem to be affected), but I think I
made my position clear already so I'll leave you and the release team
d
Hi Michael, thanks for looking into this.
> I don't think anyone can claim with a straight face that casper-rw is
> anything other than opaque.
It is still a lot more searchable than 'writable'. As I explained above,
'writable' yields next to nothing in terms of letting users understand
why a par
Actually, no, the success I got was actually a fluke. This is currently
broken again in 20.04, as per
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1863672.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad
Please do not go to release with this issue!
This is a MAJOR regression compared to 19.10, and considering the amount
of pain the previous persistent issue with LTS has caused (just go to
reddit, superuser or askubuntu and search for "mounting /cow on
/root/cow failed" reports to get an idea of ju
After some additional tests, it seems I was a bit too hasty to declare
that there exists a regression, as, even though a similar error is
displayed as the one from the original bug, the persistent partition
appears to be mounted regardless.
For the record however, `/var/log/boot.log` displays the
Please note that this appears to be broken again in Ubuntu 20.04!
Could the Ubuntu maintainers please treat this bug, which have been very
negatively affecting scores of Ubuntu users a bit more seriously?
By the looks of it, the plight of 18.04 LTS users will continue in 20.04
when it comes to be
> the ones that matter are in the initrd (casper/initrd in this case).
D'oh! Of course they are... The way I was trying to test your changes
was indeed pointless.
> OK, that wasn't so bad:
https://code.launchpad.net/~mwhudson/ubuntu/+source/casper/+git/casper/+merge/370351
Awesome.
I just teste
Thanks for looking into this.
I've been trying to validate the above fix, but I'm still seeing the
same issue. In other words, Ubuntu Live still seems to bail out to the
busybox console as soon as you use add 'persistent' to the Kernel
options.
Here's what I did:
- Extracted the content of
http:
This is a pretty serious and rather obvious bug, once you understand
what's going on.
As pointed out by @DC-THINK, whom I will mostly be paraphrasing here,
the gist of it is: /usr/share/initramfs-tools/scripts/casper-helpers may
unmount a previously mounted device, that it should *NOT* leave
unmou
Rufus developer here. I am indeed seeing sporadic reports from users
running into the bug above after they created installation media from
the Ubuntu ISO (NB: For most UEFI bootable media generation, what Rufus
does is simply copy the ISO content to a FAT32 file system on the USB),
and the root of
Public bug reported:
The GRUB EFI bootloader that is used by the current Ubuntu ISOs only
appears to include support for the FAT/FAT32 and ISO9660 file systems.
This creates issues for people who create USB bootable media from the
ISO and plan to add persistence onto it, as they are only able to
33 matches
Mail list logo
