Re: [gentoo-user] Every other startup results in a black screen (possibly SDDM related?)
Hi again, I tried to catch the error again and while doing so I realized you guys are of course correct: sddm usually starts on tty 2. I don't know why I got it into my head that it would start on tty 8. Anyway, when I finally got it to reproduce (took a few restarts) I didn't get a blinking cursor on tty 2, the monitor just goes to sleep (kind of like it does when it has no signal). Switching to tty 1 showed me the init log and let me log on so I could run the commands suggested earlier in this thread: > $ ps aux | grep sddm > root 2253 0.0 0.0 142408 14248 ?Ssl 06:26 0:00 /usr/bin/sddm > root 2300 0.2 0.2 1653332 89588 ? Ssl 06:26 0:00 /usr/bin/X > -nolisten tcp -background none -seat seat0 vt2 -auth /run/sddm/xauth_UanezA > -noreset -displayfd 16 > root 2358 0.0 0.0 61872 14024 ?S06:26 0:00 > /usr/libexec/sddm-helper --socket > /tmp/sddm-auth-49123ec6-075d-4982-860d-ea1de56059ca --id 2 --start > /usr/bin/sddm-greeter --socket /tmp/sddm-:0-emmSdV --user sddm --greeter > sddm 2359 0.0 0.4 1557540 135804 ? Sl 06:26 0:00 > /usr/bin/sddm-greeter --socket /tmp/sddm-:0-emmSdV > sddm 2365 0.0 0.0 4320 1892 ?S06:26 0:00 dbus-launch > --autolaunch d3bb17ba0dc5f70ad177e3f764fe168e --binary-syntax --close-stderr > sddm 2366 0.0 0.0 4620 224 ?Ss 06:26 0:00 > /usr/bin/dbus-daemon --syslog-only --fork --print-pid 5 --print-address 7 > --session > $ rc-service sddm status > * rc-service: service `sddm' does not exist This is what the command yields for a successful startup as well though. Should 'sddm' perhaps be 'display-manager' in the command above? Anyway: > rc-status > Runlevel: default > sysklogd [ started > ] > dhcpcd[ started > ] > dbus [ started > ] > netmount [ started > ] > chronyd [ started > ] > cupsd [ started > ] > switcheroo-control[ started > ] > display-manager [ started > ] > numlock [ started > ] > local [ started > ] > Dynamic Runlevel: hotplugged > Dynamic Runlevel: needed/wanted > display-manager-setup [ started > ] > avahi-daemon [ started > ] > Dynamic Runlevel: manual This is also what it looks like for a successful startup. And finally from /var/log/sddm.log: > [06:26:03.740] (II) DAEMON: Initializing... > [06:26:03.743] (II) DAEMON: Starting... > [06:26:03.743] (II) DAEMON: Logind interface found > [06:26:03.743] (II) DAEMON: Adding new display... > [06:26:03.744] (II) DAEMON: Loaded empty theme configuration > [06:26:03.744] (II) DAEMON: Xauthority path: "/run/sddm/xauth_UanezA" > [06:26:03.744] (II) DAEMON: Using VT 2 > [06:26:03.744] (II) DAEMON: Display server starting... > [06:26:03.744] (II) DAEMON: Writing cookie to "/run/sddm/xauth_UanezA" > [06:26:03.744] (II) DAEMON: Running: /usr/bin/X -nolisten tcp -background > none -seat seat0 vt2 -auth /run/sddm/xauth_UanezA -noreset -displayfd 16 > [06:26:04.993] (II) DAEMON: Setting default cursor > [06:26:05.010] (II) DAEMON: Running display setup script > "/usr/share/sddm/scripts/Xsetup" > [06:26:05.012] (II) DAEMON: Display server started. > [06:26:05.012] (II) DAEMON: Socket server starting... > [06:26:05.012] (II) DAEMON: Socket server started. > [06:26:05.012] (II) DAEMON: Loaded empty theme configuration > [06:26:05.012] (II) DAEMON: Greeter starting... > [06:26:05.022] (II) HELPER: [PAM] Starting... > [06:26:05.022] (II) HELPER: [PAM] Authenticating... > [06:26:05.022] (II) HELPER: [PAM] returning. > [06:26:05.142] (II) HELPER: Writing cookie to "/tmp/xauth_hBdSRs" > [06:26:05.142] (II) HELPER: Starting X11 session: "" "/usr/bin/sddm-greeter > --socket /tmp/sddm-:0-emmSdV" > [06:26:05.152] (II) DAEMON: Greeter session started successfully > [06:26:05.208] (II) DAEMON: Message received from greeter: Connect Regards, Markus On Thu, Apr 4, 2024, at 01:02, Michael wrote: > On Wednesday, 3 April 2024 19:29:11 BST Markus Gustafsson wrote: >> Hi, >> >> I'm having a problem I'm not quite sure how to tackle: every other startup >> or so results in a black screen. Usually nothing gets printed (no bios >> splash, not GRUB menu, no OpenRC prints), and the monitor goes to low power >> mode after a while (I haven't quite confirmed if this is actually the case, >> or if everything happens before my mo
Re: [gentoo-user] Every other startup results in a black screen (possibly SDDM related?)
On Wednesday, 3 April 2024 19:29:11 BST Markus Gustafsson wrote: > Hi, > > I'm having a problem I'm not quite sure how to tackle: every other startup > or so results in a black screen. Usually nothing gets printed (no bios > splash, not GRUB menu, no OpenRC prints), and the monitor goes to low power > mode after a while (I haven't quite confirmed if this is actually the case, > or if everything happens before my monitor have actually stated, but I'd > expect the GRUB menu would hang long enough for it to do so). You can increase the GRUB timeout to a longer interval, but if this an intermittent phenomenon it is probably related to hardware. Check your cable and replace it if possible, or use an alternative port (DP/HDMI/DVI). > However, it does wake up if I switch to another TTY (e.g. ctrl+alt+F4) and > lets me log on, so it has obviously booted up. If I switch back to TTY 8 > from there it just shows a blinking cursor (i.e. not SDDM, which is what > I'd expect). If I reboot from the TTY that lets me log on, the boot process > is usually normal and leaves me at the SDDM login. As others have mentioned sddm now starts in the first available tty, normaly on VT2. However, some users/PCs appear to have problems with more recent sddm versions, whereby the sddm-greeter fails to start, or fails to login into a desktop: https://bugs.gentoo.org/913862 > Any tips on how to debug this would be much appreciated. Check the output on /var/log/ssdm when this problem manifests. signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] System crash on "Detecting C compiler ABI info"
On Wednesday, 3 April 2024 19:20:27 BST Paul Sopka wrote: > On 03.04.24 09:40, Michael wrote: > > In case you haven't done it yet, if you rebuild the toolchain things > > should > > hopefully self-correct on your system: > > > > emerge --sync > > > > emerge -1av sys-devel/binutils > > > > emerge -1av --nodeps sys-devel/gcc > > > > Use 'gcc-config -l' to check you are using the correct gcc version. > > > > emerge -1av sys-libs/glibc > > > > emerge -1av dev-build/libtool > > > > env-update && source /etc/profile > > Good evening Michael > > Thank you for your suggestions, I tried them, but unfortunately it > didn't help. > > Also, i found out that removing CPU_FLAGS_X86 made the issue disappear, > but another issue appeared later. I experience a similar hang, at "-- > Looking for a ASM_NASM compiler". > > Further, compiling GCC throws the following warnings: > > * QA Notice: Installing libtool files (.la) without corresponding > static libraries! > * /usr/libexec/gcc/x86_64-pc-linux-gnu/13/liblto_plugin.la > * QA Notice: Found the following implicit function declarations in > configure logs: > * > /var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-g > nu/32/libgfortran/config.log:4628 - fpsetmask > * > /var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-g > nu/libgfortran/config.log:4536 - fpsetmask > * Check that no features were accidentally disabled. > * See https://wiki.gentoo.org/wiki/Modern_C_porting. > * QA Notice: Package triggers severe warnings which indicate that it > *may exhibit random runtime failures. > * > /var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/gcc-13-20240210/gcc/vec > .h:316: warning: ‘free’ called on unallocated object ‘accesses’ > [-Wfree-nonheap-object] > * > /var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/gcc-13-20240210/gcc/vec > .h:316:10: warning: ‘free’ called on unallocated object ‘dest_bbs’ > [-Wfree-nonheap-object] > * > /var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/gcc-13-20240210/gcc/vec > .h:316: warning: ‘free’ called on unallocated object ‘accesses’ > [-Wfree-nonheap-object] > * > /var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/gcc-13-20240210/gcc/vec > .h:316:10: warning: ‘free’ called on unallocated object ‘dest_bbs’ > [-Wfree-nonheap-object] > * > /var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/gcc-13-20240210/libsani > tizer/hwasan/hwasan.cpp:539:52: warning: format ‘%zd’ expects a matching > ‘signed size_t’ argument > [-Wformat=] > * Please do not file a Gentoo bug and instead report the above QA > * issues directly to the upstream developers of this software. > * Homepage: https://gcc.gnu.org/ > > Is this normal? No, this is not normal. I wonder if your make.conf settings are correct. Start with some safe CFLAGS as suggested here: https://wiki.gentoo.org/wiki/Safe_CFLAGS Then use the package 'app-portage/cpuid2cpuflags' to set the correct CPU flags: https://wiki.gentoo.org/wiki/CPU_FLAGS_* At this point you should be able to use gcc with no further problems. You can try to optimise your settings further by taking a look at suggestions here: https://wiki.gentoo.org/wiki/GCC_optimization signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Every other startup results in a black screen (possibly SDDM related?)
On 03/04/2024 19:53, Jack wrote: Are you certain it hasn't started on some TTY other than 8? I always start out on TTY1, although I start up text only, no SDDM. However, I do have a very vague memory of something similar, and I believe it was that I needed to change one of the kernel FB related settings. Sorry not be have more concrete suggestions. My system isn't configured to switch ttys on - that's something I need to investigate and enable. So sddm always starts on 2, with 1 being the console output. When I switch user, it switches to 1 and starts the new user there. sddm will always start on the first available number, which with no ttys is why it's 2 on my system. Cheers, Wol
Re: [gentoo-user] Every other startup results in a black screen (possibly SDDM related?)
Hoël Bézier wrote: >> However, it does wake up if I switch to another TTY (e.g. >> ctrl+alt+F4) and lets me log on, so it has obviously booted up. If I >> switch back to TTY 8 from there it just shows a blinking cursor (i.e. >> not SDDM, which is what I'd expect). If I reboot from the TTY that >> lets me log on, the boot process is usually normal and leaves me at >> the SDDM login. >> >> Any tips on how to debug this would be much appreciated. > > Since you can switch ttys, this means your computer “properly” booted. > So as far as we know, the only culprit is your login manager which > failed to start, or started improperly. > > For starters you could check, once logged in, if it is actually > running or not. > > ps faux | less > > will output the whole list of processes on your computer, check it to > see if you can find sddm in the list. > If not, then it failed to start, so you want to check if the service > in charge to start it has been run. > > rc-service sddm status # for openrc > systemctl status sddm # for systemd > > These commands should tell you if the process has been started and > failed, or if it never started in the first place. If it started and > failed, search for logs, or even try to start it manually. This will > give you indications as to why it won’t run. > > Otherwise, if it was never run by your service manager, this means > something earlier in the dependency tree failed to run. Same solution > here: search for logs, `rc-status` will give you the list of running > services on your computer and their state for openrc. > > Good luck, > Hoël He could also do a: ps aux | grep sddm and see if it lists it. Replace sddm if using something else. I'm not sure why but sometimes on my system, the GUI part is on 4. I once found it on 2. Most of the time it is on 7 but sometimes, I find it in other places. 4 is the most common alternative. You may want to cycle through ctrl alt F2 through F9 and see if it just parked itself somewhere else for some crazy reason. If you find it moves, we have a common problem. Most often it is on 7 where it should be but sometimes I have to go hunting for the thing. I've often wondered why it was in the wrong place. I just figure as long as I can find it, better not complain to much. LOL Dale :-) :-)
Re: [gentoo-user] Every other startup results in a black screen (possibly SDDM related?)
However, it does wake up if I switch to another TTY (e.g. ctrl+alt+F4) and lets me log on, so it has obviously booted up. If I switch back to TTY 8 from there it just shows a blinking cursor (i.e. not SDDM, which is what I'd expect). If I reboot from the TTY that lets me log on, the boot process is usually normal and leaves me at the SDDM login. Any tips on how to debug this would be much appreciated. Since you can switch ttys, this means your computer “properly” booted. So as far as we know, the only culprit is your login manager which failed to start, or started improperly. For starters you could check, once logged in, if it is actually running or not. ps faux | less will output the whole list of processes on your computer, check it to see if you can find sddm in the list. If not, then it failed to start, so you want to check if the service in charge to start it has been run. rc-service sddm status # for openrc systemctl status sddm # for systemd These commands should tell you if the process has been started and failed, or if it never started in the first place. If it started and failed, search for logs, or even try to start it manually. This will give you indications as to why it won’t run. Otherwise, if it was never run by your service manager, this means something earlier in the dependency tree failed to run. Same solution here: search for logs, `rc-status` will give you the list of running services on your computer and their state for openrc. Good luck, Hoël signature.asc Description: PGP signature
Re: [gentoo-user] Every other startup results in a black screen (possibly SDDM related?)
On 4/3/24 2:29 PM, Markus Gustafsson wrote: Hi, I'm having a problem I'm not quite sure how to tackle: every other startup or so results in a black screen. Usually nothing gets printed (no bios splash, not GRUB menu, no OpenRC prints), and the monitor goes to low power mode after a while (I haven't quite confirmed if this is actually the case, or if everything happens before my monitor have actually stated, but I'd expect the GRUB menu would hang long enough for it to do so). However, it does wake up if I switch to another TTY (e.g. ctrl+alt+F4) and lets me log on, so it has obviously booted up. If I switch back to TTY 8 from there it just shows a blinking cursor (i.e. not SDDM, which is what I'd expect). If I reboot from the TTY that lets me log on, the boot process is usually normal and leaves me at the SDDM login. Any tips on how to debug this would be much appreciated. Are you certain it hasn't started on some TTY other than 8? I always start out on TTY1, although I start up text only, no SDDM. However, I do have a very vague memory of something similar, and I believe it was that I needed to change one of the kernel FB related settings. Sorry not be have more concrete suggestions.
[gentoo-user] Every other startup results in a black screen (possibly SDDM related?)
Hi, I'm having a problem I'm not quite sure how to tackle: every other startup or so results in a black screen. Usually nothing gets printed (no bios splash, not GRUB menu, no OpenRC prints), and the monitor goes to low power mode after a while (I haven't quite confirmed if this is actually the case, or if everything happens before my monitor have actually stated, but I'd expect the GRUB menu would hang long enough for it to do so). However, it does wake up if I switch to another TTY (e.g. ctrl+alt+F4) and lets me log on, so it has obviously booted up. If I switch back to TTY 8 from there it just shows a blinking cursor (i.e. not SDDM, which is what I'd expect). If I reboot from the TTY that lets me log on, the boot process is usually normal and leaves me at the SDDM login. Any tips on how to debug this would be much appreciated. Regards, Markus
Re: [gentoo-user] System crash on "Detecting C compiler ABI info"
On 03.04.24 09:40, Michael wrote: In case you haven't done it yet, if you rebuild the toolchain things should hopefully self-correct on your system: emerge --sync emerge -1av sys-devel/binutils emerge -1av --nodeps sys-devel/gcc Use 'gcc-config -l' to check you are using the correct gcc version. emerge -1av sys-libs/glibc emerge -1av dev-build/libtool env-update && source /etc/profile Good evening Michael Thank you for your suggestions, I tried them, but unfortunately it didn't help. Also, i found out that removing CPU_FLAGS_X86 made the issue disappear, but another issue appeared later. I experience a similar hang, at "-- Looking for a ASM_NASM compiler". Further, compiling GCC throws the following warnings: * QA Notice: Installing libtool files (.la) without corresponding static libraries! * /usr/libexec/gcc/x86_64-pc-linux-gnu/13/liblto_plugin.la * QA Notice: Found the following implicit function declarations in configure logs: * /var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-gnu/32/libgfortran/config.log:4628 - fpsetmask * /var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/build/x86_64-pc-linux-gnu/libgfortran/config.log:4536 - fpsetmask * Check that no features were accidentally disabled. * See https://wiki.gentoo.org/wiki/Modern_C_porting. * QA Notice: Package triggers severe warnings which indicate that it * may exhibit random runtime failures. * /var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/gcc-13-20240210/gcc/vec.h:316: warning: ‘free’ called on unallocated object ‘accesses’ [-Wfree-nonheap-object] * /var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/gcc-13-20240210/gcc/vec.h:316:10: warning: ‘free’ called on unallocated object ‘dest_bbs’ [-Wfree-nonheap-object] * /var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/gcc-13-20240210/gcc/vec.h:316: warning: ‘free’ called on unallocated object ‘accesses’ [-Wfree-nonheap-object] * /var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/gcc-13-20240210/gcc/vec.h:316:10: warning: ‘free’ called on unallocated object ‘dest_bbs’ [-Wfree-nonheap-object] * /var/tmp/portage/sys-devel/gcc-13.2.1_p20240210/work/gcc-13-20240210/libsanitizer/hwasan/hwasan.cpp:539:52: warning: format ‘%zd’ expects a matching ‘signed size_t’ argument [-Wformat=] * Please do not file a Gentoo bug and instead report the above QA * issues directly to the upstream developers of this software. * Homepage: https://gcc.gnu.org/ Is this normal? Hope you all have a nice evening Nanderty
Re: [gentoo-user] Resizing boot partition while dual-booting
Hi Vit I presume you plan to have a single boot partition that will contain your bootloader, kernel and initramfs. There are actually two kinds of boot partitions that are commonly used together: 1. The EFI system partition (ESP) contains Linux and Windows's bootloaders. It's formatted as FAT. 2. The extended boot (XBOOTLDR) partition contains kernels, initramfs's and microcode. It's formatted as anything the bootloader supports (GRUB supports FAT, ext4 and more). If you have a single boot partition, you're actually just combining the above two. If you want to create more room, you can split it: 1. Shrink your Linux partition to create space for the extended boot partition. You can GParted from another system or bootable USB. 2. Create and format the extended boot partition. 3. Modify /etc/fstab so the ESP gets mounted at /efi and the XBOOTLDR gets mounted at /boot. 4. Mount these two partitions. 5. If this is an existing install, move the kernel, initramfs and microcode from /efi to /boot. Otherwise, install the bootloader and the kernel. 6. Re-configure your bootloader (e.g. `grub-mkconfig -o /efi/grub/grub.cfg`). Now the large kernel and initramfs files don't take up space on the ESP that's being shared with Windows. Alternatively, just resize the ESP. However, that breaks Windows's bootloader since the starting point of the C:\ partition moved, so you need to fix it from a Windows setup USB using bootrec. I can't help you with that. Waldo On Wed, Apr 3, 2024 at 5:38 PM Vít Smolík wrote: > Do you store your initramfs on the 100mb partition? Or do you stire it > somewhere else? > > May the Force be with you, > Vít Smolík. > > Dne st 3. 4. 2024 17:35 uživatel Alexis Praga > napsal: > >> Hi Vit, >> >> I have a dual boot with a 100Mb EFI partition. It works fine, except >> there isn’t enough place for both old and new kernels for upgrading. So I >> moved the old kernel from /boot into a safe directory before upgrading. >> Maybe not the best strategy but I didn’t dare resize it. >> >> Alexis >> >> On Wednesday, April 3rd, 2024 at 17:10, Vít Smolík >> wrote: >> >> Hello fellow Gentooers, >> >> I want to dual-boot Gentoo and M$ Windows on my computer, but windows >> only created a 100MB EFI partition. Is it necessary to resize it so my boot >> files will fit? If so - how to resize it so I don't mess up my Windows EFI >> files? >> >> -- >> May the Force be with you, >> Vít Smolík. >> >> >> >>
Re: [gentoo-user] Resizing boot partition while dual-booting
On Wednesday, 3 April 2024 16:10:41 BST Vít Smolík wrote: > Hello fellow Gentooers, > > I want to dual-boot Gentoo and M$ Windows on my computer, but windows only > created a 100MB EFI partition. Is it necessary to resize it so my boot > files will fit? If so - how to resize it so I don't mess up my Windows EFI > files? 100M for boot should be enough. This is what I have on one PC here, where / mnt/Windows is the 100M EFI partition: ~ # du -s -h /mnt/Windows 68M /mnt/Windows ~ # du -s -h /mnt/Windows/EFI/* 1.9M/mnt/Windows/EFI/Boot 36M /mnt/Windows/EFI/Gentoo 27M /mnt/Windows/EFI/Microsoft 4.3M/mnt/Windows/EFI/ubuntu The /EFI/Gentoo directory has two kernels, but no initramfs (I don't use it) and I don't use GRUB either: ~ # ls -la /mnt/Windows/EFI/Gentoo/ total 36381 drwxr-xr-x 2 root root 2048 Jan 26 16:51 . drwxr-xr-x 6 root root 1024 Aug 2 2023 .. -rwxr-xr-x 1 root root 11743360 Dec 13 10:36 bootx64-6.1.67-gentoo.efi -rwxr-xr-x 1 root root 13105984 Feb 18 08:44 bootx64-6.6.13-gentoo.efi -rwxr-xr-x 1 root root 137161 Dec 13 10:36 config-6.1.67-gentoo -rwxr-xr-x 1 root root 140301 Feb 18 08:44 config-6.6.13-gentoo -rwxr-xr-x 1 root root 4615431 Dec 13 10:36 System.map-6.1.67-gentoo -rwxr-xr-x 1 root root 7504974 Feb 18 08:44 System.map-6.6.13-gentoo The /EFI/ubuntu directory has only the GRUB .efi executable in it, because the ubuntu distribution kernel and initramfs is installed in the ubunutu / partition, not in EFI. If you really want to make the EFI partition larger you can use gparted to do this, but you have to be very careful. This is how I have done it whenever I needed to resize Windows partitions: 1. Boot into MSWindows and defragment the drive. Press Shift as you click to shutdown fully the MSWindows OS (to avoid hybrid hybernation). 2. Reboot with gparted Live USB, or with the Gentoo OS. 3. Unmount the EFI partition, if mounted and resize the C:\ drive to make it smaller, in order to release enough space on the right of it, to be able to move it out of the way. Careful you *only* drag the right hand edge of the C: \ partition when you shrink it, toward the left. 3. After you apply the changes move the C:\ partition to the right away from the EFI partition. 4. Apply the change and then resize the EFI partition to a desired size, e.g. 500M. 5. Apply again and next move the C:\ partition to the left. 6. Apply and then resize the C:\ partition to enlarge it. Apply the last change and you're done. NOTE: Do NOT delete any of the MSWindows partitions and do NOT attempt to change their order. If in doubt ask. After you reboot into MSWindows, it will pop up a warning about the C:\ drive filesystem needing checking, click to accept the warning and wait until it finishes checking the filesystem. Enjoy your Gentoo! signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Resizing boot partition while dual-booting
Do you store your initramfs on the 100mb partition? Or do you stire it somewhere else? May the Force be with you, Vít Smolík. Dne st 3. 4. 2024 17:35 uživatel Alexis Praga napsal: > Hi Vit, > > I have a dual boot with a 100Mb EFI partition. It works fine, except there > isn’t enough place for both old and new kernels for upgrading. So I moved > the old kernel from /boot into a safe directory before upgrading. > Maybe not the best strategy but I didn’t dare resize it. > > Alexis > > On Wednesday, April 3rd, 2024 at 17:10, Vít Smolík > wrote: > > Hello fellow Gentooers, > > I want to dual-boot Gentoo and M$ Windows on my computer, but windows only > created a 100MB EFI partition. Is it necessary to resize it so my boot > files will fit? If so - how to resize it so I don't mess up my Windows EFI > files? > > -- > May the Force be with you, > Vít Smolík. > > > >
Re: [gentoo-user] Resizing boot partition while dual-booting
Hi Vit, I have a dual boot with a 100Mb EFI partition. It works fine, except there isn’t enough place for both old and new kernels for upgrading. So I moved the old kernel from /boot into a safe directory before upgrading. Maybe not the best strategy but I didn’t dare resize it. Alexis On Wednesday, April 3rd, 2024 at 17:10, Vít Smolík wrote: > Hello fellow Gentooers, > > I want to dual-boot Gentoo and M$ Windows on my computer, but windows only > created a 100MB EFI partition. Is it necessary to resize it so my boot files > will fit? If so - how to resize it so I don't mess up my Windows EFI files? > > -- > May the Force be with you, > Vít Smolík. > > signature.asc Description: OpenPGP digital signature
[gentoo-user] Resizing boot partition while dual-booting
Hello fellow Gentooers, I want to dual-boot Gentoo and M$ Windows on my computer, but windows only created a 100MB EFI partition. Is it necessary to resize it so my boot files will fit? If so - how to resize it so I don't mess up my Windows EFI files? -- May the Force be with you, Vít Smolík.
Re: [gentoo-user] System crash on "Detecting C compiler ABI info"
I am a html meta data bot The human you are trying to contact is unavailable. The human you are trying to contact is purchasing a product from a grocery business with a credit card with php computer data The human you are trying to contact has been preaching Holy Bible conforming politics for many years The human you are trying to contact is a computer data scientist and has supported numerous computer scientists over the years The human you are contacting has worked as a boxing science instructor as a volunteer Sent: Wednesday, April 03, 2024 at 4:24 PM From: "Paul Sopka" To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] System crash on "Detecting C compiler ABI info" On 02.04.24 21:43, Paul Sopka wrote: > On 02.04.24 20:50, J. Roeleveld wrote: >> Did you upgrade GCC recently? >> If yes, did you follow the gcc-upgrade guide: >> >> https://wiki.gentoo.org/wiki/Upgrading_GCC >> >> ? >> >> -- >> Joost > > Thank you for your answer Joost. > > As far as I know, I didn't upgrade GCC recently. I just rebuilt > libtool to be sure, but that didn't help. > > Nanderty > > I rebuilt with emptytree over night from tty. The system didn't crash, but it hung up at the first program to use this, media-libs/libjpeg-turbo.
Re: [gentoo-user] System crash on "Detecting C compiler ABI info"
On Wednesday, 3 April 2024 06:24:53 BST Paul Sopka wrote: > On 02.04.24 21:43, Paul Sopka wrote: > > On 02.04.24 20:50, J. Roeleveld wrote: > >> Did you upgrade GCC recently? > >> If yes, did you follow the gcc-upgrade guide: > >> > >> https://wiki.gentoo.org/wiki/Upgrading_GCC > >> > >> ? > > > > Thank you for your answer Joost. > > > > As far as I know, I didn't upgrade GCC recently. I just rebuilt > > libtool to be sure, but that didn't help. > > > > Nanderty > > I rebuilt with emptytree over night from tty. The system didn't crash, > but it hung up at the first program to use this, media-libs/libjpeg-turbo. In case you haven't done it yet, if you rebuild the toolchain things should hopefully self-correct on your system: emerge --sync emerge -1av sys-devel/binutils emerge -1av --nodeps sys-devel/gcc Use 'gcc-config -l' to check you are using the correct gcc version. emerge -1av sys-libs/glibc emerge -1av dev-build/libtool env-update && source /etc/profile signature.asc Description: This is a digitally signed message part.